Hardware Environment: IBM Thinkpad T23 Software Environment: 2.6.0-test5 Problem Description: T23 boot hang with intel(R) PRO/100 PCMCIA net card plugged in. Steps to reproduce: T23 always hang whenever ACPI is enabled or not.
Created attachment 891 [details] Patch for fixing this hang. This bug seems to have nothing to do with ACPI. But there are some PCMCIA issues on Thinkpad and other laptop. I tried to reproduce them. but So far I only found this issue on T23.
But this PCMCIA net card can only work on the second slot. If plug it into the first slot. The symptom is mysterious! Sometimes it cannot obtian an IP address from DHCP server. Sometimes it will work for only a few minutes. I observed error message from PIN, which complained the lack of message buffer after sending out less than 30 icmp messages successfully, and the number of interrupt for net card wouldn't increase.(I got this point from /proc/interrupts). The problem will happen even if acpi is disabled. (2.4 seems to work.) After some investigation, It works. Until now, PIN has sent out more than 4027 icmp messages successfully. /proc/interrupts: 0: 4105552 XT-PIC timer 1: 8148 XT-PIC i8042 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 9: 17 XT-PIC acpi 11: 11453 XT-PIC yenta, yenta, eth1 12: 45043 XT-PIC i8042 14: 9238 XT-PIC ide0 NMI: 0 ERR: 0 The problem is that some config registers in pci config space of 0:2 are wrong. I found them, and corrected the wrong value. But I don't know the exact meaning of each config register of them. I just guess. :( Now, I think it is much more easy to find out which part of code was responsible for these wrong value. But this issue is irrelative to ACPI.
I think I was using command ping for testing. (It's not PIN(pin))
Created attachment 1486 [details] Hard code direct.c to make PCMCIA works well on T23. ( It's not a fix)
Is this still an issue? I don't suppose it works properly if yenta is compiled statically? In any case, it still fails if acpi=off, so I'm booting this out of the ACPI category.
Please consider using a later kernel, preferably something recent. 2.6.0-testX kernels are known to be buggy.
There is no information forthcoming from the original bug submitter for almost a month. I'm therefore inclined to reject this bug unless the original submitter responds within the next 4 days.
The original reporter is not responding; therefore as promised I am rejecting this bug. I believe it is already fixed in later kernels, but without confirmation there's no way of knowing.