Ooops with suspend to RAM

Ooops with suspend to RAM

[Ismail Dönmez]

Hi all,

With latest GIT tree I am getting the following oops when I try to suspend to 
RAM:

BUG: unable to handle kernel NULL pointer dereference at virtual address 
00000094
 printing eip:
c0222af4
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss snd_seq_dummy 
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device usbhid eth1394 ipw2200 
ieee80211 ieee80211_crypt snd_hda_intel snd_hda_codec snd_pcm snd_timer snd 
snd_page_alloc tifm_7xx1 tifm_core i2c_i801 i2c_core ehci_hcd uhci_hcd 
ohci1394 ieee1394 pcmcia usbcore yenta_socket rsrc_nonstatic pcmcia_core 
sony_laptop backlight
CPU:    0
EIP:    0060:[<c0222af4>]    Not tainted VLI
EFLAGS: 00010246   (2.6.21-rc3 #12)
EIP is at class_device_remove_attrs+0xa/0x30
eax: f7cb5b18   ebx: 00000000   ecx: f8bde010   edx: 00000000
esi: 00000000   edi: f7cb5b18   ebp: 00000000   esp: d93e7e1c
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process modprobe (pid: 12200, ti=d93e6000 task=e5770a50 task.ti=d93e6000)
Stack: f7cb5b18 f7cb5b20 00000000 c0222bc3 f7cb5990 00000000 f7cb5b18 f7cb59c4
       f8bcdc0f 00000000 c0222bfb f7cb5990 f8bcdbf6 f8bd3275 04e2c100 0000000f
       000003c3 f8dcf05f 00000000 f7e3e000 00000000 f8bcdc17 c0220567 f7e3e0a4
Call Trace:
 [<c0222bc3>] class_device_del+0xa9/0xd9
 [<f8bcdc0f>] __nodemgr_remove_host_dev+0x0/0xb [ieee1394]
 [<c0222bfb>] class_device_unregister+0x8/0x10
 [<f8bcdbf6>] nodemgr_remove_ne+0x61/0x7a [ieee1394]
 [<f8dcf05f>] ether1394_mac_addr+0x0/0x12 [eth1394]
 [<f8bcdc17>] __nodemgr_remove_host_dev+0x8/0xb [ieee1394]
 [<c0220567>] device_for_each_child+0x1a/0x3c
 [<f8bcdf34>] nodemgr_remove_host+0x30/0x90 [ieee1394]
 [<f8bcb4b1>] __unregister_host+0x1a/0xac [ieee1394]
 [<c0125e1c>] flush_cpu_workqueue+0x98/0xb7
 [<f8bcb6da>] highlevel_remove_host+0x21/0x42 [ieee1394]
 [<f8bcb247>] hpsb_remove_host+0x37/0x58 [ieee1394]
 [<f8be1229>] ohci1394_pci_remove+0x47/0x1ec [ohci1394]
 [<c01877b9>] sysfs_hash_and_remove+0xfa/0x111
 [<c01ccc9c>] pci_device_remove+0x16/0x35
 [<c0222321>] __device_release_driver+0x6e/0x8b
 [<c022279b>] driver_detach+0x99/0xda
 [<c0221fa2>] bus_remove_driver+0x57/0x75
 [<c02227fd>] driver_unregister+0x8/0x13
 [<c01ccdfd>] pci_unregister_driver+0xc/0x67
 [<c0134133>] sys_delete_module+0x15c/0x19d
 [<c0149fc0>] remove_vma+0x31/0x36
 [<c014a946>] do_munmap+0x19b/0x1b4
 [<c0104cca>] sysenter_past_esp+0x5f/0x85
 [<c0300000>] packet_notifier+0xf3/0x157
 =======================
Code: ff c3 85 c0 74 08 83 c0 08 e9 83 6d f6 ff b8 ea ff ff ff c3 85 c0 74 08 
83 c0 08 e9 4c 51 f6 ff c3 57 89 c7 56 53 8b 70 44 31 db <83> be 94 00 00 00 
00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83
EIP: [<c0222af4>] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:d93e7e1c


Checking Google I see a similar oops was reported long ago: 
http://lkml.org/lkml/2006/11/16/147 .

Any ideas/patches to test? Please CC me in your replies.

Thanks.

-- 
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)

Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer

oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)

[Stefan Richter]

