I first saw the problem on the 64x2 box after upgrading to 2.6.19. The
network appeared OK with ifconfig and route -n, but I had no network
access. Pinging any other box, the box was responding, but no response
was received by the 64x2. I checked cables and the switch which were OK,
so I figured I had a faulty receiver on the on-board ethernet. I plugged
in a PCI eepro100, reconfigured the network and it's been fine ever since.
I upgraded to 2.6.20-rc2 (also 2.6.19 and later) on the x86_64 laptop
and that also experienced the same problem - different cards in both
boxes. Downgraded to 2.6.19-rc5 and network is up.
================== 64x2 box ======================
64: None 00.0: 10701 Ethernet
[Created at net.115]
UDI: /org/freedesktop/Hal/devices/net_00_01_6c_e6_ab_7a
Unique ID: usDW.ndpeucax6V1
Parent ID: rBUF.siZp+507g89
SysFS ID: /class/net/eth0
SysFS Device Link: /devices/pci0000:00/0000:00:14.0
Hardware Class: network interface
Model: "Ethernet network interface"
Driver: "forcedeth"
Device File: eth0
HW Address: 00:01:6c:e6:ab:7a
Link detected: yes
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #39 (Ethernet controller)
*********** PROBLEM **************
--------------------------------------------------------------------
eepro100 working (64x2)
=======================
65: None 01.0: 10701 Ethernet
[Created at net.115]
UDI: /org/freedesktop/Hal/devices/net_00_d0_b7_13_e5_ea
Unique ID: L2Ua.ndpeucax6V1
Parent ID: JNkJ.HVgIlgOrmpC
SysFS ID: /class/net/eth1
SysFS Device Link: /devices/pci0000:00/0000:00:10.0/0000:04:08.0
Hardware Class: network interface
Model: "Ethernet network interface"
Driver: "eepro100"
Device File: eth1
HW Address: 00:d0:b7:13:e5:ea
Link detected: yes
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #46 (Ethernet controller)
=======================================================================
Acer 1501LCe x86_64 laptop.
============================
49: udi = '/org/freedesktop/Hal/devices/pci_14e4_169c'
info.bus = 'pci'
info.linux.driver = 'tg3'
info.parent = '/org/freedesktop/Hal/devices/computer'
info.product = 'NetXtreme BCM5788 Gigabit Ethernet'
info.udi = '/org/freedesktop/Hal/devices/pci_14e4_169c'
info.vendor = 'Broadcom Corporation'
linux.hotplug_type = 1 (0x1)
linux.subsystem = 'pci'
linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:0c.0'
linux.sysfs_path_device = '/sys/devices/pci0000:00/0000:00:0c.0'
pci.device_class = 2 (0x2)
pci.device_protocol = 0 (0x0)
pci.device_subclass = 0 (0x0)
pci.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:0c.0'
pci.product = 'NetXtreme BCM5788 Gigabit Ethernet'
pci.product_id = 5788 (0x169c)
pci.subsys_product = 'Unknown (0x0046)'
pci.subsys_product_id = 70 (0x46)
pci.subsys_vendor = 'Acer Incorporated [ALI]'
pci.subsys_vendor_id = 4133 (0x1025)
pci.vendor = 'Broadcom Corporation'
pci.vendor_id = 5348 (0x14e4)
============== tcpdump on barrabas when pinged from Boycie =====
01:45:32.089245 arp who-has Boycie.site tell barrabas.site
01:45:32.089323 arp reply Boycie.site is-at 00:0a:e4:4e:a1:42 (oui Unknown)
01:45:32.172445 IP Boycie.site > barrabas.site: ICMP echo request, id
8463, seq 41, length 64
01:45:32.172480 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463,
seq 41, length 64
01:45:33.189534 IP Boycie.site > barrabas.site: ICMP echo request, id
8463, seq 42, length 64
01:45:33.189569 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463,
seq 42, length 64
01:45:34.205635 IP Boycie.site > barrabas.site: ICMP echo request, id
8463, seq 43, length 64
01:45:34.205667 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463,
seq 43, length 64
01:45:35.221734 IP Boycie.site > barrabas.site: ICMP echo request, id
8463, seq 44, length 64
01:45:35.221767 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463,
seq 44, length 64
01:45:36.237835 IP Boycie.site > barrabas.site: ICMP echo request, id
8463, seq 45, length 64
01:45:36.237868 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463,
seq 45, length 64
01:45:37.254956 IP Boycie.site > barrabas.site: ICMP echo request, id
8463, seq 46, length 64
01:45:37.254991 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463,
seq 46, length 64
01:45:38.272044 IP Boycie.site > barrabas.site: ICMP echo request, id
8463, seq 47, length 64
01:45:38.272077 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463,
seq 47, length 64
01:45:39.288136 IP Boycie.site > barrabas.site: ICMP echo request, id
8463, seq 48, length 64
01:45:39.288170 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463,
seq 48, length 64
170 packets captured
340 packets received by filter
0 packets dropped by kernel
Boycie sees just a few packets occasionally when pinged from barrabas,
but says its dropped no packets.
Also strange, I can scp a file from Boycie.
barrabas:/usr/src/linux-2.6.20-rc1-git5 # scp Boycie:/IFCONFIG /
Password:
IFCONFIG 100% 907
0.9KB/s 00:00
barrabas:/usr/src/linux-2.6.20-rc1-git5 # o /IFCONFIG
eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42
inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0
inet6 addr: fe80::20a:e4ff:fe4e:a142/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:577 errors:0 dropped:0 overruns:0 frame:0
TX packets:569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:65202 (63.6 Kb) TX bytes:49404 (48.2 Kb)
Interrupt:20
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1866 (1.8 Kb) TX bytes:1866 (1.8 Kb)
barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig
Password:
eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42
inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0
inet6 addr: fe80::20a:e4ff:fe4e:a142/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:728 errors:0 dropped:0 overruns:0 frame:0
TX packets:710 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:83960 (81.9 Kb) TX bytes:65125 (63.5 Kb)
Interrupt:20
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1866 (1.8 Kb) TX bytes:1866 (1.8 Kb)
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
On 28-12-2006 04:23, Sid Boyce wrote:
>
>
> I first saw the problem on the 64x2 box after upgrading to 2.6.19. The
> network appeared OK with ifconfig and route -n, but I had no network
> access. Pinging any other box, the box was responding, but no response
...
> barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig
> Password:
> eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42
> inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0
This Bcast isn't probably what you need.
Regards,
Jarek P.
On Sat, Dec 30, 2006 at 02:21:15AM +0000, Sid Boyce wrote:
> Jarek Poplawski wrote:
> >On 28-12-2006 04:23, Sid Boyce wrote:
> >>
> >>I first saw the problem on the 64x2 box after upgrading to 2.6.19. The
> >>network appeared OK with ifconfig and route -n, but I had no network
> >>access. Pinging any other box, the box was responding, but no response
> >...
> >>barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig
> >>Password:
> >>eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42
> >> inet addr:192.168.10.5 Bcast:255.255.255.255
> >> Mask:255.255.255.0
> >
> >This Bcast isn't probably what you need.
> >
> >Regards,
> >Jarek P.
> >
> >
>
> Corrected on the one box where it was not correct, problem is still there.
There are many things to suspect yet:
- firewall,
- switch,
- routing,
- ifconfig,
- other misonfigured box,
- connecting
and so on.
I think you should try with some linux networking group
at first and if you really think it's driver then
[email protected] (instead of linux-kernel@).
If you could send full ifconfig, route -n (or ip route
if you use additional tables) and tcpdump (all packets)
from both boxes while pinging each other and a few words
how it is connected (other cards, other active boxes in
the network?) maybe something more could be found.
Cheers,
Jarek P.
PS: Sorry for late responding.
Jarek Poplawski wrote:
> On Sat, Dec 30, 2006 at 02:21:15AM +0000, Sid Boyce wrote:
>> Jarek Poplawski wrote:
>>> On 28-12-2006 04:23, Sid Boyce wrote:
>>>> I first saw the problem on the 64x2 box after upgrading to 2.6.19. The
>>>> network appeared OK with ifconfig and route -n, but I had no network
>>>> access. Pinging any other box, the box was responding, but no response
>>> ...
>>>> barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig
>>>> Password:
>>>> eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42
>>>> inet addr:192.168.10.5 Bcast:255.255.255.255
>>>> Mask:255.255.255.0
>>> This Bcast isn't probably what you need.
>>>
>>> Regards,
>>> Jarek P.
>>>
>>>
>> Corrected on the one box where it was not correct, problem is still there.
>
> There are many things to suspect yet:
> - firewall,
> - switch,
> - routing,
> - ifconfig,
> - other misonfigured box,
> - connecting
> and so on.
>
> I think you should try with some linux networking group
> at first and if you really think it's driver then
> [email protected] (instead of linux-kernel@).
>
> If you could send full ifconfig, route -n (or ip route
> if you use additional tables) and tcpdump (all packets)
> from both boxes while pinging each other and a few words
> how it is connected (other cards, other active boxes in
> the network?) maybe something more could be found.
>
> Cheers,
> Jarek P.
>
> PS: Sorry for late responding.
>
>
I have a problem with posting to linux-kernel and netdev, my mail got
returned as SPAM, now it just gets dropped. postmaster says the filter
is seeing a sub-string of something that is filtered. I shall try under
my other email address.
Everything is fine with a eepro100 on the 64x2 box that gave the same
problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1)
using the forcedeth module. On the x86_64 laptop the problem is with a
Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a
2.6.18.2 kernel, there is no problem.
With all configurations of cards on both, route -n is the same on all
kernels and instantly reports back. With >=2.6.19 on the laptop, netstat
-r takes a very long time before returning the information ~30 seconds,
instantly on 2.6.18.2.
Boycie:~ # netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
192.168.10.0 * 255.255.255.0 U 0 0 0
eth0
loopback * 255.0.0.0 U 0 0 0 lo
default Smoothie.site 0.0.0.0 UG 0 0 0
eth0
Boycie:~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.10.102 0.0.0.0 UG 0 0 0 eth0
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
Jarek Poplawski wrote:
> On Sat, Dec 30, 2006 at 02:21:15AM +0000, Sid Boyce wrote:
>> Jarek Poplawski wrote:
>>> On 28-12-2006 04:23, Sid Boyce wrote:
>>>> I first saw the problem on the 64x2 box after upgrading to 2.6.19. The
>>>> network appeared OK with ifconfig and route -n, but I had no network
>>>> access. Pinging any other box, the box was responding, but no response
>>> ...
>>>> barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig
>>>> Password:
>>>> eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42
>>>> inet addr:192.168.10.5 Bcast:255.255.255.255
>>>> Mask:255.255.255.0
>>> This Bcast isn't probably what you need.
>>>
>>> Regards,
>>> Jarek P.
>>>
>>>
>> Corrected on the one box where it was not correct, problem is still there.
>
> There are many things to suspect yet:
> - firewall,
> - switch,
> - routing,
> - ifconfig,
> - other misonfigured box,
> - connecting
> and so on.
>
> I think you should try with some linux networking group
> at first and if you really think it's driver then
> [email protected] (instead of linux-kernel@).
>
> If you could send full ifconfig, route -n (or ip route
> if you use additional tables) and tcpdump (all packets)
> from both boxes while pinging each other and a few words
> how it is connected (other cards, other active boxes in
> the network?) maybe something more could be found.
>
> Cheers,
> Jarek P.
>
> PS: Sorry for late responding.
>
>
I have a problem with posting to linux-kernel and netdev, my mail got
returned as SPAM, now it just gets dropped. postmaster says the filter
is seeing a sub-string of something that is filtered.
Everything is fine with a eepro100 on the 64x2 box that gave the same
problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1)
using the forcedeth module. On the x86_64 laptop the problem is with a
Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a
2.6.18.2 kernel, there is no problem.
With all configurations of cards on both, route -n is the same on all
kernels and instantly reports back. With >=2.6.19 on the laptop, netstat
-r takes a very long time before returning the information ~30 seconds,
instantly on 2.6.18.2.
Boycie:~ # netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
192.168.10.0 * 255.255.255.0 U 0 0 0
eth0
loopback * 255.0.0.0 U 0 0 0 lo
default Smoothie.site 0.0.0.0 UG 0 0 0
eth0
Boycie:~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.10.102 0.0.0.0 UG 0 0 0 eth0
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
Jarek Poplawski wrote:
> On Sat, Dec 30, 2006 at 02:21:15AM +0000, Sid Boyce wrote:
>> Jarek Poplawski wrote:
>>> On 28-12-2006 04:23, Sid Boyce wrote:
>>>> I first saw the problem on the 64x2 box after upgrading to 2.6.19. The
>>>> network appeared OK with ifconfig and route -n, but I had no network
>>>> access. Pinging any other box, the box was responding, but no response
>>> ...
>>>> barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig
>>>> Password:
>>>> eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42
>>>> inet addr:192.168.10.5 Bcast:255.255.255.255
>>>> Mask:255.255.255.0
>>> This Bcast isn't probably what you need.
>>>
>>> Regards,
>>> Jarek P.
>>>
>>>
>> Corrected on the one box where it was not correct, problem is still there.
>
> There are many things to suspect yet:
> - firewall,
> - switch,
> - routing,
> - ifconfig,
> - other misonfigured box,
> - connecting
> and so on.
>
> I think you should try with some linux networking group
> at first and if you really think it's driver then
> [email protected] (instead of linux-kernel@).
>
> If you could send full ifconfig, route -n (or ip route
> if you use additional tables) and tcpdump (all packets)
> from both boxes while pinging each other and a few words
> how it is connected (other cards, other active boxes in
> the network?) maybe something more could be found.
>
> Cheers,
> Jarek P.
>
> PS: Sorry for late responding.
>
>
I have a problem with posting to linux-kernel and netdev, my mail got
returned as SPAM, now it just gets dropped. postmaster says the filter
is seeing a sub-string of something that is filtered. I shall try
posting under another email address.
Everything is fine with a eepro100 on the 64x2 box that gave the same
problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1)
using the forcedeth module. On the x86_64 laptop the problem is with a
Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a
2.6.18.2 kernel, there is no problem.
With all configurations of cards on both, route -n is the same on all
kernels and instantly reports back. With >=2.6.19 on the laptop, netstat
-r takes a very long time before returning the information ~30 seconds,
instantly on 2.6.18.2.
Boycie:~ # netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
192.168.10.0 * 255.255.255.0 U 0 0 0
eth0
loopback * 255.0.0.0 U 0 0 0 lo
default Smoothie.site 0.0.0.0 UG 0 0 0
eth0
Boycie:~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.10.102 0.0.0.0 UG 0 0 0 eth0
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
On Tue, Jan 02, 2007 at 03:32:01PM +0000, Sid Boyce wrote:
> Jarek Poplawski wrote:
...
> >If you could send full ifconfig, route -n (or ip route
> >if you use additional tables) and tcpdump (all packets)
> >from both boxes while pinging each other and a few words
> >how it is connected (other cards, other active boxes in
> >the network?) maybe something more could be found.
...
> Everything is fine with a eepro100 on the 64x2 box that gave the same
> problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1)
> using the forcedeth module. On the x86_64 laptop the problem is with a
> Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a
> 2.6.18.2 kernel, there is no problem.
> With all configurations of cards on both, route -n is the same on all
> kernels and instantly reports back. With >=2.6.19 on the laptop, netstat
> -r takes a very long time before returning the information ~30 seconds,
> instantly on 2.6.18.2.
This could be a problem with DNS. Could you do all tests
(including pinging) with -n option?
I've read your other message on netdev and see you
have firewall working and addresses from various
networks in logs. I think it would be much easier
to exclude possible network config errors and try
to isolate pinging problems by connecting (with
switch or even crossed cable if possible) only 2
boxes with firewalls and other net devices disabled
and try to repeat this pinging with tcpdumps.
Jarek P.
Jarek Poplawski wrote:
> On Tue, Jan 02, 2007 at 03:32:01PM +0000, Sid Boyce wrote:
>> Jarek Poplawski wrote:
> ...
>>> If you could send full ifconfig, route -n (or ip route
>>> if you use additional tables) and tcpdump (all packets)
>> >from both boxes while pinging each other and a few words
>>> how it is connected (other cards, other active boxes in
>>> the network?) maybe something more could be found.
> ...
>> Everything is fine with a eepro100 on the 64x2 box that gave the same
>> problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1)
>> using the forcedeth module. On the x86_64 laptop the problem is with a
>> Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a
>> 2.6.18.2 kernel, there is no problem.
>> With all configurations of cards on both, route -n is the same on all
>> kernels and instantly reports back. With >=2.6.19 on the laptop, netstat
>> -r takes a very long time before returning the information ~30 seconds,
>> instantly on 2.6.18.2.
>
> This could be a problem with DNS. Could you do all tests
> (including pinging) with -n option?
>
> I've read your other message on netdev and see you
> have firewall working and addresses from various
> networks in logs. I think it would be much easier
> to exclude possible network config errors and try
> to isolate pinging problems by connecting (with
> switch or even crossed cable if possible) only 2
> boxes with firewalls and other net devices disabled
> and try to repeat this pinging with tcpdumps.
>
> Jarek P.
>
>
It seems >=2.6.19 and the SuSEfirewall are incompatible.
Turning off the firewall on the laptop cured the problem using
2.6.20-rc2 and 2.6.20-rc3. I thought it was off. On the 64x2 box, the
firewall is turned off, so I shall have to reconfigure the network to
use the Gigabit ethernet instead of the eepro100 in case I turned it off
after seeing the bug on that box, but didn't stop the firewall.
There is still the problem where the ethernet doesn't get configured
with acpi=off which I shall post to the acpi devel list, but this is not
a showstopper for me. ifconfig eth0 192.168.10.5 returns SIOCSIFFLAGS:
Function not implemented.
Thanks and Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
On Wed, Jan 03, 2007 at 04:53:58PM +0000, Sid Boyce wrote:
...
> It seems >=2.6.19 and the SuSEfirewall are incompatible.
Actually, many programs could be incomapatible with
newer kernel versions, so sometimes upgrades or at
least recompilations are needed.
...
> There is still the problem where the ethernet doesn't get configured
> with acpi=off which I shall post to the acpi devel list, but this is not
> a showstopper for me. ifconfig eth0 192.168.10.5 returns SIOCSIFFLAGS:
I don't know acpi enough but as far as I know
some mainboards can't work properly with acpi
off, so it's probably not a bug.
Cheers,
Jarek P.