Problem:
sched_fork() has always called scheduler_tick() in some (unlikely)
circumstances in order to update the current task in light of those
circumstances. It has always been the case that the work done by
scheduler_tick() was more than was required to handle the problem in
hand but no harm was done except for the waste of a few CPU cycles.
However, the splitting of scheduler_tick() into two procedures in
2.6.20-rc1 enables the wasted cycles to be saved as the new procedure
task_running_tick() does all the work that is required to rectify the
problem being handled.
Solution:
Replace the call to scheduler_tick() in sched_fork() with a call to
task_running_tick().
Signed-off-by: Peter Williams <pwil3058@bigpond.com.au>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
if CONFIG_CALGARY_IOMMU is built into the kernel via
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT, or is enabled via the
iommu=calgary boot option, then the detect_calgary() function runs to
detect the presence of a Calgary IOMMU.
detect_calgary() first searches the BIOS EBDA area for a "rio_table_hdr"
BIOS table. It has this parsing algorithm for the EBDA:
while (offset) {
...
/* The next offset is stored in the 1st word. 0 means no more */
offset = *((unsigned short *)(ptr + offset));
}
got that? Lets repeat it slowly: we've got a BIOS-supplied data
structure, plus Linux kernel code that will only break out of an
infinite parsing loop once the BIOS gives a zero offset. Ok?
Translation: what an excellent opportunity for BIOS writers to lock up
the Linux boot process in an utterly hard to debug place! Indeed the
BIOS jumped on that opportunity on my box, which has the following EBDA
chaining layout:
384, 65282, 65535, 65535, 65535, 65535, 65535, 65535 ...
see the pattern? So my, definitely non-Calgary system happily locks up
in detect_calgary()!
the patch below fixes the boot hang by trusting the BIOS-supplied data
structure a bit less: the parser always has to make forward progress,
and if it doesnt, we break out of the loop and i get the expected kernel
message:
Calgary: Unable to locate Rio Grande Table in EBDA - bailing!
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Muli Ben-Yehuda <muli@il.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
one of my boxes didnt boot the 2.6.20-rc1-rt0 kernel rpm, it hung during
early bootup. After an hour or two of happy debugging i narrowed it down
to the CALGARY_IOMMU_ENABLED_BY_DEFAULT option, which was freshly added
to 2.6.20 via the x86_64 tree and /enabled by default/.
commit bff6547bb6 claims:
[PATCH] Calgary: allow compiling Calgary in but not using it by default
This patch makes it possible to compile Calgary in but not use it by
default. In this mode, use 'iommu=calgary' to activate it.
but the change does not actually practice it:
config CALGARY_IOMMU_ENABLED_BY_DEFAULT
bool "Should Calgary be enabled by default?"
default y
depends on CALGARY_IOMMU
help
Should Calgary be enabled by default? if you choose 'y', Calgary
will be used (if it exists). If you choose 'n', Calgary will not be
used even if it exists. If you choose 'n' and would like to use
Calgary anyway, pass 'iommu=calgary' on the kernel command line.
If unsure, say Y.
it's both 'default y', and says "If unsure, say Y". Clearly not a typo.
disabling this option makes my box boot again. The patch below fixes the
Kconfig entry. Grumble.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* 'for-linus' of git://brick.kernel.dk/data/git/linux-2.6-block:
[PATCH] block: document io scheduler allow_merge_fn hook
[PATCH] cfq-iosched: don't allow sync merges across queues
[PATCH] Fixup blk_rq_unmap_user() API
[PATCH] __blk_rq_unmap_user() fails to return error
[PATCH] __blk_rq_map_user() doesn't need to grab the queue_lock
[PATCH] Remove queue merging hooks
[PATCH] ->nr_sectors and ->hard_nr_sectors are not used for BLOCK_PC requests
[PATCH] cciss: fix XFER_READ/XFER_WRITE in do_cciss_request
[PATCH] cciss: set default raid level when reading geometry fails
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev:
[libata] sata_svw, sata_vsc: kill iomem warnings
[PATCH] libata: take scmd->cmd_len into account when translating SCSI commands
[PATCH] libata: kill @cdb argument from xlat methods
[PATCH] libata: clean up variable name usage in xlat related functions
[libata] Move some PCI IDs from sata_nv to ahci
[libata] pata_via: suspend/resume support fix
[libata] pata_cs5530: suspend/resume support tweak
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6: (34 commits)
USB Storage: remove duplicate Nokia entry in unusual_devs.h
[PATCH] bluetooth: add support for another Kensington dongle
[PATCH] usb serial: add support for Novatel S720/U720 CDMA/EV-DO modems
[PATCH] USB: Nokia E70 is an unusual device
USB: fix to usbfs_snoop logging of user defined control urbs
USB: at91_udc: Additional checks
USB: at91_udc: Cleanup variables after failure in usb_gadget_register_driver()
USB: at91_udc: allow drivers that support high speed
USB: u132-hcd/ftdi-elan: add support for Option GT 3G Quad card
USB: at91_udc, misc fixes
USB: at91 udc, support at91sam926x addresses
USB: OHCI support for PNX8550
USB: ohci handles hardware faults during root port resets
USB: ohci at91 warning fix
USB: ohci whitespace/comment fixups
USB: MAINTAINERS update, EHCI and OHCI
USB: gadget driver unbind() is optional; section fixes; misc
UHCI: module parameter to ignore overcurrent changes
USB: Nokia E70 is an unusual device
USB AUERSWALD: replace kmalloc+memset with kzalloc
...
Now that iomap merge is close to reality, and since the warnings and
issue have been around so long, we don't need a reminder on every build
that libata needs to be converted over to iomap.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Add USB vendor/device IDs for Novatel Wireless S720 and U720 CDMA/EV-DO
modems to airprime.c.
Signed-off-by: Eric Smith <eric@brouhaha.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=7508
When the Nokia E70 Phone is plugged in to the USB port, I get:
end_request: I/O error, dev sda, sector 1824527
sd 0:0:0:0: SCSI error: return code = 0x10070000
end_request: I/O error, dev sda, sector 1824535
sd 0:0:0:0: SCSI error: return code = 0x10070000
The fix is to add these lines to drivers/usb/storage/unusual_devs.h:
Cc: <honkkis@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
libata depended on SCSI command to have the correct length when
tranlating it into an ATA command. This generally worked for commands
issued by SCSI HLD but user could issue arbitrary broken command using
sg interface.
Also, when building ATAPI command, full command size was always
copied. Because some ATAPI devices needs bytes after CDB cleared, if
upper layer doesn't clear bytes after CDB, such devices will
malfunction. This necessiated recent clear-garbage-after-CDB fix in
sg interfaces. However, scsi_execute() isn't fixed yet and HL-DT-ST
DVD-RAM GSA-H30N malfunctions on initialization commands issued from
SCSI.
This patch makes xlat functions always consider SCSI cmd_len. Each
translation function checks for proper cmd_len and ATAPI translaation
clears bytes after CDB.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Douglas Gilbert <dougg@torque.net>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
xlat function will be updated to consider qc->scsicmd->cmd_len and
many xlat functions deference qc->scsicmd already. It doesn't make
sense to pass qc->scsicmd->cmnd as @cdb separately. Kill the
argument.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Variable names in xlat functions are quite confusing now. 'scsicmd'
is used for CDB while qc->scsicmd points to struct scsi_cmnd while
'cmd' is used for struct scsi_cmnd.
This patch cleans up variable names in xlat functions such that 'scmd'
is used for struct scsi_cmnd and 'cdb' for CDB. Also, 'scmd' local
variable is added if qc->scsicmd is used multiple times.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The content of memory map io of BAR5 have been change from MCP65 then
sata_nv can't work fine on the platform based on MCP65 and MCP67, so move
their IDs from sata_nv.c to ahci.c.
Signed-off-by: Peer Chen <pchen@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Add a prototype for driver_init() in include/linux/device.h.
Also remove a static function of the same name in drivers/acpi/ibm_acpi.c to
ibm_acpi_driver_init() to fix the namespace collision.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since kobject_uevent() function does not return an integer value to
indicate if its operation was completed with success or not, it is worth
changing it in order to report a proper status (success or error) instead
of returning void.
[randy.dunlap@oracle.com: Fix inline kobject functions]
Cc: Mauricio Lin <mauriciolin@gmail.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
With WARN_ON addition to kobject_init()
[ http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/dont-use/broken-out/gregkh-driver-kobject-warn.patch ]
I started seeing following WARNING on CPU offline followed by online on my
x86_64 system.
WARNING at lib/kobject.c:172 kobject_init()
Call Trace:
[<ffffffff8020ab45>] dump_trace+0xaa/0x3ef
[<ffffffff8020aec4>] show_trace+0x3a/0x50
[<ffffffff8020b0f6>] dump_stack+0x15/0x17
[<ffffffff80350abc>] kobject_init+0x3f/0x8a
[<ffffffff80350be1>] kobject_register+0x1a/0x3e
[<ffffffff803bbd89>] sysdev_register+0x5b/0xf9
[<ffffffff80211d0b>] mce_create_device+0x77/0xf4
[<ffffffff80211dc2>] mce_cpu_callback+0x3a/0xe5
[<ffffffff805632fd>] notifier_call_chain+0x26/0x3b
[<ffffffff8023f6f3>] raw_notifier_call_chain+0x9/0xb
[<ffffffff802519bf>] _cpu_up+0xb4/0xdc
[<ffffffff80251a12>] cpu_up+0x2b/0x42
[<ffffffff803bef00>] store_online+0x4a/0x72
[<ffffffff803bb6ce>] sysdev_store+0x24/0x26
[<ffffffff802baaa2>] sysfs_write_file+0xcf/0xfc
[<ffffffff8027fc6f>] vfs_write+0xae/0x154
[<ffffffff80280418>] sys_write+0x47/0x6f
[<ffffffff8020963e>] system_call+0x7e/0x83
DWARF2 unwinder stuck at system_call+0x7e/0x83
Leftover inexact backtrace:
This is a false positive as mce.c is unregistering/registering sysfs
interfaces cleanly on hotplug.
kref_put() and conditional decrement of refcnt seems to be the root cause
for this and the patch below resolves the issue for me.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I'm seeing:
`acpiphp_glue_exit' referenced in section `.init.text' of
drivers/built-in.o: defined in discarded section `.exit.text' of
drivers/built-in.o
when trying to compile an IA64 kernel with PCI hotplug enabled.
I suggest this patch:
Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The struct php_ctlr seems to be only for complicating codes. This
patch removes struct php_ctlr and related codes.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since commit 368c73d4f6 the kernel will try
to update the non-writeable BAR registers 0..3 of PIIX4 IDE adapters if
pci_assign_unassigned_resources() is used to do full resource assignment of
the bus. This fails because in the PIIX4 these BAR registers have
implicitly assumed values and read back as zero; it used to work because
the kernel used to just write zero to that register the read back value did
match what was written.
The fix is a new resource flag IORESOURCE_PCI_FIXED used to mark a resource
as non-movable. This will also be useful to keep other import system
resources from being moved around - for example system consoles on PCI
busses.
[akpm@osdl.org: cleanup]
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I don't see any good reason for exporting device IDs to userspace.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
pci_get_slot() may return NULL if nothing was found. quirk_nvidia_ck804()
does not check the value returned from pci_get_slot(), so it may end up
causing a NULL pointer deref.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is designed to fix:
- Disk eating corruptor on KT7 after resume from RAM
- VIA IRQ handling
- VIA fixups for bus lockups after resume from RAM
The core of this is to add a table of resume fixups run at resume time.
We need to do this for a variety of boards and features, but particularly
we need to do this to get various critical VIA fixups done on resume.
The second part of the problem is to handle VIA IRQ number rules which
are a bit odd and need special handling for PIC interrupts. Various
patches broke various boxes and while this one may not be perfect
(hopefully it is) it ensures the workaround is applied to the right
devices only.
From: Jean Delvare <khali@linux-fr.org>
Now that PCI quirks are replayed on software resume, we can safely
re-enable the Asus SMBus unhiding quirk even when software suspend support
is enabled.
[akpm@osdl.org: fix const warning]
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Only compare the exact HT capability bits against HT_CAPTYPE_IRQ,
this is a little paranoid, but doesn't hurt.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use pci_find_ht_capability() in drivers/pci/quirks.c.
I'm pretty sure the logic is unchanged here, but someone please eye-ball it
for me. I've changed the message to be a little shorter, it's now:
PCI: Found (enabled|disabled) HT MSI mapping on xxxx:xx:xx.x
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add a few #defines for grabbing and working with the address fields
in a HT_CAPTYPE_MSI_MAPPING capability. All from the HT spec v3.00.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use pci_find_ht_capability() in drivers/pci/htirq.c
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are already several places in the kernel that want to search a PCI
device for a given Hypertransport capability. Although this is possible
using pci_find_capability() etc., it makes sense to encapsulate that
logic in a helper - pci_find_ht_capability().
To cater for searching exhaustively for a capability, we also provide
pci_find_next_ht_capability().
We also need to cater for the fact that the HT capability fields may be
either 3 or 5 bits wide. pci_find_ht_capability() deals with this for you,
but callers using the #defines directly must handle that themselves.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The current implementation of __pci_bus_find_cap() does two things,
first it determines the start of the capability chain for the device,
and then it trys to find the requested capability.
Split these out, so that we can use the two parts independantly in
a subsequent patch. Externally visible behaviour should be unchanged.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This works like pci_dev_present but instead of returning boolean returns
the matching pci_device_id entry. This makes it much more useful. Code
bloat is basically nil as the old boolean function is rewritten in terms of
the new one.
This will be used by the updated VIA PCI quirks for one
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The following warning message should not be displayed for devices
which don't use an interrupt pin.
pcie_portdrv_probe->Dev[XXXX:XXXX] has invalid IRQ. Check vendor BIOS
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This janitorial patch removes the following annoying
compile-time message:
drivers/pci/hotplug/rpaphp_slot.c:57: warning: ignoring return
value of sfs_create_file declared with attribute warn_unused_result
It also fixes a typo, removes some misc crud.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: John Rose <johnrose@us.ibm.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Removes redundant check for dev->subordinate; if it is NULL, the function
returns before the patch-affected code region.
Signed-off-by: David Rientjes <rientjes@cs.washington.edu>
Acked-by: Brice Goglin <brice@myri.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
pci: add class codes for Wireless RF controllers
Add PCI codes to include/linux/pci_ids.h for RF controllers; first
batch of these devices seem to be the Ultra-Wide-Band and Wireless USB
controllers (WHCI spec).
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Unfortunately, the .../new_id feature does not work with the 8250_pci
driver.
The reason for this comes down to the way .../new_id is implemented.
When PCI tries to match a driver to a device, it checks the modules
static device ID tables _before_ checking the dynamic new_id tables.
When a driver is capable of matching by ID, and falls back to matching
by class (as 8250_pci does), this makes it absolutely impossible to
specify a board by ID, and as such the correct driver_data value to
use with it.
Let's say you have a serial board with vendor 0x1234 and device 0x5678.
It's class is set to PCI_CLASS_COMMUNICATION_SERIAL.
On boot, this card is matched to the 8250_pci driver, which tries to
probe it because it matched using the class entry. The driver finds
that it is unable to automatically detect the correct settings to use,
so it returns -ENODEV.
You know that the information the driver needs is to match this card
using a device_data value of '7'. So you echo 1234 5678 0 0 0 0 7
into new_id.
The kernel attempts to re-bind 8250_pci to this device. However,
because it scans the PCI driver tables, it _again_ matches the class
entry which has the wrong device_data. It fails.
End of story. You can't support the card without rebuilding the
kernel (or writing a specific PCI probe module to support it.)
So, can we make new_id override the driver-internal PCI ID tables?
IOW, like this:
From: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When sending CONTROL URB's using the usual CONTROL ioctl, logging works
fine, but when sending them via SUBMITURB, like VMWare does, the
control fields are not logged. This patch fixes that.
I didn't see any major changes to devio.c recently, so this patch should apply
cleanly to even the latest kernel. I can resubmit if it doesn't.
From: Chris Frey <cdfrey@foursquare.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch performs additional checks in at91_udc, just in case of
some spurious interrupts or device enumeration.
Signed-off-by: Wojtek Kaniewski <wojtekka@toxygen.net>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch zeroes some variables when usb_gadget_register_driver()
fails. gadgetfs does a dummy registration to get the name of the USB
driver and then waits for user-land driver. If someone plugs the cable
in the meantime, bad things happen, because at91_udc has been left in
inconsistent state.
Signed-off-by: Wojtek Kaniewski <wojtekka@toxygen.net>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