(Cc'ing Greg KH and linux1394-devel)

Ismail Dönmez wrote at lkml:
> With latest GIT tree I am getting the following oops when I try to suspend to 
> RAM:
> 
> BUG: unable to handle kernel NULL pointer dereference at virtual address 
> 00000094
>  printing eip:
> c0222af4
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT
> Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss snd_seq_dummy 
> snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device usbhid eth1394 ipw2200 
> ieee80211 ieee80211_crypt snd_hda_intel snd_hda_codec snd_pcm snd_timer snd 
> snd_page_alloc tifm_7xx1 tifm_core i2c_i801 i2c_core ehci_hcd uhci_hcd 
> ohci1394 ieee1394 pcmcia usbcore yenta_socket rsrc_nonstatic pcmcia_core 
> sony_laptop backlight
> CPU:    0
> EIP:    0060:[<c0222af4>]    Not tainted VLI
> EFLAGS: 00010246   (2.6.21-rc3 #12)
> EIP is at class_device_remove_attrs+0xa/0x30
> eax: f7cb5b18   ebx: 00000000   ecx: f8bde010   edx: 00000000
> esi: 00000000   edi: f7cb5b18   ebp: 00000000   esp: d93e7e1c
> ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> Process modprobe (pid: 12200, ti=d93e6000 task=e5770a50 task.ti=d93e6000)
> Stack: f7cb5b18 f7cb5b20 00000000 c0222bc3 f7cb5990 00000000 f7cb5b18 f7cb59c4
>        f8bcdc0f 00000000 c0222bfb f7cb5990 f8bcdbf6 f8bd3275 04e2c100 0000000f
>        000003c3 f8dcf05f 00000000 f7e3e000 00000000 f8bcdc17 c0220567 f7e3e0a4
> Call Trace:
>  [<c0222bc3>] class_device_del+0xa9/0xd9
>  [<f8bcdc0f>] __nodemgr_remove_host_dev+0x0/0xb [ieee1394]
>  [<c0222bfb>] class_device_unregister+0x8/0x10
>  [<f8bcdbf6>] nodemgr_remove_ne+0x61/0x7a [ieee1394]
>  [<f8dcf05f>] ether1394_mac_addr+0x0/0x12 [eth1394]
>  [<f8bcdc17>] __nodemgr_remove_host_dev+0x8/0xb [ieee1394]
>  [<c0220567>] device_for_each_child+0x1a/0x3c
>  [<f8bcdf34>] nodemgr_remove_host+0x30/0x90 [ieee1394]
>  [<f8bcb4b1>] __unregister_host+0x1a/0xac [ieee1394]
>  [<c0125e1c>] flush_cpu_workqueue+0x98/0xb7
>  [<f8bcb6da>] highlevel_remove_host+0x21/0x42 [ieee1394]
>  [<f8bcb247>] hpsb_remove_host+0x37/0x58 [ieee1394]
>  [<f8be1229>] ohci1394_pci_remove+0x47/0x1ec [ohci1394]
>  [<c01877b9>] sysfs_hash_and_remove+0xfa/0x111
>  [<c01ccc9c>] pci_device_remove+0x16/0x35
>  [<c0222321>] __device_release_driver+0x6e/0x8b
>  [<c022279b>] driver_detach+0x99/0xda
>  [<c0221fa2>] bus_remove_driver+0x57/0x75
>  [<c02227fd>] driver_unregister+0x8/0x13
>  [<c01ccdfd>] pci_unregister_driver+0xc/0x67
>  [<c0134133>] sys_delete_module+0x15c/0x19d
>  [<c0149fc0>] remove_vma+0x31/0x36
>  [<c014a946>] do_munmap+0x19b/0x1b4
>  [<c0104cca>] sysenter_past_esp+0x5f/0x85
>  [<c0300000>] packet_notifier+0xf3/0x157
>  =======================
> Code: ff c3 85 c0 74 08 83 c0 08 e9 83 6d f6 ff b8 ea ff ff ff c3 85 c0 74 08 
> 83 c0 08 e9 4c 51 f6 ff c3 57 89 c7 56 53 8b 70 44 31 db <83> be 94 00 00 00 
> 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83
> EIP: [<c0222af4>] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:d93e7e1c
> 
> 
> Checking Google I see a similar oops was reported long ago: 
> http://lkml.org/lkml/2006/11/16/147 .
> 
> Any ideas/patches to test? Please CC me in your replies.

Thanks for the report.  Do you have a script or config which marks the
ohci1394 module to be unloaded before suspend?  This should not be
necessary since 2.6.21-rc1 anymore.  (Although I tested this only with
APM suspend to RAM and only with the sbp2 driver as IEEE 1394
application-layer software, and only with current 1394 drivers on top of
2.6.20-rcX instead of 2.6.21-rcX.  I heard that raw1394 survives
suspend/resume thanks to the ohci1394 updates already in 2.6.20.)

But back to your problem.  The older report which you pointed to was a
hickup caused by the ongoing conversion away from class_device.  Further
down that discussion, a 2.6.19-rcX-mmY patch was discovered to trigger
this:  http://lkml.org/lkml/2006/11/19/53
|  the winner is... gregkh-driver-network-device.patch
By "trigger" I mean that I don't know where the bug was, i.e. in the
then partial driver core conversion or in the ieee1394 nodemgr.

*However*, this time it's different --- you don't have eth1394 present.

I will boot 2.6.21-rc3 on a spare machine and see how it goes.

As a side note, the IEEE 1394 subsystem features quite a fat usage of
the driver core.  We have (in order of parent devices to child devices)
the host adapter's PCI device's device, the 1394 host device
(hpsb_host), the node entry devices, the unit directory devices.  And
all of them have respective class devices.  But really important outside
of the ieee1394 core are only the first and the last, i.e. PCI device
and unit directories.  Maybe we should redesign nodemgr to work without
host devices and node entry devices.

Side note to the side note:  The new alternative IEEE 1394 drivers which
are currently maturing in -mm (the 1394 stack nicknamed Juju), does
indeed create only unit directory devices if I'm not badly mistaken.
-- 
Stefan Richter
-=====-=-=== --== -===-
http://arcgraph.de/sr/

Re: oops in __nodemgr_remove_host_dev

[Stefan Richter]

I wrote:
> As a side note, the IEEE 1394 subsystem features quite a fat usage of
> the driver core. [...] Maybe we should redesign nodemgr to work without
> host devices and node entry devices.

Greg, you once indicated you had class device conversion patches for
1394 in the pipeline, but they couldn't go out to -mm or wherever
because of them depending on unfinished driver core changes.  If you
found that the 1394 subsystem needed some special treatment, there might
be a chance to eliminate this by pulling some historically grown but now
obsolete infrastructure out.  (Of course not for 2.6.21-rc anymore, but
perhaps post 2.6.21 if we take it on quickly.)
-- 
Stefan Richter
-=====-=-=== --== -===-
http://arcgraph.de/sr/

Re: Ooops with suspend to RAM

[Adrian Bunk]

On Wed, Mar 14, 2007 at 06:42:28AM +0200, Ismail Dönmez wrote:
> Hi all,
> 
> With latest GIT tree I am getting the following oops when I try to suspend to 
> RAM:
>...

Is this an old problem, or what was the last kernel that worked for you?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)

[Ismail Dönmez]

On Wednesday 14 March 2007 13:14:42 Stefan Richter wrote:
> (Cc'ing Greg KH and linux1394-devel)
>
> Ismail Dönmez wrote at lkml:
> > With latest GIT tree I am getting the following oops when I try to
> > suspend to RAM:
> >
> > BUG: unable to handle kernel NULL pointer dereference at virtual address
> > 00000094
> >  printing eip:
> > c0222af4
> > *pde = 00000000
> > Oops: 0000 [#1]
> > PREEMPT
> > Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss snd_seq_dummy
> > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device usbhid eth1394
> > ipw2200 ieee80211 ieee80211_crypt snd_hda_intel snd_hda_codec snd_pcm
> > snd_timer snd snd_page_alloc tifm_7xx1 tifm_core i2c_i801 i2c_core
> > ehci_hcd uhci_hcd ohci1394 ieee1394 pcmcia usbcore yenta_socket
> > rsrc_nonstatic pcmcia_core sony_laptop backlight
> > CPU:    0
> > EIP:    0060:[<c0222af4>]    Not tainted VLI
> > EFLAGS: 00010246   (2.6.21-rc3 #12)
> > EIP is at class_device_remove_attrs+0xa/0x30
> > eax: f7cb5b18   ebx: 00000000   ecx: f8bde010   edx: 00000000
> > esi: 00000000   edi: f7cb5b18   ebp: 00000000   esp: d93e7e1c
> > ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> > Process modprobe (pid: 12200, ti=d93e6000 task=e5770a50 task.ti=d93e6000)
> > Stack: f7cb5b18 f7cb5b20 00000000 c0222bc3 f7cb5990 00000000 f7cb5b18
> > f7cb59c4 f8bcdc0f 00000000 c0222bfb f7cb5990 f8bcdbf6 f8bd3275 04e2c100
> > 0000000f 000003c3 f8dcf05f 00000000 f7e3e000 00000000 f8bcdc17 c0220567
> > f7e3e0a4 Call Trace:
> >  [<c0222bc3>] class_device_del+0xa9/0xd9
> >  [<f8bcdc0f>] __nodemgr_remove_host_dev+0x0/0xb [ieee1394]
> >  [<c0222bfb>] class_device_unregister+0x8/0x10
> >  [<f8bcdbf6>] nodemgr_remove_ne+0x61/0x7a [ieee1394]
> >  [<f8dcf05f>] ether1394_mac_addr+0x0/0x12 [eth1394]
> >  [<f8bcdc17>] __nodemgr_remove_host_dev+0x8/0xb [ieee1394]
> >  [<c0220567>] device_for_each_child+0x1a/0x3c
> >  [<f8bcdf34>] nodemgr_remove_host+0x30/0x90 [ieee1394]
> >  [<f8bcb4b1>] __unregister_host+0x1a/0xac [ieee1394]
> >  [<c0125e1c>] flush_cpu_workqueue+0x98/0xb7
> >  [<f8bcb6da>] highlevel_remove_host+0x21/0x42 [ieee1394]
> >  [<f8bcb247>] hpsb_remove_host+0x37/0x58 [ieee1394]
> >  [<f8be1229>] ohci1394_pci_remove+0x47/0x1ec [ohci1394]
> >  [<c01877b9>] sysfs_hash_and_remove+0xfa/0x111
> >  [<c01ccc9c>] pci_device_remove+0x16/0x35
> >  [<c0222321>] __device_release_driver+0x6e/0x8b
> >  [<c022279b>] driver_detach+0x99/0xda
> >  [<c0221fa2>] bus_remove_driver+0x57/0x75
> >  [<c02227fd>] driver_unregister+0x8/0x13
> >  [<c01ccdfd>] pci_unregister_driver+0xc/0x67
> >  [<c0134133>] sys_delete_module+0x15c/0x19d
> >  [<c0149fc0>] remove_vma+0x31/0x36
> >  [<c014a946>] do_munmap+0x19b/0x1b4
> >  [<c0104cca>] sysenter_past_esp+0x5f/0x85
> >  [<c0300000>] packet_notifier+0xf3/0x157
> >  =======================
> > Code: ff c3 85 c0 74 08 83 c0 08 e9 83 6d f6 ff b8 ea ff ff ff c3 85 c0
> > 74 08 83 c0 08 e9 4c 51 f6 ff c3 57 89 c7 56 53 8b 70 44 31 db <83> be 94
> > 00 00 00 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83
> > EIP: [<c0222af4>] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:d93e7e1c
> >
> >
> > Checking Google I see a similar oops was reported long ago:
> > http://lkml.org/lkml/2006/11/16/147 .
> >
> > Any ideas/patches to test? Please CC me in your replies.
>
> Thanks for the report.  Do you have a script or config which marks the
> ohci1394 module to be unloaded before suspend?  


I used kpowersave to suspend, I failed to find anything related to ohci1394 in 
its config but rmmod ohci1394 gives exact oops so it must be rmmoding it. 
Also doing echo mem > /sys/power/state from konsole tries to suspend but 
freezes at Suspending console(s) but gives no oops.

> This should not be 
> necessary since 2.6.21-rc1 anymore.  (Although I tested this only with
> APM suspend to RAM and only with the sbp2 driver as IEEE 1394
> application-layer software, and only with current 1394 drivers on top of
> 2.6.20-rcX instead of 2.6.21-rcX.  I heard that raw1394 survives
> suspend/resume thanks to the ohci1394 updates already in 2.6.20.)

Are you able to rmmod it?

> But back to your problem.  The older report which you pointed to was a
> hickup caused by the ongoing conversion away from class_device.  Further
> down that discussion, a 2.6.19-rcX-mmY patch was discovered to trigger
> this:  http://lkml.org/lkml/2006/11/19/53
>
> |  the winner is... gregkh-driver-network-device.patch
>
> By "trigger" I mean that I don't know where the bug was, i.e. in the
> then partial driver core conversion or in the ieee1394 nodemgr.
>
> *However*, this time it's different --- you don't have eth1394 present.

Right, no firewire devices are attached.

> I will boot 2.6.21-rc3 on a spare machine and see how it goes.

Thanks.

> As a side note, the IEEE 1394 subsystem features quite a fat usage of
> the driver core.  We have (in order of parent devices to child devices)
> the host adapter's PCI device's device, the 1394 host device
> (hpsb_host), the node entry devices, the unit directory devices.  And
> all of them have respective class devices.  But really important outside
> of the ieee1394 core are only the first and the last, i.e. PCI device
> and unit directories.  Maybe we should redesign nodemgr to work without
> host devices and node entry devices.
>
> Side note to the side note:  The new alternative IEEE 1394 drivers which
> are currently maturing in -mm (the 1394 stack nicknamed Juju), does
> indeed create only unit directory devices if I'm not badly mistaken.

I'll give -mm a try sometime this weekend then.

Regards.

-- 
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)

Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer

Re: Ooops with suspend to RAM

[Ismail Dönmez]

On Wednesday 14 March 2007 13:50:47 Adrian Bunk wrote:
> On Wed, Mar 14, 2007 at 06:42:28AM +0200, Ismail Dönmez wrote:
> > Hi all,
> >
> > With latest GIT tree I am getting the following oops when I try to
> > suspend to RAM:
> >...
>
> Is this an old problem, or what was the last kernel that worked for you?

I changed my .config totally so I'll have to check with older kernels and get 
back to you. I hope to try latest -mm and 2.6.20 this weekend.

Thanks.

-- 
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)

Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer

Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)

[Stefan Richter]

Ismail Dönmez wrote:
> On Wednesday 14 March 2007 13:14:42 Stefan Richter wrote:
>> Do you have a script or config which marks the
>> ohci1394 module to be unloaded before suspend?  
> 
> I used kpowersave to suspend, I failed to find anything related to ohci1394 in 
> its config but rmmod ohci1394 gives exact oops so it must be rmmoding it. 
[...]
> Are you able to rmmod it?

Yes, but on 2.6.20 and earlier kernels, most of the time with
development versions of the 1394 drivers. I still haven't tried
2.6.21-rc, will hopefully get to it tonight.

[...]
> I'll give -mm a try sometime this weekend then.

It will most certainly behave the same, unless you use the new
alternative FireWire drivers which are a whole different game. I hate to
say it but they don't have suspend + resume support yet. Like the
vanilla Linux drivers before 2.6.20/21, they have to be unloaded before
suspend or at least reloaded after resume.
-- 
Stefan Richter
-=====-=-=== --== -===-
http://arcgraph.de/sr/

Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)

