Am Thursday 03 January 2013 schrieb Martin Kuball: > Am Wednesday 02 January 2013 schrieb Martin Kuball: > > Am Wednesday 02 January 2013 schrieb Michel Dänzer: > > > On Mit, 2013-01-02 at 14:40 +0100, Martin Kuball wrote: > > > > Am Wednesday 02 January 2013 schrieb Michel Dänzer: > > > > > On Die, 2013-01-01 at 21:52 +0100, Martin Kuball wrote: > > > > > > Hello, > > > > > > > > > > > > I made some progress. After switching update to sequential boot I > > > > > > saw > > > > > > the following exception: > > > > > > > > > > > > machine check in kernel mode > > > > > > caused by (from SRR1=49030): Transfer error ack signal > > > > > > oops: machine check, sig: 7 [#1] > > > > > > > > > > > > the top entry of the call trace is: > > > > > > gem_ioctl+0x60/0x94 [sungem] > > > > > > > > > > > > But this seems really odd to me. If the error is in the kernel > > > > > > module, > > > > > > why does it still occur after switching back to the old kernel? > > > > > > > > > > Maybe one of the userspace packages you upgraded is now using the > > > > > broken > > > > > kernel functionality but wasn't before. > > > > > > > > > But sungem ist the ethernet driver, isn't it? And indeed networking is > > > > broken. > > > > > > Right, so the most likely trigger was the upgrade of anything network > > > related, or maybe some kind of boot/init related package which is now > > > setting networking parameters it wasn't before. > > > > > > But a machine check leaves little doubt that the root cause is a bug in > > > the sungem kernel driver (or a hardware problem). > > > > > > > > > > Running ping gives "network unreachable". > > > > ifconfig simply hangs (and with it the shell/terminal from which it > > > > was started). > > > > > > Given the subject says 'stopped booting', how are you able to test > > > that? :) > > > > See the top of my posting. I configured upstart (oh, my bad - I wrote > > update) to run the init jobs sequentially. After that i saw the error > > message and got a login prompt. But no networking. And no X. > > > > The next things I will try is disabling eth0 and reverting every updated > > package to its previous versions. > > > > I don't think it's a hardware problem. The rescue disk works just fine - > > including newtwork. > > > I made a step forward by doing something I should have done right away: > disabling the init script that run just before the kernel produced the error > message. And it is: laptop-mode. But still no clue as to what actually > triggered the error. laptop-mode-tools was not updated. >
After spending to much time figuring out what's going on, I have at least a working system. The error is triggered when laptop-mode is setting the auto negotiation attribute. So it may be a hardware error after all. Because if I bring up the network manually (ifup -a) it works. Well, I can live with that for now. -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201301141947.13873.martinkub...@web.de
