Mageia forum

Hi, so I installed Mageia on a Lenovo G575 laptop, but ran into problems.

System installed fine, but would hang sometime after booting, before I had time to log in, making it completely unusable. So I investigated a bit, and in short - it seems to be the network driver issue. Only it was difficult to locate because of the new non-sequential init...

Here's what happened:

eth0 is enabled on boot, but the cable's not plugged in, and when network-up init script does ip -o link show eth0 the kernel immediately hangs (ie. the cursor stops blinking, no response from anything...). IMHO, this is probably kernel driver bug, so please inform upstream if possible.

There seems to be another issue that this problem highlighted: since the kernel would hang, I had to force power off the laptop. But after restart and ensuing fsck, the messages file would get truncated way into kernel startup messages, so using install dvd for rescue no useful information is to be found.

I guess this is the "feature" of ext4 - if we can't have reiserfs, why not try btrfs, even in alpha it couldn't be worse than this!

Also, try to rehash interface detection, since this makes Mageia unusable on this laptop.

Thanks in advance.

Here's the lspci output for this device:

# lspci -nnvs 02:00.0
02:00.0 Ethernet controller [0200]: Atheros Communications AR8152 v2.0 Fast Ethernet [1969:2062] (rev c1)
Subsystem: Lenovo Device [17aa:397b]
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at d0100000 (64-bit, non-prefetchable) [size=256K]
I/O ports at 2000 [size=128]
Capabilities: [40] Power Management version 3
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [58] Express Endpoint, MSI 00
Capabilities: [6c] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [180] Device Serial Number ff-67-f2-79-1c-75-08-ff
Kernel driver in use: atl1c
Kernel modules: atl1c

chomee wrote:There seems to be another issue that this problem highlighted: since the kernel would hang, I had to force power off the laptop. But after restart and ensuing fsck, the messages file would get truncated way into kernel startup messages, so using install dvd for rescue no useful information is to be found.

I guess this is the "feature" of ext4 - if we can't have reiserfs, why not try btrfs, even in alpha it couldn't be worse than this!

Also, try to rehash interface detection, since this makes Mageia unusable on this laptop.

Please, don't mangle thread topics. One problem per thread. So, what does the choice of file system
have to do with truncating kernel messages? Also, what do you mean by "the messages file would get truncated way into kernel startup messages" ?
Also, you can have ReiserFS without problems during installation. And honestly, can't figure out how
BTRFS would change anything at your situation. Please don't do such side-blows, this is not constructive.

Could you also please describe what do you mean by "try to rehash interface detection" ?

OK, sorry about bashing ext4, just needed to vent my frustration.

By "rehashing" I meant maybe try to devise another way of testing for network presence. Alternatively, setting eth0 with onboot=no might help the issue.

I have tried giving the test command after the system has worked for a couple of hours, and it came back OK. So I assumed that intervening kernel update has fixed this problem as well and turned onboot back on, but the system promptly hung after restart.

So my current guess is that there's something about the order the modules are loaded. Maybe atheros modules somehow interact, so that ethernet (atl module) hangs if it has no connection and wifi (ath) is down too.

Please let me know if you have any idea how to pinpoint the problem, since I won't have the laptop much longer.

Thanks.

Could you please post or pastebin your dmesg output, if it doesn't fit all in one code-tag?

Well that is the problem - when computer locks up, not even magic sysrq keys work, so I can't force umount. But when computer is uncleanly shut down, ext4 kindly erases whole of dmesg, dmesg.old and everything useful in messages. And it typically hangs in slightly various places, thanks to async init.

I had to run init scripts with bash -x to see where it hangs - but then I can't see dmesg...

BTW, I tested a bit more, and the test works OK when computer has been running for a while.