[Ismail Dönmez]

On Wednesday 14 March 2007 20:25:24 Stefan Richter wrote:
> Ismail Dönmez wrote:
> > On Wednesday 14 March 2007 13:14:42 Stefan Richter wrote:
> >> Do you have a script or config which marks the
> >> ohci1394 module to be unloaded before suspend?
> >
> > I used kpowersave to suspend, I failed to find anything related to
> > ohci1394 in its config but rmmod ohci1394 gives exact oops so it must be
> > rmmoding it.
>
> [...]
>
> > Are you able to rmmod it?
>
> Yes, but on 2.6.20 and earlier kernels, most of the time with
> development versions of the 1394 drivers. I still haven't tried
> 2.6.21-rc, will hopefully get to it tonight.

Ok then that explains a bit, without suspend if I rmmod ohci1394 module I got 
the exact oops.

Regards.

-- 
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)

Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer

Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)

[Stefan Richter]

Ismail Dönmez wrote:
> On Wednesday 14 March 2007 20:25:24 Stefan Richter wrote:
>> Ismail Dönmez wrote:
>> > Are you able to rmmod it?
>>
>> Yes, but on 2.6.20 and earlier kernels, most of the time with
>> development versions of the 1394 drivers. I still haven't tried
>> 2.6.21-rc, will hopefully get to it tonight.
> 
> Ok then that explains a bit, without suspend if I rmmod ohci1394 module I got 
> the exact oops.

