Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 07 3月, 2007 1 次提交
  3. 05 3月, 2007 1 次提交
  5. 24 2月, 2007 1 次提交
    • A
      USB: make autosuspend delay a module parameter · b5e795f8
      由 Alan Stern 提交于 
      This patch (as859) makes the default USB autosuspend delay a module
parameter of usbcore.  By setting the delay value at boot time, users
will be able to prevent the system from autosuspending devices which
for some reason can't handle it.

The patch also stores the autosuspend delay as a per-device value.  A
later patch will allow the user to change the value, tailoring the
delay for each individual device.  A delay value of 0 will prevent
autosuspend.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b5e795f8
  7. 18 2月, 2007 1 次提交
  9. 17 2月, 2007 4 次提交
  11. 13 2月, 2007 2 次提交
  13. 12 2月, 2007 1 次提交
  15. 21 12月, 2006 1 次提交
    • A
      UHCI: module parameter to ignore overcurrent changes · 5f8364b7
      由 Alan Stern 提交于 
      Certain boards seem to like to issue false overcurrent notifications,
for example on ports that don't have anything connected to them.  This
looks like a hardware error, at the level of noise to those ports'
overcurrent input signals (or non-debounced VBUS comparators).  This
surfaces to users as truly massive amounts of syslog spam from khubd
(which is appropriate for real hardware problems, except for the
volume from multiple ports).

Using this new "ignore_oc" flag helps such systems work more sanely,
by preventing such indications from getting to khubd (and spamming
syslog).  The downside is of course that true overcurrent errors will
be masked; they'll appear as spontaneous disconnects, without the
diagnostics that will let users troubleshoot issues like
short-circuited cables.  In addition, controllers with no devices
attached will be forced to poll for new devices rather than relying on
interrupts, since each overcurrent event would generate a new
interrupt.

This patch (as826) is essentially a copy of David Brownell's ignore_oc
patch for ehci-hcd, ported to uhci-hcd.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5f8364b7
  17. 14 12月, 2006 1 次提交
  19. 09 12月, 2006 1 次提交
    • A
      [PATCH] fault injection: documentation and scripts · de1ba09b
      由 Akinobu Mita 提交于 
      This patch set provides some fault-injection capabilities.

- kmalloc() failures

- alloc_pages() failures

- disk IO errors

We can see what really happens if those failures happen.

In order to enable these fault-injection capabilities:

1. Enable relevant config options (CONFIG_FAILSLAB, CONFIG_PAGE_ALLOC,
   CONFIG_MAKE_REQUEST) and if you want to configure them via debugfs,
   enable CONFIG_FAULT_INJECTION_DEBUG_FS.

2. Build and boot with this kernel

