- 09 Mar, 2007 40 commits
-
-
Michael Krufky authored
dvb-pll normally opens the i2c gate before attempting to communicate with the pll, but the code for this device is not using dvb-pll. This should be cleaned up in the future, but for now, just open the i2c gate at the appropriate place in order to fix this driver bug. (cherry picked from commit 2fe22dcd) Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jin-Bong lee authored
Without this patch, the device will not be detected after firmware download on big endian systems. (cherry picked from commit 1d1370a4) Signed-off-by:
Jin-Bong lee <jinbong.lee@samsung.com> Signed-off-by:
-
Mike Isely authored
Rework the cx23416 firmware loader so that it longer requires the firmware size to be a multiple of 8KB. Until recently all cx2341x firmware images were exactly 256KB, but newer firmware is larger than that and also appears to have arbitrary size. We still must check against a multiple of 4 bytes (because the cx23416 itself uses a 32 bit word size). This fix is already in the upstream driver source and has proven itself there; this is a backport for the 2.6.20.y kernel series. (backported from commit 90060d32) Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
-
Mike Isely authored
This introduces some extra cx23416 commands when streaming is started. The addition of these commands fix random sporadic video corruption that can take place when the video stream is temporarily disrupted through loss of signal (e.g. changing the channel in the RF tuner). This fix is already in the upstream driver source and has proven itself there; this is a backport for the 2.6.20.y kernel series. (backported from commit 6fe7d2c4) Signed-off-by:
-
Marcel Siegert authored
Arjan van de Ven <arjan@infradead.org> reported an illegal re-usage of the fileoperations struct if more than one dvb device (e.g. frontend) is present. This patch fixes this issue. It allocates a new fileoperations struct each time a device is registered and copies the default template fileops. (backported from commit b6190102) Signed-off-by:
Marcel Siegert <mws@linuxtv.org> Signed-off-by:
-
NeilBrown authored
There are two errors that can lead to recovery problems with raid10 when used in 'far' more (not the default). Due to a '>' instead of '>=' the wrong block is located which would result in garbage being written to some random location, quite possible outside the range of the device, causing the newly reconstructed device to fail. The device size calculation had some rounding errors (it didn't round when it should) and so recovery would go a few blocks too far which would again cause a write to a random block address and probably a device error. The code for working with device sizes was fairly confused and spread out, so this has been tided up a bit. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Stefano Brivio authored
BCM4309 devices aren't working properly as A PHYs aren't supported yet, but we probe 802.11a cores anyway. This fixes it, while still allowing for A PHY code to be developed in the future. Signed-off-by:
Stefano Brivio <stefano.brivio@polimi.it> Cc: Michael Buesch <mb@bu3sch.de> Signed-off-by:
-
Jan Beulich authored
After updating several machines to 2.6.20, I can't boot anymore the single one of them that supports the NX bit and is configured as a 32-bit system. My understanding is that the VDSO changes in 2.6.20-rc7 were not fully cooked, in that with that config option enabled VDSO_SYM(x) now equals x, meaning that an address in the fixmap area is now being passed to apps via AT_SYSINFO. However, the page is mapped with PAGE_READONLY rather than PAGE_READONLY_EXEC. I'm not certain whether having app code go through the fixmap area is intended, but in case it is here is the simple patch that makes things work again. Cc: Theodore Tso <tytso@mit.edu> Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Andi Kleen authored
x86: Don't require the vDSO for handling a.out signals and in other strange binfmts. vDSO is not necessarily mapped there. This fixes signals in a.out programs Signed-off-by:
-
Andi Kleen authored
gcc 5.0 will likely not have the constraint problem Signed-off-by:
-
Stephen Hemminger authored
The code in transmit timeout incorrectly assumed that netif_tx_lock was not set. Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
-
Stephen Hemminger authored
Don't mark pause frames as errors. This problem caused transmitter not to pause and would effectively take out a gigabit switch because the it can't handle overrun. Signed-off-by:
-
David Miller authored
[XFRM]: Fix OOPSes in xfrm_audit_log(). Make sure that this function is called correctly, and add BUG() checking to ensure the arguments are sane. Based upon a patch by Joy Latten. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ilpo Järvinen authored
TCP may advertize up to 16-bits window in SYN packets (no window scaling allowed). At the same time, TCP may have rcv_wnd (32-bits) that does not fit to 16-bits without window scaling resulting in pseudo garbage into advertized window from the low-order bits of rcv_wnd. This can happen at least when mss <= (1<<wscale) (see tcp_select_initial_window). This patch fixes the handling of SYN advertized windows (compile tested only). In worst case (which is unlikely to occur though), the receiver advertized window could be just couple of bytes. I'm not sure that such situation would be handled very well at all by the receiver!? Fortunately, the situation normalizes after the first non-SYN ACK is received because it has the correct, scaled window. Alternatively, tcp_select_initial_window could be changed to prevent too large rcv_wnd in the first place. [ tcp_make_synack() has the same bug, and I've added a fix for that to this patch -DaveM ] Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Jiri Bohac authored
[IPX]: Fix NULL pointer dereference on ipx unload Fixes a null pointer dereference when unloading the ipx module. On initialization of the ipx module, registering certain packet types can fail. When this happens, unloading the module later dereferences NULL pointers. This patch fixes that. Please apply. Signed-off-by:
Jiri Bohac <jbohac@suse.cz> Signed-off-by:
-
Herbert Xu authored
[NETFILTER]: Clear GSO bits for TCP reset packet The TCP reset packet is copied from the original. This includes all the GSO bits which do not apply to the new packet. So we should clear those bits. Spotted by Patrick McHardy. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
David Miller authored
[ATM]: atmarp.h needs to always include linux/types.h To provide the __be* types, even for userspace includes. Reported by Andrew Walrond. Signed-off-by:
-
Alan Stern authored
This patch (as863) fixes a problem encountered sometimes when resuming a port on a UHCI controller. The hardware may turn off the Resume-Detect bit before turning off the Suspend bit, leading usbcore to think that the port is still suspended and the resume has failed. The patch makes uhci_finish_suspend() wait until both bits are safely off. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
NeilBrown authored
When the last thread of nfsd exits, it shuts down all related sockets. It currently uses svc_close_socket to do this, but that only is immediately effective if the socket is not SK_BUSY. If the socket is busy - i.e. if a request has arrived that has not yet been processes - svc_close_socket is not effective and the shutdown process spins. So create a new svc_force_close_socket which removes the SK_BUSY flag is set and then calls svc_close_socket. Also change some open-codes loops in svc_destroy to use list_for_each_entry_safe. Signed-off-by:
-
NeilBrown authored
process-pools have real benefits for NUMA, but on SMP machines they only work if network interface interrupts go to all CPUs (via round-robin or multiple nics). This is not always the case, so disable the pools in this case until a better solution is developped. Signed-off-by:
-
Alan Stern authored
This patch (as850b) disables remote wakeup (and everything else!) on all EHCI ports when the shutdown() method is called. If remote wakeup is left active then some systems will reboot instead of powering off. This fixes Bugzilla #7828. Signed-off-by:
-
YOSHIFUJI Hideaki authored
Tetsuo Handa <handat@pm.nttdata.co.jp> told me that connect(2) with TCPv6 socket almost always took a few minutes to return when we did not have any ports available in the range of net.ipv4.ip_local_port_range. The reason was that we used incorrect seed for calculating index of hash when we check established sockets in __inet6_check_established(). Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
David Woodhouse authored
[MTD] Fix regression in RedBoot partition scanning This fixes a regression introduced by the attempt to handle RedBoot FIS tables which are smaller than an eraseblock, in commit 0b47d654 It moves the recalculation of the number of slots in the table to the correct place, and improves the heuristic for when we think we need to byte-swap what we read from the flash. Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Cc: Rod Whitby <rod@whitby.id.au> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
There is no prompt for STACKTRACE, so it is enabled only when 'select'ed. FAULT_INJECTION depends on it, while LOCKDEP selects it. So FAULT_INJECTION becomes visible in Kconfig only when LOCKDEP is enabled. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Julien BLACHE authored
The USB vendor and product IDs are not byteswapped appropriately, and thus come out in the wrong endianness when fetched through the evdev using ioctl() on big endian platforms. Signed-off-by:
Julien BLACHE <jb@jblache.org> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Michael Hanselmann authored
Commit 40b20c25 by Len Brown introduced a null pointer dereference in the appledisplay driver. This patch fixes it. Signed-off-by:
Michael Hanselmann <linux-kernel@hansmi.ch> Signed-off-by:
-
Stefan Richter authored
Since my commit 8252bbb1 in 2.6.20-rc1, host devices have a dummy driver attached. Alas the driver was not registered before use if ieee1394 was loaded with disable_nodemgr=1. This resulted in non-functional FireWire drivers or kernel lockup. http://bugzilla.kernel.org/show_bug.cgi?id=7942Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
David Moore authored
This together with the phys_to_virt fix in lib/swiotlb.c::swiotlb_sync_sg fixes video1394 DMA on machines with DMA bounce buffers, especially Intel x86-64 machines with > 3GB RAM. Signed-off-by:
David Moore <dcm@acm.org> Tested-by:
Nicolas Turro <Nicolas.Turro@inrialpes.fr> Signed-off-by:
-
Rojhalat Ibrahim authored
We get the following compiler error: CC arch/ppc/kernel/ppc_ksyms.o arch/ppc/kernel/ppc_ksyms.c:275: error: '__mtdcr' undeclared here (not in a function) arch/ppc/kernel/ppc_ksyms.c:275: warning: type defaults to 'int' in declaration of '__mtdcr' arch/ppc/kernel/ppc_ksyms.c:276: error: '__mfdcr' undeclared here (not in a function) arch/ppc/kernel/ppc_ksyms.c:276: warning: type defaults to 'int' in declaration of '__mfdcr' make[1]: *** [arch/ppc/kernel/ppc_ksyms.o] Error 1 This is due to the EXPORT_SYMBOL for __mtdcr/__mfdcr not having the proper CONFIG protection Signed-off-by:
Rojhalat Ibrahim <imr@rtschenk.de> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
-
Neil Brown authored
md/bitmap tracks how many active write requests are pending on blocks associated with each bit in the bitmap, so that it knows when it can clear the bit (when count hits zero). The counter has 14 bits of space, so if there are ever more than 16383, we cannot cope. Currently the code just calles BUG_ON as "all" drivers have request queue limits much smaller than this. However is seems that some don't. Apparently some multipath configurations can allow more than 16383 concurrent write requests. So, in this unlikely situation, instead of calling BUG_ON we now wait for the count to drop down a bit. This requires a new wait_queue_head, some waiting code, and a wakeup call. Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower in that case...). Signed-off-by:
-
Alexey Dobriyan authored
[IPV4/IPV6] multicast: Check add_grhead() return value add_grhead() allocates memory with GFP_ATOMIC and in at least two places skb from it passed to skb_put() without checking. Signed-off-by:
Alexey Dobriyan <adobriyan@openvz.org> Signed-off-by:
-
John Heffner authored
We can accidently spit out a huge burst of packets with TSO when the FIN back is piggybacked onto the final packet. [TCP]: Don't apply FIN exception to full TSO segments. Signed-off-by:
John Heffner <jheffner@psc.edu> Signed-off-by:
-
Daniel Walker authored
[ATM]: Fix for crash in adummy_init() This was reported by Ingo Molnar here, http://lkml.org/lkml/2006/12/18/119 The problem is that adummy_init() depends on atm_init() , but adummy_init() is called first. So I put atm_init() into subsys_initcall which seems appropriate, and it will still get module_init() if it becomes a module. Interesting to note that you could crash your system here if you just load the modules in the wrong order. Signed-off-by:
Daniel Walker <dwalker@mvista.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Neil Brown authored
Fix various bugs with aligned reads in RAID5. It is possible for raid5 to be sent a bio that is too big for an underlying device. So if it is a READ that we pass stright down to a device, it will fail and confuse RAID5. So in 'chunk_aligned_read' we check that the bio fits within the parameters for the target device and if it doesn't fit, fall back on reading through the stripe cache and making lots of one-page requests. Note that this is the earliest time we can check against the device because earlier we don't have a lock on the device, so it could change underneath us. Also, the code for handling a retry through the cache when a read fails has not been tested and was badly broken. This patch fixes that code. Signed-off-by:
-
Takashi Iwai authored
[ALSA] hda-intel - Don't try to probe invalid codecs Fix the max number of codecs detected by HD-intel (and compatible) controllers to 3. Some hardware reports extra bits as if connected, and the driver gets confused to probe unexisting codecs. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Jaroslav Kysela <perex@suse.cz> Signed-off-by:
-
Takashi Iwai authored
The patch fixes the memory corruption by the support of unconventional sample rates. Also, it avoids the too restrictive constraints if any of usb descriptions contain continuous rates. Signed-off-by:
-
Takashi Iwai authored
This is a patch for ALSA Bug #2724. Some webcams provide bogus settings with no valid rates. With this patch those are skipped. Signed-off-by:
Gregor Jasny <gjasny@web.de> Signed-off-by:
-
Alan Stern authored
This patch (as849) fixes a bug in the USB hub driver. A single pre-allocated buffer is used for all port status reads, but nothing guarantees exclusive use of the buffer. A mutex is added to provide this guarantee. Signed-off-by:
-
David Moore authored
Missing critical phys_to_virt in lib/swiotlb.c Adds missing call to phys_to_virt() in the lib/swiotlb.c:swiotlb_sync_sg() function. Without this change, a kernel panic will always occur whenever a SWIOTLB bounce buffer from a scatter-gather list gets synced. Affected are especially Intel x86_64 machines with more than about 3 GB RAM. Signed-off-by:
-
Dave Jones authored
On Sun, Feb 04, 2007 at 04:51:38PM +0100, Eric Piel wrote: > Hello, > > I've got a regression in 2.6.20-rc7 (-rc6 was fine) due to commit > 4b95320f ([AGPGART] intel_agp: restore > graphics device's pci space early in resume). I think the key to this failure is the last line here .. > agpgart-intel 0000:00:00.0: resuming > PM: Writing back config space on device 0000:00:02.0 at offset f (was 10b, writing 0) > PM: Writing back config space on device 0000:00:02.0 at offset d (was dc, writing 0) > PM: Writing back config space on device 0000:00:02.0 at offset b (was 10161025, writing 0) > PM: Writing back config space on device 0000:00:02.0 at offset 5 (was f4000000, writing 0) > PM: Writing back config space on device 0000:00:02.0 at offset 4 (was f8000008, writing 0) > PM: Writing back config space on device 0000:00:02.0 at offset 2 (was 3000011, writing 0) > PM: Writing back config space on device 0000:00:02.0 at offset 1 (was 2b00007, writing 0) > PM: Writing back config space on device 0000:00:02.0 at offset 0 (was 11328086, writing 0) > agpgart: Unable to remap memory. This then blows up the next access to intel_i810_private.registers, which happens to be intel_i810_insert_entries. Either we need .suspend methods which unmap these regions, or we need to skip trying to map them a second time on resume. There's an ugly patch below which does the latter. Give it a try? The intel-agp suspend/resume code has really grown into something of a monster, and could use some refactoring in a big way. Dave From: Dave Jones <davej@redhat.com> Signed-off-by:
-
