On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
>
> Hi guys,
> I have been running custom compiled 2.6.28.7 in OpenSUSE 11.1 and using
> hiberation/resume daily as configured by the distro. Yesterday I upgraded to
> 2.6.29 (make oldconfig from 2.6.28.7, attached) and after resume networking
> (at least) does not work. Reboot at this point takes very long because of
> timeouts on CIFS and whatelse.
>
> Below is how /var/log/messagess looks for one cycle (hibernate-resume-reboot)
> and I am also attaching kernel config and /var/log/pm-suspend.log.
>
> You will probably notice evil nvidia.ko in there but don't panic, it all
> happens without it as well. Tested from runlevel 3 and by running
> pm-hibernate. After resume from that NIC LEDs were off. I
> tried /etc/init.d/network restart but that hung so I ^C and tried rmmod
> forcedeth && modprobe forcedeth && ifup eth0 and after some time network went
> live again. Haven't had time to test further though, so this is all pretty
> rough.
Ok, can you try to rmmod forcedeth before hibernation, then insmod it
after resume?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thursday 26 March 2009 20:18:40 Pavel Machek wrote:
> On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
> > Hi guys,
> > I have been running custom compiled 2.6.28.7 in OpenSUSE 11.1 and using
> > hiberation/resume daily as configured by the distro. Yesterday I upgraded
> > to 2.6.29 (make oldconfig from 2.6.28.7, attached) and after resume
> > networking (at least) does not work. Reboot at this point takes very long
> > because of timeouts on CIFS and whatelse.
> >
> > Below is how /var/log/messagess looks for one cycle
> > (hibernate-resume-reboot) and I am also attaching kernel config and
> > /var/log/pm-suspend.log.
> >
> > You will probably notice evil nvidia.ko in there but don't panic, it all
> > happens without it as well. Tested from runlevel 3 and by running
> > pm-hibernate. After resume from that NIC LEDs were off. I
> > tried /etc/init.d/network restart but that hung so I ^C and tried rmmod
> > forcedeth && modprobe forcedeth && ifup eth0 and after some time network
> > went live again. Haven't had time to test further though, so this is all
> > pretty rough.
>
> Ok, can you try to rmmod forcedeth before hibernation, then insmod it
> after resume?
Sure, after insmod and /etc/init.d/network start following resume network was
fine. Guess I could kludge that sequence into pm scripts somehow but would
rather avoid that since it slows down the cycle and would make scripts
non-stock.
Tvrtko
On Thu 2009-03-26 20:55:23, Tvrtko A. Ursulin wrote:
> On Thursday 26 March 2009 20:18:40 Pavel Machek wrote:
> > On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
> > > Hi guys,
> > > I have been running custom compiled 2.6.28.7 in OpenSUSE 11.1 and using
> > > hiberation/resume daily as configured by the distro. Yesterday I upgraded
> > > to 2.6.29 (make oldconfig from 2.6.28.7, attached) and after resume
> > > networking (at least) does not work. Reboot at this point takes very long
> > > because of timeouts on CIFS and whatelse.
> > >
> > > Below is how /var/log/messagess looks for one cycle
> > > (hibernate-resume-reboot) and I am also attaching kernel config and
> > > /var/log/pm-suspend.log.
> > >
> > > You will probably notice evil nvidia.ko in there but don't panic, it all
> > > happens without it as well. Tested from runlevel 3 and by running
> > > pm-hibernate. After resume from that NIC LEDs were off. I
> > > tried /etc/init.d/network restart but that hung so I ^C and tried rmmod
> > > forcedeth && modprobe forcedeth && ifup eth0 and after some time network
> > > went live again. Haven't had time to test further though, so this is all
> > > pretty rough.
> >
> > Ok, can you try to rmmod forcedeth before hibernation, then insmod it
> > after resume?
>
> Sure, after insmod and /etc/init.d/network start following resume network was
> fine. Guess I could kludge that sequence into pm scripts somehow but would
> rather avoid that since it slows down the cycle and would make scripts
> non-stock.
Ok, I guess you need to talk to forcedeth maintainers then... sounds
like a forcedeth problem to me.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thursday 26 March 2009, Pavel Machek wrote:
> On Thu 2009-03-26 20:55:23, Tvrtko A. Ursulin wrote:
> > On Thursday 26 March 2009 20:18:40 Pavel Machek wrote:
> > > On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
> > > > Hi guys,
> > > > I have been running custom compiled 2.6.28.7 in OpenSUSE 11.1 and using
> > > > hiberation/resume daily as configured by the distro. Yesterday I upgraded
> > > > to 2.6.29 (make oldconfig from 2.6.28.7, attached) and after resume
> > > > networking (at least) does not work. Reboot at this point takes very long
> > > > because of timeouts on CIFS and whatelse.
> > > >
> > > > Below is how /var/log/messagess looks for one cycle
> > > > (hibernate-resume-reboot) and I am also attaching kernel config and
> > > > /var/log/pm-suspend.log.
> > > >
> > > > You will probably notice evil nvidia.ko in there but don't panic, it all
> > > > happens without it as well. Tested from runlevel 3 and by running
> > > > pm-hibernate. After resume from that NIC LEDs were off. I
> > > > tried /etc/init.d/network restart but that hung so I ^C and tried rmmod
> > > > forcedeth && modprobe forcedeth && ifup eth0 and after some time network
> > > > went live again. Haven't had time to test further though, so this is all
> > > > pretty rough.
> > >
> > > Ok, can you try to rmmod forcedeth before hibernation, then insmod it
> > > after resume?
> >
> > Sure, after insmod and /etc/init.d/network start following resume network was
> > fine. Guess I could kludge that sequence into pm scripts somehow but would
> > rather avoid that since it slows down the cycle and would make scripts
> > non-stock.
>
> Ok, I guess you need to talk to forcedeth maintainers then... sounds
> like a forcedeth problem to me.
I have a box with forcedeth somewhere here, I should be able to check that
in the next few days.
Thanks,
Rafael
On Thursday 26 March 2009 21:35:29 Rafael J. Wysocki wrote:
> On Thursday 26 March 2009, Pavel Machek wrote:
> > On Thu 2009-03-26 20:55:23, Tvrtko A. Ursulin wrote:
> > > On Thursday 26 March 2009 20:18:40 Pavel Machek wrote:
> > > > On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
> > > > > Hi guys,
> > > > > I have been running custom compiled 2.6.28.7 in OpenSUSE 11.1 and
> > > > > using hiberation/resume daily as configured by the distro.
> > > > > Yesterday I upgraded to 2.6.29 (make oldconfig from 2.6.28.7,
> > > > > attached) and after resume networking (at least) does not work.
> > > > > Reboot at this point takes very long because of timeouts on CIFS
> > > > > and whatelse.
> > > > >
> > > > > Below is how /var/log/messagess looks for one cycle
> > > > > (hibernate-resume-reboot) and I am also attaching kernel config and
> > > > > /var/log/pm-suspend.log.
> > > > >
> > > > > You will probably notice evil nvidia.ko in there but don't panic,
> > > > > it all happens without it as well. Tested from runlevel 3 and by
> > > > > running pm-hibernate. After resume from that NIC LEDs were off. I
> > > > > tried /etc/init.d/network restart but that hung so I ^C and tried
> > > > > rmmod forcedeth && modprobe forcedeth && ifup eth0 and after some
> > > > > time network went live again. Haven't had time to test further
> > > > > though, so this is all pretty rough.
> > > >
> > > > Ok, can you try to rmmod forcedeth before hibernation, then insmod it
> > > > after resume?
> > >
> > > Sure, after insmod and /etc/init.d/network start following resume
> > > network was fine. Guess I could kludge that sequence into pm scripts
> > > somehow but would rather avoid that since it slows down the cycle and
> > > would make scripts non-stock.
> >
> > Ok, I guess you need to talk to forcedeth maintainers then... sounds
> > like a forcedeth problem to me.
>
> I have a box with forcedeth somewhere here, I should be able to check that
> in the next few days.
Not a lot activity in forcedeth.c from 2.6.28 to 2.6.29 so I will CC two guys
who commited changes in that period. Ayaz, Tobias, forcedeth does not seem to
come up after hibernation well for me. Actual hardware is:
00:0f.0 Ethernet controller: nVidia Corporation MCP73 Ethernet (rev a2)
Anything more I can do just shout!
Tvrtko
On Thu 2009-03-26 22:01:03, Tvrtko A. Ursulin wrote:
> On Thursday 26 March 2009 21:35:29 Rafael J. Wysocki wrote:
> > On Thursday 26 March 2009, Pavel Machek wrote:
> > > On Thu 2009-03-26 20:55:23, Tvrtko A. Ursulin wrote:
> > > > On Thursday 26 March 2009 20:18:40 Pavel Machek wrote:
> > > > > On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
> > > > > > Hi guys,
> > > > > > I have been running custom compiled 2.6.28.7 in OpenSUSE 11.1 and
> > > > > > using hiberation/resume daily as configured by the distro.
> > > > > > Yesterday I upgraded to 2.6.29 (make oldconfig from 2.6.28.7,
> > > > > > attached) and after resume networking (at least) does not work.
> > > > > > Reboot at this point takes very long because of timeouts on CIFS
> > > > > > and whatelse.
> > > > > >
> > > > > > Below is how /var/log/messagess looks for one cycle
> > > > > > (hibernate-resume-reboot) and I am also attaching kernel config and
> > > > > > /var/log/pm-suspend.log.
> > > > > >
> > > > > > You will probably notice evil nvidia.ko in there but don't panic,
> > > > > > it all happens without it as well. Tested from runlevel 3 and by
> > > > > > running pm-hibernate. After resume from that NIC LEDs were off. I
> > > > > > tried /etc/init.d/network restart but that hung so I ^C and tried
> > > > > > rmmod forcedeth && modprobe forcedeth && ifup eth0 and after some
> > > > > > time network went live again. Haven't had time to test further
> > > > > > though, so this is all pretty rough.
> > > > >
> > > > > Ok, can you try to rmmod forcedeth before hibernation, then insmod it
> > > > > after resume?
> > > >
> > > > Sure, after insmod and /etc/init.d/network start following resume
> > > > network was fine. Guess I could kludge that sequence into pm scripts
> > > > somehow but would rather avoid that since it slows down the cycle and
> > > > would make scripts non-stock.
> > >
> > > Ok, I guess you need to talk to forcedeth maintainers then... sounds
> > > like a forcedeth problem to me.
> >
> > I have a box with forcedeth somewhere here, I should be able to check that
> > in the next few days.
>
> Not a lot activity in forcedeth.c from 2.6.28 to 2.6.29 so I will CC two guys
> who commited changes in that period. Ayaz, Tobias, forcedeth does not seem to
> come up after hibernation well for me. Actual hardware is:
>
> 00:0f.0 Ethernet controller: nVidia Corporation MCP73 Ethernet (rev a2)
>
> Anything more I can do just shout!
Actually yes. Testing forcedeth from 2.6.28 in 2.6.29 would be nice
way to prove problem is indeed in that module.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thursday 26 March 2009 22:38:55 Pavel Machek wrote:
> On Thu 2009-03-26 22:01:03, Tvrtko A. Ursulin wrote:
> > On Thursday 26 March 2009 21:35:29 Rafael J. Wysocki wrote:
> > > On Thursday 26 March 2009, Pavel Machek wrote:
> > > > On Thu 2009-03-26 20:55:23, Tvrtko A. Ursulin wrote:
> > > > > On Thursday 26 March 2009 20:18:40 Pavel Machek wrote:
> > > > > > On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
> > > > > > > Hi guys,
> > > > > > > I have been running custom compiled 2.6.28.7 in OpenSUSE 11.1
> > > > > > > and using hiberation/resume daily as configured by the distro.
> > > > > > > Yesterday I upgraded to 2.6.29 (make oldconfig from 2.6.28.7,
> > > > > > > attached) and after resume networking (at least) does not work.
> > > > > > > Reboot at this point takes very long because of timeouts on
> > > > > > > CIFS and whatelse.
> > > > > > >
> > > > > > > Below is how /var/log/messagess looks for one cycle
> > > > > > > (hibernate-resume-reboot) and I am also attaching kernel config
> > > > > > > and /var/log/pm-suspend.log.
> > > > > > >
> > > > > > > You will probably notice evil nvidia.ko in there but don't
> > > > > > > panic, it all happens without it as well. Tested from runlevel
> > > > > > > 3 and by running pm-hibernate. After resume from that NIC LEDs
> > > > > > > were off. I tried /etc/init.d/network restart but that hung so
> > > > > > > I ^C and tried rmmod forcedeth && modprobe forcedeth && ifup
> > > > > > > eth0 and after some time network went live again. Haven't had
> > > > > > > time to test further though, so this is all pretty rough.
> > > > > >
> > > > > > Ok, can you try to rmmod forcedeth before hibernation, then
> > > > > > insmod it after resume?
> > > > >
> > > > > Sure, after insmod and /etc/init.d/network start following resume
> > > > > network was fine. Guess I could kludge that sequence into pm
> > > > > scripts somehow but would rather avoid that since it slows down the
> > > > > cycle and would make scripts non-stock.
> > > >
> > > > Ok, I guess you need to talk to forcedeth maintainers then... sounds
> > > > like a forcedeth problem to me.
> > >
> > > I have a box with forcedeth somewhere here, I should be able to check
> > > that in the next few days.
> >
> > Not a lot activity in forcedeth.c from 2.6.28 to 2.6.29 so I will CC two
> > guys who commited changes in that period. Ayaz, Tobias, forcedeth does
> > not seem to come up after hibernation well for me. Actual hardware is:
> >
> > 00:0f.0 Ethernet controller: nVidia Corporation MCP73 Ethernet (rev a2)
> >
> > Anything more I can do just shout!
>
> Actually yes. Testing forcedeth from 2.6.28 in 2.6.29 would be nice
> way to prove problem is indeed in that module.
Good idea, I had to massage it a bit due to some API changes, but the end
result is a correct resume which proves that the problem really is in
forcedeth.
Tvrtko
On Friday 27 March 2009, Tvrtko A. Ursulin wrote:
> On Thursday 26 March 2009 22:38:55 Pavel Machek wrote:
> > On Thu 2009-03-26 22:01:03, Tvrtko A. Ursulin wrote:
> > > On Thursday 26 March 2009 21:35:29 Rafael J. Wysocki wrote:
> > > > On Thursday 26 March 2009, Pavel Machek wrote:
> > > > > On Thu 2009-03-26 20:55:23, Tvrtko A. Ursulin wrote:
> > > > > > On Thursday 26 March 2009 20:18:40 Pavel Machek wrote:
> > > > > > > On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
> > > > > > > > Hi guys,
> > > > > > > > I have been running custom compiled 2.6.28.7 in OpenSUSE 11.1
> > > > > > > > and using hiberation/resume daily as configured by the distro.
> > > > > > > > Yesterday I upgraded to 2.6.29 (make oldconfig from 2.6.28.7,
> > > > > > > > attached) and after resume networking (at least) does not work.
> > > > > > > > Reboot at this point takes very long because of timeouts on
> > > > > > > > CIFS and whatelse.
> > > > > > > >
> > > > > > > > Below is how /var/log/messagess looks for one cycle
> > > > > > > > (hibernate-resume-reboot) and I am also attaching kernel config
> > > > > > > > and /var/log/pm-suspend.log.
> > > > > > > >
> > > > > > > > You will probably notice evil nvidia.ko in there but don't
> > > > > > > > panic, it all happens without it as well. Tested from runlevel
> > > > > > > > 3 and by running pm-hibernate. After resume from that NIC LEDs
> > > > > > > > were off. I tried /etc/init.d/network restart but that hung so
> > > > > > > > I ^C and tried rmmod forcedeth && modprobe forcedeth && ifup
> > > > > > > > eth0 and after some time network went live again. Haven't had
> > > > > > > > time to test further though, so this is all pretty rough.
> > > > > > >
> > > > > > > Ok, can you try to rmmod forcedeth before hibernation, then
> > > > > > > insmod it after resume?
> > > > > >
> > > > > > Sure, after insmod and /etc/init.d/network start following resume
> > > > > > network was fine. Guess I could kludge that sequence into pm
> > > > > > scripts somehow but would rather avoid that since it slows down the
> > > > > > cycle and would make scripts non-stock.
> > > > >
> > > > > Ok, I guess you need to talk to forcedeth maintainers then... sounds
> > > > > like a forcedeth problem to me.
> > > >
> > > > I have a box with forcedeth somewhere here, I should be able to check
> > > > that in the next few days.
> > >
> > > Not a lot activity in forcedeth.c from 2.6.28 to 2.6.29 so I will CC two
> > > guys who commited changes in that period. Ayaz, Tobias, forcedeth does
> > > not seem to come up after hibernation well for me. Actual hardware is:
> > >
> > > 00:0f.0 Ethernet controller: nVidia Corporation MCP73 Ethernet (rev a2)
> > >
> > > Anything more I can do just shout!
> >
> > Actually yes. Testing forcedeth from 2.6.28 in 2.6.29 would be nice
> > way to prove problem is indeed in that module.
>
> Good idea, I had to massage it a bit due to some API changes, but the end
> result is a correct resume which proves that the problem really is in
> forcedeth.
Well, since you can easily check what commits changed forcedeth between
2.6.28 and 2.6.29, you can find the one that introduced the problem for you.
Thanks,
Rafael
On Thursday 26 March 2009 23:08:59 Rafael J. Wysocki wrote:
> On Friday 27 March 2009, Tvrtko A. Ursulin wrote:
> > On Thursday 26 March 2009 22:38:55 Pavel Machek wrote:
> > > On Thu 2009-03-26 22:01:03, Tvrtko A. Ursulin wrote:
> > > > On Thursday 26 March 2009 21:35:29 Rafael J. Wysocki wrote:
> > > > > On Thursday 26 March 2009, Pavel Machek wrote:
> > > > > > On Thu 2009-03-26 20:55:23, Tvrtko A. Ursulin wrote:
> > > > > > > On Thursday 26 March 2009 20:18:40 Pavel Machek wrote:
> > > > > > > > On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
> > > > > > > > > Hi guys,
> > > > > > > > > I have been running custom compiled 2.6.28.7 in OpenSUSE
> > > > > > > > > 11.1 and using hiberation/resume daily as configured by the
> > > > > > > > > distro. Yesterday I upgraded to 2.6.29 (make oldconfig from
> > > > > > > > > 2.6.28.7, attached) and after resume networking (at least)
> > > > > > > > > does not work. Reboot at this point takes very long because
> > > > > > > > > of timeouts on CIFS and whatelse.
> > > > > > > > >
> > > > > > > > > Below is how /var/log/messagess looks for one cycle
> > > > > > > > > (hibernate-resume-reboot) and I am also attaching kernel
> > > > > > > > > config and /var/log/pm-suspend.log.
> > > > > > > > >
> > > > > > > > > You will probably notice evil nvidia.ko in there but don't
> > > > > > > > > panic, it all happens without it as well. Tested from
> > > > > > > > > runlevel 3 and by running pm-hibernate. After resume from
> > > > > > > > > that NIC LEDs were off. I tried /etc/init.d/network restart
> > > > > > > > > but that hung so I ^C and tried rmmod forcedeth && modprobe
> > > > > > > > > forcedeth && ifup eth0 and after some time network went
> > > > > > > > > live again. Haven't had time to test further though, so
> > > > > > > > > this is all pretty rough.
> > > > > > > >
> > > > > > > > Ok, can you try to rmmod forcedeth before hibernation, then
> > > > > > > > insmod it after resume?
> > > > > > >
> > > > > > > Sure, after insmod and /etc/init.d/network start following
> > > > > > > resume network was fine. Guess I could kludge that sequence
> > > > > > > into pm scripts somehow but would rather avoid that since it
> > > > > > > slows down the cycle and would make scripts non-stock.
> > > > > >
> > > > > > Ok, I guess you need to talk to forcedeth maintainers then...
> > > > > > sounds like a forcedeth problem to me.
> > > > >
> > > > > I have a box with forcedeth somewhere here, I should be able to
> > > > > check that in the next few days.
> > > >
> > > > Not a lot activity in forcedeth.c from 2.6.28 to 2.6.29 so I will CC
> > > > two guys who commited changes in that period. Ayaz, Tobias, forcedeth
> > > > does not seem to come up after hibernation well for me. Actual
> > > > hardware is:
> > > >
> > > > 00:0f.0 Ethernet controller: nVidia Corporation MCP73 Ethernet (rev
> > > > a2)
> > > >
> > > > Anything more I can do just shout!
> > >
> > > Actually yes. Testing forcedeth from 2.6.28 in 2.6.29 would be nice
> > > way to prove problem is indeed in that module.
> >
> > Good idea, I had to massage it a bit due to some API changes, but the end
> > result is a correct resume which proves that the problem really is in
> > forcedeth.
>
> Well, since you can easily check what commits changed forcedeth between
> 2.6.28 and 2.6.29, you can find the one that introduced the problem for
> you.
Not so easily :/ I don't know git for start, what I did so far was through the
web interface, but this morning a lot more commits appeared so my assumption
that if I start by selecting 2.6.29 tag and then tree, that leaves the view
in 2.6.29 tagged state was obviously wrong.
What I managed to do is to revert this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=34edaa88324004baf4884fb0388f86059d9c4878
But that didn't fix the problem. That one was also the last commit yesterday,
but not any more today as I said. Interestingly, the next one
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e70049b9e74267dd47e1ffa62302073487afcb48#patch203)
seems to introduce the same change.
Anyway, I won't have time due to personal and business commitments to test
this further for a couple of weeks.
Tvrtko
Tvrtko A. Ursulin wrote:
> Not a lot activity in forcedeth.c from 2.6.28 to 2.6.29 so I will CC two guys
> who commited changes in that period. Ayaz, Tobias, forcedeth does not seem to
> come up after hibernation well for me. Actual hardware is:
>
> 00:0f.0 Ethernet controller: nVidia Corporation MCP73 Ethernet (rev a2)
Unfortunately, after moving to a different appartement last weekend,
my nforce mainboard is now about 650Km from where I am and will stay
there for the next months...
--
Tobias PGP: http://9ac7e0bc.uguu.de
On Friday 27 March 2009, Tvrtko A. Ursulin wrote:
> On Thursday 26 March 2009 23:08:59 Rafael J. Wysocki wrote:
> > On Friday 27 March 2009, Tvrtko A. Ursulin wrote:
> > > On Thursday 26 March 2009 22:38:55 Pavel Machek wrote:
> > > > On Thu 2009-03-26 22:01:03, Tvrtko A. Ursulin wrote:
> > > > > On Thursday 26 March 2009 21:35:29 Rafael J. Wysocki wrote:
> > > > > > On Thursday 26 March 2009, Pavel Machek wrote:
> > > > > > > On Thu 2009-03-26 20:55:23, Tvrtko A. Ursulin wrote:
> > > > > > > > On Thursday 26 March 2009 20:18:40 Pavel Machek wrote:
> > > > > > > > > On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
> > > > > > > > > > Hi guys,
> > > > > > > > > > I have been running custom compiled 2.6.28.7 in OpenSUSE
> > > > > > > > > > 11.1 and using hiberation/resume daily as configured by the
> > > > > > > > > > distro. Yesterday I upgraded to 2.6.29 (make oldconfig from
> > > > > > > > > > 2.6.28.7, attached) and after resume networking (at least)
> > > > > > > > > > does not work. Reboot at this point takes very long because
> > > > > > > > > > of timeouts on CIFS and whatelse.
> > > > > > > > > >
> > > > > > > > > > Below is how /var/log/messagess looks for one cycle
> > > > > > > > > > (hibernate-resume-reboot) and I am also attaching kernel
> > > > > > > > > > config and /var/log/pm-suspend.log.
> > > > > > > > > >
> > > > > > > > > > You will probably notice evil nvidia.ko in there but don't
> > > > > > > > > > panic, it all happens without it as well. Tested from
> > > > > > > > > > runlevel 3 and by running pm-hibernate. After resume from
> > > > > > > > > > that NIC LEDs were off. I tried /etc/init.d/network restart
> > > > > > > > > > but that hung so I ^C and tried rmmod forcedeth && modprobe
> > > > > > > > > > forcedeth && ifup eth0 and after some time network went
> > > > > > > > > > live again. Haven't had time to test further though, so
> > > > > > > > > > this is all pretty rough.
> > > > > > > > >
> > > > > > > > > Ok, can you try to rmmod forcedeth before hibernation, then
> > > > > > > > > insmod it after resume?
> > > > > > > >
> > > > > > > > Sure, after insmod and /etc/init.d/network start following
> > > > > > > > resume network was fine. Guess I could kludge that sequence
> > > > > > > > into pm scripts somehow but would rather avoid that since it
> > > > > > > > slows down the cycle and would make scripts non-stock.
> > > > > > >
> > > > > > > Ok, I guess you need to talk to forcedeth maintainers then...
> > > > > > > sounds like a forcedeth problem to me.
> > > > > >
> > > > > > I have a box with forcedeth somewhere here, I should be able to
> > > > > > check that in the next few days.
> > > > >
> > > > > Not a lot activity in forcedeth.c from 2.6.28 to 2.6.29 so I will CC
> > > > > two guys who commited changes in that period. Ayaz, Tobias, forcedeth
> > > > > does not seem to come up after hibernation well for me. Actual
> > > > > hardware is:
> > > > >
> > > > > 00:0f.0 Ethernet controller: nVidia Corporation MCP73 Ethernet (rev
> > > > > a2)
> > > > >
> > > > > Anything more I can do just shout!
> > > >
> > > > Actually yes. Testing forcedeth from 2.6.28 in 2.6.29 would be nice
> > > > way to prove problem is indeed in that module.
> > >
> > > Good idea, I had to massage it a bit due to some API changes, but the end
> > > result is a correct resume which proves that the problem really is in
> > > forcedeth.
> >
> > Well, since you can easily check what commits changed forcedeth between
> > 2.6.28 and 2.6.29, you can find the one that introduced the problem for
> > you.
>
> Not so easily :/ I don't know git for start,
I didn't know that, sorry.
Basically, you can do:
$ git whatchanged v2.6.28..v2.6.29 drivers/net/forcedeth.c | grep '^commit'
> what I did so far was through the
> web interface, but this morning a lot more commits appeared so my assumption
> that if I start by selecting 2.6.29 tag and then tree, that leaves the view
> in 2.6.29 tagged state was obviously wrong.
>
> What I managed to do is to revert this:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=34edaa88324004baf4884fb0388f86059d9c4878
>
> But that didn't fix the problem. That one was also the last commit yesterday,
> but not any more today as I said. Interestingly, the next one
> (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e70049b9e74267dd47e1ffa62302073487afcb48#patch203)
> seems to introduce the same change.
>
> Anyway, I won't have time due to personal and business commitments to test
> this further for a couple of weeks.
and here's the result (in case you have some time to check):
commit 34edaa88324004baf4884fb0388f86059d9c4878
commit eb10a781824ca63c4e484c4642a19b3370980792
commit a7ee2f73f3ce90d73736de1cf432339c35a3faf2
commit f1405d32e392f2f5f80f4687fe186305de300bf6
commit 001eb84bbf7205f8cc541a75364a6a0892b5d0a2
commit 36994a0a7004fd4777cd93a4b658b5f84bf4c93e
commit 908a7a16b852ffd618a9127be8d62432182d81b4
commit b74ca3a896b9ab5f952bc440154758e708c48884
commit cb52deba12f27af90a46d2f8667a64888118a888
commit 008298231abbeb91bc7be9e8b078607b816d1a4a
commit b94426bd9d16fb2753ada1255c7a432f49dfebcb
commit babcda74e9d96bb58fd9c6c5112dbdbff169e695
commit dccd547e2bf2c01a13c967ae03a705338394fad6
commit e174961ca1a0b28f7abf0be47973ad57cb74e5f0
Thanks,
Rafael
On Friday 27 March 2009, Rafael J. Wysocki wrote:
> On Friday 27 March 2009, Tvrtko A. Ursulin wrote:
> > On Thursday 26 March 2009 23:08:59 Rafael J. Wysocki wrote:
> > > On Friday 27 March 2009, Tvrtko A. Ursulin wrote:
> > > > On Thursday 26 March 2009 22:38:55 Pavel Machek wrote:
> > > > > On Thu 2009-03-26 22:01:03, Tvrtko A. Ursulin wrote:
> > > > > > On Thursday 26 March 2009 21:35:29 Rafael J. Wysocki wrote:
> > > > > > > On Thursday 26 March 2009, Pavel Machek wrote:
> > > > > > > > On Thu 2009-03-26 20:55:23, Tvrtko A. Ursulin wrote:
> > > > > > > > > On Thursday 26 March 2009 20:18:40 Pavel Machek wrote:
> > > > > > > > > > On Thu 2009-03-26 19:20:32, Tvrtko A. Ursulin wrote:
> > > > > > > > > > > Hi guys,
> > > > > > > > > > > I have been running custom compiled 2.6.28.7 in OpenSUSE
> > > > > > > > > > > 11.1 and using hiberation/resume daily as configured by the
> > > > > > > > > > > distro. Yesterday I upgraded to 2.6.29 (make oldconfig from
> > > > > > > > > > > 2.6.28.7, attached) and after resume networking (at least)
> > > > > > > > > > > does not work. Reboot at this point takes very long because
> > > > > > > > > > > of timeouts on CIFS and whatelse.
> > > > > > > > > > >
> > > > > > > > > > > Below is how /var/log/messagess looks for one cycle
> > > > > > > > > > > (hibernate-resume-reboot) and I am also attaching kernel
> > > > > > > > > > > config and /var/log/pm-suspend.log.
> > > > > > > > > > >
> > > > > > > > > > > You will probably notice evil nvidia.ko in there but don't
> > > > > > > > > > > panic, it all happens without it as well. Tested from
> > > > > > > > > > > runlevel 3 and by running pm-hibernate. After resume from
> > > > > > > > > > > that NIC LEDs were off. I tried /etc/init.d/network restart
> > > > > > > > > > > but that hung so I ^C and tried rmmod forcedeth && modprobe
> > > > > > > > > > > forcedeth && ifup eth0 and after some time network went
> > > > > > > > > > > live again. Haven't had time to test further though, so
> > > > > > > > > > > this is all pretty rough.
> > > > > > > > > >
> > > > > > > > > > Ok, can you try to rmmod forcedeth before hibernation, then
> > > > > > > > > > insmod it after resume?
> > > > > > > > >
> > > > > > > > > Sure, after insmod and /etc/init.d/network start following
> > > > > > > > > resume network was fine. Guess I could kludge that sequence
> > > > > > > > > into pm scripts somehow but would rather avoid that since it
> > > > > > > > > slows down the cycle and would make scripts non-stock.
> > > > > > > >
> > > > > > > > Ok, I guess you need to talk to forcedeth maintainers then...
> > > > > > > > sounds like a forcedeth problem to me.
> > > > > > >
> > > > > > > I have a box with forcedeth somewhere here, I should be able to
> > > > > > > check that in the next few days.
> > > > > >
> > > > > > Not a lot activity in forcedeth.c from 2.6.28 to 2.6.29 so I will CC
> > > > > > two guys who commited changes in that period. Ayaz, Tobias, forcedeth
> > > > > > does not seem to come up after hibernation well for me. Actual
> > > > > > hardware is:
> > > > > >
> > > > > > 00:0f.0 Ethernet controller: nVidia Corporation MCP73 Ethernet (rev
> > > > > > a2)
> > > > > >
> > > > > > Anything more I can do just shout!
> > > > >
> > > > > Actually yes. Testing forcedeth from 2.6.28 in 2.6.29 would be nice
> > > > > way to prove problem is indeed in that module.
> > > >
> > > > Good idea, I had to massage it a bit due to some API changes, but the end
> > > > result is a correct resume which proves that the problem really is in
> > > > forcedeth.
> > >
> > > Well, since you can easily check what commits changed forcedeth between
> > > 2.6.28 and 2.6.29, you can find the one that introduced the problem for
> > > you.
I was able to reproduce the problem and identify the commit that broke the
resume of forcedeth, which turned out to be:
commit cb52deba12f27af90a46d2f8667a64888118a888
Author: Ed Swierk <[email protected]>
Date: Mon Dec 1 12:24:43 2008 +0000
forcedeth: power down phy when interface is down
Signed-off-by: Ed Swierk <[email protected]>
Tested-by: Arthur Jones <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Since I have no slightest idea of what this commit is supposed to achieve,
I can only ask for reverting it. It reverts cleanly, BTW.
Thanks,
Rafael
On Friday 27 March 2009 20:09:20 Rafael J. Wysocki wrote:
> I was able to reproduce the problem and identify the commit that broke the
> resume of forcedeth, which turned out to be:
>
> commit cb52deba12f27af90a46d2f8667a64888118a888
> Author: Ed Swierk <[email protected]>
> Date: Mon Dec 1 12:24:43 2008 +0000
>
> forcedeth: power down phy when interface is down
>
> Signed-off-by: Ed Swierk <[email protected]>
> Tested-by: Arthur Jones <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> Signed-off-by: David S. Miller <[email protected]>
>
> Since I have no slightest idea of what this commit is supposed to achieve,
> I can only ask for reverting it. It reverts cleanly, BTW.
Reverting this fixes it for me as well.
Thanks for your effort!
Tvrtko
On Sunday 29 March 2009 09:03:57 Tvrtko A. Ursulin wrote:
> On Friday 27 March 2009 20:09:20 Rafael J. Wysocki wrote:
> > I was able to reproduce the problem and identify the commit that broke
> > the resume of forcedeth, which turned out to be:
> >
> > commit cb52deba12f27af90a46d2f8667a64888118a888
> > Author: Ed Swierk <[email protected]>
> > Date: Mon Dec 1 12:24:43 2008 +0000
> >
> > forcedeth: power down phy when interface is down
> >
> > Signed-off-by: Ed Swierk <[email protected]>
> > Tested-by: Arthur Jones <[email protected]>
> > Signed-off-by: Andrew Morton <[email protected]>
> > Signed-off-by: David S. Miller <[email protected]>
> >
> > Since I have no slightest idea of what this commit is supposed to
> > achieve, I can only ask for reverting it. It reverts cleanly, BTW.
>
> Reverting this fixes it for me as well.
>
> Thanks for your effort!
Would reverting this be a -stable material?
Tvrtko
On Fri, Mar 27, 2009 at 1:09 PM, Rafael J. Wysocki <[email protected]> wrote:
> I was able to reproduce the problem and identify the commit that broke the
> resume of forcedeth, which turned out to be:
>
> commit cb52deba12f27af90a46d2f8667a64888118a888
> Author: Ed Swierk <[email protected]>
> Date: ? Mon Dec 1 12:24:43 2008 +0000
>
> ? ?forcedeth: power down phy when interface is down
>
> ? ?Signed-off-by: Ed Swierk <[email protected]>
> ? ?Tested-by: Arthur Jones <[email protected]>
> ? ?Signed-off-by: Andrew Morton <[email protected]>
> ? ?Signed-off-by: David S. Miller <[email protected]>
>
> Since I have no slightest idea of what this commit is supposed to achieve,
> I can only ask for reverting it. ?It reverts cleanly, BTW.
The change causes forcedeth to bring down the physical link when an
interface goes down; leaving it up causes the switch at the other end
to think the port is still active, with potentially random speed and
duplex parameters.
It's possible that the forcedeth driver needs to reset autonegotiation
after bringing it up the link again.
Can you please try this on a 2.6.29 kernel that's exhibiting the
symptoms you describe, after resuming the machine from hibernation:
ethtool -s eth1 autoneg off speed 100 duplex full
ethtool -s eth1 autoneg on
This should reset autonegotiation manually and bring the link. Let me
know how it goes.
Thanks,
--Ed
On Fri, 2009-04-03 at 08:24 -0700, Ed Swierk wrote:
> On Fri, Mar 27, 2009 at 1:09 PM, Rafael J. Wysocki <[email protected]> wrote:
> > I was able to reproduce the problem and identify the commit that broke the
> > resume of forcedeth, which turned out to be:
> >
> > commit cb52deba12f27af90a46d2f8667a64888118a888
> > Author: Ed Swierk <[email protected]>
> > Date: Mon Dec 1 12:24:43 2008 +0000
> >
> > forcedeth: power down phy when interface is down
> >
> > Signed-off-by: Ed Swierk <[email protected]>
> > Tested-by: Arthur Jones <[email protected]>
> > Signed-off-by: Andrew Morton <[email protected]>
> > Signed-off-by: David S. Miller <[email protected]>
> >
> > Since I have no slightest idea of what this commit is supposed to achieve,
> > I can only ask for reverting it. It reverts cleanly, BTW.
>
> The change causes forcedeth to bring down the physical link when an
> interface goes down; leaving it up causes the switch at the other end
> to think the port is still active, with potentially random speed and
> duplex parameters.
>
> It's possible that the forcedeth driver needs to reset autonegotiation
> after bringing it up the link again.
>
> Can you please try this on a 2.6.29 kernel that's exhibiting the
> symptoms you describe, after resuming the machine from hibernation:
>
> ethtool -s eth1 autoneg off speed 100 duplex full
> ethtool -s eth1 autoneg on
>
> This should reset autonegotiation manually and bring the link. Let me
> know how it goes.
Also please try this patch; it fixes the problem on my test system (a
DFI board with an nVidia MCP55).
Signed-off-by: Ed Swierk <[email protected]>
--
--- linux-2.6.29.x86_64/drivers/net/forcedeth.c.orig 2009-03-23 16:12:14.000000000 -0700
+++ linux-2.6.29.x86_64/drivers/net/forcedeth.c 2009-04-03 10:11:26.839614710 -0700
@@ -5995,6 +5995,9 @@
for (i = 0;i <= np->register_size/sizeof(u32); i++)
writel(np->saved_config_space[i], base+i*sizeof(u32));
+ /* restore phy state, including autoneg */
+ phy_init(dev);
+
netif_device_attach(dev);
if (netif_running(dev)) {
rc = nv_open(dev);
On Friday 03 April 2009, Ed Swierk wrote:
> On Fri, 2009-04-03 at 08:24 -0700, Ed Swierk wrote:
> > On Fri, Mar 27, 2009 at 1:09 PM, Rafael J. Wysocki <[email protected]> wrote:
> > > I was able to reproduce the problem and identify the commit that broke the
> > > resume of forcedeth, which turned out to be:
> > >
> > > commit cb52deba12f27af90a46d2f8667a64888118a888
> > > Author: Ed Swierk <[email protected]>
> > > Date: Mon Dec 1 12:24:43 2008 +0000
> > >
> > > forcedeth: power down phy when interface is down
> > >
> > > Signed-off-by: Ed Swierk <[email protected]>
> > > Tested-by: Arthur Jones <[email protected]>
> > > Signed-off-by: Andrew Morton <[email protected]>
> > > Signed-off-by: David S. Miller <[email protected]>
> > >
> > > Since I have no slightest idea of what this commit is supposed to achieve,
> > > I can only ask for reverting it. It reverts cleanly, BTW.
> >
> > The change causes forcedeth to bring down the physical link when an
> > interface goes down; leaving it up causes the switch at the other end
> > to think the port is still active, with potentially random speed and
> > duplex parameters.
> >
> > It's possible that the forcedeth driver needs to reset autonegotiation
> > after bringing it up the link again.
> >
> > Can you please try this on a 2.6.29 kernel that's exhibiting the
> > symptoms you describe, after resuming the machine from hibernation:
> >
> > ethtool -s eth1 autoneg off speed 100 duplex full
> > ethtool -s eth1 autoneg on
> >
> > This should reset autonegotiation manually and bring the link. Let me
> > know how it goes.
>
> Also please try this patch; it fixes the problem on my test system (a
> DFI board with an nVidia MCP55).
>
> Signed-off-by: Ed Swierk <[email protected]>
> --
> --- linux-2.6.29.x86_64/drivers/net/forcedeth.c.orig 2009-03-23 16:12:14.000000000 -0700
> +++ linux-2.6.29.x86_64/drivers/net/forcedeth.c 2009-04-03 10:11:26.839614710 -0700
> @@ -5995,6 +5995,9 @@
> for (i = 0;i <= np->register_size/sizeof(u32); i++)
> writel(np->saved_config_space[i], base+i*sizeof(u32));
>
> + /* restore phy state, including autoneg */
> + phy_init(dev);
> +
> netif_device_attach(dev);
> if (netif_running(dev)) {
> rc = nv_open(dev);
Tvrtko, can you test it, please? I'll be away from my NVidia box during the
next couple of days.
Thanks,
Rafael
On Friday 03 April 2009 18:41:12 Ed Swierk wrote:
> On Fri, 2009-04-03 at 08:24 -0700, Ed Swierk wrote:
> > On Fri, Mar 27, 2009 at 1:09 PM, Rafael J. Wysocki <[email protected]> wrote:
> > > I was able to reproduce the problem and identify the commit that broke
> > > the resume of forcedeth, which turned out to be:
> > >
> > > commit cb52deba12f27af90a46d2f8667a64888118a888
> > > Author: Ed Swierk <[email protected]>
> > > Date: Mon Dec 1 12:24:43 2008 +0000
> > >
> > > forcedeth: power down phy when interface is down
> > >
> > > Signed-off-by: Ed Swierk <[email protected]>
> > > Tested-by: Arthur Jones <[email protected]>
> > > Signed-off-by: Andrew Morton <[email protected]>
> > > Signed-off-by: David S. Miller <[email protected]>
> > >
> > > Since I have no slightest idea of what this commit is supposed to
> > > achieve, I can only ask for reverting it. It reverts cleanly, BTW.
> >
> > The change causes forcedeth to bring down the physical link when an
> > interface goes down; leaving it up causes the switch at the other end
> > to think the port is still active, with potentially random speed and
> > duplex parameters.
> >
> > It's possible that the forcedeth driver needs to reset autonegotiation
> > after bringing it up the link again.
> >
> > Can you please try this on a 2.6.29 kernel that's exhibiting the
> > symptoms you describe, after resuming the machine from hibernation:
> >
> > ethtool -s eth1 autoneg off speed 100 duplex full
> > ethtool -s eth1 autoneg on
> >
> > This should reset autonegotiation manually and bring the link. Let me
> > know how it goes.
>
> Also please try this patch; it fixes the problem on my test system (a
> DFI board with an nVidia MCP55).
>
> Signed-off-by: Ed Swierk <[email protected]>
> --
> --- linux-2.6.29.x86_64/drivers/net/forcedeth.c.orig 2009-03-23
> 16:12:14.000000000 -0700 +++
> linux-2.6.29.x86_64/drivers/net/forcedeth.c 2009-04-03 10:11:26.839614710
> -0700 @@ -5995,6 +5995,9 @@
> for (i = 0;i <= np->register_size/sizeof(u32); i++)
> writel(np->saved_config_space[i], base+i*sizeof(u32));
>
> + /* restore phy state, including autoneg */
> + phy_init(dev);
> +
> netif_device_attach(dev);
> if (netif_running(dev)) {
> rc = nv_open(dev);
Works for me on MCP73 as well.
Although NIC LED is still on after hibernation - seems to go off shortly
before power off and then comes back on. Could be firmware issue I guess,
this motherboard has always gulped power when off.
Tvrtko
On Saturday 04 April 2009, Tvrtko A. Ursulin wrote:
> On Friday 03 April 2009 18:41:12 Ed Swierk wrote:
> > On Fri, 2009-04-03 at 08:24 -0700, Ed Swierk wrote:
> > > On Fri, Mar 27, 2009 at 1:09 PM, Rafael J. Wysocki <[email protected]> wrote:
> > > > I was able to reproduce the problem and identify the commit that broke
> > > > the resume of forcedeth, which turned out to be:
> > > >
> > > > commit cb52deba12f27af90a46d2f8667a64888118a888
> > > > Author: Ed Swierk <[email protected]>
> > > > Date: Mon Dec 1 12:24:43 2008 +0000
> > > >
> > > > forcedeth: power down phy when interface is down
> > > >
> > > > Signed-off-by: Ed Swierk <[email protected]>
> > > > Tested-by: Arthur Jones <[email protected]>
> > > > Signed-off-by: Andrew Morton <[email protected]>
> > > > Signed-off-by: David S. Miller <[email protected]>
> > > >
> > > > Since I have no slightest idea of what this commit is supposed to
> > > > achieve, I can only ask for reverting it. It reverts cleanly, BTW.
> > >
> > > The change causes forcedeth to bring down the physical link when an
> > > interface goes down; leaving it up causes the switch at the other end
> > > to think the port is still active, with potentially random speed and
> > > duplex parameters.
> > >
> > > It's possible that the forcedeth driver needs to reset autonegotiation
> > > after bringing it up the link again.
> > >
> > > Can you please try this on a 2.6.29 kernel that's exhibiting the
> > > symptoms you describe, after resuming the machine from hibernation:
> > >
> > > ethtool -s eth1 autoneg off speed 100 duplex full
> > > ethtool -s eth1 autoneg on
> > >
> > > This should reset autonegotiation manually and bring the link. Let me
> > > know how it goes.
> >
> > Also please try this patch; it fixes the problem on my test system (a
> > DFI board with an nVidia MCP55).
> >
> > Signed-off-by: Ed Swierk <[email protected]>
> > --
> > --- linux-2.6.29.x86_64/drivers/net/forcedeth.c.orig 2009-03-23
> > 16:12:14.000000000 -0700 +++
> > linux-2.6.29.x86_64/drivers/net/forcedeth.c 2009-04-03 10:11:26.839614710
> > -0700 @@ -5995,6 +5995,9 @@
> > for (i = 0;i <= np->register_size/sizeof(u32); i++)
> > writel(np->saved_config_space[i], base+i*sizeof(u32));
> >
> > + /* restore phy state, including autoneg */
> > + phy_init(dev);
> > +
> > netif_device_attach(dev);
> > if (netif_running(dev)) {
> > rc = nv_open(dev);
>
> Works for me on MCP73 as well.
Great, thanks for testing.
I think the patch should go to Linus ASAP and to -stable as a regression fix.
Thanks,
Rafael