Bug 177645 - panic in iscsi show_session_first_burst_len shortly after loading iscsi
Summary: panic in iscsi show_session_first_burst_len shortly after loading iscsi
Status: CLOSED DUPLICATE of bug 159709
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: iscsi-initiator-utils
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Mike Christie
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2006-01-12 17:08 UTC by Dave Wysochanski
Modified: 2008-04-07 05:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-01-12 17:58:03 UTC

Attachments (Terms of Use)

Description Dave Wysochanski 2006-01-12 17:08:57 UTC
Description of problem:
Kernel panic in iscsi module - show_session_first_burst_len().

Version-Release number of selected component (if applicable):
- RHEL4 U3 beta + device-mapper-multipath-0.4.5-11.0.RHEL4 RPM

How reproducible:
Not sure.

Steps to Reproduce:
Was testing dm-multipath + iSCSI, was doing repeated sequences like this:
1. start iscsi
2. run I/O directly to dm-device with 4 paths (no filesystem involved)
3. stop I/O
4. flush maps "multipath -F"
5. stop iscsi

Panic occurred shortly after step #1 on an iteration.  Will try to get a
reproducible case.

Actual results:
iscsi-sfnet: Loading iscsi_sfnet version 4:0.1.11-2
iscsi-sfnet: Control device major number 254
Unable to handle kernel NULL pointer dereference at virtual address 00000038
 printing eip:
*pde = 34c27001
Oops: 0000 [#1]
Modules linked in: iscsi_sfnet dm_round_robin md5 ipv6 crc32c libcrc32c autofs4
i2c_dev i2c_core sunrpc scsi_transport_iscsi dm_mird
CPU:    2
EIP:    0060:[<f891515c>]    Not tainted VLI
EFLAGS: 00010286   (2.6.9-27.ELsmp)
EIP is at show_session_first_burst_len+0x18/0x3c [scsi_transport_iscsi]
eax: 00000000   ebx: f7d94400   ecx: f8915144   edx: f3cab000
esi: f3cab000   edi: c034131c   ebp: f8916cc8   esp: f057af44
ds: 007b   es: 007b   ss: 0068
Process iscsid (pid: 25725, threadinfo=f057a000 task=f4a2c630)
Stack: f3cab000 00000000 c021f093 c322e380 f7d944d4 c018d081 00000000 c322e394
       c322e380 f0a5ad80 00001000 c018d1b3 09eea968 c032e2e0 f0a5ad80 00001000
       f057afac c015a4e5 f057afac 09eea968 f0a5ad80 fffffff7 00000006 f057a000
Call Trace:
 [<c021f093>] class_device_attr_show+0x14/0x1b
 [<c018d081>] fill_read_buffer+0x45/0x6f
 [<c018d1b3>] sysfs_read_file+0x47/0x70
 [<c015a4e5>] vfs_read+0xb6/0xe2
 [<c015a6f8>] sys_read+0x3c/0x62
 [<c02d2723>] syscall_call+0x7/0xb
Code: 68 e7 58 91 f8 6a 14 56 e8 fa c8 8a c7 83 c4 10 5b 5e c3 56 89 d6 53 8d 98
34 ff ff ff 8b 43 24 2d d4 00 00 00 8b 40 78 8b 40
 <0>Fatal exception: panic in 5 seconds
Kernel panic - not syncing: Fatal exception

Expected results:

Additional info:

Comment 1 Mike Christie 2006-01-12 17:58:03 UTC
This is a duplicate of this bug

where we believe the threading in iscsid needs fixing (bogus fd is getting opened).

*** This bug has been marked as a duplicate of 159709 ***

Note You need to log in before you can comment on or make changes to this bug.