3. Configure fault-injection capabilities behavior by boot option or debugfs

   - Boot option

     failslab=
     fail_page_alloc=
     fail_make_request=

   - Debugfs

     /debug/failslab/*
     /debug/fail_page_alloc/*
     /debug/fail_make_request/*

   Please refer to the Documentation/fault-injection/fault-injection.txt
   for details.

4. See what really happens.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NDon Mullis <dwm@meer.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      de1ba09b
  21. 08 12月, 2006 5 次提交
    • I
      [PATCH] add ignore_loglevel boot option · 79290822
      由 Ingo Molnar 提交于 
      Sometimes the kernel prints something interesting while userspace bootup
keeps messages turned off via loglevel.  Enable the printing of /all/
kernel messages via the "ignore_loglevel" boot option.  Off by default.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      79290822
    • I
      [PATCH] sleep profiling · ece8a684
      由 Ingo Molnar 提交于 
      Implement prof=sleep profiling.  TASK_UNINTERRUPTIBLE sleeps will be taken
as a profile hit, and every millisecond spent sleeping causes a profile-hit
for the call site that initiated the sleep.

Sample readprofile output on i386:

   306 ps2_sendbyte                               1.3973
   432 call_usermodehelper_keys                   1.9548
   484 ps2_command                                0.6453
   790 __driver_attach                            4.7879
  1593 msleep                                    44.2500
  3976 sync_buffer                               64.1290
  4076 do_lookup                                 12.4648
  8587 sync_page                                122.6714
 20820 total                                      0.0067

(NOTE: architectures need to check whether get_wchan() can be called from
deep within the wakeup path.)

akpm: we need to mark more functions __sched.  lock_sock(), msleep(), others..

akpm: the contention in do_lookup() is a surprise.  Presumably doing disk
reads for directory contents while holding i_mutex.

[akpm@osdl.org: various fixes]
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ece8a684
    • D
      [PATCH] get_options to allow a hypenated range for isolcpus · 22f2e280
      由 Derek Fults 提交于 
      This allows a hyphenated range of positive numbers in the string passed
to command line helper function, get_options.

Currently the command line option "isolcpus=" takes as its argument a
list of cpus.

Format: <cpu number>,...,<cpu number>
Valid values of <cpu_number>  include all cpus, 0 to "number of CPUs in
system - 1". This can get extremely long when isolating the majority of
cpus on a large system.  The kernel isolcpus code would not need any
changing to use this feature.  To use it, the change would be in the
command line format for 'isolcpus='
Format:
<cpu number>,...,<cpu number>
or
<cpu number>-<cpu number>  (must be a positive range in ascending
order.)
or a mixture
<cpu number>,...,<cpu number>-<cpu number>
Signed-off-by: NDerek Fults <dfults@sgi.com>
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      22f2e280
    • R
      [PATCH] swsusp: document support for swap files · ecbd0da1
      由 Rafael J. Wysocki 提交于 
      Document the "resume_offset=" command line parameter as well as the way in
which swap files are supported by swsusp.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ecbd0da1
    • P
      [PATCH] mm: add noaliencache boot option to disable numa alien caches · 3395ee05
      由 Paul Menage 提交于 
      When using numa=fake on non-NUMA hardware there is no benefit to having the
alien caches, and they consume much memory.

Add a kernel boot option to disable them.

Christoph sayeth "This is good to have even on large NUMA.  The problem is
that the alien caches grow by the square of the size of the system in terms of
nodes."

Cc: Christoph Lameter <clameter@engr.sgi.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3395ee05
  23. 07 12月, 2006 2 次提交
  25. 04 12月, 2006 1 次提交
  27. 14 11月, 2006 1 次提交
    • A
      [PATCH] x86: Add acpi_user_timer_override option for Asus boards · fa18f477
      由 Andi Kleen 提交于 
      Timer overrides are normally disabled on Nvidia board because
they are commonly wrong, except on new ones with HPET support.
Unfortunately there are quite some Asus boards around that
don't have HPET, but need a timer override.

We don't know yet how to handle this transparently,
but at least add a command line option to force the timer override
and let them boot.

Cc: len.brown@intel.com
Signed-off-by: NAndi Kleen <ak@suse.de>
      fa18f477
  29. 19 10月, 2006 1 次提交
    • M
      PCI: optionally sort device lists breadth-first · 6b4b78fe
      由 Matt Domsch 提交于 
      Problem:
New Dell PowerEdge servers have 2 embedded ethernet ports, which are
labeled NIC1 and NIC2 on the chassis, in the BIOS setup screens, and
in the printed documentation.  Assuming no other add-in ethernet ports
in the system, Linux 2.4 kernels name these eth0 and eth1
respectively.  Many people have come to expect this naming.  Linux 2.6
kernels name these eth1 and eth0 respectively (backwards from
expectations).  I also have reports that various Sun and HP servers
have similar behavior.


Root cause:
Linux 2.4 kernels walk the pci_devices list, which happens to be
sorted in breadth-first order (or pcbios_find_device order on i386,
which most often is breadth-first also).  2.6 kernels have both the
pci_devices list and the pci_bus_type.klist_devices list, the latter
is what is walked at driver load time to match the pci_id tables; this
klist happens to be in depth-first order.

On systems where, for physical routing reasons, NIC1 appears on a
lower bus number than NIC2, but NIC2's bridge is discovered first in
the depth-first ordering, NIC2 will be discovered before NIC1.  If the
list were sorted breadth-first, NIC1 would be discovered before NIC2.

A PowerEdge 1955 system has the following topology which easily
exhibits the difference between depth-first and breadth-first device
lists.

-[0000:00]-+-00.0  Intel Corporation 5000P Chipset Memory Controller Hub
           +-02.0-[0000:03-08]--+-00.0-[0000:04-07]--+-00.0-[0000:05-06]----00.0-[0000:06]----00.0  Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC2, 2.4 kernel name eth1, 2.6 kernel name eth0)
           +-1c.0-[0000:01-02]----00.0-[0000:02]----00.0  Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC1, 2.4 kernel name eth0, 2.6 kernel name eth1)


Other factors, such as device driver load order and the presence of
PCI slots at various points in the bus hierarchy further complicate
this problem; I'm not trying to solve those here, just restore the
device order, and thus basic behavior, that 2.4 kernels had.


Solution:

The solution can come in multiple steps.

Suggested fix #1: kernel
Patch below optionally sorts the two device lists into breadth-first
ordering to maintain compatibility with 2.4 kernels.  It adds two new
command line options:
  pci=bfsort
  pci=nobfsort
to force the sort order, or not, as you wish.  It also adds DMI checks
for the specific Dell systems which exhibit "backwards" ordering, to
make them "right".


Suggested fix #2: udev rules from userland
Many people also have the expectation that embedded NICs are always
discovered before add-in NICs (which this patch does not try to do).
Using the PCI IRQ Routing Table provided by system BIOS, it's easy to
determine which PCI devices are embedded, or if add-in, which PCI slot
they're in.  I'm working on a tool that would allow udev to name
ethernet devices in ascending embedded, slot 1 .. slot N order,
subsort by PCI bus/dev/fn breadth-first.  It'll be possible to use it
independent of udev as well for those distributions that don't use
udev in their installers.

Suggested fix #3: system board routing rules
One can constrain the system board layout to put NIC1 ahead of NIC2
regardless of breadth-first or depth-first discovery order.  This adds
a significant level of complexity to board routing, and may not be
possible in all instances (witness the above systems from several
major manufacturers).  I don't want to encourage this particular train
of thought too far, at the expense of not doing #1 or #2 above.


Feedback appreciated.  Patch tested on a Dell PowerEdge 1955 blade
with 2.6.18.

You'll also note I took some liberty and temporarily break the klist
abstraction to simplify and speed up the sort algorithm.  I think
that's both safe and appropriate in this instance.
Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6b4b78fe
  31. 12 10月, 2006 1 次提交
    • M
      [SCSI] Add ability to scan scsi busses asynchronously · 3e082a91
      由 Matthew Wilcox 提交于 
      Since it often takes around 20-30 seconds to scan a scsi bus, it's
highly advantageous to do this in parallel with other things.  The bulk
of this patch is ensuring that devices don't change numbering, and that
all devices are discovered prior to trying to start init.  For those
who build SCSI as modules, there's a new scsi_wait_scan module that will
ensure all bus scans are finished.

This patch only handles drivers which call scsi_scan_host.  Fibre Channel,
SAS, SATA, USB and Firewire all need additional work.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      3e082a91
  33. 04 10月, 2006 5 次提交
  35. 30 9月, 2006 2 次提交
  37. 27 9月, 2006 2 次提交
  39. 26 9月, 2006 2 次提交
  41. 19 9月, 2006 1 次提交
    • L
      Revert mmiocfg heuristics and blacklist changes · 79e453d4
      由 Linus Torvalds 提交于 
      This reverts commits 11012d41 and
40dd2d20, which allowed us to use the
MMIO accesses for PCI config cycles even without the area being marked
reserved in the e820 memory tables.

Those changes were needed for EFI-environment Intel macs, but broke some
newer Intel 965 boards, so for now it's better to revert to our old
2.6.17 behaviour and at least avoid introducing any new breakage.

Andi Kleen has a set of patches that work with both EFI and the broken
Intel 965 boards, which will be applied once they get wider testing.

Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Edgar Hucek <hostmaster@ed-soft.at>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      79e453d4
  43. 18 9月, 2006 1 次提交
  45. 31 8月, 2006 1 次提交
  47. 01 8月, 2006 1 次提交