- 07 Dec, 2004 40 commits
-
-
Linus Torvalds authored
The real bug was in the debugging code, not the actual domain data structure setup. Cset exclude: sivanich@sgi.com[torvalds]|ChangeSet|20041207160443|30564
-
bk://kernel.bkbits.net/davem/net-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Patrick McHardy authored
The problem is in tcf_action_copy_stats, it assumes a->priv has the same layout as struct tcf_act_hdr, which is not true for struct tcf_police. This patch rearranges struct tcf_police to match tcf_act_hdr. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Mitchell Blank Jr. authored
Signed-off-by:
Mitchell Blank Jr <mitch@sfgoth.com> Signed-off-by:
-
David S. Miller authored
into nuts.davemloft.net:/disk1/BK/sparc-2.6
-
bk://gkernel.bkbits.net/libata-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Douglas Gilbert authored
I have some code (in sginfo) that requests the first 4 bytes of SCSI INQUIRY VPD pages to get their length then asks for that exact length in a follow up request to fetch the payload. Just like I saw with 36 byte standard INQUIRYs (no fixed) I get a buffer full or zeroes. BTW SCSI standards dictate that in situations where the allocation length (in the cdb) is less than what is needed that what can be sent shall be sent (i.e. truncated and without any error indication or modification to the part of the response returned). In other words it is up the the application client to take remedial action. Changelog: - fix off-by-1 allocation length issue with SCSI INQUIRY VPD pages 0x80 and 0x83 Signed-off-by:Jeff Garzik <jgarzik@pobox.com>
-
Jeff Garzik authored
libata made the assumption that (for PIO commands in this case) it could modify DMA memory at the kernel-virtual address, after mapping this. This is incorrect, and fails on e.g. platforms that copy DMA memory back and forth (swiotlb on Intel EM64T and IA64). Remove this assumption by ensuring that we only call the DMA mapping routines if we really are going to use DMA for data xfer. Also: remove a bogus WARN_ON() in ata_sg_init_one() which caused bug reports (but no problems).
-
Linus Torvalds authored
They turn out to be buggy, and result in the same filename being reported twice when htree directory indexing is enabled. Thanks for Kris Karas for helping chase it down. Also reported by Holger Kiehl. Cset exclude: akpm@osdl.org[torvalds]|ChangeSet|20041108040801|49372
-
Gerd Knorr authored
The new "simpler" opmode added by the recent merge from ivtv breaks msp3400 support for other tv cards. Not figured yet why. This patch disables the "simpler" mode by default (can still be enabled by insmod option) as quick fix for 2.6.10. Signed-off-by:
Gerd Knorr <kraxel@bytesex.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Michael Hunold authored
- [DVB] dvb-ttpci, budget: updated to fix problems with some CAMs on KNC1 cards - [DVB] dvb-ttpci, budget: make needlessly global code static, whitespace and newline cleanups, thanks to Adrian Bunk <bunk@stusta.de> - [DVB] dvb-ttpci, budget: follow frontend changes in driver - [DVB] dvb-ttpci, budget: fix drivers to use new wait_for_debi_done(...,nobusywait) routine. Signed-off-by:
Michael Hunold <hunold@linuxtv.org> Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Michael Hunold authored
- [DVB] remove obsolete grundig_29504-401, grundig_29504-491, alps_tdlb7 and alps_tdmb7 frontend drivers - [DVB] remove sp887x firmware file, it's unused thanks to firmware_class Signed-off-by:
-
Michael Hunold authored
- [DVB] dvb-core: follow Linux coding style, kill dvb_ksyms.c and move the EXPORT_SYMBOLs to the files where the functions are, thanks to Adrian Bunk <bunk@stusta.de> - [DVB] dvb-core: #if 0'ing unused code, make needlessly global code static, whitespace and newline cleanups, thanks to Adrian Bunk <bunk@stusta.de> - [DVB] dvb_ca_en50221.c: support for KNC1/Cinergy CI modules, fix segfaults, enhanced poll_slot_status to support non-IRQ interfaces, Fix module usage count problem - [DVB] dvb-frontend.c: core changes to support the refactorized frontend drivers Signed-off-by:
-
Michael Hunold authored
- [DVB] dibusb: added remote control event handling, thanks to David Matthews. - [DVB] dibusb: added support for special Artec devices (with AN2235 usb controller) - [DVB] dibusb: enable several new devices (even the broken Artec T1) - [DVB] dibusb: #if 0'ing unused code - [DVB] dibusb: follow frontend changes Signed-off-by:
-
Michael Hunold authored
- [DVB] cinergyT2: update driver to exploit hardware capabilities Signed-off-by:
-
Michael Hunold authored
- [DVB] dvb-ttusb-dec, dvb-ttusb-budget, skystar2, bt878 + dvb-bt8xx: follow frontend changes in driver - [DVB] DST isn't a real frontend, it's an interface to a frontend microcontroller, so move the hardware dependend stuff to the right place Signed-off-by:
-
Michael Hunold authored
- [DVB] saa7146_core.c, saa7146_video.c: MODULE_PARM -> module_param, added non-busy waiting option for saa7146_wait_for_debi_done(), make needlessly global code static and remove unused code (thanks to Adrian Bunk <bunk@stusta.de) - [DVB] saa7146_core.c: dev is kmalloc'ed twice, add missing pci_disable_device(), rename goto labels, propagate the error code from the underlying layers when possible, pci_request_region replaces request_mem_region, other minor cleanups (thanks to Francois Romieu) - [DVB] saa7146_fops.c, saa7146_i2c.c, saa7146_hlp.c, saa7146_vbi.c: make needlessly global code static, remove unused code (thanks to Adrian Bunk <bunk@stusta.de>) Signed-off-by:
-
Michael Hunold authored
- [DVB] reafactor or add the following frontend drivers: at76c651, cx22700, ves1x93, ves1820, tda80xx, tda8083, cx22702, tda1004x, tda10021, cx24110, dvb_dummy_fe, l64781, mt312, mt352, stv0299, sp887x, stv0297, nxt6000, sp8870 - [DVB] remove dib3000mb from frontends, it's handled by the hw dependent driver now Signed-off-by:
-
Michael Hunold authored
- [DVB] get_dvb_firmware: rework to reflect new frontend design, added additional firmware location - [DVB] Kconfig and Makefile changes all over the place, remove Makefile.lib Signed-off-by:
-
Michael Hunold authored
Start of a big DVB update. The reasons for revamping the DVB frontend architecture: Just as analog TV cards, DVB cards need some sort of tuner to tune to the desired frequency of the digital transponder. Tuning alone doesn't give you a digital DVB datastream, however, you need a demodulator as well. The combination of tuner and demodulator is called frontend in the DVB world. Tuner and demodulator are both accessed via the serial i2c bus on all DVB cards out there. So, technically a frontend consists of two i2c helper chipsets. In former times when there was only a handful of different DVB cards, the frontend was encapsulated in one tin box. Some people had the idea that there should be one "frontend driver" instead of dedicated tuner and demodulator drivers. A bad idea. As time went on, different manufacturers used the same tuner and demodulator combination, but used a different wiring for the tuner or did other technical changes. The only possibility to support different cards with one combined frontend driver was to add hardware dependent tuner code inside the generic i2c frontend drivers. Yuck. So there was a need for communication between the i2c frontend driver and the hardware depenedent driver, for example to exchange initialization code for the tuner. Unfortunately, the i2c infrastructure is one way, from the i2c client to the i2c adapter using a non-typesafe ioctl() like interface, which is ugly by itself. Greg K-H and others refused the idea to add an iotctl() like interface from the i2c adapter to the i2c client and instead proposed to use a typesafe interface instead. We all agreed with that. The existing i2c infrastructure heavily depends on the probing facility, ie. clients probe for their existence on i2c busses. This is dumb for most i2c busses out there that sit on dedicated hardware. A DVB card is uniquely identified with pci or usb subvendor and subsystem ids, so on that particular bus we exactly *know* which kinds of i2c helper chipsets sit on there. Up to now this wasn't a problem, because we could fix all conflicts manually until half a year ago. By that date, we found two different DVB designs which used different demodulators that unfortunately use the same i2c address and which cannot be distinguished by hardware tricks (ie. different number of registers, some fixed hw dependent register,...) Getting a usable DVB card depended on the load order of the modules, because the i2c core probed the demodulator drivers one after another and the first one won the race. Compiling all drivers statically into the kernel resulted in non-working cards. Our solution is as follows: we agreed to keep the basic underlying kernel i2c infrastructure, but we decided not to register our bussed and chipsets to the kernel i2c "probing" infrastructure. Instead, we killed the tuner parts of the frontend drivers and put them into the dedicated hardware drivers (this is were they technically belong, they are highly hardware dependent) and we changed the frontend drivers to pure demodulator drivers (which are hardware independend). There is now a type-safe functional dependency between the drivers and the demodulator drivers, the drivers explicitely ask the demodulator drivers to attach to their i2c bus. The only negative aspect of that approach is that for some hardware there are now more dependencies to demodulator drivers than needed, ie. a small amount of memory is wasted. This patch: - [DVB] cards.txt: added the USB devices to the card-list - [DVB] README.dibusb: follow changes in dibusb-driver Signed-off-by:
-
Linus Torvalds authored
Heh. usually these come through Andrew, but this time it was all me. Noted by BenH. Cset exclude: paulus@samba.org[torvalds]|ChangeSet|20041207181541|44524
-
Andries E. Brouwer authored
In 2.6.8 the code for the BLKRRPART ioctl was changed to return EIO when no partitions were found, such as on an empty disk. This breaks some partitioning programs and is also confusing: "Input/Output error" while in fact nothing was wrong with this brand new all blank disk. This restores old behaviour.
-
Alan Cox authored
Self explanatory.. Based on a report on l/k Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Paul Mackerras authored
We recently found a problem that was causing memory corruption during boot on IBM POWER5 machines. The problem was that the if you have a USB keyboard and it is set to the input device for the firmware, it will still be active when the kernel is started. That means that the OHCI controller has pointers to various memory areas that it polls for transfers to do. When we start using that same memory in the kernel, bad things can happen. (This isn't a problem on powermacs because the Apple OF implements a "quiesce" call which turns off all the devices it is using.) This patch fixes the problem by calling the Open Firmware "close" method for the input device. Stephen Rothwell and I have verified that doing this fixes the problem on the POWER5 machine where we observed it. I verified that this patch doesn't cause any problems on powermacs. I think this patch should go into 2.6.10 since it fixes a nasty memory corruption bug that can cause rather subtle and hard-to-diagnose problems during boot. (The symptom on the POWER5 machine with the particular kernel that we were using was that reading /proc/net/tcp would oops, due to one of the pointers in tcp_ehash being corrupted.) Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Parag Warudkar authored
alloc_dma_rcv_ctx is called in interrupt and Kernel Spinlock debugging code cribs about it via "Debug: sleeping function called in interrupt context". See sample stack traces below. The patch below corrects ohci1394.c to use GFP_ATOMIC instead of GFP_KERNEL. Tested to work fine with 2 different Camcorder devices for fairly long periods and connect/disconnects. Signed-off-by:
Parag Warudkar <kernel-stuff@comcast.net> Signed-off-by:
-
Takashi Iwai authored
The patch adds the definition vm_private_data again to snd_pcm_lib_mmap_iomem(). It got lost during the rewrite of the mmap stuff. Signed-off-by:
Martin Langer <martin-langer@gmx.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
pci_disable_device() is called properly in the removal and error paths. Also, the pci_set_master() is added to the resume callbacks if missing (just to be sure). Signed-off-by:
-
Takashi Iwai authored
Fixed the sleep in spinlock during prepare callback. This happened only on Nforce chips. Signed-off-by:
-
Tom Rini authored
The PCI IRQ map for the old Motorola PowerStackII (Utah) boards was incorrect, but this breakage wasn't exposed until 2.5, and finally fixed until recently by Sebastian Heutling <sheutlin@gmx.de>. Signed-off-by:
Christian Kujau <evil@g-house.de> Signed-off-by:
Tom Rini <trini@kernel.crashing.org> Signed-off-by:
-
Mike Miller authored
This patches fixes the return code from cciss_ioctl. Without this some block layer (BLK*) ioctls do not work. Thanks to Jens Axboe for pointing this out. Signed-off-by:
Mike Miller <mike.miller@hp.com> Signed-off-by:
-
Paul Mackerras authored
We recently found a problem that was causing memory corruption during boot on IBM POWER5 machines. The problem was that the if you have a USB keyboard and it is set to the input device for the firmware, it will still be active when the kernel is started. That means that the OHCI controller has pointers to various memory areas that it polls for transfers to do. When we start using that same memory in the kernel, bad things can happen. (This isn't a problem on powermacs because the Apple OF implements a "quiesce" call which turns off all the devices it is using.) This patch fixes the problem by calling the Open Firmware "close" method for the input device. Stephen Rothwell and I have verified that doing this fixes the problem on the POWER5 machine where we observed it. I verified that this patch doesn't cause any problems on powermacs. I think this patch should go into 2.6.10 since it fixes a nasty memory corruption bug that can cause rather subtle and hard-to-diagnose problems during boot. (The symptom on the POWER5 machine with the particular kernel that we were using was that reading /proc/net/tcp would oops, due to one of the pointers in tcp_ehash being corrupted.) Signed-off-by:
-
Li Shaohua authored
Fix eepro100 driver suspend/resume issue. Signed-off-by: Li Shaohua<shaohua.li@intel.com> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
Jens Axboe authored
Current cfq can cause hangs with non-fs requests, because the accounting goes bad. This fixes it. Signed-off-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
-
Geert Uytterhoeven authored
M68k: Update defconfigs for 2.6.10-rc3 Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
François Romieu authored
The D-Link DGE-528T gigabit adapter is based on the 8169 chipset (reported by Andreas Tauscher <ta@lonestar-bbs.de>, checked in the sources of a driver for this adapter). Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
Dimitri Sivanich authored
The isolcpus option is broken in 2.6.10-rc2-bk2. The domains are no longer being properly initialized (which results in a panic at bootup). Signed-off-by:
Dimitri Sivanich <sivanich@sgi.com> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Benjamin Herrenschmidt authored
The PowerMac specific sleep code in the OHCI USB driver used to call disable/enable irq, which is no longer necessary and actually clashes with the calls to free/request_irq that the common OHCI code now does, thus causing WARN_ON's to trigger each time a PowerBook is woken up from sleep. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: David Brownell <david-b@pacbell.net> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Fenghua Yu authored
If given no-hlt kernel option, ia32 idle loop turns out to be a spin loop. Add cpu_relax() in this spin loop because IA32 SDM recommends that a PAUSE instruction be put in all spin loops. Signed-off-by:
Fenghua Yu <fenghua.yu@intel.com> Signed-off-by:
-
Santiago Leon authored
There's a chance that the receive buffers are being consumed at the same rate as they are being replenished in ibmveth_replenish_task()... Meanwhile, the calls to schedule_replenishing() from ibmveth_poll() won't schedule another replenishing cycle (because the not_replenishing flag is zero), starving the buffers and making the adapter unable to receive packets unless the module is reloaded... Here's a small patch that will fix it by scheduling another replenishing task after toggling the not_replenishing flag. Signed-Off-By:
Santiago Leon <santil@us.ibm.com> Signed-off-by:
-
Herbert Pötzl authored
Fix the non-normalized wall_to_monotonic for i386 and m32r (The other archs seem to get it right) Signed-off-by:
Herbert Poetzl <herbert@13thfloor.at> Signed-off-by:
George Anzinger <george@mvista.com> Signed-off-by:
-
