- 12 7月, 2005 10 次提交
-
-
由 David Shaohua Li 提交于
pci_choose_state() can now call platform_pci_choose_state() and ACPI can answer http://bugzilla.kernel.org/show_bug.cgi?id=4277Signed-off-by: NDavid Shaohua Li <shaohua.li@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 David Shaohua Li 提交于
http://bugzilla.kernel.org/show_bug.cgi?id=4277Signed-off-by: NDavid Shaohua Li <shaohua.li@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 David Shaohua Li 提交于
Implement the framework for binding physical devices with ACPI devices. A physical bus like PCI bus should create a 'acpi_bus_type', with: .find_device: For device which has parent such as normal PCI devices. .find_bridge: It's for special devices, such as PCI root bridge or IDE controller. Such devices generally haven't a parent or ->bus. We use the special method to get an ACPI handle. Uses new field in struct device: firmware_data http://bugzilla.kernel.org/show_bug.cgi?id=4277Signed-off-by: NDavid Shaohua Li <shaohua.li@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Luming Yu 提交于
See Documentation/acpi-hotkey.txt Use cmdline "acpi_specific_hotkey" to enable legacy platform specific drivers. http://bugzilla.kernel.org/show_bug.cgi?id=3887Signed-off-by: NLuming Yu <luming.yu@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 David Shaohua Li 提交于
Drivers should do this: .suspend() pci_disable_device() .resume() pci_enable_device() http://bugzilla.kernel.org/show_bug.cgi?id=3469Signed-off-by: NDavid Shaohua Li <shaohua.li@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 David Shaohua Li 提交于
Delete PCI Interrupt Link Device .resume method -- it is the device driver's job to request interrupts, not the Link's job to remember what the devices want. This addresses the issue of attempting to run the ACPI interpreter too early in resume, when interrupts are still disabled. http://bugzilla.kernel.org/show_bug.cgi?id=3469Signed-off-by: NDavid Shaohua Li <shaohua.li@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexey Starikovskiy 提交于
Register an "acpi" system device to be notified of shutdown preparation. This depends on CONFIG_PM http://bugzilla.kernel.org/show_bug.cgi?id=4041Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Len Brown 提交于
Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexey Starikovskiy 提交于
delete /proc/acpi/button http://bugzilla.kernel.org/show_bug.cgi?id=1920Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Keiichiro Tokunaga 提交于
Signed-off-by: NKeiichiro Tokunaga <tokunaga.keiich@jp.fujitsu.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 18 6月, 2005 1 次提交
-
-
由 Christoph Hellwig 提交于
There are many drivers that have been setting the generic driver model level shutdown callback, and pci thus must not override it. Without this patch we can have really bad data loss on various raid controllers. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 6月, 2005 4 次提交
-
-
由 Kiyoshi Ueda 提交于
__cfq_get_queue(). __cfq_get_queue() finds an existing queue (struct cfq_queue) of the current process for the device and returns it. If it's not found, __cfq_get_queue() creates and returns a new one if __cfq_get_queue() is called with __GFP_WAIT flag, or __cfq_get_queue() returns NULL (this means that get_request() fails) if no __GFP_WAIT flag. On the other hand, in __make_request(), get_request() is called without __GFP_WAIT flag at the first time. Thus, the get_request() fails when there is no existing queue, typically when it's called for the first I/O request of the process to the device. Though it will be followed by get_request_wait() for general case, __make_request() will just end the I/O with an error (EWOULDBLOCK) when the request was for read-ahead. Signed-off-by: NJens Axboe <axboe@suse.de> Signed-off-by: NKiyoshi Ueda <k-ueda@ct.jp.nec.com> Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com>
-
由 Oliver Neukum 提交于
Cc: Greg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Dmitry Torokhov 提交于
It looks like logic for enabling hardware tapping in ALPS driver was inverted and we enable it only if it was already enabled by BIOS or firmware. I have a confirmation from one user that the patch below fixes the problem for him and it might be beneficial if we could get it into 2.6.12. Signed-off-by: NDmitry Torokhov <dtor@mail.ru> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Alexandre Oliva 提交于
This fixed a problem that showed up in the Fedora development tree a few weeks before the Fedora Core 4 release, initially as slab corruption, later as hard crashes on boot up, when slab debugging was disabled for the release. More details on the history at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158424 The problem is caused by sbp2's use of scsi_host->hostdata[0] to hold a scsi_id, without explicitly requesting space for it. Since hostdata is declared as a zero-sized array, we don't get any such space by default, so it must be explicitly requested. The patch below implements just that. Signed-off-by: NAlexandre Oliva <aoliva@redhat.com> Cc: Jody McIntyre <scjody@modernduck.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 16 6月, 2005 2 次提交
-
-
由 Tejun Heo 提交于
__elv_add_request(). rq.count[READ] + rq.count[WRITE] can increase more than one if another thread has allocated a request after the current request is allocated or in_flight could have changed resulting in larger-than-one change of nrq, thus breaking the threshold mechanism. Signed-off-by: NJens Axboe <axboe@suse.de> Signed-off-by: NTejun Heo <htejun@gmail.com>
-
由 Tejun Heo 提交于
nothing. Signed-off-by: NJens Axboe <axboe@suse.de> Signed-off-by: NTejun Heo <htejun@gmail.com>
-
- 14 6月, 2005 5 次提交
-
-
由 Randy Dunlap 提交于
Module needs a license to prevent kernel tainting. Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Markus Lidel 提交于
Fixed freeing of event memory in i2o_block_event() Signed-off-by: NMarkus Lidel <Markus.Lidel@shadowconnect.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jon Smirl 提交于
It prints out x,x instead of x,y. Signed-off-by: NJon Smirl <jonsmirl@gmail.com> Cc: "Antonino A. Daplas" <adaplas@hotpop.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Olof Johansson 提交于
On 64-bit machines, PCI_BASE_ADDRESS_MEM_MASK and other mask constants passed to pci_size() are 64-bit (for example ~0x0fUL). However, pci_size does comparisons between the u32 arguments and the mask, which will fail even though any result from pci_size is still just 32-bit. Changing the mask argument to u32 seems the obvious thing to do, since all arithmetic in the function is 32-bit and having a larger mask makes no sense. This triggered on a PPC64 system here where an adapter (VGA, as it happened) had a memory region base of 0xfe000000 and a sz of the same, matching the if (max == maxbase ...) test at the bottom of pci_size but failing the mask comparison. Quite a corner case which I guess explains why we haven't seen it until now. Signed-off-by: NOlof Johansson <olof@lixom.net> Acked-by: NGreg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Ralf Baechle 提交于
From: Ralf Baechle <ralf@linux-mips.org> There are archives of the old list at http://oss.sgi.com/archives/netdevSigned-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 13 6月, 2005 5 次提交
-
-
由 David Brownell 提交于
This makes the EHCI driver spin a bit longer before concluding that the port reset failed. "Obviously safe." It allows some devices to enumerate that previously didn't. We've seen a bunch of these problem reports recently, this will make some go away. As reported by Michael Zapf <Michael.Zapf@uni-kassel.de>, some EHCI controllers seem to take forever to finish port resets and produce "port N reset error -110" type errors. Spinning a bit longer helps. Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Alan Cox 提交于
The pwc chainsaw session left some setups not working. There is a sanity check on compression buffers that simply isn't right any more as we never allocate one. This doesn't address the email and other changes. I'll do those tomorrow if I get time, but it is the minimal fix for the code and basic feature set. Signed-off-by: NAlan Cox <alan@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Benjamin Herrenschmidt 提交于
The current radeonfb memset's the framebuffer to 0 when loaded. This removes occasional artifacts but has the nasty side effect that if you load radeonfb without framebuffer console, you destroy the VGA text buffer, font, etc... radeon must not touch the framebuffer content when it doesn't "own" it. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Geert Uytterhoeven 提交于
M68k: Mark Sun-3 NCR5380 SCSI broken until NCR5380_abort() and NCR5380_bus_reset() are replaced with real new-style EH routines (the old EH SCSI constants were removed in 2.6.12-rc3). Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Geert Uytterhoeven 提交于
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 10 6月, 2005 5 次提交
-
-
由 Dave Airlie 提交于
This removes a bogus hack from the radeon IRQ handler. There is a better fix from myself and benh in DRM CVS but I'll wait until 2.6.13-rc so it gets more testing. Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Dave Airlie 提交于
Add pci identifier for i945G chipset Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Benjamin Herrenschmidt 提交于
Despite all the care lately in making the powermac sleep/wakeup as robust as possible, there is still a nasty related to the use of cpufreq on PMU based machines. Unfortunately, it affects paulus old powerbook so I have to fix it :) We didn't manage to understand what is precisely going on, it leads to memory corruption and might have to do with RAM not beeing properly refreshed when a cpufreq transition is done right before the sleep. The best workaround (and less intrusive at this point) we could come up with is included in this patch. We basically do _not_ force a switch to high speed on suspend anymore (that is what is causing the problem) on those machines. We still force a speed switch on wakeup (since we don't know what speed we are coming back from sleep at, and that seems to work fine). Since, during this short interval, the actual CPU speed might be incorrect, we also hack around by multiplying loops_per_jiffy by 2 (max speed factor on those machines) during early wakeup stage to make sure udelay's during that time aren't too short. For after 2.6.12, we'll change udelay implementation to use the CPU timebase (which is always constant) instead like we do on ppc64 and thus get rid of all those problems. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Michael Ellerman 提交于
My patch from a few weeks back (now in mainline), called "Cleanup skbs to prevent unregister_netdevice() hanging", can cause our TX timeout code to fire on machines with lots of VLANs (because it takes > 2 seconds between when we stop the queues and when we're finished stopping the connections). When that happens the TX timeout code freaks out and does a WARN_ON() because as far as it's concerned there shouldn't be a TX timeout happening, which is fair enough. I have a "proper" fix for this, which is to a) do refcounting on connections and b) implement a proper ack timer so we don't keep unacked skbs lying around for ever. But for 2.6.12 I propose just supressing the WARN_ON(). Users will still see the "NETDEV WATCHDOG" warning, but that's not nearly as bad as a WARN_ON() which users interpret as an Oops. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Narendra Sankar 提交于
MSI functionality is broken on the GC_LE x86 chipset that Serverworks developed and that is being used in various platforms today. Broadcom is going to push out to the kernel MSI enabled Gigabit drivers (in the very near future), and we would like to make sure that MSI does not get enabled on any platforms using the GC_LE chipset (device id 0x17). Following the AMD 8131 example, I am including a patch to disable MSI functionality when a GCNB_LE is detected. Please let me know if there are any issues with this. This is a permanent fix for this chipset, as the hardware will not be updated. Signed-off-by: NNarendra Sankar <nsankar@broadcom.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 09 6月, 2005 8 次提交
-
-
由 Ian Abbott 提交于
ftdi_sio: Avoid losing bytes at tty-ldisc. This patch was originally developed by Daniel Smertnig. I (Ian Abbott) made a few changes. It has been tested by both Daniel and I, at least for raw, non-canonical receive data processing. Here is Daniel's original description of the patch: === During a project in which I was using a FTDI 232BM to transmit data at relative high speeds (625kBit/s), I noticed a problem where data was lost even if flow control was enabled: The FTDI-Driver receives 512 Bytes of data over USB at a time, which consists of 8 64-Byte packets. Subtracting the 2 bytes of status information included in each packet this gives 496 "real" data bytes per read. This data is passed (indirectly, via the flip buffers) to the tty line discipline which takes care of throttling when there the free buffer space reaches TTY_THRESHOLD_THROTTLE (128). Because the FTDI driver processes up to 496 bytes at a time, throttling won't happen in time and the line discipline will discard the remaining bytes. To avoid this the patch passes data in 62-byte blocks to the tty layer and checks the available space in the ldisc-buffers. If there isn't enough free space, processing the rest of the data is delayed using a workqueue. Note: The original problem should be easily reproducible with a userspace program which does slow & small reads. === Signed-off-by: NIan Abbott <abbotti@mev.co.uk> Signed-off-by: NDaniel Smertnig <daniel.smertnig@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Pete Zaitcev 提交于
This smoothes two imperfections: - Increase number of LUNs per device from 4 to 9. The best solution would be to remove this limit altogether, but that has to wait until the time when more than 26 hosts are allowed. - Replace mdelay with msleep in a probing routine. Signed-off-by: NPete Zaitcev <zaitcev@yahoo.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Scott Murray 提交于
Here's a patch that fixes up the pci_dev refcounting in the CPCI code. I've done some testing against it and it seems fine here. Signed-off-by: NScott Murray <scottm@somanetworks.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Albert Lee 提交于
Problem: Incorrect md5sum when using ATAPI PIO mode to verify a distro CD. Root cause: sg traverse problem. In __atapi_pio_bytes(), if qc->cursg++ is increased and "goto next_page" is executed, then sg is not updated to the new qc->cursg and the old sg is overwritten with the new data. Changes: - Replace "goto next_page" with "goto next_sg" to make sg updated. Signed-off-by: NAlbert Lee <albertcc@tw.ibm.com>
-
由 Jens Axboe 提交于
Correct this. diff --git a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c
-
由 Lars Marowsky-Bree 提交于
READA errors failing with EWOULDBLOCK/EAGAIN do not constitute a valid reason for failing the path; this lead to erratic errors on DM multipath devices. This error can be safely propagated upwards without failing the path. Acked-by: NKevin Corry <kevcorry@us.ibm.com> Acked-by: NJens Axboe <axboe@suse.de> Signed-off-by: NLars Marowsky-Bree <lmb@suse.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
Fix 5700/5701 DMA write corruption on Apple G4 by detecting the Apple UniNorth PCI 1.5 chipset and adjusting the DMA write boundary to 16. DMA test fails to detect the problem with this chipset. Thanks to Manuel Perez Ayala for reporting the problem and helping to debug it. Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-