Elsewhere, Adrian Bunk wrote:
| Is this an old problem, or what was the last kernel that worked
| for you?

Adrian,

according to a quick test I made right now it is a regression post 2.6.20.
# modprobe ohci1394   # wait a bit, eth1394 is auto-loaded
# modprobe -r eth1394
# modprobe -r ohci1394
works.
# modprobe ohci1394   # wait a bit, eth1394 is auto-loaded
# modprobe -r ohci1394
oopses with the same trace as Ismael posted. And indeed, looking at his
trace once more I now also spot eth1394 among his linked-in modules.

Ismail, if you have the opportunity, the next thing you could test would
be to unload eth1394 explicitly before ohci1394 on 2.6.21-rc3. This
would _not_ oops according to my observation.

Thanks to Ismail's link to the similar report on 2.6.19-rc5-mm2 we
already have a hot candidate to be the trigger (not necessarily to be
the actual bug):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=43cb76d91ee85f579a69d42bc8efc08bac560278
"Network: convert network devices to use struct device instead of
class_device"

Alas I didn't remember that older 2.6.19-rc5-mm2 discussion when I saw
Greg's pull request with this conversion patch (February 7) and didn't
react and test Linus' newest.

Advice would be appreciated...
-- 
Stefan Richter
-=====-=-=== --== -====
http://arcgraph.de/sr/

Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)

