Hangs with 2.6.10-ac11
I've been experiencing hangs with kernel 2.6.10-ac11 and also previous ac-series. The affected box is a quite loaded Dual-Xeon HT system. The kernel was built with gcc-2.95 (Debian woody). Sysrq-b on ac11 brings the following and the completely hangs, i.e. no sysrq responses anymore: SysRq : Emergency Sync SysRq : Emergency Remount R/O SysRq : Resetting Badness in smp_call_function at arch/i386/kernel/smp.c:523 [] smp_call_function+0x4c/0xf0 [] release_console_sem+0x1f/0xa8 [] smp_send_stop+0x10/0x1c [] stop_this_cpu+0x0/0x30 [] machine_restart+0x7c/0xf8 [] sysrq_handle_reboot+0x7/0xc [] __handle_sysrq+0x6b/0x104 [] handle_sysrq+0x1d/0x24 [] receive_chars+0x138/0x204 [] serial8250_interrupt+0x66/0xe4 [] handle_IRQ_event+0x28/0x58 [] __do_IRQ+0xfb/0x150 [] do_IRQ+0x1b/0x28 [] common_interrupt+0x1a/0x20 [] _spin_lock+0xa/0x10 [] smp_call_function+0x86/0xf0 [] do_drain+0x0/0x44 [] do_drain+0x0/0x44 [] smp_call_function_all_cpus+0x1a/0x2c [] do_drain+0x0/0x44 [] drain_cpu_caches+0x11/0x40 [] do_drain+0x0/0x44 [] __cache_shrink+0xd/0x8c [] kmem_cache_shrink+0x26/0x2c [] xfs_inode_shake+0xc/0x24 [] shrink_slab+0x86/0x1a0 [] try_to_free_pages+0xd2/0x188 [] __alloc_pages+0x1e5/0x308 [] do_page_cache_readahead+0x10a/0x194 [] page_cache_readahead+0x191/0x1c8 [] do_generic_mapping_read+0xe6/0x464 [] generic_file_sendfile+0x51/0x64 [] file_send_actor+0x0/0x50 [] xfs_sendfile+0x152/0x1a4 [] file_send_actor+0x0/0x50 [] file_send_actor+0x0/0x50 [] linvfs_sendfile+0x36/0x40 [] file_send_actor+0x0/0x50 [] do_sendfile+0x246/0x294 [] file_send_actor+0x0/0x50 [] sys_sendfile64+0x3c/0xa0 [] syscall_call+0x7/0xb Btw, would it be possible to directly boot the box in the sysrq case instead of going through the smp functions as it looks they do not always have the desired effect? Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1-ac10: Oooops in SCSI
Hi! I've got an ooops today on a 2.4.1-ac10 running three bonnie++ in parallel on the RAID-Array. The machine is a IBM Netfinity 7100-8666 with 2.5G RAM and 4 CPUs, the RAID-Controller is an IBM ServeRAID 4L using the ips driver. All filesystems on this machine are ext2. (ips0) Resetting controller. (several times) Unable to handle kernel NULL pointer dereference at virtual address 0178f889b9e3 *pde = Oops: 0002 CPU:3 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010046 eax: ebx: c02d5640 ecx: f720c6b8 edx: esi: 0002 edi: f720c6cc ebp: esp: c3ab5da0 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c3ab5000) Stack: f720c6b8 f6dcce00 f720c678 f720c600 c3ab5dfc f6dd7c00 f720c6b8 f720c680 f6dcce00 3a8a6121 000d06e7 f889a564 f720c678 0001 0202 f78484d8 f6dd7c00 f720c600 0001 c3ab5e08 c3ab5e08 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: c7 85 78 01 00 00 00 00 00 00 c7 85 74 01 00 00 00 00 00 00 >>EIP; f889b9e3<= Trace; f889a564 Trace; c01be446 Trace; c01beab0 Trace; c01c558c Trace; c01c4c26 Trace; c01c4e28 <__scsi_end_request+140/14c> Trace; c01c5072 Trace; c01e18b2 Trace; c01beefb Trace; c01bed96 Trace; c011ab41 Trace; c011aa27 Trace; c011a8cc Trace; c010a7c5 Trace; c0107170 Trace; c0107170 Trace; c010900c Trace; c0107170 Trace; c0107170 Trace; c0100018 Trace; c010719c Trace; c0107202 Trace; c0116c36 Code; f889b9e3 <_EIP>: Code; f889b9e3<= 0: c7 85 78 01 00 00 00 movl $0x0,0x178(%ebp) <= Code; f889b9ea 7: 00 00 00 Code; f889b9ed a: c7 85 74 01 00 00 00 movl $0x0,0x174(%ebp) Code; f889b9f4 11: 00 00 00 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing 1 warning and 2 errors issued. Results may not be reliable. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://a.home.dhs.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI bridge handling 2.4.0-test10 -> 2.4.2-pre3
On Tue Feb 13, 2001 at 12:20:14 +0100, Jan-Benedict Glaw wrote: > On Tue, Feb 13, 2001 at 12:38:15AM +0100, Adam Lackorzynski wrote: > > On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote: > > > I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID > > > controller. The mainboard is ServerWorks based and however, 2.4.2-pre3 > > > fails to find the RAID controller. I think there's a problem at > > > scanning PCI busses behind PCI bridges. Here's the PCI bus layout as > > > 2.4.0-test10 recognizes it: > > > > --- pci-pc.c.orig Tue Feb 13 00:02:50 2001 > > +++ pci-pc.cTue Feb 13 00:19:29 2001 > > @@ -953,9 +953,6 @@ > [Removal of serverworks fixup routines] > > That patch cured the problem; the box is up'n'running again. Thanks! Ok, fine. Since this patch works for Jan, Dan and me I'd suggest putting it into the kernel and thus removing the fixup routines (Anyone know the reason why they're there?). Comments?! Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://a.home.dhs.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI bridge handling 2.4.0-test10 -> 2.4.2-pre3
On Mon Feb 12, 2001 at 14:04:20 +0100, Jan-Benedict Glaw wrote:
> I've got a "Bull Express5800/Series" (dual P3) with a DAC1164 RAID
> controller. The mainboard is ServerWorks based and however, 2.4.2-pre3
> fails to find the RAID controller. I think there's a problem at
> scanning PCI busses behind PCI bridges. Here's the PCI bus layout as
> 2.4.0-test10 recognizes it:
There's was a change in the PCI bus scan code in pre3.
Could you please apply the following patch to arch/i386/kernel/pci-pc.c (against
2.4.1-pre3) and tell us your results? The fixup functions do not seem to
work right now so we'll trust the BIOS...
--- pci-pc.c.orig Tue Feb 13 00:02:50 2001
+++ pci-pc.cTue Feb 13 00:19:29 2001
@@ -953,9 +953,6 @@
struct pci_fixup pcibios_fixups[] = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82451NX,
pci_fixup_i450nx },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82454GX,
pci_fixup_i450gx },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_HE, pci_fixup_serverworks },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_LE, pci_fixup_serverworks },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_CMIC_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_6010,
pci_fixup_compaq },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_UMC, PCI_DEVICE_ID_UMC_UM8886BF,
pci_fixup_umc_ide },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_5513,
pci_fixup_ide_trash },
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://a.home.dhs.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://vger.kernel.org/lkml/
Re: [Patch] ServerWorks peer bus fix for 2.4.x
On Thu Feb 08, 2001 at 03:06:27 -0800, Andre Hedrick wrote: > Have you got a hack for 2.2.18/19x ?? I do not have problems with 2.2.x Kernels here. They see all the PCI devices just fine. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://a.home.dhs.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI-Devices and ServerWorks chipset
On Wed Jan 17, 2001 at 09:52:21 +0100, Martin Mares wrote:
> Hello!
>
> > The patch below (against vanilla 2.4.0) makes Linux recognize
> > PCI-Devices sitting in another PCI bus than 0 (or 1).
> >
> > This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
>
> I don't have the ServerWorks chipset documentation at hand, but I think your
> patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers
Another possible workaround for my problem is just not to call the
fixup routine for the chipset:
--- pci-pc.c~Thu Jun 22 16:17:16 2000
+++ pci-pc.cTue Jan 23 18:46:55 2001
@@ -927,7 +927,6 @@
struct pci_fixup pcibios_fixups[] = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82451NX,
pci_fixup_i450nx },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82454GX,
pci_fixup_i450gx },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_LE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_CMIC_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_6010,
pci_fixup_compaq },
This patch is against 2.4.0-ac10. Having the above line in the PCI devices do
not occur, leaving it out they appear.
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://a.home.dhs.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI-Devices and ServerWorks chipset
Hi! On Wed Jan 17, 2001 at 09:52:21 +0100, Martin Mares wrote: > > The patch below (against vanilla 2.4.0) makes Linux recognize > > PCI-Devices sitting in another PCI bus than 0 (or 1). > > > > This was tested on a Netfinity 7100-8666 using a ServerWorks chipset. > > I don't have the ServerWorks chipset documentation at hand, but I think your > patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers > 0x44 and 0x45 are probably ID's of two primary buses and the code should scan > both of them, but not the space between them. I was just inspired by the comment in this function and knew that this "patch" was probably wrong but it was enough to get someone else' eyes watching on it ... :-) BTW, one line of dmesg says: PCI: PCI BIOS revision 2.10 entry at 0xfd5cc, last bus=6 So that "6" in 0x45 made some sense to me... > Anyway, could you send me a `lspci -MH1 -vvx' and `lspci -vvxxx -s0:0', please? $ lspci -MH1 -vvx 00:00.0 Host bridge: ServerWorks CNB20HE (rev 21) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://a.home.dhs.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI-Devices and ServerWorks chipset
The patch below (against vanilla 2.4.0) makes Linux recognize
PCI-Devices sitting in another PCI bus than 0 (or 1).
This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
00:00.0 Host bridge: ServerWorks CNB20HE (rev 21)
00:00.1 Host bridge: ServerWorks CNB20HE (rev 01)
00:00.2 Host bridge: ServerWorks: Unknown device 0006
00:00.3 Host bridge: ServerWorks: Unknown device 0006
00:01.0 SCSI storage controller: Adaptec 7896
00:01.1 SCSI storage controller: Adaptec 7896
00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
00:06.0 VGA compatible controller: S3 Inc. Trio 64 3D (rev 01)
00:0f.0 ISA bridge: ServerWorks OSB4 (rev 4f)
00:0f.1 IDE interface: ServerWorks: Unknown device 0211
00:0f.2 USB Controller: ServerWorks: Unknown device 0220 (rev 04)
02:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
02:06.0 RAID bus controller: IBM: Unknown device 01bd
The last two lines do not occur without the patch.
diff -ur linux-2.4.0/linux/arch/i386/kernel/pci-pc.c linux/arch/i386/kernel/pci-pc.c
--- linux-2.4.0/linux/arch/i386/kernel/pci-pc.c Thu Jun 22 16:17:16 2000
+++ linux/arch/i386/kernel/pci-pc.c Tue Jan 16 18:10:30 2001
@@ -849,10 +849,13 @@
* ServerWorks host bridges -- Find and scan all secondary buses.
* Register 0x44 contains first, 0x45 last bus number routed there.
*/
- u8 busno;
- pci_read_config_byte(d, 0x44, &busno);
- printk("PCI: ServerWorks host bridge: secondary bus %02x\n", busno);
- pci_scan_bus(busno, pci_root_ops, NULL);
+ u8 busno_first, busno_last, i;
+ pci_read_config_byte(d, 0x44, &busno_first);
+ pci_read_config_byte(d, 0x45, &busno_last);
+ for (i = busno_first; i <= busno_last; i++) {
+ printk("PCI: ServerWorks host bridge: secondary bus %02x\n", i);
+ pci_scan_bus(i, pci_root_ops, NULL);
+ }
pcibios_last_bus = -1;
}
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://a.home.dhs.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test13-pre4 doesn't detect PCI devices
Hi! Kernel 2.4.0-test13-pre4 (without any patches) does not see some of the PCI devices with my setup here. The machine is a IBM Netfinity 7100 Quad-Xeon with a Serverworks Chipset. The RAID-Controller (a IBM ServeRAID-4L) is not detected. Kernel 2.2.17 detects it. I also checked -test10 and -test12 kernels which suffer the same problem. $ lspci 00:00.0 Host bridge: ServerWorks CNB20HE (rev 21) 00:00.1 Host bridge: ServerWorks CNB20HE (rev 01) 00:00.2 Host bridge: ServerWorks: Unknown device 0006 00:00.3 Host bridge: ServerWorks: Unknown device 0006 00:01.0 SCSI storage controller: Adaptec 7896 00:01.1 SCSI storage controller: Adaptec 7896 00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44) 00:06.0 VGA compatible controller: S3 Inc. Trio 64 3D (rev 01) 00:0f.0 ISA bridge: ServerWorks OSB4 (rev 4f) 00:0f.1 IDE interface: ServerWorks: Unknown device 0211 00:0f.2 USB Controller: ServerWorks: Unknown device 0220 (rev 04) $ lspci -vv -s 00:00.0 00:00.0 Host bridge: ServerWorks CNB20HE (rev 21) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- found at PCI 0/1/0 (scsi1) found at PCI 0/1/1 scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.31/3.2.4 scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.31/3.2.4 pcnet32.c: PCI bios is present, checking for devices... Found PCnet/PCI at 0x2200, irq 11. $ uname -r 2.4.0-test13-pre4 $ dmesg | grep -i pci Bus #0 is PCI Bus #1 is PCI Bus #2 is PCI Bus #3 is PCI Bus #4 is PCI Bus #5 is PCI Bus #6 is PCI PCI: PCI BIOS revision 2.10 entry at 0xfd5cc, last bus=6 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: ServerWorks host bridge: secondary bus 01 PCI: ServerWorks host bridge: secondary bus 00 PCI->APIC IRQ transform: (B0,I1,P0) -> 17 PCI->APIC IRQ transform: (B0,I1,P0) -> 17 PCI->APIC IRQ transform: (B0,I5,P0) -> 16 PCI->APIC IRQ transform: (B0,I15,P0) -> 26 ServerWorks OSB4: IDE controller on PCI bus 00 dev 79 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled pcnet32_probe_pci: found device 0x001022.0x002000 (scsi0) found at PCI 0/1/0 (scsi1) found at PCI 0/1/1 scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 I plugged an additional nic (tulip) into the same bus but it is not detected as well. Any hints? Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://a.home.dhs.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
