As the maintainer of via-rhine, I get bug reports that almost in their
entirety are "fixed" by turning off APIC and/or ACPI. This has been going
on for several months now. Every now and then, something promising gets
posted on LKML, but so far if anything I've seen an _increase_ in those bug
reports. Maybe a fix is floating around and this will be a non-issue RSN. I
simply can't tell, since I don't have any IO-APIC hardware to play with.
Instead of just telling everybody to turn off APIC, I'd like to point bug
reporters to the proper place and tell them what information they should
provide so it can get fixed for real. According to MAINTAINERS, Ingo Molnar
does Intel APIC, but the problems are with VIA chip sets. So where do I
send my users? Any takers?
Roger
On Wednesday 03 Sep 2003 9:08 am, Roger Luethi wrote:
> As the maintainer of via-rhine, I get bug reports that almost in their
> entirety are "fixed" by turning off APIC and/or ACPI. This has been going
> on for several months now. Every now and then, something promising gets
> posted on LKML, but so far if anything I've seen an _increase_ in those bug
> reports. Maybe a fix is floating around and this will be a non-issue RSN. I
> simply can't tell, since I don't have any IO-APIC hardware to play with.
>
> Instead of just telling everybody to turn off APIC, I'd like to point bug
> reporters to the proper place and tell them what information they should
> provide so it can get fixed for real. According to MAINTAINERS, Ingo Molnar
> does Intel APIC, but the problems are with VIA chip sets. So where do I
> send my users? Any takers?
Hi, I'm trying to develop patches for ACPI IRQ issues.
Are these VIA KT333/KT400 chipsets? If so, there's a known bug in many BIOSes
with these chipsets. I'm waiting on some docs from VIA to fix this issue.
On Wednesday 03 Sep 2003 9:08 am, Roger Luethi wrote:
> As the maintainer of via-rhine, I get bug reports that almost in their
> entirety are "fixed" by turning off APIC and/or ACPI. This has been going
> on for several months now. Every now and then, something promising gets
> posted on LKML, but so far if anything I've seen an _increase_ in those bug
> reports. Maybe a fix is floating around and this will be a non-issue RSN. I
> simply can't tell, since I don't have any IO-APIC hardware to play with.
>
> Instead of just telling everybody to turn off APIC, I'd like to point bug
> reporters to the proper place and tell them what information they should
> provide so it can get fixed for real. According to MAINTAINERS, Ingo Molnar
> does Intel APIC, but the problems are with VIA chip sets. So where do I
> send my users? Any takers?
Hi, I'm trying to develop patches for ACPI IRQ issues.
Are these VIA KT333/KT400 chipsets? If so, there's a known bug in many BIOSes
with these chipsets. I'm waiting on some docs from VIA to fix this issue.
On Wed, 03 Sep 2003 11:23:58 +0100, Andrew de Quincey wrote:
> Hi, I'm trying to develop patches for ACPI IRQ issues.
That would be most appreciated.
> Are these VIA KT333/KT400 chipsets? If so, there's a known bug in many BIOSes
Yes, at least some of them are. I often don't know, since the reports just
say "Rhine ethernet broke in the new kernel" (VIA based boards typically
come with Rhine ethernet integrated into the south bridge).
> with these chipsets. I'm waiting on some docs from VIA to fix this issue.
Which still leaves the question of why it used to work (or made the
impression it did) with older kernels.
Roger
> > with these chipsets. I'm waiting on some docs from VIA to fix this issue.
>
> Which still leaves the question of why it used to work (or made the
> impression it did) with older kernels.
I think on earlier kernels there was a bug in ACPI which prevented it from
being used for PCI IRQ routing. I know this was fixed somewhere in the 2.5.5X
series.
When this bug was fixed, it unfortunately caused my nforce2 board to stop
working because of other IRQ issues, which is how I got into this. Its likely
the same thing causes older kernels to work with Via motherboards to work
'cos ACPI isn't being used for IRQ routing.
2.4.22 has the ACPI from 2.6 backported into it, (which includes my patch for
nforce2 boards) so it will start having the same issue with the BIOS bug in
KT333/KT400 boards.
If interrupts work with acpi=off, but otherwise don't, then:
--begin quote--
Please file a bug at http://bugzilla.kernel.org/
Category: Power Management
Componenet: ACPI
Please attach the output from dmidecide, available in /usr/sbin/, or
here:
http://www.nongnu.org/dmidecode/
Please attach the output from acpidmp, available in /usr/sbin/, or in
here
http://www.intel.com/technology/iapc/acpi/downloads/pmtools-20010730.tar
.gz
Please attach /proc/interrupts and the dmesg output showing the failure,
if possible.
--end quote--
This answer is the same no matter who built the system.
Thanks,
-Len
Ps. Needless to say, this is a hot issue and has become hotter as more
people are enabling ACPI. There are a number of bugs open on this
topic already with fixes in the works -- so check for dupes.
> -----Original Message-----
> From: Roger Luethi [mailto:[email protected]]
> Sent: Wednesday, September 03, 2003 4:09 AM
> To: [email protected]
> Cc: [email protected]
> Subject: Where do I send APIC victims?
>
>
> As the maintainer of via-rhine, I get bug reports that almost in their
> entirety are "fixed" by turning off APIC and/or ACPI. This
> has been going
> on for several months now. Every now and then, something
> promising gets
> posted on LKML, but so far if anything I've seen an
> _increase_ in those bug
> reports. Maybe a fix is floating around and this will be a
> non-issue RSN. I
> simply can't tell, since I don't have any IO-APIC hardware to
> play with.
>
> Instead of just telling everybody to turn off APIC, I'd like
> to point bug
> reporters to the proper place and tell them what information
> they should
> provide so it can get fixed for real. According to
> MAINTAINERS, Ingo Molnar
> does Intel APIC, but the problems are with VIA chip sets. So
> where do I
> send my users? Any takers?
>
> Roger
> -
> 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/
>
On Mer, 2003-09-03 at 11:48, Andrew de Quincey wrote:
> 2.4.22 has the ACPI from 2.6 backported into it, (which includes my patch for
> nforce2 boards) so it will start having the same issue with the BIOS bug in
> KT333/KT400 boards.
It does - 2.4.22pre7 is great on my boxes, 2.4.22 final ACPI is
basically unusable on anything I own thats not intel.
On Wed, 03 Sep 2003 12:40:06 +0100
Alan Cox <[email protected]> wrote:
> On Mer, 2003-09-03 at 11:48, Andrew de Quincey wrote:
> > 2.4.22 has the ACPI from 2.6 backported into it, (which includes my patch
> > for nforce2 boards) so it will start having the same issue with the BIOS
> > bug in KT333/KT400 boards.
>
> It does - 2.4.22pre7 is great on my boxes, 2.4.22 final ACPI is
> basically unusable on anything I own thats not intel.
I can't back that. At least on all my Serverworks boxes there are no problems
with ACPI. I got reports from VIA-bases SMP boards that they are doing well, too.
(all for 2.4.22)
Regards,
Stephan
On my board, A7V8X, ACPI/APIC works just perfectly with 2.4.22 and KT400
chipset, alas on A7N8X Deluxe board with nForce2 chipsets it causes nasty
hangups.
Machine just simply freezes, no oops, nothing whatsoever.
Disabling APIC solved the problem.
--
Regards,
Vladimir
On Wednesday 03 September 2003 14:53, Stephan von Krawczynski wrote:
> On Wed, 03 Sep 2003 12:40:06 +0100
>
> Alan Cox <[email protected]> wrote:
> > On Mer, 2003-09-03 at 11:48, Andrew de Quincey wrote:
> > > 2.4.22 has the ACPI from 2.6 backported into it, (which includes my
> > > patch for nforce2 boards) so it will start having the same issue with
> > > the BIOS bug in KT333/KT400 boards.
> >
> > It does - 2.4.22pre7 is great on my boxes, 2.4.22 final ACPI is
> > basically unusable on anything I own thats not intel.
>
> I can't back that. At least on all my Serverworks boxes there are no
> problems with ACPI. I got reports from VIA-bases SMP boards that they are
> doing well, too. (all for 2.4.22)
>
> Regards,
> Stephan
> -
> 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/
--
Best regards,
Vladimir Lazarenko
Vladimir Lazarenko wrote:
> On my board, A7V8X, ACPI/APIC works just perfectly with 2.4.22 and KT400
> chipset, alas on A7N8X Deluxe board with nForce2 chipsets it causes nasty
> hangups.
> Machine just simply freezes, no oops, nothing whatsoever.
>
> Disabling APIC solved the problem.
>
> --
> Regards,
> Vladimir
>
> On Wednesday 03 September 2003 14:53, Stephan von Krawczynski wrote:
>
>>On Wed, 03 Sep 2003 12:40:06 +0100
>>
>>Alan Cox <[email protected]> wrote:
>>
>>>On Mer, 2003-09-03 at 11:48, Andrew de Quincey wrote:
>>>
>>>>2.4.22 has the ACPI from 2.6 backported into it, (which includes my
>>>>patch for nforce2 boards) so it will start having the same issue with
>>>>the BIOS bug in KT333/KT400 boards.
>>>
>>>It does - 2.4.22pre7 is great on my boxes, 2.4.22 final ACPI is
>>>basically unusable on anything I own thats not intel.
>>
>>I can't back that. At least on all my Serverworks boxes there are no
>>problems with ACPI. I got reports from VIA-bases SMP boards that they are
>>doing well, too. (all for 2.4.22)
And I can say that my Soyo SY-KT600 Ultra (VIA KT600+8237) has ACPI
problems as well. pci=noacpi doesn't help but acpi=off does. It gives
lots of errors that the ACPI tables are buggy when booting claiming
my 8237 SATA controller has gotten IRQ -19 for instance.
Using acpi=off solves the problem. This is with or without the libata
VIA 8237 SATA driver. Without anything it recognizes the chip but
doesn't like using IRQ -19 and doesn't see any disks. With pci=noacpi
it sees the disks but bombs out when trying to get the partition table.
It gets IRQ -19 still there. acpi=off makes it all work.
// Stefan
> >>I can't back that. At least on all my Serverworks boxes there are no
> >>problems with ACPI. I got reports from VIA-bases SMP boards that they are
> >>doing well, too. (all for 2.4.22)
>
> And I can say that my Soyo SY-KT600 Ultra (VIA KT600+8237) has ACPI
> problems as well. pci=noacpi doesn't help but acpi=off does. It gives
> lots of errors that the ACPI tables are buggy when booting claiming
> my 8237 SATA controller has gotten IRQ -19 for instance.
> Using acpi=off solves the problem. This is with or without the libata
> VIA 8237 SATA driver. Without anything it recognizes the chip but
> doesn't like using IRQ -19 and doesn't see any disks. With pci=noacpi
> it sees the disks but bombs out when trying to get the partition table.
> It gets IRQ -19 still there. acpi=off makes it all work.
The IRQ -19 thing is a bug in my nforce2 patch in 2.4.22. It didn't drop back
to using the PIC correctly. My latest acpi-picmode patch (posted to this list
a few days back) corrects this, among other things.
On Wednesday 03 Sep 2003 2:04 pm, Vladimir Lazarenko wrote:
> On my board, A7V8X, ACPI/APIC works just perfectly with 2.4.22 and KT400
> chipset,
Does it indeed? Sounds like that BIOS doesn't have the bug! Can you send me
your /proc/acpi/dsdt so I can see what is different? Be really good if I can
nick the code out of that for the other boards!
> alas on A7N8X Deluxe board with nForce2 chipsets it causes nasty
> hangups.
> Machine just simply freezes, no oops, nothing whatsoever.
>
> Disabling APIC solved the problem.
Does it work with ACPI disabled, but APIC enabled?
On Wed, 3 Sep 2003, Alan Cox wrote:
> On Mer, 2003-09-03 at 11:48, Andrew de Quincey wrote:
> > 2.4.22 has the ACPI from 2.6 backported into it, (which includes my patch for
> > nforce2 boards) so it will start having the same issue with the BIOS bug in
> > KT333/KT400 boards.
>
> It does - 2.4.22pre7 is great on my boxes, 2.4.22 final ACPI is
> basically unusable on anything I own thats not intel.
I've collected a few 2.4.22 ACPI problems and sent them to the ACPI guys.
Randy, Len? Any update on any bug?
On Wed, 3 Sep 2003, Marcelo Tosatti wrote:
>
>
> On Wed, 3 Sep 2003, Alan Cox wrote:
>
> > On Mer, 2003-09-03 at 11:48, Andrew de Quincey wrote:
> > > 2.4.22 has the ACPI from 2.6 backported into it, (which includes my patch for
> > > nforce2 boards) so it will start having the same issue with the BIOS bug in
> > > KT333/KT400 boards.
> >
> > It does - 2.4.22pre7 is great on my boxes, 2.4.22 final ACPI is
> > basically unusable on anything I own thats not intel.
>
> I've collected a few 2.4.22 ACPI problems and sent them to the ACPI guys.
>
> Randy, Len? Any update on any bug?
Alan, mind sending us detailed reports of the ACPI issues with 2.4.22,
too?
Thanks
Well I am one APIC victim since Jan 2002. almost 2 years.
I suggested build one database of "APIC victims"
"Hi I would like make a database of the computers that have to Turning
off APIC. Model, mother board and chip set, processor type , and DSDT
signature.
And put in blacklist.c to give this exactly warning."
But what I would like to say here is: I try to understand where kernel
hangs when I enable APIC and doesn't hangs when IRQ routing is setting,
but hangs before, exactly when try to:
"evxfevnt-0093 [04] acpi_enable : Transition to ACPI mode
successful." this message never appears.
PS: I just don't had begging the database because, now, I don't have
any time for that. But I had some ideas, like using php to upload dsdt
bin and try automatically Disassemble AML to ASL using iasl as cgi etc.
thanks
On Wed, 2003-09-03 at 19:13, Marcelo Tosatti wrote:
>
>
> On Wed, 3 Sep 2003, Alan Cox wrote:
>
> > On Mer, 2003-09-03 at 11:48, Andrew de Quincey wrote:
> > > 2.4.22 has the ACPI from 2.6 backported into it, (which includes my patch for
> > > nforce2 boards) so it will start having the same issue with the BIOS bug in
> > > KT333/KT400 boards.
> >
> > It does - 2.4.22pre7 is great on my boxes, 2.4.22 final ACPI is
> > basically unusable on anything I own thats not intel.
>
> I've collected a few 2.4.22 ACPI problems and sent them to the ACPI guys.
>
> Randy, Len? Any update on any bug?
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Acpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
--
S?rgioMB
email: [email protected]
Who gives me one shell, give me everything.
On Wed, Sep 03, 2003 at 05:09:08PM +0100, Andrew de Quincey wrote:
> On Wednesday 03 Sep 2003 2:04 pm, Vladimir Lazarenko wrote:
> > On my board, A7V8X, ACPI/APIC works just perfectly with 2.4.22 and KT400
> > chipset,
>
> Does it indeed? Sounds like that BIOS doesn't have the bug! Can you send me
> your /proc/acpi/dsdt so I can see what is different? Be really good if I can
> nick the code out of that for the other boards!
>
I have a board like this too. It works fine with 2.4 & 2.6. The only
trouble I've had has been a hard drive. (hardware)
> > alas on A7N8X Deluxe board with nForce2 chipsets it causes nasty
> > hangups.
> > Machine just simply freezes, no oops, nothing whatsoever.
> >
> > Disabling APIC solved the problem.
>
> Does it work with ACPI disabled, but APIC enabled?
00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge
00:0a.0 VGA compatible controller: Trident Microsystems TGUI 9660/938x/968x
(rev d3)
00:0e.0 RAID bus controller: CMD Technology Inc PCI0680 (rev 02)
00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus
Master IDE (rev 06)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
On Wed, 03 Sep 2003, Andrew de Quincey wrote:
> Hi, I'm trying to develop patches for ACPI IRQ issues.
>
> Are these VIA KT333/KT400 chipsets? If so, there's a known bug in many BIOSes
> with these chipsets. I'm waiting on some docs from VIA to fix this issue.
I'm looking after a box with EPoX 8K9A2+ board (IIRC), with KT400 chip
set. Booting with ACPI enabled (i. e. no acpi=off in kernel command
line) makes most interrupts (network, disk) invisible. acpi=off fixes
this. I haven't bothered to report this because it's running some
SuSE-patched 2.4.20 kernel (they did patch newer ACPI, "Subsystem
revision 20030228").
Is testing a newer kernel or ACPI stuff worthwhile or should I wait?
It's a production machine, so "see if this works" is out of the game,
"it should work" can be tested in times of low load but not necessarily
on short notice.
Is this any help?
<6>ACPI: Subsystem revision 20030228
<6>ACPI: Disabled via command line (acpi=off)
<6>PCI: PCI BIOS revision 2.10 entry at 0xfb380, last bus=1
<6>PCI: Using configuration type 1
<6>PCI: Probing PCI hardware
<4>PCI: ACPI tables contain no PCI IRQ routing entries
<4>PCI: Probing PCI hardware (bus 00)
<6>PCI: Using IRQ router VIA [1106/3177] at 00:11.0
That 00:11.0 is:
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95