Re: no carrier detection after resume from swsusp (8139too)
On Fri, 2006-02-24 at 09:31 -0500, Robert Love wrote: > On Fri, 2006-02-24 at 13:42 +0100, Nikolaus Filus wrote: > > > That's it! No real problem or bug in driver or kernel. > > An ifconfig eth1 after resume is enough to recognise the plug-in of > > netwwork cable. > > > > BTW: I added an ifconfig up into my resume script, but shouldn't it be > > done by Networkmanager? > > NM should up the interface. I don't know why it is not. NM tries to bring the interface up when it recognizes the interface on wakeup, and tries to keep it up every 2 seconds or so if it's down. Are the sleep/wake signals getting sent to NM at the appropriate times, either from g-p-m or from distro-specific scripts? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: no carrier detection after resume from swsusp (8139too)
On Fri, 2006-02-24 at 13:42 +0100, Nikolaus Filus wrote: > That's it! No real problem or bug in driver or kernel. > An ifconfig eth1 after resume is enough to recognise the plug-in of > netwwork cable. > > BTW: I added an ifconfig up into my resume script, but shouldn't it be > done by Networkmanager? NM should up the interface. I don't know why it is not. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: no carrier detection after resume from swsusp (8139too)
Hi, On Wednesday 22 February 2006 16:19, Robert Love wrote: > On Wed, 2006-02-22 at 16:12 +0100, Nikolaus Filus wrote: > > I didn't look enough on this issue before. > > > > After resume, I get "invalid argument" from > > /sys/class/net/eth1/carrier. Reloading the driver *OR* restarting > > networkmanager solves the problem! Is it possible a process like nm > > blocks some ressources, which are re-initialised by reloading the > > driver or restarting nm? Notice, that just stopping nm is not enough. > > > > Thanks in advance, > > e100 or e1000? as subject says: 8139too :) > `carrier' returns EINVAL if the device is not UP. It might be a bug in > NM if the device is not UP after a resume. What does `ifconfig eth1` > show before and after a resume? That's it! No real problem or bug in driver or kernel. An ifconfig eth1 after resume is enough to recognise the plug-in of netwwork cable. BTW: I added an ifconfig up into my resume script, but shouldn't it be done by Networkmanager? Thanks for all the investigation help. Nikolaus ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: no carrier detection after resume from swsusp (8139too)
On Wednesday 22 February 2006 16:19, Robert Love wrote: > e100 or e1000? 8139cp here. Seems to have picked up this behaviour since SL10.1beta2 or so, still in beta4. See https://bugzilla.novell.com/show_bug.cgi?id=151892 > `carrier' returns EINVAL if the device is not UP. It might be a bug in > NM if the device is not UP after a resume. What does `ifconfig eth1` > show before and after a resume? carrier is 1 before and after, eth0 is UP before and after, restarting NM doesn't help, nor does stopping NM, rmmod, modprobe, and starting NM. I didn't think it is NM related, as I could not configure the network by hand after resume. However, I just switched my network config to SUSE traditional ifup+ifplugd (joys of flexibility), and although eth0 does not work on resume, rcnetwork restart fixes it, whereas when NM is in charge, this does not help. So my understanding is NM is not the direct cause but is a contributing factor. Will eth0 Link encap:Ethernet HWaddr 00:02:3F:67:0A:E3 inet addr:169.254.137.164 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::202:3fff:fe67:ae3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2769 errors:0 dropped:3144 overruns:0 frame:0 TX packets:180 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:285833 (279.1 Kb) TX bytes:14752 (14.4 Kb) Interrupt:10 Base address:0x2000 eth1 Link encap:Ethernet HWaddr 00:0C:F1:13:76:CB UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:5 Memory:9000-9fff loLink 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:277 errors:0 dropped:0 overruns:0 frame:0 TX packets:277 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:21838 (21.3 Kb) TX bytes:21838 (21.3 Kb) eth0 Link encap:Ethernet HWaddr 00:02:3F:67:0A:E3 inet addr:10.10.101.143 Bcast:10.10.255.255 Mask:255.255.0.0 inet6 addr: 2001:780:101:a00:202:3fff:fe67:ae3/64 Scope:Global inet6 addr: fe80::202:3fff:fe67:ae3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2210 errors:0 dropped:0 overruns:0 frame:0 TX packets:177 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:251842 (245.9 Kb) TX bytes:14494 (14.1 Kb) Interrupt:10 Base address:0x2000 eth1 Link encap:Ethernet HWaddr 00:0C:F1:13:76:CB UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:5 Memory:9000-9fff loLink 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:149 errors:0 dropped:0 overruns:0 frame:0 TX packets:149 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:12784 (12.4 Kb) TX bytes:12784 (12.4 Kb) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: no carrier detection after resume from swsusp (8139too)
On Wed, 2006-02-22 at 16:12 +0100, Nikolaus Filus wrote: > I didn't look enough on this issue before. > > After resume, I get "invalid argument" from > /sys/class/net/eth1/carrier. Reloading the driver *OR* restarting > networkmanager solves the problem! Is it possible a process like nm blocks > some ressources, which are re-initialised by reloading the driver or > restarting nm? Notice, that just stopping nm is not enough. > > Thanks in advance, e100 or e1000? `carrier' returns EINVAL if the device is not UP. It might be a bug in NM if the device is not UP after a resume. What does `ifconfig eth1` show before and after a resume? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: no carrier detection after resume from swsusp (8139too)
Cc: networkamanger-list, as it seems now to be related to nm On Wednesday 22 February 2006 00:49, Francois Romieu wrote: > (owner of http://bugzilla.kernel.org/show_bug.cgi?id=5681 Cc:ed) > > Nikolaus Filus <[EMAIL PROTECTED]> : > [...] > > > I'm using linux 2.6.14.3 with swsusp2 2.2rc14 (not the most new > > ones). Since I'm using NetworkManager, which switches and manages my > > wired and wireless devices, I have to reload 8139too after resume, > > before plugin events of wired network are recognized. Some other > > users of NM are reporting similar problems. > > May I assume that your 8139too device does not need to be reloaded when > you suspend/resume and NM is not used ? I didn't look enough on this issue before. After resume, I get "invalid argument" from /sys/class/net/eth1/carrier. Reloading the driver *OR* restarting networkmanager solves the problem! Is it possible a process like nm blocks some ressources, which are re-initialised by reloading the driver or restarting nm? Notice, that just stopping nm is not enough. Thanks in advance, Nikolaus ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
