Distribution: LFS 6.0 Hardware Environment: gericom m6t notebook PIII tualatin ati radeon mobility ADMtek Comet rev 17 builtin Software Environment: gcc 3.4 glibc-cvs Problem Description: ADMtek Comet rev 17 stops working when moving from 2.6.9 to 2.6.10 or 2.6.11 There has been an fix for this device in x86-64 code in 2.6.11 but it seems that there's a bug since 2.6.10 in x86 code too. I don't know what has been changed to 2.6.10 but probably somebody should undo it. error message is "tulip_stop_rxtx() failed" Steps to reproduce: The error is permanent with kernel 2.6.10 and 2.6.11 there is no difference with drivers compiled as modules the network interface simply does not work at all PS sorry for my english ;-) i hope it's understandable
Created attachment 4691 [details] tulip: make tulip_stop_rxtx() wait for DMA to fully stop Try this patch with -R, if it works you should probably bug top-most signed-off-by people from: http://linux.bkbits.net:8080/linux-2.5/cset@41a4e7cbMTburuvEhDi76cSLevFw7g There's one thing I'd like to comment: - (void) ioread32(ioaddr + CSR6); /* mmio sync */ + while (--i && (ioread32(ioaddr + CSR5) & (CSR5_TS|CSR5_RS))) + udelay(10); Old code read from CSR6, newer code reads from CSR5. Might be right, but this stood out to me.
No Patch does not fix the problem. But there is no error message at all after patching. Thats exactly the same behaviour as 2.6.9. This laptop is known to have problems with irq meaning that only irq tables form acpi do work at all without acpi interrupt tables nearly nothing works. probably there was a change in acpi code that caused the break of admtek driver.
ops sorry not same behaviour as 2.6.9 I meant 2.6.10
For 3 cases, please include the /proc/interrupts and attach the output from dmesg -s64000: 1. working 2.6.9 2. failing 2.6.11 3. 2.6.11 booted with "pnpacpi=off"
Hello while preparing the dmesg output as requested I noticed a dmesg message that I didn'r recognize before. According to that message there were changes in acpi handling and old behaviour could be restroed by "pci=routeirq" kernel parameter furthermore the author of the changes requested a mail with information on incompatibilities. As admtek works again with this kernel parameter I'll send him the requested information. Hopefully he knows how to fix the tulip driver to be compatible with new acpi interrupt behaviour. I think the dmesg requested before is no longer needed so I'll skip posting it.
Does 2.6.12-rc5 still need the `pci=routeirq' workaround? If so, can we get this regressions fixed prior to 2.6.12?
"BUG" stil exists in 2.6.12-rc5 but it's not related to admtek. Bug has been tracked back to a change in ACPI Interrupt behavior. New behavior is to only enable a link when a device is connected. Due to incorrect ACPI information in my laptop (admtek is connected to another link that ACPI tells) the lnk the device is really connected does not get enabled when driver is initialized threrfore the device can not work. The best way to fix it would be a new fixed bios but as this laptop is around 4 years i don't think that this will happen at all. According to Bjordn Helgaas there is no other "good" solution he suggested to blacklist this laptop for acpi but I strongly rejected this as acpi is the only way to get irqs to be assigned at all. I suggested a kernel-config entry that restores the old acpi irq behaviour. Simmilar to other hardware flaw workaround config entrys but I don't know if this Problem is common enough to make this necessary.
I think we should look at a PNP or ACPI quirk to work around the buggy BIOS. This would be breaking new ground, since we don't have an ACPI quirk mechanism yet. But if we can figure out how to make one, I think it would be useful in several cases. Thanks for updating this, Adrian. I had forgotten about this one. I don't have time to work on it right now, but I'll put it on my list to look at it again.
For the default (no kernel parameters), using a recent kernel, such as 2.6.17 or 2.6.18, please attach the output from dmesg -s64000, and paste the out lspci -vv, dmidecode, and acpidump. acpidump is available in the latest pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ Then for the "pci=routeirq" case, please again paste the dmesg and interrupts. Before we start creating "ACPI quirks", lets make completely sure that this failure is well understood.
uh ... I didn't use bugzilla for quite a while so sorry for any format errors I'm going to make I'm sorry but I can`t help you anymore my old gericom m6t does "rest in peace" for about 2 months now, and my new laptop does work without any problems ;-). I've got only the information I sent to Bjorn in 2005 including the mails I sent him, but it's only dmesg output and a small snip of the decoded acpi. Hope you find someone who can help you fix this issue