[Stefan Richter]

I wrote:
> according to a quick test I made right now it is a regression post 2.6.20.
> # modprobe ohci1394   # wait a bit, eth1394 is auto-loaded
> # modprobe -r eth1394
> # modprobe -r ohci1394
> works.
> # modprobe ohci1394   # wait a bit, eth1394 is auto-loaded
> # modprobe -r ohci1394
> oopses with the same trace as Ismael posted. And indeed, looking at his
> trace once more I now also spot eth1394 among his linked-in modules.

To avoid any misunderstandings: Both the former and the latter sequence
work under 2.6.20 and earlier.
-- 
Stefan Richter
-=====-=-=== --== -====
http://arcgraph.de/sr/

Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)

[Ismail Dönmez]

On Thursday 15 March 2007 02:08:43 Stefan Richter wrote:
[...]
> Ismail, if you have the opportunity, the next thing you could test would
> be to unload eth1394 explicitly before ohci1394 on 2.6.21-rc3. This
> would _not_ oops according to my observation.

rmmod eth1394 and modprobe -r eth1394 both hangs here no oops nothing.

Regards.

-- 
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)

Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer

Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)

[Ismail Dönmez]

On Thursday 15 March 2007 02:08:43 Stefan Richter wrote:
[...]
>
> Ismail, if you have the opportunity, the next thing you could test would
> be to unload eth1394 explicitly before ohci1394 on 2.6.21-rc3. This
> would _not_ oops according to my observation.

On a clean reboot it works as expected ;

southpark cartman # rmmod eth1394
southpark cartman # rmmod ohci1394
southpark cartman #

No oops.

Thanks.

-- 
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)

Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer

Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)

[Stefan Richter]

Ismail Dönmez wrote:
> On Thursday 15 March 2007 02:08:43 Stefan Richter wrote:
> [...]
>> Ismail, if you have the opportunity, the next thing you could test would
>> be to unload eth1394 explicitly before ohci1394 on 2.6.21-rc3. This
>> would _not_ oops according to my observation.
> 
> On a clean reboot it works as expected ;
> 
> southpark cartman # rmmod eth1394
> southpark cartman # rmmod ohci1394
> southpark cartman #
> 
> No oops.

I now tested 2.6.20-rc4 with the following two commits reverted:

43cb76d91ee85f579a69d42bc8efc08bac560278
"Network: convert network devices to use struct device instead of
class_device"

40cf67c5fcc513406558c01b91129280208e57bf
"Driver core: remove class_device_rename"

I can now unload ohci1394 again while eth1394 is loaded. The reverting
patch is available at
http://me.in-berlin.de/~s5r6/linux1394/work-in-progress/revert-network-convert-network-devices-to-use-struct-device-instead-of-class_device.patch
(The server may be briefly down tonight and sometime during tomorrow.)

Next thing to do: Find a minimal fix which keeps Greg's net conversions.
-- 
Stefan Richter
-=====-=-=== --== =----
http://arcgraph.de/sr/

[PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion

[Stefan Richter]

The networking subsystem has been converted from class_device to device
but ieee1394 hasn't.  This results in a 100% reproducible NULL pointer
dereference if the ohci1394 driver module is unloaded while the eth1394
module is still loaded.
http://lkml.org/lkml/2006/11/16/147
http://lkml.org/lkml/2007/3/14/4

This is a regression in 2.6.21-rc1.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---

Works for me.  I still can connect to an OS X box via eth1394 after that
and modprobe -r ohci1394 before modprobe -r eth1394 works again.

Index: linux-2.6.21-rc4/drivers/ieee1394/eth1394.c
===================================================================
--- linux-2.6.21-rc4.orig/drivers/ieee1394/eth1394.c	2007-03-16 19:24:44.000000000 +0100
+++ linux-2.6.21-rc4/drivers/ieee1394/eth1394.c	2007-03-20 22:28:49.000000000 +0100
@@ -586,7 +586,10 @@ static void ether1394_add_host (struct h
         }
 
 	SET_MODULE_OWNER(dev);
+#if 0
+	/* FIXME - Is this the correct parent device anyway? */
 	SET_NETDEV_DEV(dev, &host->device);
+#endif
 
 	priv = netdev_priv(dev);
 


-- 
Stefan Richter
-=====-=-=== --== =-=--
http://arcgraph.de/sr/

Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion

[Ismail Dönmez]

On Tuesday 20 March 2007 23:43:22 Stefan Richter wrote:
> The networking subsystem has been converted from class_device to device
> but ieee1394 hasn't.  This results in a 100% reproducible NULL pointer
> dereference if the ohci1394 driver module is unloaded while the eth1394
> module is still loaded.
> http://lkml.org/lkml/2006/11/16/147
> http://lkml.org/lkml/2007/3/14/4
>
> This is a regression in 2.6.21-rc1.
>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> ---
>
> Works for me.  I still can connect to an OS X box via eth1394 after that
> and modprobe -r ohci1394 before modprobe -r eth1394 works again.
>
> Index: linux-2.6.21-rc4/drivers/ieee1394/eth1394.c
> ===================================================================
> --- linux-2.6.21-rc4.orig/drivers/ieee1394/eth1394.c	2007-03-16
> 19:24:44.000000000 +0100 +++
> linux-2.6.21-rc4/drivers/ieee1394/eth1394.c	2007-03-20 22:28:49.000000000
> +0100 @@ -586,7 +586,10 @@ static void ether1394_add_host (struct h
>          }
>
>  	SET_MODULE_OWNER(dev);
> +#if 0
> +	/* FIXME - Is this the correct parent device anyway? */
>  	SET_NETDEV_DEV(dev, &host->device);
> +#endif
>
>  	priv = netdev_priv(dev);

This also fixes the issue for me, thanks for tracking this down Stefan.

Regards.

-- 
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)

Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer

Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion

[Greg KH]

On Tue, Mar 20, 2007 at 10:43:22PM +0100, Stefan Richter wrote:
> The networking subsystem has been converted from class_device to device
> but ieee1394 hasn't.  This results in a 100% reproducible NULL pointer
> dereference if the ohci1394 driver module is unloaded while the eth1394
> module is still loaded.
> http://lkml.org/lkml/2006/11/16/147
> http://lkml.org/lkml/2007/3/14/4
> 
> This is a regression in 2.6.21-rc1.
> 
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> ---
> 
> Works for me.  I still can connect to an OS X box via eth1394 after that
> and modprobe -r ohci1394 before modprobe -r eth1394 works again.
> 
> Index: linux-2.6.21-rc4/drivers/ieee1394/eth1394.c
> ===================================================================
> --- linux-2.6.21-rc4.orig/drivers/ieee1394/eth1394.c	2007-03-16 19:24:44.000000000 +0100
> +++ linux-2.6.21-rc4/drivers/ieee1394/eth1394.c	2007-03-20 22:28:49.000000000 +0100
> @@ -586,7 +586,10 @@ static void ether1394_add_host (struct h
>          }
>  
>  	SET_MODULE_OWNER(dev);
> +#if 0
> +	/* FIXME - Is this the correct parent device anyway? */
>  	SET_NETDEV_DEV(dev, &host->device);
> +#endif

That's interesting.  What does 'tree /sys/class/net/' look like with
this patch applied?  Does the eth1394 device now live off in
/sys/device/virtual?

If so, I guess this is ok for now as we can wait for the rewrite of the
ieee1394 subsystem to get the linking done correctly :)

thanks,

greg k-h

Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion

[Stefan Richter]

On 20 Mar, Greg KH wrote:
> On Tue, Mar 20, 2007 at 10:43:22PM +0100, Stefan Richter wrote:
>> @@ -586,7 +586,10 @@ static void ether1394_add_host (struct h
>>          }
>>  
>>  	SET_MODULE_OWNER(dev);
>> +#if 0
>> +	/* FIXME - Is this the correct parent device anyway? */
>>  	SET_NETDEV_DEV(dev, &host->device);
>> +#endif
> 
> That's interesting.  What does 'tree /sys/class/net/' look like with
> this patch applied?  Does the eth1394 device now live off in
> /sys/device/virtual?

Yes.

lrwxrwxrwx  1 root root 0 Mär 21 01:02 eth0 -> ../../devices/pci0000:00/0000:00:0b.0/eth0/
lrwxrwxrwx  1 root root 0 Mär 21 01:02 eth1 -> ../../devices/virtual/net/eth1/
lrwxrwxrwx  1 root root 0 Mär 21 01:02 lo -> ../../devices/virtual/net/lo/

