* scsi_transport_iscsi.c + transport_container_unregister() oops
@ 2005-04-27 18:34 Nicholas A. Bellinger
2005-04-27 18:50 ` Mike Christie
0 siblings, 1 reply; 4+ messages in thread
From: Nicholas A. Bellinger @ 2005-04-27 18:34 UTC (permalink / raw)
To: Mike Christie; +Cc: linux-scsi, James Bottomley
While adding support for the iSCSI Transport class
(scsi_transport_iscsi.c) to the iscsi-initiator-core stack, I ran into a
problem with iscsi_release_transport() and
transport_container_unregister().
When iscsi_register_transport() and iscsi_release_transport() are called
WITHOUT calling scsi_add_host() and scsi_remove_host() there are no
problems.
When iscsi_register_transport() and iscsi_release_transport() are called
WITH calling scsi_add_host() and scsi_remove_host() the following OOPs
appears in attribute_container_unregister during the list_empty() loop.
I also noticed that that transport_container_[register,unregister]()
calls in iscsi_[register,release]_transport() where added around
2.6.12-rc1, but are not included in the scsi_transport_iscsi.c within
the 4.0.1.11.
Any ideas?
(gdb) list *(attribute_container_unregister+0x1c)
0x7c is in attribute_container_unregister (list.h:251).
246 /**
247 * list_empty - tests whether a list is empty
248 * @head: the list to test.
249 */
250 static inline int list_empty(const struct list_head *head)
251 {
252 return head->next == head;
253 }
254
255 /**
(gdb)
Unable to handle kernel paging request at virtual address 63722d5e
printing eip:
c029ed5c
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: iscsi_initiator_mod scsi_transport_iscsi microcode
usbcore
CPU: 1
EIP: 0060:[<c029ed5c>] Not tainted VLI
EFLAGS: 00010246 (2.6.12-rc3)
EIP is at attribute_container_unregister+0x1c/0x50
eax: 63722d5e ebx: fffffff0 ecx: 63722d56 edx: 00000282
esi: 00000000 edi: bfaf3650 ebp: f6ed5f24 esp: f6ed5f20
ds: 007b es: 007b ss: 0068
Process rmmod (pid: 4501, threadinfo=f6ed5000 task=f7873530)
Stack: 63722d32 f6ed5f34 f886e043 63722d56 f8cf2680 f6ed5f4c f8cd0248
63722d32
00000008 f8cf2680 00000880 f6ed5f54 f8cde7d8 f6ed5fb4 c01381f7
f8cf2680
00000880 f6ed5f68 00000000 73637369 6e695f69 61697469 5f726f74
00646f6d
Call Trace:
[<c0103c9f>] show_stack+0x7f/0xa0
[<c0103e4e>] show_registers+0x15e/0x1d0
[<c0104062>] die+0xf2/0x180
[<c0113252>] do_page_fault+0x382/0x6e0
[<c01038a3>] error_code+0x4f/0x54
[<f886e043>] iscsi_release_transport+0x23/0x60 [scsi_transport_iscsi]
[<f8cd0248>] iscsi_linux_fini+0x18/0x80 [iscsi_initiator_mod]
[<f8cde7d8>] exit_iscsi_module+0x8/0xa [iscsi_initiator_mod]
[<c01381f7>] sys_delete_module+0x157/0x190
[<c0102d33>] sysenter_past_esp+0x54/0x75
--
Nicholas A. Bellinger <nick@pyxtechnologies.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: scsi_transport_iscsi.c + transport_container_unregister() oops
2005-04-27 18:50 ` Mike Christie
@ 2005-04-27 18:49 ` Nicholas A. Bellinger
2005-04-27 19:03 ` Mike Christie
0 siblings, 1 reply; 4+ messages in thread
From: Nicholas A. Bellinger @ 2005-04-27 18:49 UTC (permalink / raw)
To: Mike Christie; +Cc: linux-scsi, James Bottomley
On Wed, 2005-04-27 at 11:50 -0700, Mike Christie wrote:
> Nicholas A. Bellinger wrote:
> > While adding support for the iSCSI Transport class
> > (scsi_transport_iscsi.c) to the iscsi-initiator-core stack, I ran into a
> > problem with iscsi_release_transport() and
> > transport_container_unregister().
> >
> > When iscsi_register_transport() and iscsi_release_transport() are called
> > WITHOUT calling scsi_add_host() and scsi_remove_host() there are no
> > problems.
> >
> > When iscsi_register_transport() and iscsi_release_transport() are called
> > WITH calling scsi_add_host() and scsi_remove_host() the following OOPs
> > appears in attribute_container_unregister during the list_empty() loop.
> >
> > I also noticed that that transport_container_[register,unregister]()
> > calls in iscsi_[register,release]_transport() where added around
> > 2.6.12-rc1, but are not included in the scsi_transport_iscsi.c within
> > the 4.0.1.11.
>
> The scsi_transport_iscsi.c in 4.0.1.11 is old. That version of the driver
> was for before James's transport container code so you cannot use the
> scsi_transport_iscsi.c in there with the current driver model transport
> code.
>
> Also you do not need to worry about sfnet compatibilty. If your changes
> are good/merged we will adapt to them. So do not worry about breaking
> us in the mean time.
>
Just to double check as I have not had a chance to test this myself,
does iscsi_release_transport() work correctly once a scsi host has been
registered with sfnet and 2.6.12-rc3's scsi_transport_iscsi.c?
I am trying to make sure it is not something obvious I am missing on my
side.
Thanks,
--
Nicholas A. Bellinger <nick@pyxtechnologies.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: scsi_transport_iscsi.c + transport_container_unregister() oops
2005-04-27 18:34 scsi_transport_iscsi.c + transport_container_unregister() oops Nicholas A. Bellinger
@ 2005-04-27 18:50 ` Mike Christie
2005-04-27 18:49 ` Nicholas A. Bellinger
0 siblings, 1 reply; 4+ messages in thread
From: Mike Christie @ 2005-04-27 18:50 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: linux-scsi, James Bottomley
Nicholas A. Bellinger wrote:
> While adding support for the iSCSI Transport class
> (scsi_transport_iscsi.c) to the iscsi-initiator-core stack, I ran into a
> problem with iscsi_release_transport() and
> transport_container_unregister().
>
> When iscsi_register_transport() and iscsi_release_transport() are called
> WITHOUT calling scsi_add_host() and scsi_remove_host() there are no
> problems.
>
> When iscsi_register_transport() and iscsi_release_transport() are called
> WITH calling scsi_add_host() and scsi_remove_host() the following OOPs
> appears in attribute_container_unregister during the list_empty() loop.
>
> I also noticed that that transport_container_[register,unregister]()
> calls in iscsi_[register,release]_transport() where added around
> 2.6.12-rc1, but are not included in the scsi_transport_iscsi.c within
> the 4.0.1.11.
The scsi_transport_iscsi.c in 4.0.1.11 is old. That version of the driver
was for before James's transport container code so you cannot use the
scsi_transport_iscsi.c in there with the current driver model transport
code.
Also you do not need to worry about sfnet compatibilty. If your changes
are good/merged we will adapt to them. So do not worry about breaking
us in the mean time.
>
> Any ideas?
>
> (gdb) list *(attribute_container_unregister+0x1c)
> 0x7c is in attribute_container_unregister (list.h:251).
> 246 /**
> 247 * list_empty - tests whether a list is empty
> 248 * @head: the list to test.
> 249 */
> 250 static inline int list_empty(const struct list_head *head)
> 251 {
> 252 return head->next == head;
> 253 }
> 254
> 255 /**
> (gdb)
>
> Unable to handle kernel paging request at virtual address 63722d5e
> printing eip:
> c029ed5c
> *pde = 00000000
> Oops: 0000 [#1]
> SMP
> Modules linked in: iscsi_initiator_mod scsi_transport_iscsi microcode
> usbcore
> CPU: 1
> EIP: 0060:[<c029ed5c>] Not tainted VLI
> EFLAGS: 00010246 (2.6.12-rc3)
> EIP is at attribute_container_unregister+0x1c/0x50
> eax: 63722d5e ebx: fffffff0 ecx: 63722d56 edx: 00000282
> esi: 00000000 edi: bfaf3650 ebp: f6ed5f24 esp: f6ed5f20
> ds: 007b es: 007b ss: 0068
> Process rmmod (pid: 4501, threadinfo=f6ed5000 task=f7873530)
> Stack: 63722d32 f6ed5f34 f886e043 63722d56 f8cf2680 f6ed5f4c f8cd0248
> 63722d32
> 00000008 f8cf2680 00000880 f6ed5f54 f8cde7d8 f6ed5fb4 c01381f7
> f8cf2680
> 00000880 f6ed5f68 00000000 73637369 6e695f69 61697469 5f726f74
> 00646f6d
> Call Trace:
> [<c0103c9f>] show_stack+0x7f/0xa0
> [<c0103e4e>] show_registers+0x15e/0x1d0
> [<c0104062>] die+0xf2/0x180
> [<c0113252>] do_page_fault+0x382/0x6e0
> [<c01038a3>] error_code+0x4f/0x54
> [<f886e043>] iscsi_release_transport+0x23/0x60 [scsi_transport_iscsi]
> [<f8cd0248>] iscsi_linux_fini+0x18/0x80 [iscsi_initiator_mod]
> [<f8cde7d8>] exit_iscsi_module+0x8/0xa [iscsi_initiator_mod]
> [<c01381f7>] sys_delete_module+0x157/0x190
> [<c0102d33>] sysenter_past_esp+0x54/0x75
>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: scsi_transport_iscsi.c + transport_container_unregister() oops
2005-04-27 18:49 ` Nicholas A. Bellinger
@ 2005-04-27 19:03 ` Mike Christie
0 siblings, 0 replies; 4+ messages in thread
From: Mike Christie @ 2005-04-27 19:03 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: linux-scsi, James Bottomley
Nicholas A. Bellinger wrote:
> On Wed, 2005-04-27 at 11:50 -0700, Mike Christie wrote:
>
>>Nicholas A. Bellinger wrote:
>>
>>>While adding support for the iSCSI Transport class
>>>(scsi_transport_iscsi.c) to the iscsi-initiator-core stack, I ran into a
>>>problem with iscsi_release_transport() and
>>>transport_container_unregister().
>>>
>>>When iscsi_register_transport() and iscsi_release_transport() are called
>>>WITHOUT calling scsi_add_host() and scsi_remove_host() there are no
>>>problems.
>>>
>>>When iscsi_register_transport() and iscsi_release_transport() are called
>>>WITH calling scsi_add_host() and scsi_remove_host() the following OOPs
>>>appears in attribute_container_unregister during the list_empty() loop.
>>>
>>>I also noticed that that transport_container_[register,unregister]()
>>>calls in iscsi_[register,release]_transport() where added around
>>>2.6.12-rc1, but are not included in the scsi_transport_iscsi.c within
>>>the 4.0.1.11.
>>
>>The scsi_transport_iscsi.c in 4.0.1.11 is old. That version of the driver
>>was for before James's transport container code so you cannot use the
>>scsi_transport_iscsi.c in there with the current driver model transport
>>code.
>>
>>Also you do not need to worry about sfnet compatibilty. If your changes
>>are good/merged we will adapt to them. So do not worry about breaking
>>us in the mean time.
>>
>
>
> Just to double check as I have not had a chance to test this myself,
> does iscsi_release_transport() work correctly once a scsi host has been
> registered with sfnet and 2.6.12-rc3's scsi_transport_iscsi.c?
>
Yes. Just double checked.
> I am trying to make sure it is not something obvious I am missing on my
> side.
>
> Thanks,
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-04-27 19:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-27 18:34 scsi_transport_iscsi.c + transport_container_unregister() oops Nicholas A. Bellinger
2005-04-27 18:50 ` Mike Christie
2005-04-27 18:49 ` Nicholas A. Bellinger
2005-04-27 19:03 ` Mike Christie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox