Description of problem:
On install of a FC2-test2 system, networking will not work.
The machine is known to work, as it has recently had FC1 on it, and
boots successfully to an LTSP server through PXE booting.
Computer is a Toshiba Satellite Pro 4600.
After booting the fresh install, the computer gets a DHCP address, but
is unable to route to the gateway box which provided the address.
route -n reports an apparently OK routing table, but ping reports host
The same things happen after changing to a static network address.
I have a FC1 machine handy for comparison, and the routing table seems
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install FC2test2 (Personal Workstation, no other unique options)
3. ping or konqueror
Actual Results: Host unreachable.
Expected Results: ping return or web page of gateway.
does it work if you echo 0 > /proc/sys/net/ipv4/tcp_ecn ?
I am setting up a serial console to grab whatever files or listings
would be useful to debug.
I will attach in a tgz file the /proc/pci listing, the lsmod listing,
route -n. Anything else?
Created attachment 99645 [details]
ran lspci, cat /proc/pci, route -n, ifconfig eth0, dmesg
Your machine seems to have serious ACPI problems with the kernel. Try
running with the boot option "acpi=off" and report back if that fixes it.
ACPI-0165: *** Error: No object was returned from [\_SB_.LNKA._STA] (Node
ACPI: No IRQ known for interrupt pin D of device 0000:00:1f.2
irq 11: nobody cared! (screaming interrupt?)
Oh yes, ACPI interrupt configuration is very broken here.
/proc/interrupts may show your devices on the wrong irqs.
"pci=noacpi" would probably be a sufficient workaround.
Please verify that you're running the latest BIOS
Please verify that if there are any ACPI related settings in SETUP
that ACPI is enabled.
Please attach the output from acpidmp available in /usr/sbin/, or in pmtools:
Probably good to update to the final FC2 release from test2.
Also, it would be interesting if you can boot the latest 2.6 kernel.org kernel
on this system, since it contains additional debugging info.
BIOS Version 2.60, 10/12/2001, which is the latest one, according to
toshiba. URL of BIOS release notes:
BIOS options set (reading them from the Windows program supplied by
"Device Configureation": All Devices (not "Setup by OS")
Hardware Alarms: All on (Low Battery, Panel Close, System Beep)
LAN: Wake on LAN Enabled
USB Legacy Emulation: Disabled
CPU: Frequency Dynamically Switchable (not Always Hi or Always Low)
Anyway, FWIW, I will try turning Wake on LAN off, then turning ACPI on
(removing kernel cmdline parameter), and see what that does. It's
always worth a try...
Nope - still no network.
I will return to acpi=off, as suggested by Alan Cox. I will update the
system to the newly released final version of FC2, but I am not
hopeful. By the way, that did enable the network, so all was well for
In the mean time, I have re-enabled Wake On LAN, which (I think) is an
ACPI option, so that implies ACPI is running, but then I could also be
I will play, and see what I can arrange. Thank you all for your time
Created attachment 100387 [details]
acpidmp output with kernel parameter acpi=on
Ran acpidmp, downloaded and compiled from kernel.org.
command line was
acpidmp > acpi_on_aspidmp.txt
And, no, I can't spell.... Yeesh.
Created attachment 100388 [details]
acpidmp output with kernel parameter acpi=off
Sounds like no return value of '_STA' problem, please check the patch
Once my (overnight, HTTP) install of FC2final is complete, I will test
this patch. I agree that it sounds familiar. The bug referred to from
that bug is back here, on a Toshiba Tecra 8000.
It certainly has the same message, although the specific behaviour is
disassembling the DSDT and re-compiling it gave 40 errors
DSDT.dsl 55: Method (_STA, 0, NotSerialized)
Warning 2026 - ^ Reserved method must return a value (_STA)
Depending on where these errors are in the source,
the symptoms are different from system to system.
Woohoo! I have now got a custom kernel with the patch referred to in
bug 107458 (see above). The kernel is stock FC2 (2.6.5-1.358) with the
This is the patch in question:
I presently have a kernel booting with a command line "acpi=on" and
using the network, which solves my issues.
Thanks for all the help, everybody. I appreciate it, from the quick
workaround to the root cause fix, and especially the bug-identifying help.
It's a BIOS bug, but can we work around it permanently? Please? I
don't want to do a custom kernel every time I install FC on these
machines I have here.
exactly what patch did you apply?
bug 107458 doesn't contain a patch,
and the url above is an acpidmp output file.
did you try the patch on OSDL?:
MMMhmmm. Yes, it was the patch on OSDL, as you've noted. My mistake.
fixed in the current errata kernel ?
no response in 6 months - closing.