(eth1 is IP over 1394 alias eth1394. eth0 is an actual ethernet
interface.)

And eth1/device (ex -> ../../../devices/pci*___*/fw-host*) is now gone.
Would anybody miss it?

> If so, I guess this is ok for now as we can wait for the rewrite of the
> ieee1394 subsystem to get the linking done correctly :)

That's my hope too.
-- 
Stefan Richter
-=====-=-=== --== =-=-=
http://arcgraph.de/sr/

Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion

[Stefan Richter]

Ismail Dönmez wrote:
> On Tuesday 20 March 2007 23:43:22 Stefan Richter wrote:
...
>> +#if 0
>> +	/* FIXME - Is this the correct parent device anyway? */
>>  	SET_NETDEV_DEV(dev, &host->device);
>> +#endif
...
> This also fixes the issue for me,

Thanks for confirming this. I will sent the fix to Linus soon.
-- 
Stefan Richter
-=====-=-=== --== =-=-=
http://arcgraph.de/sr/

Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion

[Stefan Richter]

I wrote on 2007-03-21:
> On 20 Mar, Greg KH wrote:
>> On Tue, Mar 20, 2007 at 10:43:22PM +0100, Stefan Richter wrote:
>>> @@ -586,7 +586,10 @@ static void ether1394_add_host (struct h
>>>          }
>>>  
>>>  	SET_MODULE_OWNER(dev);
>>> +#if 0
>>> +	/* FIXME - Is this the correct parent device anyway? */
>>>  	SET_NETDEV_DEV(dev, &host->device);
>>> +#endif
>> That's interesting.  What does 'tree /sys/class/net/' look like with
>> this patch applied?  Does the eth1394 device now live off in
>> /sys/device/virtual?
> 
> Yes.
> 
> lrwxrwxrwx  1 root root 0 Mär 21 01:02 eth0 -> ../../devices/pci0000:00/0000:00:0b.0/eth0/
> lrwxrwxrwx  1 root root 0 Mär 21 01:02 eth1 -> ../../devices/virtual/net/eth1/
> lrwxrwxrwx  1 root root 0 Mär 21 01:02 lo -> ../../devices/virtual/net/lo/
> 
> (eth1 is IP over 1394 alias eth1394. eth0 is an actual ethernet
> interface.)
> 
> And eth1/device (ex -> ../../../devices/pci*___*/fw-host*) is now gone.
> Would anybody miss it?
> 
>> If so, I guess this is ok for now as we can wait for the rewrite of the
>> ieee1394 subsystem to get the linking done correctly :)
> 
> That's my hope too.

Alas there is some userspace breakage:
https://bugs.gentoo.org/show_bug.cgi?id=177199

| Ethernet over firewire devices (driver: eth1394) have - starting with
kernel
| 2.6.21 - no longer a proper parent-device/subsystem in sysfs.
|
| The code change resulting in this is:
[...]
| This missing parent-device breaks persistence-net, as that adds
DRIVERS=="?*"
| to the generated rules, but the driver-attribute resides in the
parent-device
| that no longer is available now.
|
| This leads to not matching the existing rule, but at every boot
running into
| the code to get a new number for the interface, and thus enlarging the
ruleset
| with one line at every boot.

I didn't notice this problem on my own Gentoo box here.  But then I
rarely reboot and don't automatically load eth1394 anymore since I
applied a post-2.6.21 patch which uncouples ieee1394 from eth1394.  I
still load it manually for frequent testing though.
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion

[Stefan Richter]

> I wrote on 2007-03-21:
>> On 20 Mar, Greg KH wrote:
>>> On Tue, Mar 20, 2007 at 10:43:22PM +0100, Stefan Richter wrote:
>>>>  	SET_MODULE_OWNER(dev);
>>>> +#if 0
>>>> +	/* FIXME - Is this the correct parent device anyway? */
>>>>  	SET_NETDEV_DEV(dev, &host->device);
>>>> +#endif
...
>>> If so, I guess this is ok for now as we can wait for the rewrite of the
>>> ieee1394 subsystem to get the linking done correctly :)
>> That's my hope too.
> 
> Alas there is some userspace breakage:
> https://bugs.gentoo.org/show_bug.cgi?id=177199

Greg, what about the ieee1394 class_device conversion patches you had in
the works?
-- 
Stefan Richter
-=====-=-=== -=-= =-=--
http://arcgraph.de/sr/