Asus CUV4X-DLS apic fun (pre8/ac22)
With apic enabled on this board, some normal amount of disk access (including building a kernel) is successful. However, irqs are messed up. The eepro100 module for the onboard 82559 nic loads, but prints this after the revision history: PCI: No IRQ known for interrupt pin A of device 00:07.0. Probably buggy MP table. Also, when booting with apic, I get this (with both MP Spec 1.1 and 1.4) ... IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail to [EMAIL PROTECTED] dmesg for both MP Spec 1.1 and 1.4 for ac8 boot are attached (it looks like there's one more irq in one of the modes, eepro has same error on both). ac22 has the same io-apic warning and eepro100 load-time messages. with noapic, dmesg includes this nugget of information after eepro100 revision history and before all the usual diagnostic s and self-tests: PCI: Enabling device 00:07.0 (0014 ->0017) PCI: Assigned IRQ 5 for device 00:07.0 This is all with the latest bios vdls1010. The changelog lists "Support Solaris 8.0 dual processor environment" so I thought it was worth a shot, but doesn't seem to fix the problem. On Wed, 27 Jun 2001, J. Nick Koston wrote: > There seems to be a major problem with this board and 2.4.x kernels. > I consistantly get SCSI Input/Output errors on multiple drives that I > know are good when running a SMP kernel. These errors do no happen > with a UP kernel. This is happening on multiple systems and with > multiple know good scsi drives of all speeds and sizes. (modified) > Test#1: > dd if=/dev/sdc of=/dev/null > (fails with input/output error) When running this (kernel booted with noapic), I get no io errors (only ran it once), but there is a bit of disk access on sda. It seems the kernel (2.4.6-pre8) has decided to use 4MB of swap in addition to the 200+MB of physical ram. I guess this is another weird system situation that the vm could be optimized for, but at the expense of good performance for the other 99% of the world. Mem: 255436K av, 250848 used, 4588k free, 0k shared, 222712k buff swap: 205k av, 4192k used, 2045808k free 644k cached bdflush and kswapd are taking 1-5% cpu each vmstat: 1 0 0 4160 3572 219376 4232 4 2 5275 795 148 3684 2 9 89 justin Linux version 2.4.6-pre8 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010315 (release)) #2 SMP Mon Jul 2 06:13:18 EDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fffc000 (usable) BIOS-e820: 0fffc000 - 0000 (ACPI data) BIOS-e820: 0000 - 1000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f5530 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. On node 0 totalpages: 65532 zone(0): 4096 pages. zone(1): 61436 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #3 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bus #0 is PCI Bus #1 is PCI Bus #2 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 0, trig 0, bus 2, IRQ 05, APIC ID 2, APIC INT 05 Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 0, trig 0, bus 2, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 2, IRQ 09, APIC ID 2, APIC INT 09 Int: type 0, pol 0,
Re: Asus CUV4X-DLS
I thought it was ok with a 2.4.5-ac kernel however it started
acting up again today giving more i/o errors. I think I'm just going
to give up on these boards as I have 3 of them doing the exact same
thing. However they are flawless in up mode.
Nick
On Thu, Jun 28, 2001 at 04:11:32AM -0400, Chris Siebenmann wrote:
> Envelope-to: [EMAIL PROTECTED]
> Delivery-date: Thu, 28 Jun 2001 04:11:14 -0400
> To: [EMAIL PROTECTED] ("J. Nick Koston")
> Subject: Re: Asus CUV4X-DLS
> X-Newsgroups: mail.linux.kernel
> In-Reply-To: [EMAIL PROTECTED]>
> Organization: Ziebmef home away from home
> Date: Thu, 28 Jun 2001 04:11:32 -0400
> From: Chris Siebenmann <[EMAIL PROTECTED]>
>
> You write:
> | Anyways in case anyone is curious the i/o problem still happens
> | with an aic7xxx card put in and the onboard scsi disabled.
>
> That's odd; our CUV4X-DLS is stable with PCI Adaptec cards in (but the
> onboard Symbios controllers have problems). We're running various -ac
> kernels (2.4.5-ac18 right now), SMP, etc. We currently have three SCSI
> channels and two disks per channel, and it's surviving the VA Linux
> stress tests quite handily.
>
> ---
> "I shall clasp my hands together and bow to the corners of the world."
> Number Ten Ox, "Bridge of Birds"
> [EMAIL PROTECTED] utgpu!cks
--
BurstNET - The Speed the Internet Travels
To place an order, or for more info, contact;
BurstNET Technologies, Inc. - BurstNET
Toll Free 24/7/365 Support: 1-877-BURSTNET
Phone (570) 389-1100 - Fax (570) 389-1855=20
http://www.burst.net - [EMAIL PROTECTED]
P.O. Box #400 Bloomsburg, PA 17815-0400 USA
A World Wide Leader in Web Hosting & Internet Solutions
The Best Value For Your Dollar On The Net!
Copyright 1996-2000 ©
BurstNET Technologies, Inc.
All Rights Reserved.
PGP signature
Re: Asus CUV4X-DLS
I thought it was ok with a 2.4.5-ac kernel however it started acting up again today giving more i/o errors. I think I'm just going to give up on these boards as I have 3 of them doing the exact same thing. However they are flawless in up mode. Nick On Thu, Jun 28, 2001 at 04:11:32AM -0400, Chris Siebenmann wrote: Envelope-to: [EMAIL PROTECTED] Delivery-date: Thu, 28 Jun 2001 04:11:14 -0400 To: [EMAIL PROTECTED] (J. Nick Koston) Subject: Re: Asus CUV4X-DLS X-Newsgroups: mail.linux.kernel In-Reply-To: mail.linux.kernel/[EMAIL PROTECTED] Organization: Ziebmef home away from home Date: Thu, 28 Jun 2001 04:11:32 -0400 From: Chris Siebenmann [EMAIL PROTECTED] You write: | Anyways in case anyone is curious the i/o problem still happens | with an aic7xxx card put in and the onboard scsi disabled. That's odd; our CUV4X-DLS is stable with PCI Adaptec cards in (but the onboard Symbios controllers have problems). We're running various -ac kernels (2.4.5-ac18 right now), SMP, etc. We currently have three SCSI channels and two disks per channel, and it's surviving the VA Linux stress tests quite handily. --- I shall clasp my hands together and bow to the corners of the world. Number Ten Ox, Bridge of Birds [EMAIL PROTECTED] utgpu!cks -- BurstNET - The Speed the Internet Travels To place an order, or for more info, contact; BurstNET Technologies, Inc. - BurstNET Toll Free 24/7/365 Support: 1-877-BURSTNET Phone (570) 389-1100 - Fax (570) 389-1855=20 http://www.burst.net - [EMAIL PROTECTED] P.O. Box #400 Bloomsburg, PA 17815-0400 USA A World Wide Leader in Web Hosting Internet Solutions The Best Value For Your Dollar On The Net! Copyright 1996-2000 © BurstNET Technologies, Inc. All Rights Reserved. PGP signature
Asus CUV4X-DLS apic fun (pre8/ac22)
With apic enabled on this board, some normal amount of disk access (including building a kernel) is successful. However, irqs are messed up. The eepro100 module for the onboard 82559 nic loads, but prints this after the revision history: PCI: No IRQ known for interrupt pin A of device 00:07.0. Probably buggy MP table. Also, when booting with apic, I get this (with both MP Spec 1.1 and 1.4) ... IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail to [EMAIL PROTECTED] dmesg for both MP Spec 1.1 and 1.4 for ac8 boot are attached (it looks like there's one more irq in one of the modes, eepro has same error on both). ac22 has the same io-apic warning and eepro100 load-time messages. with noapic, dmesg includes this nugget of information after eepro100 revision history and before all the usual diagnostic s and self-tests: PCI: Enabling device 00:07.0 (0014 -0017) PCI: Assigned IRQ 5 for device 00:07.0 This is all with the latest bios vdls1010. The changelog lists Support Solaris 8.0 dual processor environment so I thought it was worth a shot, but doesn't seem to fix the problem. On Wed, 27 Jun 2001, J. Nick Koston wrote: There seems to be a major problem with this board and 2.4.x kernels. I consistantly get SCSI Input/Output errors on multiple drives that I know are good when running a SMP kernel. These errors do no happen with a UP kernel. This is happening on multiple systems and with multiple know good scsi drives of all speeds and sizes. (modified) Test#1: dd if=/dev/sdc of=/dev/null (fails with input/output error) When running this (kernel booted with noapic), I get no io errors (only ran it once), but there is a bit of disk access on sda. It seems the kernel (2.4.6-pre8) has decided to use 4MB of swap in addition to the 200+MB of physical ram. I guess this is another weird system situation that the vm could be optimized for, but at the expense of good performance for the other 99% of the world. Mem: 255436K av, 250848 used, 4588k free, 0k shared, 222712k buff swap: 205k av, 4192k used, 2045808k free 644k cached bdflush and kswapd are taking 1-5% cpu each vmstat: 1 0 0 4160 3572 219376 4232 4 2 5275 795 148 3684 2 9 89 justin Linux version 2.4.6-pre8 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010315 (release)) #2 SMP Mon Jul 2 06:13:18 EDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fffc000 (usable) BIOS-e820: 0fffc000 - 0000 (ACPI data) BIOS-e820: 0000 - 1000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f5530 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. On node 0 totalpages: 65532 zone(0): 4096 pages. zone(1): 61436 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #3 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bus #0 is PCI Bus #1 is PCI Bus #2 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 0, trig 0, bus 2, IRQ 05, APIC ID 2, APIC INT 05 Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 0, trig 0, bus 2, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 2, IRQ 09, APIC ID 2, APIC INT 09 Int: type 0, pol 0, trig 0, bus 2,
Re: Asus CUV4X-DLS
It seems to be ok with 2.4.5-ac19, so I guess I'll just wait for 2.4.6 and hope that resolves it for good. Nick On Thu, Jun 28, 2001 at 08:27:17AM -0400, John Cavan wrote: > Envelope-to: [EMAIL PROTECTED] > Delivery-date: Thu, 28 Jun 2001 08:26:20 -0400 > Date: Thu, 28 Jun 2001 08:27:17 -0400 > From: John Cavan <[EMAIL PROTECTED]> > X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.5-ac18 i686) > X-Accept-Language: en > To: "J. Nick Koston" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Asus CUV4X-DLS > > John Cavan wrote: > > I have an AIC7 based SCSI card in my machine as well, hooked up to a > > Jaz. I haven't actually used it in ages, but I'll test it to see of the > > problem is apparent on CUV4X-D board as well. > > First, I copied 640 Mb file to the jaz disk, no problem. Then I ran the > same commands you did, also no problem... > > That would imply, at least, that the SCSI drivers are not at fault here. > > John -- BurstNET - The Speed the Internet Travels To place an order, or for more info, contact; BurstNET Technologies, Inc. - BurstNET Toll Free 24/7/365 Support: 1-877-BURSTNET Phone (570) 389-1100 - Fax (570) 389-1855=20 http://www.burst.net - [EMAIL PROTECTED] P.O. Box #400 Bloomsburg, PA 17815-0400 USA A World Wide Leader in Web Hosting & Internet Solutions The Best Value For Your Dollar On The Net! Copyright 1996-2000 © BurstNET Technologies, Inc. All Rights Reserved. PGP signature
Re: Asus CUV4X-DLS
John Cavan wrote: > I have an AIC7 based SCSI card in my machine as well, hooked up to a > Jaz. I haven't actually used it in ages, but I'll test it to see of the > problem is apparent on CUV4X-D board as well. First, I copied 640 Mb file to the jaz disk, no problem. Then I ran the same commands you did, also no problem... That would imply, at least, that the SCSI drivers are not at fault here. John - 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: Asus CUV4X-DLS
"J. Nick Koston" wrote: > > Thanks for the tips, however it doesn't help :-( It was worth a shot... > > Also, try passing "noapic" to the kernel on boot if the problem still > > persists. The downside is that all interrupts will be handled by a > > single CPU. There is a definite problem with VIA chipsets. > > > Tried this as well (mentioned in my original email) I realized that after I sent the message. Doh! I have an AIC7 based SCSI card in my machine as well, hooked up to a Jaz. I haven't actually used it in ages, but I'll test it to see of the problem is apparent on CUV4X-D board as well. John - 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: Asus CUV4X-DLS
J. Nick Koston wrote: Thanks for the tips, however it doesn't help :-( It was worth a shot... Also, try passing noapic to the kernel on boot if the problem still persists. The downside is that all interrupts will be handled by a single CPU. There is a definite problem with VIA chipsets. Tried this as well (mentioned in my original email) I realized that after I sent the message. Doh! I have an AIC7 based SCSI card in my machine as well, hooked up to a Jaz. I haven't actually used it in ages, but I'll test it to see of the problem is apparent on CUV4X-D board as well. John - 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: Asus CUV4X-DLS
John Cavan wrote: I have an AIC7 based SCSI card in my machine as well, hooked up to a Jaz. I haven't actually used it in ages, but I'll test it to see of the problem is apparent on CUV4X-D board as well. First, I copied 640 Mb file to the jaz disk, no problem. Then I ran the same commands you did, also no problem... That would imply, at least, that the SCSI drivers are not at fault here. John - 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: Asus CUV4X-DLS
It seems to be ok with 2.4.5-ac19, so I guess I'll just wait for 2.4.6 and hope that resolves it for good. Nick On Thu, Jun 28, 2001 at 08:27:17AM -0400, John Cavan wrote: Envelope-to: [EMAIL PROTECTED] Delivery-date: Thu, 28 Jun 2001 08:26:20 -0400 Date: Thu, 28 Jun 2001 08:27:17 -0400 From: John Cavan [EMAIL PROTECTED] X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.5-ac18 i686) X-Accept-Language: en To: J. Nick Koston [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Asus CUV4X-DLS John Cavan wrote: I have an AIC7 based SCSI card in my machine as well, hooked up to a Jaz. I haven't actually used it in ages, but I'll test it to see of the problem is apparent on CUV4X-D board as well. First, I copied 640 Mb file to the jaz disk, no problem. Then I ran the same commands you did, also no problem... That would imply, at least, that the SCSI drivers are not at fault here. John -- BurstNET - The Speed the Internet Travels To place an order, or for more info, contact; BurstNET Technologies, Inc. - BurstNET Toll Free 24/7/365 Support: 1-877-BURSTNET Phone (570) 389-1100 - Fax (570) 389-1855=20 http://www.burst.net - [EMAIL PROTECTED] P.O. Box #400 Bloomsburg, PA 17815-0400 USA A World Wide Leader in Web Hosting Internet Solutions The Best Value For Your Dollar On The Net! Copyright 1996-2000 © BurstNET Technologies, Inc. All Rights Reserved. PGP signature
Re: Asus CUV4X-DLS
Thanks for the tips, however it doesn't help :-( Anyways in case anyone is curious the i/o problem still happens with an aic7xxx card put in and the onboard scsi disabled. [snip] > "J. Nick Koston" wrote: > > > > There seems to be a major problem with this board and 2.4.x kernels. > > I consistantly get SCSI Input/Output errors on multiple drives that I > > know are good when running a SMP kernel. These errors do no happen > > with a UP kernel. This is happening on multiple systems and with > > multiple know good scsi drives of all speeds and sizes. > > Make sure you have the latest BIOS upgrade and set the MPS revision in > the BIOS to 1.1 rather than 1.4. This cured a similar issue for me and > USB on the CUV4X-D motherboard, but as your board is different, your > mileage may vary. Already set at 1.1 > > Also, try passing "noapic" to the kernel on boot if the problem still > persists. The downside is that all interrupts will be handled by a > single CPU. There is a definite problem with VIA chipsets. > Tried this as well (mentioned in my original email) > John -- PGP signature
Asus CUV4X-DLS
There seems to be a major problem with this board and 2.4.x kernels. I consistantly get SCSI Input/Output errors on multiple drives that I know are good when running a SMP kernel. These errors do no happen with a UP kernel. This is happening on multiple systems and with multiple know good scsi drives of all speeds and sizes. Test#1: 2.4.2 (redhat 7.1 version) dd if=/dev/sda of=/dev/null (fails with input/output error) Test #2: 2.4.2 (redhat 7.1 version) noapic on boot dd if=/dev/sda of=/dev/null (fails with input/output error) Test #3: 2.4.2 (redhat 7.1 edition) dd if=/dev/sda of=/dev/null PASS! Nick -- PGP signature
Asus CUV4X-DLS
There seems to be a major problem with this board and 2.4.x kernels. I consistantly get SCSI Input/Output errors on multiple drives that I know are good when running a SMP kernel. These errors do no happen with a UP kernel. This is happening on multiple systems and with multiple know good scsi drives of all speeds and sizes. Test#1: 2.4.2 (redhat 7.1 version) dd if=/dev/sda of=/dev/null (fails with input/output error) Test #2: 2.4.2 (redhat 7.1 version) noapic on boot dd if=/dev/sda of=/dev/null (fails with input/output error) Test #3: 2.4.2 (redhat 7.1 edition) dd if=/dev/sda of=/dev/null PASS! Nick -- PGP signature
Re: Asus CUV4X-DLS
Thanks for the tips, however it doesn't help :-( Anyways in case anyone is curious the i/o problem still happens with an aic7xxx card put in and the onboard scsi disabled. [snip] J. Nick Koston wrote: There seems to be a major problem with this board and 2.4.x kernels. I consistantly get SCSI Input/Output errors on multiple drives that I know are good when running a SMP kernel. These errors do no happen with a UP kernel. This is happening on multiple systems and with multiple know good scsi drives of all speeds and sizes. Make sure you have the latest BIOS upgrade and set the MPS revision in the BIOS to 1.1 rather than 1.4. This cured a similar issue for me and USB on the CUV4X-D motherboard, but as your board is different, your mileage may vary. Already set at 1.1 Also, try passing noapic to the kernel on boot if the problem still persists. The downside is that all interrupts will be handled by a single CPU. There is a definite problem with VIA chipsets. Tried this as well (mentioned in my original email) John -- PGP signature
Re: 2.4.4 Kernel - ASUS CUV4X-DLS Question
> When it gets to the point of activating the second processor, kernel > 2.4.3-ac13 starts spewing: > > probable hardware bug: clock timer configuration lost - probably a VIA686a >motherboard. > probable hardware bug: restoring chip configuration. That is useful informtion. The kernel is seeing the interval timer overrun which implies things are very very stuck - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
When it gets to the point of activating the second processor, kernel 2.4.3-ac13 starts spewing: probable hardware bug: clock timer configuration lost - probably a VIA686a motherboard. probable hardware bug: restoring chip configuration. That is useful informtion. The kernel is seeing the interval timer overrun which implies things are very very stuck - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
All, I unfortunately don't have the time this evening to produce actual kernel messages, but I did want to throw out that I have an ASUS CUV4X-DLS board too, with two PIII/1GHz processors in it, and I cannot get it to boot an SMP kernel at all. In addition to the built-in devices, the following cards are also present: * Netgear FA310TX (rev. D, I believe - lspci reports it as a Lite-On LNE100TX rev 21) * Promise PDC20267 Ultra100 controller * Creative SB Live! Value * Matrox G200 AGP When it gets to the point of activating the second processor, kernel 2.4.3-ac13 starts spewing: probable hardware bug: clock timer configuration lost - probably a VIA686a motherboard. probable hardware bug: restoring chip configuration. continuously. Older kernels simply hang at this point. I'll try to get the actual messages leading up to this tomorrow. Also, if there's any other information I can collect from my system that could help, feel free to ask. I'll also build 2.4.4-ac6 on it tomorrow and try booting it SMP. Here's the output of lspci -vv: 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) Subsystem: Asustek Computer, Inc.: Unknown device 8038 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: Asustek Computer, Inc.: Unknown device 8038 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=256K] 00:0b.0 Unknown mass storage controller: Promise Technology, Inc. 20267 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] Capabilities: [58] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:0c.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 08) Subsystem: Creative Labs CT4832 SBLive! Value Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Starting kswapd v1.8 Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ... SMSC Super-IO detection, now testing Ports 2F0, 370 ... 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: ECP port cfgA=0x10 cfgB=0x00 0x378: ECP settings irq= dma= parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP] parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport_pc: Via 686A parallel port: io=0x378 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured lp0: using parport0 (polling). block: queued sectors max/low 169506kB/56502kB, 512 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 21 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:04.1 ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA PDC20267: IDE controller on PCI bus 00 dev 58 PCI: Found IRQ 10 for device 00:0b.0 PCI: The same IRQ used for device 00:07.0 PDC20267: chipset revision 2 PDC20267: not 100% native mode: will probe irqs later PDC20267: (U)DMA Burst Bit ENAB
Re: 2.4.4 Kernel - ASUS CUV4X-DLS Question
All, I unfortunately don't have the time this evening to produce actual kernel messages, but I did want to throw out that I have an ASUS CUV4X-DLS board too, with two PIII/1GHz processors in it, and I cannot get it to boot an SMP kernel at all. In addition to the built-in devices, the following cards are also present: * Netgear FA310TX (rev. D, I believe - lspci reports it as a Lite-On LNE100TX rev 21) * Promise PDC20267 Ultra100 controller * Creative SB Live! Value * Matrox G200 AGP When it gets to the point of activating the second processor, kernel 2.4.3-ac13 starts spewing: probable hardware bug: clock timer configuration lost - probably a VIA686a motherboard. probable hardware bug: restoring chip configuration. continuously. Older kernels simply hang at this point. I'll try to get the actual messages leading up to this tomorrow. Also, if there's any other information I can collect from my system that could help, feel free to ask. I'll also build 2.4.4-ac6 on it tomorrow and try booting it SMP. Here's the output of lspci -vv: 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) Subsystem: Asustek Computer, Inc.: Unknown device 8038 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR+ Latency: 0 Region 0: Memory at fc00 (32-bit, prefetchable) [size=32M] Capabilities: [a0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate=none Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: e000-dfff Memory behind bridge: f980-fadf Prefetchable memory behind bridge: faf0-fbff BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: Asustek Computer, Inc.: Unknown device 8038 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 Region 4: I/O ports at d800 [size=16] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:07.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (2000ns min, 14000ns max), cache line size 08 Interrupt: pin A routed to IRQ 10 Region 0: Memory at f900 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at b800 [size=64] Region 2: Memory at f880 (32-bit, non
Re: 2.4.4 Kernel - ASUS CUV4X-DLS Question
I have some info at "http://web.irridia.com/linux/; from an LPr having issues, including the dmidecode output and a mostly complete boot-time dmesg dump from an LPr and LP1000r. The LPr was running 2.4.2-pre4 and the LP1000r is running 2.4.5-pre1, both without "noapic". Please let me know if you need more info. BTW, I have an isolated bank of redundant machines, one of which I can load down with heavy live load so I can test patches pretty easily. I'll do anything, including setting fire to a machine, if it'll help. :-) -- Ken. On Thursday, May 3, 2001, at 03:23 PM, Alan Cox wrote: >> But the distributions use _the_ kernel. Even if -ac is fixed, it's not >> really something I would be willing to put in production. Until I >> found > > Actually by unit count Linus is currently losing to me on 2.4 shipping. > Thats one reason I really want to get the stuff I have back into the > main > tree. > >> the noapic work-around, we were basically going to have to move off of >> Linux. I could very well be an isolated case, but the APIC issues I'm >> seeing scare me, and not just for my sake. > > Can you give me the detailed boot up messages from one of your HP boxes > and > some more info. Also can you run dmidecode.c from > ftp://ftp.linux.org.uk/pub/linux/alan > > on them and send me the DMI strings. You will need to run it as root but > it can be run on a live system (at least I dont know of any bugs in it > and > it only reads from raw BIOS memory not writes). > > Alan - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
> But the distributions use _the_ kernel. Even if -ac is fixed, it's not > really something I would be willing to put in production. Until I found Actually by unit count Linus is currently losing to me on 2.4 shipping. Thats one reason I really want to get the stuff I have back into the main tree. > the noapic work-around, we were basically going to have to move off of > Linux. I could very well be an isolated case, but the APIC issues I'm > seeing scare me, and not just for my sake. Can you give me the detailed boot up messages from one of your HP boxes and some more info. Also can you run dmidecode.c from ftp://ftp.linux.org.uk/pub/linux/alan on them and send me the DMI strings. You will need to run it as root but it can be run on a live system (at least I dont know of any bugs in it and it only reads from raw BIOS memory not writes). Alan - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
I'm losing the timer interrupt, but it's not driver-specific -- only the motherboard is required to reproduce for me; different SCSI, RAID, and ether drivers have been swapped out. Nothing with "HP" on it seems to work, and it wouldn't surprise me in the least to find out that HP's stuff is broken. But this problem has existed since 2.4.0-test1 and hasn't changed, and it surprises me that at least a work-around hasn't been merged into "the" kernel by now. There might be fixes in the -ac tree that effect my problem -- I'll try the latest -ac and see what happens. Thanks for the suggestion. But the distributions use _the_ kernel. Even if -ac is fixed, it's not really something I would be willing to put in production. Until I found the noapic work-around, we were basically going to have to move off of Linux. I could very well be an isolated case, but the APIC issues I'm seeing scare me, and not just for my sake. I mean all of this in the utmost respect -- I just felt that this issue needs a little more light shed on it, and I'm here to help in any way I can. -- Ken. On Thursday, May 3, 2001, at 02:24 PM, Hugh Dickins wrote: > On Thu, 3 May 2001, Alan Cox wrote on APIC problems in 2.4: >> There are five cases I am seeing >> 1. Serverworks total APIC hose ups. >> Fix: remove OSB4 or use -ac tree >> 2. 440BX and similar boards losing interrupts on some drivers >> Fix: use -ac >> 3. APIC errors notably checksum errors. >> Fix: buy properly manufactured hardware >> 4. Hangs on boot with the CUV4XD and a couple of other boards. >> Still a mystery >> 5. Incorrect PCI IRQ routing >> Fix: Mostly get a board with a correct BIOS. There are a couple of >> cases people are looking at - some are fixed in 2.4.4 and -ac >> where magic IRQ lines are not visible directly in PCI space > > Doesn't 2.4.1-ac1 onwards contain: > > o Workaround code for APIC problems with ne2k (Maciej Rozycki) > | this will break original 82489DX devices for now > | ie _very_ early dual pentium boards > > Got good reviews at the time, and I thought it was more general than > ne2k. I don't remember it going forward to Linus (but I've not looked). > > Hugh > > - > 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/ - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
The failure mode I'm seeing is that the timer interrupt disappears. Hard to schedule processes at that point. I'm not seeing the IRQ issues personally. HP's LP1000r machine uses ServerWorks, but still shows the problem. I only have access to HP SMP hardware currently, but they all have the same issue. I've heard of Tyan and Asus issues (not just the one recently posted), though I have an LX machine that has been okay with 2.4. I've seen the VIA issues, but they aren't related from what I can tell. -- Ken. On Thursday, May 3, 2001, at 01:17 PM, Mark Hahn wrote: >> I just wanted to throw in my two cents and say that there appear to be >> widespread issues with the APIC code in 2.4.x. I'm tempted to stick my > > are there any known problems on non-VIA boards? BX seems to work fine, > and I haven't heard of any problems from serverworks people. > > I'm guessing (wag) that there's some VIA-specific thing that needs > to be done to get the PIT timer working with io-apic. no real problem > with apic/ioapic, just some little divergence on VIA's part. > >> from APICitis. I realize there are different failure modes and I >> assume >> different issues are involved within the APIC code. > > are there? I haven't heard anything except "hangs on boot except with > noapic". - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
> Got good reviews at the time, and I thought it was more general than > ne2k. I don't remember it going forward to Linus (but I've not looked). ne2k is the big one it shows up on. Its on my for Linus list in the next few pushes of stuff. - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
On Thu, 3 May 2001, Alan Cox wrote on APIC problems in 2.4: > There are five cases I am seeing > 1.Serverworks total APIC hose ups. > Fix: remove OSB4 or use -ac tree > 2.440BX and similar boards losing interrupts on some drivers > Fix: use -ac > 3.APIC errors notably checksum errors. > Fix: buy properly manufactured hardware > 4.Hangs on boot with the CUV4XD and a couple of other boards. > Still a mystery > 5.Incorrect PCI IRQ routing > Fix: Mostly get a board with a correct BIOS. There are a couple of > cases people are looking at - some are fixed in 2.4.4 and -ac > where magic IRQ lines are not visible directly in PCI space Doesn't 2.4.1-ac1 onwards contain: o Workaround code for APIC problems with ne2k (Maciej Rozycki) | this will break original 82489DX devices for now | ie _very_ early dual pentium boards Got good reviews at the time, and I thought it was more general than ne2k. I don't remember it going forward to Linus (but I've not looked). Hugh - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
> I just wanted to throw in my two cents and say that there appear to be > widespread issues with the APIC code in 2.4.x. I'm tempted to stick my > neck out and say that it might be best to disable SMP IOAPIC by default > until APIC can be massaged, at least for a wider variety of hardware. I would disagree There are five cases I am seeing 1. Serverworks total APIC hose ups. Fix: remove OSB4 or use -ac tree 2. 440BX and similar boards losing interrupts on some drivers Fix: use -ac 3. APIC errors notably checksum errors. Fix: buy properly manufactured hardware 4. Hangs on boot with the CUV4XD and a couple of other boards. Still a mystery 5. Incorrect PCI IRQ routing Fix: Mostly get a board with a correct BIOS. There are a couple of cases people are looking at - some are fixed in 2.4.4 and -ac where magic IRQ lines are not visible directly in PCI space - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
I just wanted to throw in my two cents and say that there appear to be widespread issues with the APIC code in 2.4.x. I'm tempted to stick my neck out and say that it might be best to disable SMP IOAPIC by default until APIC can be massaged, at least for a wider variety of hardware. I'm getting many replies to my "Persistent 2.4.x stability problem" post. Manfred Spraul has been extremely helpful in working through the issue with me and providing the "noapic" work-around, but this problem is fairly subtle and is most likely effecting a lot more people than those reporting the issue. It seems like some Tyan motherboards and _all_ HP hardware do not play well with the APIC code. That's a pretty big subset of hardware; Asus also seems to be effected now, and many other platforms may also suffer from APICitis. I realize there are different failure modes and I assume different issues are involved within the APIC code. I have HP hardware that I can make available for patches and tests -- I want to help solve this and contribute what I can. Using "noapic" does take the pressure off the issue, but I guess this problem remains insidious in my mind. I realize I'm not fully familiar with the general issues, so I apologize if I'm re-covering old ground or missing any relevant issues. Thanks, -- Ken. On Thursday, May 3, 2001, at 10:51 AM, David A. Neal wrote: > I am encountering a problem I am having a little difficulty > trying to solve. I have a system with a ASUS CUV4X-DLS system > board, Bios 1004, 1GB of memory. dual P3 933MHz processors, > a G450 Matrox card in the AGP slot, and a SBLive! sound > card in PCI Slot 4. > > I have provided the output from dmesg below and the .config > file I used in compiling the 2.4.4 kernel on this system > with a Redhat 7.1 (Seawolf) distribution. > > The problem is that the system will boot everytime if and only > if I use "noapic". If I do not use "noapic", the system will > boot sometimes. The dmesg info below is from a successful boot > when I did not use "noapic". When I do not use "noapic" > __and__ it does not boot, the boot sequence stops at > >..TIMER: vector=49 pin1=2 pin2=0 > > Matter of fact, the first boot after installing Redhat 7.1 stop > at the same message/location with the 2.4.2 kernel. > > I thought about "append"(ing) some "pirq" arguments to the boot > but I really not sure how to do this and whether or not it > would fix the problem. > > What is the impact on performance by disabling APIC? Is there > something wrong with the .config file that might fix this. > > > === Begin dmesg > info == > Linux version 2.4.4 (root@ouzel) (gcc version 2.96 2731 (Red Hat > Linux 7.1 2.96-81)) #2 SMP Wed May 2 17:19:43 MDT 2001 > BIOS-provided physical RAM map: > BIOS-e820: - 0009f000 (usable) > BIOS-e820: 0009f000 - 000a (reserved) > BIOS-e820: 000f - 0010 (reserved) > BIOS-e820: 0010 - 3fffc000 (usable) > BIOS-e820: 3fffc000 - 3000 (ACPI data) > BIOS-e820: 3000 - 4000 (ACPI NVS) > BIOS-e820: fec0 - fec01000 (reserved) > BIOS-e820: fee0 - fee01000 (reserved) > BIOS-e820: - 0001 (reserved) > 127MB HIGHMEM available. > Scan SMP from c000 for 1024 bytes. > Scan SMP from c009fc00 for 1024 bytes. > Scan SMP from c00f for 65536 bytes. > found SMP MP-table at 000f54c0 > hm, page 000f5000 reserved twice. > hm, page 000f6000 reserved twice. > hm, page 000f5000 reserved twice. > hm, page 000f6000 reserved twice. > On node 0 totalpages: 262140 > zone(0): 4096 pages. > zone(1): 225280 pages. > zone(2): 32764 pages. > Intel MultiProcessor Specification v1.4 > Virtual Wire compatibility mode. > OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 > Processor #3 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > SEP present. > MTRR present. > PGE present. > MCA present. > CMOV present. > PAT present. > PSE present. > MMX present. > FXSR present. > XMM present. > Bootup CPU > Processor #0 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > SEP present. > MTRR present. > PGE present. > MCA present. > CMOV p
Re: 2.4.4 Kernel - ASUS CUV4X-DLS Question
> trying to solve. I have a system with a ASUS CUV4X-DLS system > > The problem is that the system will boot everytime if and only > if I use "noapic". If I do not use "noapic", the system will Known problem with the CUV4X boards. > What is the impact on performance by disabling APIC? Is there > something wrong with the .config file that might fix this. Disabling the apic stops irq sharing from occuring. The impact is normally pretty minimal - 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.4 Kernel - ASUS CUV4X-DLS Question
I am encountering a problem I am having a little difficulty trying to solve. I have a system with a ASUS CUV4X-DLS system board, Bios 1004, 1GB of memory. dual P3 933MHz processors, a G450 Matrox card in the AGP slot, and a SBLive! sound card in PCI Slot 4. I have provided the output from dmesg below and the .config file I used in compiling the 2.4.4 kernel on this system with a Redhat 7.1 (Seawolf) distribution. The problem is that the system will boot everytime if and only if I use "noapic". If I do not use "noapic", the system will boot sometimes. The dmesg info below is from a successful boot when I did not use "noapic". When I do not use "noapic" __and__ it does not boot, the boot sequence stops at ..TIMER: vector=49 pin1=2 pin2=0 Matter of fact, the first boot after installing Redhat 7.1 stop at the same message/location with the 2.4.2 kernel. I thought about "append"(ing) some "pirq" arguments to the boot but I really not sure how to do this and whether or not it would fix the problem. What is the impact on performance by disabling APIC? Is there something wrong with the .config file that might fix this. === Begin dmesg info == Linux version 2.4.4 (root@ouzel) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81)) #2 SMP Wed May 2 17:19:43 MDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fffc000 (usable) BIOS-e820: 3fffc000 - 3000 (ACPI data) BIOS-e820: 3000 - 4000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) 127MB HIGHMEM available. Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f54c0 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. On node 0 totalpages: 262140 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 32764 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #3 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bus #0 is PCI Bus #1 is PCI Bus #2 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 0, trig 0, bus 2, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 2, IRQ 0c, APIC ID 2, APIC INT 0c Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 2, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 3, trig 3, bus 0, IRQ 13, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 1c, APIC ID 2, APIC INT 11 Int: type 0, pol 3, trig 3, bus 0, IRQ 20, APIC ID 2, APIC INT 13 Int: type 0, pol 3, trig 3, bus 0, IRQ 21, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 0, IRQ 28, APIC ID 2, APIC INT 12 Lint: type 3, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: auto BOOT_IMAGE=linux ro root=801 BOOT_FILE=/boot/vmlinuz-2.4.4 Initializing CPU#0 Detected 937.577 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1867.77 BogoMIPS Memory: 1028188k/1048560k available
2.4.4 Kernel - ASUS CUV4X-DLS Question
I am encountering a problem I am having a little difficulty trying to solve. I have a system with a ASUS CUV4X-DLS system board, Bios 1004, 1GB of memory. dual P3 933MHz processors, a G450 Matrox card in the AGP slot, and a SBLive! sound card in PCI Slot 4. I have provided the output from dmesg below and the .config file I used in compiling the 2.4.4 kernel on this system with a Redhat 7.1 (Seawolf) distribution. The problem is that the system will boot everytime if and only if I use noapic. If I do not use noapic, the system will boot sometimes. The dmesg info below is from a successful boot when I did not use noapic. When I do not use noapic __and__ it does not boot, the boot sequence stops at ..TIMER: vector=49 pin1=2 pin2=0 Matter of fact, the first boot after installing Redhat 7.1 stop at the same message/location with the 2.4.2 kernel. I thought about append(ing) some pirq arguments to the boot but I really not sure how to do this and whether or not it would fix the problem. What is the impact on performance by disabling APIC? Is there something wrong with the .config file that might fix this. === Begin dmesg info == Linux version 2.4.4 (root@ouzel) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81)) #2 SMP Wed May 2 17:19:43 MDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fffc000 (usable) BIOS-e820: 3fffc000 - 3000 (ACPI data) BIOS-e820: 3000 - 4000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) 127MB HIGHMEM available. Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f54c0 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. On node 0 totalpages: 262140 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 32764 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #3 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bus #0 is PCI Bus #1 is PCI Bus #2 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 0, trig 0, bus 2, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 2, IRQ 0c, APIC ID 2, APIC INT 0c Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 2, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 3, trig 3, bus 0, IRQ 13, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 1c, APIC ID 2, APIC INT 11 Int: type 0, pol 3, trig 3, bus 0, IRQ 20, APIC ID 2, APIC INT 13 Int: type 0, pol 3, trig 3, bus 0, IRQ 21, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 0, IRQ 28, APIC ID 2, APIC INT 12 Lint: type 3, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: auto BOOT_IMAGE=linux ro root=801 BOOT_FILE=/boot/vmlinuz-2.4.4 Initializing CPU#0 Detected 937.577 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1867.77 BogoMIPS Memory: 1028188k/1048560k available (1353k kernel code, 19984k reserved, 560k data, 228k init, 131056k highmem) Dentry
Re: 2.4.4 Kernel - ASUS CUV4X-DLS Question
trying to solve. I have a system with a ASUS CUV4X-DLS system The problem is that the system will boot everytime if and only if I use noapic. If I do not use noapic, the system will Known problem with the CUV4X boards. What is the impact on performance by disabling APIC? Is there something wrong with the .config file that might fix this. Disabling the apic stops irq sharing from occuring. The impact is normally pretty minimal - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
I just wanted to throw in my two cents and say that there appear to be widespread issues with the APIC code in 2.4.x. I'm tempted to stick my neck out and say that it might be best to disable SMP IOAPIC by default until APIC can be massaged, at least for a wider variety of hardware. I'm getting many replies to my Persistent 2.4.x stability problem post. Manfred Spraul has been extremely helpful in working through the issue with me and providing the noapic work-around, but this problem is fairly subtle and is most likely effecting a lot more people than those reporting the issue. It seems like some Tyan motherboards and _all_ HP hardware do not play well with the APIC code. That's a pretty big subset of hardware; Asus also seems to be effected now, and many other platforms may also suffer from APICitis. I realize there are different failure modes and I assume different issues are involved within the APIC code. I have HP hardware that I can make available for patches and tests -- I want to help solve this and contribute what I can. Using noapic does take the pressure off the issue, but I guess this problem remains insidious in my mind. I realize I'm not fully familiar with the general issues, so I apologize if I'm re-covering old ground or missing any relevant issues. Thanks, -- Ken. On Thursday, May 3, 2001, at 10:51 AM, David A. Neal wrote: I am encountering a problem I am having a little difficulty trying to solve. I have a system with a ASUS CUV4X-DLS system board, Bios 1004, 1GB of memory. dual P3 933MHz processors, a G450 Matrox card in the AGP slot, and a SBLive! sound card in PCI Slot 4. I have provided the output from dmesg below and the .config file I used in compiling the 2.4.4 kernel on this system with a Redhat 7.1 (Seawolf) distribution. The problem is that the system will boot everytime if and only if I use noapic. If I do not use noapic, the system will boot sometimes. The dmesg info below is from a successful boot when I did not use noapic. When I do not use noapic __and__ it does not boot, the boot sequence stops at ..TIMER: vector=49 pin1=2 pin2=0 Matter of fact, the first boot after installing Redhat 7.1 stop at the same message/location with the 2.4.2 kernel. I thought about append(ing) some pirq arguments to the boot but I really not sure how to do this and whether or not it would fix the problem. What is the impact on performance by disabling APIC? Is there something wrong with the .config file that might fix this. === Begin dmesg info == Linux version 2.4.4 (root@ouzel) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81)) #2 SMP Wed May 2 17:19:43 MDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fffc000 (usable) BIOS-e820: 3fffc000 - 3000 (ACPI data) BIOS-e820: 3000 - 4000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) 127MB HIGHMEM available. Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f54c0 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. On node 0 totalpages: 262140 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 32764 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #3 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bus #0 is PCI Bus #1 is PCI Bus #2 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03
Re: 2.4.4 Kernel - ASUS CUV4X-DLS Question
I just wanted to throw in my two cents and say that there appear to be widespread issues with the APIC code in 2.4.x. I'm tempted to stick my neck out and say that it might be best to disable SMP IOAPIC by default until APIC can be massaged, at least for a wider variety of hardware. I would disagree There are five cases I am seeing 1. Serverworks total APIC hose ups. Fix: remove OSB4 or use -ac tree 2. 440BX and similar boards losing interrupts on some drivers Fix: use -ac 3. APIC errors notably checksum errors. Fix: buy properly manufactured hardware 4. Hangs on boot with the CUV4XD and a couple of other boards. Still a mystery 5. Incorrect PCI IRQ routing Fix: Mostly get a board with a correct BIOS. There are a couple of cases people are looking at - some are fixed in 2.4.4 and -ac where magic IRQ lines are not visible directly in PCI space - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
On Thu, 3 May 2001, Alan Cox wrote on APIC problems in 2.4: There are five cases I am seeing 1.Serverworks total APIC hose ups. Fix: remove OSB4 or use -ac tree 2.440BX and similar boards losing interrupts on some drivers Fix: use -ac 3.APIC errors notably checksum errors. Fix: buy properly manufactured hardware 4.Hangs on boot with the CUV4XD and a couple of other boards. Still a mystery 5.Incorrect PCI IRQ routing Fix: Mostly get a board with a correct BIOS. There are a couple of cases people are looking at - some are fixed in 2.4.4 and -ac where magic IRQ lines are not visible directly in PCI space Doesn't 2.4.1-ac1 onwards contain: o Workaround code for APIC problems with ne2k (Maciej Rozycki) | this will break original 82489DX devices for now | ie _very_ early dual pentium boards Got good reviews at the time, and I thought it was more general than ne2k. I don't remember it going forward to Linus (but I've not looked). Hugh - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
The failure mode I'm seeing is that the timer interrupt disappears. Hard to schedule processes at that point. I'm not seeing the IRQ issues personally. HP's LP1000r machine uses ServerWorks, but still shows the problem. I only have access to HP SMP hardware currently, but they all have the same issue. I've heard of Tyan and Asus issues (not just the one recently posted), though I have an LX machine that has been okay with 2.4. I've seen the VIA issues, but they aren't related from what I can tell. -- Ken. On Thursday, May 3, 2001, at 01:17 PM, Mark Hahn wrote: I just wanted to throw in my two cents and say that there appear to be widespread issues with the APIC code in 2.4.x. I'm tempted to stick my are there any known problems on non-VIA boards? BX seems to work fine, and I haven't heard of any problems from serverworks people. I'm guessing (wag) that there's some VIA-specific thing that needs to be done to get the PIT timer working with io-apic. no real problem with apic/ioapic, just some little divergence on VIA's part. from APICitis. I realize there are different failure modes and I assume different issues are involved within the APIC code. are there? I haven't heard anything except hangs on boot except with noapic. - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
Got good reviews at the time, and I thought it was more general than ne2k. I don't remember it going forward to Linus (but I've not looked). ne2k is the big one it shows up on. Its on my for Linus list in the next few pushes of stuff. - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
I'm losing the timer interrupt, but it's not driver-specific -- only the motherboard is required to reproduce for me; different SCSI, RAID, and ether drivers have been swapped out. Nothing with HP on it seems to work, and it wouldn't surprise me in the least to find out that HP's stuff is broken. But this problem has existed since 2.4.0-test1 and hasn't changed, and it surprises me that at least a work-around hasn't been merged into the kernel by now. There might be fixes in the -ac tree that effect my problem -- I'll try the latest -ac and see what happens. Thanks for the suggestion. But the distributions use _the_ kernel. Even if -ac is fixed, it's not really something I would be willing to put in production. Until I found the noapic work-around, we were basically going to have to move off of Linux. I could very well be an isolated case, but the APIC issues I'm seeing scare me, and not just for my sake. I mean all of this in the utmost respect -- I just felt that this issue needs a little more light shed on it, and I'm here to help in any way I can. -- Ken. On Thursday, May 3, 2001, at 02:24 PM, Hugh Dickins wrote: On Thu, 3 May 2001, Alan Cox wrote on APIC problems in 2.4: There are five cases I am seeing 1. Serverworks total APIC hose ups. Fix: remove OSB4 or use -ac tree 2. 440BX and similar boards losing interrupts on some drivers Fix: use -ac 3. APIC errors notably checksum errors. Fix: buy properly manufactured hardware 4. Hangs on boot with the CUV4XD and a couple of other boards. Still a mystery 5. Incorrect PCI IRQ routing Fix: Mostly get a board with a correct BIOS. There are a couple of cases people are looking at - some are fixed in 2.4.4 and -ac where magic IRQ lines are not visible directly in PCI space Doesn't 2.4.1-ac1 onwards contain: o Workaround code for APIC problems with ne2k (Maciej Rozycki) | this will break original 82489DX devices for now | ie _very_ early dual pentium boards Got good reviews at the time, and I thought it was more general than ne2k. I don't remember it going forward to Linus (but I've not looked). Hugh - 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/ - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
But the distributions use _the_ kernel. Even if -ac is fixed, it's not really something I would be willing to put in production. Until I found Actually by unit count Linus is currently losing to me on 2.4 shipping. Thats one reason I really want to get the stuff I have back into the main tree. the noapic work-around, we were basically going to have to move off of Linux. I could very well be an isolated case, but the APIC issues I'm seeing scare me, and not just for my sake. Can you give me the detailed boot up messages from one of your HP boxes and some more info. Also can you run dmidecode.c from ftp://ftp.linux.org.uk/pub/linux/alan on them and send me the DMI strings. You will need to run it as root but it can be run on a live system (at least I dont know of any bugs in it and it only reads from raw BIOS memory not writes). Alan - 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: 2.4.4 Kernel - ASUS CUV4X-DLS Question
I have some info at http://web.irridia.com/linux/; from an LPr having issues, including the dmidecode output and a mostly complete boot-time dmesg dump from an LPr and LP1000r. The LPr was running 2.4.2-pre4 and the LP1000r is running 2.4.5-pre1, both without noapic. Please let me know if you need more info. BTW, I have an isolated bank of redundant machines, one of which I can load down with heavy live load so I can test patches pretty easily. I'll do anything, including setting fire to a machine, if it'll help. :-) -- Ken. On Thursday, May 3, 2001, at 03:23 PM, Alan Cox wrote: But the distributions use _the_ kernel. Even if -ac is fixed, it's not really something I would be willing to put in production. Until I found Actually by unit count Linus is currently losing to me on 2.4 shipping. Thats one reason I really want to get the stuff I have back into the main tree. the noapic work-around, we were basically going to have to move off of Linux. I could very well be an isolated case, but the APIC issues I'm seeing scare me, and not just for my sake. Can you give me the detailed boot up messages from one of your HP boxes and some more info. Also can you run dmidecode.c from ftp://ftp.linux.org.uk/pub/linux/alan on them and send me the DMI strings. You will need to run it as root but it can be run on a live system (at least I dont know of any bugs in it and it only reads from raw BIOS memory not writes). Alan - 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/
