- 22 Aug, 2007 33 commits
-
-
Jean Delvare authored
The k8t_sound_hostbridge PCI quick fires on my motherboard (Jetway K8M8MS) while it shouldn't: the on-board sound chip is not disabled and is working just fine. Looking at the code, I see that we are running the quirk for two distinct register values (0x88 and 0xc8) and then clear bit 6 (0x40). However value 0x88 already has bit 6 cleared so this is a no-op. This is what happens on my board. Thus I believe that the quirk should only be run for register value 0xc8. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tejun Heo authored
RX790 can't do MSI like its predecessors. Disable MSI on RX790. Signed-off-by:
Tejun Heo <htejun@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Tejun Heo authored
RD580 can't do MSI like its predecessors. Disable MSI on RD580. Signed-off-by:
Tejun Heo <teheo@suse.de> CC: stable <stable@kernel.org> Signed-off-by:
-
Tejun Heo authored
RS690 can't do MSI like its predecessors. Disable MSI on RS690. Signed-off-by:
-
Brice Goglin authored
[PATCH] PCI: make pcie_get_readrq visible in pci.h pcie_get_readrq() is EXPORT_SYMBOL'ed, but its prototype is not visible in pci.h, add it there. This is needed by some network drivers. Signed-off-by:
Brice Goglin <brice@myri.com> Acked-by:
Peter Oruba <peter.oruba@amd.com> Signed-off-by:
-
Bernhard Kaindl authored
Adrian Bunk wrote: > Alois Nešpor wrote >> PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0b) (try 'pci=assign-busses') >> Please report the result to linux-kernel to fix this permanently" >> >> dmesg: >> "Yenta: Raising subordinate bus# of parent bus (#0a) from #0b to #0e" >> without pci=assign-busses and nothing with pci=assign-busses. > > Bernhard? Ok, lets kill the message. As Alois Nešpor also saw, that's fixed up by Yenta, so PCI does not have to warn about it. PCI could still warn about it if is_cardbus is 0 in that instance of pci_scan_bridge(), but so far I have not seen a report where this would have been the case so I think we can spare the kernel of that check (removes ~300 lines of asm) unless debugging is done. History: The whole check was added in the days before we had the fixup for this in Yenta and pci=assign-busses was the only way to get CardBus cards detected on many (not all) of the machines which give this warning. In theory, there could be cases when this warning would be triggered and it's not cardbus, then the warning should still apply, but I think this should only be the case when working on a completely broken PCI setup, but one may have already enabled the debug code in drivers/pci and the patched check would then trigger. I do not sign this off yet because it's completely untested so far, but everyone is free to test it (with the #ifdef DEBUG replaced by #if 1 and pr_debug( changed to printk(. We may also dump the whole check (remove everything within the #ifdef from the source) if that's perferred. On Alois Nešpor's machine this would then (only when debugging) this message: "PCI: Bus #0b (-#0e) is partially hidden behind transparent bridge #0a (-#0b)" "partially" should be in the message on his machine because #0b of #0b-#0e is reachable behind #0a-#0b, but not #0c-#0e. But that differentiation is now moot anyway because the fixup in Yenta takes care of it as far as I could see so far, which means that unless somebody is debugging a totally broken PCI setup, this message is not needed anymore, not even for debugging PCI. Ok, here the patch with the following changes: * Refined to say that the bus is only partially hidden when the parent bus numbers are not totally way off (outside of) the child bus range * remove the reference to pci=assign-busses and the plea to report it We could add a pure source code-only comment to keep a reference to pci=assign-busses the in case when this is triggered by someone who is debugging the cause of this message and looking the way to solve it. From: Bernhard Kaindl <bk@suse.de> Cc: stable <stable@kernel.org> Signed-off-by: -
Ingo Molnar authored
remove stale BKL use from drivers/pci/hotplug/cpqphp_ctrl.c. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Rolf Eike Beer authored
This useful interface is hardly mentioned anywhere in the in-tree documentation. Signed-off-by:
Rolf Eike Beer <eike-kernel@sf-tec.de> Cc: Tejun Heo <htejun@gmail.com> Acked-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Marian Balakowicz authored
quirk_e100_interrupts() is called after PCI controller is initialized and before PCI bus enumeration is performed. On some powerpc platforms which modify PCI controller configuration and set different MEM and IO windows than those set by firmware quirk_e100_interrupt() is causing kernel panic as it tries to read from device BAR0 offets which at this time points to a invalid PCI window (set by firmware). This patch delays the quirk_100_interrupt() to pci_fixup_final phase, which happens after bus enumeration and before PCI enable and device driver initialization. Signed-off-by:
Marian Balakowicz <m8@semihalf.com> Signed-off-by:
-
Kumar Gala authored
We need pci_bus_find_capability() in some arch/powerpc code so move the prototype into a header accessible to it. Also kill the duplicate prototype for pci_bus_alloc_resource(). Signed-off-by:
Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdogLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog: [WATCHDOG] Add support for 1533 bridge to alim1535_wdt [WATCHDOG] Add a 00-INDEX file to Documentation/watchdog/ [WATCHDOG] Eurotechwdt.c - clean-up comments
-
Linus Torvalds authored
* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6: [SPARC32]: Revert f642b263. [SPARC64]: Need to clobber global reg vars in switch_to().
-
Linus Torvalds authored
* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [IRDA] irda_nl_get_mode: always results in failure [PPP]: Fix output buffer size in ppp_decompress_frame(). [IRDA]: Avoid a label defined but not used warning in irda_init() [IPV6]: Fix kernel panic while send SCTP data with IP fragments [SNAP]: Check packet length before reading [DCCP]: Allocation in atomic context
-
git://git390.osdl.marist.edu/pub/scm/linux-2.6Linus Torvalds authored
* 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6: [S390] Change atomic_read/set to inline functions with barrier semantics. [S390] kprobes: fix instruction length calculation [S390] hypfs: inode corruption due to missing locking [S390] disassembler: fix b2 opcodes like srst, bsg, and others [S390] vmur: fix reference counting for vmur device structure [S390] vmur: fix diag14 exceptions with addresses > 2GB. [S390] qdio: Refresh buffer states for IQDIO Asynchronous output queue [S390] qdio: fix EQBS handling on CCQ96 [S390] cio: change confusing message in cmf. [S390] cio: dont forget to set last slot to NULL in ccw_uevent().
-
Zachary Amsden authored
Touching vmalloc memory in the middle of a lazy mode update can generate a kernel PDE update, which must be flushed immediately. The fix is to leave lazy mode when doing a vmalloc sync. Signed-off-by:
Zachary Amsden <zach@vmware.com> Acked-by:
Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Heiko Carstens authored
After doing some tests this seems to be the best variant for s390 and should be correct as well. With gcc 4.2.1 we get the following kernel image sizes using the default configuration: atomic_t type volatile, atomic_read/set defines 5311824 bytes atomic_t type int, atomic_read/set defines 5270864 bytes atomic_t type int, atomic_read/set inline asm 5279056 bytes atomic_t type int, atomic_read/set inline barrier 5270864 bytes Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
David Wilder authored
Placing a kprobe on "bc" instruction (s390/s390x) can cause an oops. The instruction length is encoded into the first two bits of the s390 instruction. Kprobe is incorrectly computing the instruction length. The instruction length is used for determining what type of "fix-up" is needed for conditional branch instruction. The problem can bee seen by placing a kprobe on a "bc" instruction that will not branch. The results is that Kprobe incorrectly computes the new instruction pointer (psw.addr) after single stepping the instruction. The problem is corrected with this patch. Signed-off-by:
David Wilder <dwilder@us.ibm.com> Signed-off-by:
-
Michael Holzheu authored
hypfs removes the whole hypfs directory tree and creates a new one, when a process triggers an update by writing to the "update" attribute. When removing and creating files, it is necessary to lock the inode of the parent directory where the files live. Currently hypfs does not lock the parent inode, which can lead to inode corruption. This patch: * Introduces correct locking * Fixes i_nlink reference counting for inodes, when creating directories * Adds info printk, when hypfs filesystem has been mounted Signed-off-by:
Michael Holzheu <holzheu@de.ibm.com> Signed-off-by:
-
Christian Borntraeger authored
The instruction table for b2 opcodes was missing an opfrag value for the cpya instruction. All instructions specified after cpya were not considered by the disassembler. The fix is simple and obvious - add the opfrag field to the cpya instruction. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Michael Holzheu authored
When a vmur device is removed due to a detach of the device, currently the ur device structure is freed. Unfortunately it can happen, that there is still a user of the device structure, when the character device is open during the detach process. To fix this, reference counting for the vmur structure is introduced. In addition to that, the online, offline, probe and remove functions are serialized now using a global mutex. Signed-off-by:
-
Michael Holzheu authored
There are several s390 diagnose calls, which must be executed below the 2GB memory boundary. In order to enforce this, those diagnoses must be compiled into the kernel. Currently diag 14 can be called within the vmur kernel module from addresses above 2GB. This leads to specification exceptions. This patch moves diag10, diag14 and diag210 into the new diag.c file. Signed-off-by:
-
Klaus D. Wacker authored
Hipersocket Multicast queue works asynchronously. When sending buffers, the buffer state change may happen delayed. The tasklet for checking changes in the outbound queue excluded IQDIO async queues from this process. This created either a hang situation when the queue ran full, or presented a hang situation a interface close time. The tasklet processing is changed to include IQDIO async queues when requesting buffer state refresh. Signed-off-by:
Klaus D. Wacker <kdwacker@de.ibm.com> Signed-off-by:
-
Klaus D. Wacker authored
QDIO returned from EQBS instruction in any case after return code CCQ=96 was issued regardless whether buffer states for at least one buffer were extracted or not. This caused FCP devices to hang when running under z/VM and having QIOASSASIST=ON and having high I/O rates. In order to fix this qdio return code processing of EQBS instruction after CCQ=96 is changed that buffers are returned and if no buffers where extracted the instruction is repeated at once. Signed-off-by:
-
Cornelia Huck authored
cmf currently prints a message that more than 4096 channels are not allowed in basic mode - however, this can only be enforced if cmf was a module (which is no longer possible). It makes much more sense to not check the specified number of channels and just print a message if the block for basic mode could not be allocated (which may happen for any number of specified channels). Signed-off-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
-
Cornelia Huck authored
Signed-off-by:
-
Andy Whitcroft authored
It seems an extraneous trailing ';' has slipped in to the error handling for a name registration failure causing the error path to trigger unconditionally. Signed-off-by:
Andy Whitcroft <apw@shadowen.org> Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Konstantin Sharlaimov authored
This patch addresses the issue with "osize too small" errors in mppe encryption. The patch fixes the issue with wrong output buffer size being passed to ppp decompression routine. -------------------- As pointed out by Suresh Mahalingam, the issue addressed by ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet. The size of allocated output buffer is correct, however it size passed to ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that. -------------------- Signed-off-by:
Konstantin Sharlaimov <konstantin.sharlaimov@gmail.com> Signed-off-by:
-
Jesper Juhl authored
Easily avoidable compiler warnings bug me. Building irmod without CONFIG_SYSCTL currently results in : net/irda/irmod.c:132: warning: label 'out_err_2' defined but not used But that can easily be avoided by simply moving the label inside the existing "#ifdef CONFIG_SYSCTL" one line above it. This patch moves the label and buys us one less warning with no ill effects. Signed-off-by:
Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by:
-
Wei Yongjun authored
If ICMP6 message with "Packet Too Big" is received after send SCTP DATA, kernel panic will occur when SCTP DATA is send again. This is because of a bad dest address when call to skb_copy_bits(). The messages sequence is like this: Endpoint A Endpoint B <------- SCTP DATA (size=1432) ICMP6 message -------> (Packet Too Big pmtu=1280) <------- Resend SCTP DATA (size=1432) ------------kernel panic--------------- printing eip: c05be62a *pde = 00000000 Oops: 0002 [#1] SMP Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd CPU: 0 EIP: 0060:[<c05be62a>] Not tainted VLI EFLAGS: 00010282 (2.6.23-rc2 #1) EIP is at skb_copy_bits+0x4f/0x1ef eax: 000004d0 ebx: ce12a980 ecx: 00000134 edx: cfd5a880 esi: c8246858 edi: 00000000 ebp: c0759b14 esp: c0759adc ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000) Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880 d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521 000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4 Call Trace: [<c0405e1d>] show_trace_log_lvl+0x1a/0x2f [<c0405ecd>] show_stack_log_lvl+0x9b/0xa3 [<c040608d>] show_registers+0x1b8/0x289 [<c0406271>] die+0x113/0x246 [<c0625dbc>] do_page_fault+0x4ad/0x57e [<c0624642>] error_code+0x72/0x78 [<d09bc521>] ip6_output+0x8e5/0xab2 [ipv6] [<d09bcec1>] ip6_xmit+0x2ea/0x3a3 [ipv6] [<d0a3f2ca>] sctp_v6_xmit+0x248/0x253 [sctp] [<d0a3c934>] sctp_packet_transmit+0x53f/0x5ae [sctp] [<d0a34bf8>] sctp_outq_flush+0x555/0x587 [sctp] [<d0a34d3c>] sctp_retransmit+0xf8/0x10f [sctp] [<d0a3d183>] sctp_icmp_frag_needed+0x57/0x5b [sctp] [<d0a3ece2>] sctp_v6_err+0xcd/0x148 [sctp] [<d09cf1ce>] icmpv6_notify+0xe6/0x167 [ipv6] [<d09d009a>] icmpv6_rcv+0x7d7/0x849 [ipv6] [<d09be240>] ip6_input+0x1dc/0x310 [ipv6] [<d09be965>] ipv6_rcv+0x294/0x2df [ipv6] [<c05c3789>] netif_receive_skb+0x2d2/0x335 [<c05c5733>] process_backlog+0x7f/0xd0 [<c05c58f6>] net_rx_action+0x96/0x17e [<c042e722>] __do_softirq+0x64/0xcd [<c0406f37>] do_softirq+0x5c/0xac ======================= Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00 <f3> a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01 EIP: [<c05be62a>] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc Kernel panic - not syncing: Fatal exception in interrupt Arnaldo says: ==================== Thanks! I'm to blame for this one, problem was introduced in: b0e380b1 @@ -761,7 +762,7 @@ slow_path: /* * Copy a block of the IP datagram. */ - if (skb_copy_bits(skb, ptr, frag->h.raw, len)) + if (skb_copy_bits(skb, ptr, skb_transport_header(skb), len)) BUG(); left -= len; ==================== Signed-off-by:Wei Yongjun <yjwei@cn.fujitsu.com> Acked-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Signed-off-by:
-
Herbert Xu authored
The snap_rcv code reads 5 bytes so we should make sure that we have 5 bytes in the head before proceeding. Based on diagnosis and fix by Evgeniy Polyakov, reported by Alan J. Wylie. Patch also kills the skb->sk assignment before kfree_skb since it's redundant. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Gerrit Renker authored
This fixes the following bug reported in syslog: [ 4039.051658] BUG: sleeping function called from invalid context at /usr/src/davem-2.6/mm/slab.c:3032 [ 4039.051668] in_atomic():1, irqs_disabled():0 [ 4039.051670] INFO: lockdep is turned off. [ 4039.051674] [<c0104c0f>] show_trace_log_lvl+0x1a/0x30 [ 4039.051687] [<c0104d4d>] show_trace+0x12/0x14 [ 4039.051691] [<c0104d65>] dump_stack+0x16/0x18 [ 4039.051695] [<c011371e>] __might_sleep+0xaf/0xbe [ 4039.051700] [<c0157b66>] __kmalloc+0xb1/0xd0 [ 4039.051706] [<f090416f>] ccid2_hc_tx_alloc_seq+0x35/0xc3 [dccp_ccid2] [ 4039.051717] [<f09048d6>] ccid2_hc_tx_packet_sent+0x27f/0x2d9 [dccp_ccid2] [ 4039.051723] [<f085486b>] dccp_write_xmit+0x1eb/0x338 [dccp] [ 4039.051741] [<f085603d>] dccp_sendmsg+0x113/0x18f [dccp] [ 4039.051750] [<c03907fc>] inet_sendmsg+0x2e/0x4c [ 4039.051758] [<c033a47d>] sock_aio_write+0xd5/0x107 [ 4039.051766] [<c015abc1>] do_sync_write+0xcd/0x11c [ 4039.051772] [<c015b296>] vfs_write+0x118/0x11f [ 4039.051840] [<c015b932>] sys_write+0x3d/0x64 [ 4039.051845] [<c0103e7c>] syscall_call+0x7/0xb [ 4039.051848] ======================= The problem was that GFP_KERNEL was used; fixed by using gfp_any(). Signed-off-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
-
Robin Getz authored
Gerd Hoffmann pointed out that my patch from yesterday can lead to a null pointer dereference if the kernel is booted with no console, and no earlyprintk defined. This fixes that issue. Signed-off-by:
Robin Getz <rgetz@blackfin.uclinux.org> Signed-off-by:
-
Kumar Gala authored
The initial user manuals for MPC8544/8533 had some issues with properly documenting the device IDs for MPC8544/8533. These processors are almost identical and both show up on the reference boards. Fix up the quirks for PCIe support to handle MPC8533/E. Signed-off-by:
-
- 21 Aug, 2007 7 commits
-
-
Stephen Hemminger authored
There are special PHY settings available on Yukon EC-U chip that should not get cleared. This should solve mysterious errors on some motherboards (like Gigabyte DS-3). Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
-
Martin Bachem authored
This fixes handling of USB ISO completion error -EXDEV and includes several other changes to current CVS version at isdn4linux.de (changes in debug flags, style of code remarks, etc) Signed-off-by:
Martin Bachem <info@colognechip.com> Acked-by:
Karsten Keil <kkeil@suse.de> Signed-off-by:
-
Andi Kleen authored
I did some testing and found quite a lot of problems (doesn't boot at all on non NUMA and misassigns cores on Opteron systems). Mark it as experimental and warn against its use for now. It's still default y for SUMMIT/NUMAQ because it'll presumably work on these systems. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
David S. Miller authored
This causes boot failures for some people. It looks like in fact that some SILO provided ramdisk images should not be KERNBASE normalized. Signed-off-by: -
David S. Miller authored
Otherwise the compiler can't see the things like the per-cpu area base register are changing. Signed-off-by: -
Linus Torvalds authored
This reverts commit 196705c9. It was reported to cause a regression by Daniel Exner, and Arjan van de Ven points out that we actually already have infrastructure in place for setting limits on acceptable DMA latency that would be the much more correct fix for the problem with some Broadcom EHCI controllers. Fixed up trivial conflicts due to the changes to support big-endian host controller descriptors in drivers/usb/host/{ehci-sched.c,ehci.h}. Signed-off-by:
-
Zach Brown authored
This patch uses kzalloc to zero all of struct dio rather than manually trying to track which fields we rely on being zero. It passed aio+dio stress testing and some bug regression testing on ext3. This patch was introduced by Linus in the conversation that lead up to Badari's minimal fix to manually zero .map_bh.b_state in commit: 6a648fa7 It makes the code a bit smaller. Maybe a couple fewer cachelines to load, if we're lucky: text data bss dec hex filename 3285925 568506 1304616 5159047 4eb887 vmlinux 3285797 568506 1304616 5158919 4eb807 vmlinux.patched I was unable to measure a stable difference in the number of cpu cycles spent in blockdev_direct_IO() when pushing aio+dio 256K reads at ~340MB/s. So the resulting intent of the patch isn't a performance gain but to avoid exposing ourselves to the risk of finding another field like .map_bh.b_state where we rely on zeroing but don't enforce it in the code. Signed-off-by:
Zach Brown <zach.brown@oracle.com> Signed-off-by:
-
