- 04 Nov, 2006 40 commits
-
-
Jeff Garzik authored
Most of the ISDN ->readstat() implementations needed to check copy_to_user() and put_user() return values. Signed-off-by:
Jeff Garzik <jeff@garzik.org> Cc: Karsten Keil <kkeil@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Francisco Larramendi authored
Fix October-only BCD-to-binary conversion bug: 0x08 -> 7 0x09 -> 8 0x10 -> 15 (!) 0x11 -> 19 Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7361 Cc: Raphael Assenat <raph@raphnet.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@kernel.org> Signed-off-by:
-
Thomas Gleixner authored
The integer divisions in the timer accounting code can round the result down to 0. Adding 0 is without effect and the signal delivery stops. Clamp the division result to minimum 1 to avoid this. Problem was reported by Seongbae Park <spark@google.com>, who provided also an inital patch. Roland sayeth: I have had some more time to think about the problem, and to reproduce it using Toyo's test case. For the record, if my understanding of the problem is correct, this happens only in one very particular case. First, the expiry time has to be so soon that in cputime_t units (usually 1s/HZ ticks) it's < nthreads so the division yields zero. Second, it only affects each thread that is so new that its CPU time accumulation is zero so now+0 is still zero and ->it_*_expires winds up staying zero. For the VIRT and PROF clocks when cputime_t is tick granularity (or the SCHED clock on configurations where sched_clock's value only advances on clock ticks), this is not hard to arrange with new threads starting up and blocking before they accumulate a whole tick of CPU time. That's what happens in Toyo's test case. Note that in general it is fine for that division to round down to zero, and set each thread's expiry time to its "now" time. The problem only arises with thread's whose "now" value is still zero, so that now+0 winds up 0 and is interpreted as "not set" instead of ">= now". So it would be a sufficient and more precise fix to just use max(ticks, 1) inside the loop when setting each it_*_expires value. But, it does no harm to round the division up to one and always advance every thread's expiry time. If the thread didn't already fire timers for the expiry time of "now", there is no expectation that it will do so before the next tick anyway. So I followed Thomas's patch in lifting the max out of the loops. This patch also covers the reload cases, which are harder to write a test for (and I didn't try). I've tested it with Toyo's case and it fixes that. [toyoa@mvista.com: fix: min_t -> max_t] Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Roland McGrath <roland@redhat.com> Cc: Daniel Walker <dwalker@mvista.com> Cc: Toyo Abe <toyoa@mvista.com> Cc: john stultz <johnstul@us.ibm.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Seongbae Park <spark@google.com> Cc: Peter Mattis <pmattis@google.com> Cc: Rohit Seth <rohitseth@google.com> Cc: Martin Bligh <mbligh@google.com> Cc: <stable@kernel.org> Signed-off-by:
-
Jan Beulich authored
Previously, since determination whether there was an Intel random number generator was based on a single bit, on systems with a matching bridge device but without a firmware hub, there was a 50% chance that the code would incorrectly decide that the system had an RNG. This patch adds detection of the firmware hub to better qualify the existence of an RNG. There is one issue with the patch: I was unable to determine the LPC equivalent for the PCI bridge 8086:2430 (since the old code didn't care about which of the many devices provided by the ICH/ESB it was chose to use the PCI bridge device, but the FWH settings live in the LPC device, so the device list needed to be changed). Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Akinobu Mita authored
[WATCHDOG] sc1200wdt.c pnp unregister fix. If no devices found or invalid parameter is specified, scl200wdt_pnp_driver is left unregistered. It breaks global list of pnp drivers. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
-
Clemens Ladisch authored
The calls to rtc_control() from inside the interrupt handler can deadlock the RTC code, so move our interrupt handling code to a tasklet. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Add needed includes for syscall() function, also to remove warnings spit out by GCC; they were added by previous -stable patch, and at least on my system (Ubuntu x86-64) these warnings do show up. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Ulrich Drepper authored
I need this patch to get a UML kernel to compile. This is with the kernel headers in FC6 which are automatically generated from the kernel tree. Some headers are missing but those files don't need them. At least it appears so since the resulting kernel works fine. Tested on x86-64. Signed-off-by:
Ulrich Drepper <drepper@redhat.com> Cc: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Andi Kleen authored
There was a typo in the C3 latency test to decide of the TSC should be used or not. It used the C2 latency threshold, not the C3 one. Fix that. This should fix the time on various dual core laptops. Acked-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Herbert Xu authored
I was looking at a RHEL5 bug report involving Xen and SCTP (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212550). It turns out that SCTP wasn't written to handle skb fragments at all. The absence of any calls to skb_may_pull is testament to that. It just so happens that Xen creates fragmented packets more often than other scenarios (header & data split when going from domU to dom0). That's what caused this bug to show up. Until someone has the time sits down and audits the entire net/sctp directory, here is a conservative and safe solution that simply linearises all packets on input. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Herbert Xu authored
[NET]: Fix segmentation of linear packets skb_segment fails to segment linear packets correctly because it tries to write all linear parts of the original skb into each segment. This will always panic as each segment only contains enough space for one MSS. This was not detected earlier because linear packets should be rare for GSO. In fact it still remains to be seen what exactly created the linear packets that triggered this bug. Basically the only time this should happen is if someone enables GSO emulation on an interface that does not support SG. Signed-off-by:
-
Al Viro authored
several targets have no ....at() family and m32r calls its only chown variant chown32(), with __NR_chown being undefined. creat(2) is also absent in some targets. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Doug Ledford authored
[SCSI] aic7xxx: pause sequencer before touching SBLKCTL Some cards need to pause the sequencer before the SBLKCTL register is touched. This fixes a PCI related oops seen on powerpc macs with this card caused by trying to ascertain the bus signalling before beginning domain validation. Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Stephen Hemminger authored
The reason sky2 driver was locking up on transmit on the Yukon-FE chipset is that it was misconfiguring the internal RAM buffer so the transmitter and receiver were sharing the same space. It is a wonder it worked at all! This patch addresses this, and fixes an easily reproducible hang on Transmit. Only the Yukon-FE chip is Marvell 88E803X (10/100 only) are affected. Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
Zachary Amsden authored
Interrupts must be disabled during alternative instruction patching. On systems with high timer IRQ rates, or when running in an emulator, timing differences can result in random kernel panics because of running partially patched instructions. This doesn't yet fix NMIs, which requires extricating the patch code from the late bug checking and is logically separate (and also less likely to cause problems). Signed-off-by:
Zachary Amsden <zach@vmware.com> Signed-off-by:
-
Miklos Szeredi authored
Fuse didn't always call i_size_write() with i_mutex held which caused rare hangs on SMP/32bit. This bug has been present since fuse-2.2, well before being merged into mainline. The simplest solution is to protect i_size_write() with the per-connection spinlock. Using i_mutex for this purpose would require some restructuring of the code and I'm not even sure it's always safe to acquire i_mutex in all places i_size needs to be set. Since most of vmtruncate is already duplicated for other reasons, duplicate the remaining part as well, making all i_size_write() calls internal to fuse. Using i_size_write() was unnecessary in fuse_init_inode(), since this function is only called on a newly created locked inode. Reported by a few people over the years, but special thanks to Dana Henriksen who was persistent enough in helping me debug it. Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Arthur Kepner authored
We discovered a problem when running IPoIB applications on multiple CPUs on an Altix system. Many messages such as: ib_mthca 0002:01:00.0: SQ 000014 full (19941644 head, 19941707 tail, 64 max, 0 nreq) appear in syslog, and the driver wedges up. Apparently this is because writes to the doorbells from different CPUs reach the device out of order. The following patch adds mmiowb() calls after doorbell rings to ensure the doorbell writes are ordered. Signed-off-by:
Arthur Kepner <akepner@sgi.com> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Eli Cohen authored
When ipoib_ib_dev_flush() is called because of a port event, the driver needs to rejoin all multicast groups, since the flush will call ipoib_mcast_dev_flush() (via ipoib_ib_dev_down()). Otherwise no (non-broadcast) multicast groups will be rejoined until the networking core calls ->set_multicast_list again, and so multicast reception will be broken for potentially a long time. Signed-off-by:
Eli Cohen <eli@mellanox.co.il> Signed-off-by:
Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by:
-
James Bottomley authored
[SCSI] aic7xxx: avoid checking SBLKCTL register for certain cards For cards that don't support LVD, checking the SBLKCTL register to determine the bus singalling doesn't work. So, check that the card supports LVD first (AHC_ULTRA2) before checking the register. Signed-off-by:
-
NeilBrown authored
This is a long standing bug that seems to have only recently become apparent, presumably due to increasing use of NFS over TCP - many distros seem to be making it the default. The SK_CONN bit gets set when a listening socket may be ready for an accept, just as SK_DATA is set when data may be available. It is entirely possible for svc_tcp_accept to be called with neither of these set. It doesn't happen often but there is a small race in svc_sock_enqueue as SK_CONN and SK_DATA are tested outside the spin_lock. They could be cleared immediately after the test and before the lock is gained. This normally shouldn't be a problem. The sockets are non-blocking so trying to read() or accept() when ther is nothing to do is not a problem. However: svc_tcp_recvfrom makes the decision "Should I accept() or should I read()" based on whether SK_CONN is set or not. This usually works but is not safe. The decision should be based on whether it is a TCP_LISTEN socket or a TCP_CONNECTED socket. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
Two less-used md personalities have bugs in the calculation of ->degraded (the extent to which the array is degraded). Signed-off-by:
-
NeilBrown authored
If save_raid_disk is >= 0, then the device could be a device that is already in sync that is being re-added. So we need to default this value to -1. Signed-off-by:
-
Takashi Iwai authored
The va_list is designed to be used only once. The current code may pass va_list arguments multiple times and may cause Oops. Copy/release the arguments temporarily to avoid this problem. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Michael Krufky authored
DVB: fix dvb_pll_attach for mt352/zl10353 in cx88-dvb, and nxt200x Typical wiring of MT352, ZL10353, NXT2002 and NXT2004 based tuners differ from dvb-pll's expectation that the PLL is directly accessible. On these boards, the PLL is actually hidden behind the demodulator, and as such can only be accessed via the demodulator's interface. It was failing to communicate with the PLL during an attach test and subsequently not connecting the tuner ops. By passing a NULL I2C bus handle to dvb_pll_attach, this accessibility check can be bypassed. Do this for the affected boards. Also fix a possible NULL dereference at sleep time, which would otherwise be exposed by this change. This patch has been backported to the 2.6.18.y stable kernel series from the original changesets from Chris Pascoe and Michael Krufky, already present in the upstream 2.6.19 kernel tree. Signed-off-by:
Chris Pascoe <c.pascoe@itee.uq.edu.au> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Michael Buesch authored
This fixes a netdev watchdog timeout problem. The problem is caused by a needed netif_tx_disable in the hardware calibration code and can be shown by the following timegraph. |---5secs - ~10 jiffies time---|---|OOPS ^ ^ last real TX periodic work stops netif At OOPS, the following happens: The watchdog timer triggers, because the timeout of 5secs is over. The watchdog first checks for stopped TX. _Usually_ TX is only stopped from the TX handler to indicate a full TX queue. But this is different. We need to stop TX here, regardless of the TX queue state. So the watchdog recognizes the stopped device and assumes it is stopped due to full TX queues (Which is a _wrong_ assumption in this case). It then tests how far the last TX has been in the past. If it's more than 5secs (which is the case for low or no traffic), it will fire a TX timeout. Acked-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
David Miller authored
The second argument to free_npages() was being incorrectly calculated, which would thus access far past the end of the arena->map[] bitmap. Signed-off-by:
-
David Miller authored
1) probe_other_fhcs() wants to see only non-central FHC busses, so skip FHCs that don't sit off the root 2) Like SBUS, FHC can lack the appropriate address and size cell count properties, so add an of_busses[] entry and handlers for that. 3) Central FHC irq translator probing was buggy. We were trying to use dp->child in irq_trans_init but that linkage is not setup at this point. So instead, pass in the parent of "dp" and look for the child "fhc" with parent "central". Thanks to the tireless assistence of Ben Collins in tracking down these problems and testing out these fixes. Signed-off-by:
-
Dave Kleikamp authored
JFS: pageno needs to be long diRead and diWrite are representing the page number as an unsigned int. This causes file system corruption on volumes larger than 16TB. Signed-off-by:
Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by:
-
Marcel Holtmann authored
[Bluetooth] Check if DLC is still attached to the TTY If the DLC device is no longer attached to the TTY device, then it makes no sense to go through with changing the termios settings. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Russell King authored
[SERIAL] Fix oops when removing suspended serial port A serial card might have been removed when the system is resumed. This results in a suspended port being shut down, which results in the ports shutdown method being called twice in a row. This causes BUGs. Avoid this by tracking the suspended state separately from the initialised state. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
maximilian attems <maks@sternwelten.at> Signed-off-by:
-
Russell King authored
Unfortunately, pcmcia_dev_present() returns false when a device is suspended, so checking this on resume does not work too well. Omit this test. the backported patch below is already in fedora tree. -maks Signed-off-by:
-
David Woodhouse authored
The uninitialised pmu_backlight_lock causes the current Fedora test kernel (which has spinlock debugging enabled) to panic on suspend. This is suboptimal, so I fixed it. Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
Michael Hanselmann <linux-kernel@hansmi.ch> Signed-off-by:
-
Brian King authored
[SCSI] DAC960: PCI id table fixup The PCI ID table in the DAC960 driver conflicts with some devices that use the ipr driver. All ipr adapters that use this chip have an IBM subvendor ID and all DAC960 adapters that use this chip have a Mylex subvendor id. Signed-off-by:
Brian King <brking@us.ibm.com> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Makes UML compile on any possible processor choice. The two problems were: *) x86 code, when 386 is selected, checks at runtime boot_cpuflags, which we do not have. *) 3Dnow support for memcpy() et al. does not compile currently and fixing this is not trivial, so simply disable it; with this change, if one selects MK7 UML compiles (while it did not). Merged upstream. Signed-off-by:
-
Stephen Hemminger authored
This reverts earlier change that attempted to fix flow control. Device needs to discard pause frames, otherwise it passes pause frames up the stack. Signed-off-by:
-
Stephen Hemminger authored
When using flow control, the PHY needs to accept multicast pause frames. Without this fix, these frames were getting discarded by the PHY before doing any flow control. Signed-off-by:
-
Karsten Wiese authored
ALSA: Repair snd-usb-usx2y for usb 2.6.18 urb->start_frame rolls over beyond MAX_INT now. This is for stable kernel and stable alsa. From: Karsten Wiese <annabellesgarden@yahoo.de> Signed-off-by:
Karsten Wiese <annabellesgarden@yahoo.de> Signed-off-by:
-
Karsten Wiese authored
Fix bug in snd-usb-usx2y's usX2Y_pcms_lock_check() substream can be NULL...... in mainline, bug was introduced by: 2006-06-22 [ALSA] Add O_APPEND flag support to PCM From: Karsten Wiese <annabellesgarden@yahoo.de> Signed-off-by:
-
Florin Malita authored
snd_card_file_remove() may free hw->card so we can't dereference hw->card->module after that. Coverity ID 1420. This bug actually causes an Oops at usb-disconnection, especially with CONFIG_PREEMPT. From: Florin Malita <fmalita@gmail.com> Signed-off-by:
Florin Malita <fmalita@gmail.com> Signed-off-by:
-
Amol Lad authored
From: Amol Lad <amol@verismonetworks.com> Signed-off-by:
Amol Lad <amol@verismonetworks.com> Signed-off-by:
-
