RE: [PATCH 3/3] MidLayer updates - extending scsi_target support
the idea behind this is fine, I just don't like the interface. Really a target device is nothing more than a container to SCSI. We already do the transport add/remove calls for targets, I don't see we need other calls duplicating this. So, I think the implementation would look a whole lot better if the fc transport class just exported an interface to get the extra storage for the driver and tacked it on to its allocation. Then you can use the existing mid-layer transport target triggers to do everything you want. This can certainly be transport-specific. However, I assumed the better solution was to make it more generic as there's nothing about this problem that's transport-centric. If a driver only tracks things by target (not lun), it makes a whole lotta sense to allow for per-target data. Please note however, that I recommend the changes for calling sequence be taken in regardless. The issue is that the sdev transport setup and slave alloc calls are made prior to the existence of the starget (thus any starget transport setup call). The starget really needs to be in place beforehand. Let me know - I can revise the patch accordingly. -- James S - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] MidLayer updates - extending scsi_target support
[EMAIL PROTECTED] wrote: the idea behind this is fine, I just don't like the interface. Really a target device is nothing more than a container to SCSI. We already do the transport add/remove calls for targets, I don't see we need other calls duplicating this. So, I think the implementation would look a whole lot better if the fc transport class just exported an interface to get the extra storage for the driver and tacked it on to its allocation. Then you can use the existing mid-layer transport target triggers to do everything you want. This can certainly be transport-specific. However, I assumed the better solution was to make it more generic as there's nothing about this problem that's transport-centric. If a driver only tracks things by target (not lun), it makes a whole lotta sense to allow for per-target data. Targets speak the same transport protocol as the HBA. This cannot necessarily be said about logical units. Bridges are being proposed between SAS and SPI in which U160/U320 disks on a SPI bus appear as luns on a single SAS target (i.e. the bridge device). If the initiator wants to speak to the disks then it uses luns (most likely where SPI target ids appear as luns). The initiator may be a little surprised if it queries the protocol specific mode and log pages on those disks (as they will reveal their native SPI transport characteristics). To query and configure the bridge (and perhaps check its protocol specific mode and logs pages) well known logical unit numbers will be used. SCSI targets seem like an important abstraction in their own right, not just containers for lus. Doug Gilbert - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sbp2 oops with external ieee1394 burner
Searched and didn't find anything on archives for this, but I probably just missed it. Upgraded from 2.6.8.1 today to 2.6.10, and using my external firewire DVD-RW I get oopsed. I patched to 2.6.11-rc3 and it's still there, I can't speak for 2.6.9 at this point, I can try later if I have to narrow it down. Just wondered if anyone else had this prob? Feb 5 07:55:18 jkd kernel: f9aee36b Feb 5 07:55:18 jkd kernel: PREEMPT Feb 5 07:55:18 jkd kernel: Modules linked in: sg spca50x videodev ath_pci ath_rate_onoe wlan ath_hal ipt_MASQUERADE iptable_nat iptable_ filter ip_tables ipv6 snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_p age_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore parport_pc lp parport cls_route cls_u32 cls_fw sch_prio sch_sfq sch_tb f sch_cbq sr_mod sbp2 sd_mod eth1394 r8169 ohci1394 ieee1394 usbhid usb_storage scsi_mod loop pcspkr evdev ehci_hcd ohci_hcd uhci_hcd usb core video Feb 5 07:55:18 jkd kernel: CPU:0 Feb 5 07:55:18 jkd kernel: EIP:0060:[pg0+962773867/1068745728] Tainted: P VLI Feb 5 07:55:18 jkd kernel: EIP:0060:[f9aee36b]Tainted: P VLI Feb 5 07:55:18 jkd kernel: EFLAGS: 00010013 (2.6.11-rc3) Feb 5 07:55:18 jkd kernel: EIP is at sbp2util_find_command_for_SCpnt+0x2b/0xb0 [sbp2] Feb 5 07:55:18 jkd kernel: eax: 0001 ebx: 0001 ecx: 0001 edx: f742df88 Feb 5 07:55:18 jkd kernel: esi: 0086 edi: f6ccdfb4 ebp: f69ca7c0 esp: f6ccdf4c Feb 5 07:55:18 jkd kernel: ds: 007b es: 007b ss: 0068 Feb 5 07:55:18 jkd kernel: Process scsi_eh_1 (pid: 4417, threadinfo=f6ccd000 task=f6defaa0) Feb 5 07:55:19 jkd kernel: Stack: f69ca7c0 f742df00 f6ccdfb4 f6ccdfac f9af0a9b f742df00 f69ca7c0 0206 Feb 5 07:55:19 jkd kernel:f69ca7c0 f98849fd f69ca7c0 f69ca7c0 f69ca658 f9884b49 f69ca7c0 f6ccdfe0 Feb 5 07:55:19 jkd kernel:f69bb430 0286 f6ccdfac f6ccdfb4 f98857fc f6ccdfb4 f6ccdfac f6defbf4 Feb 5 07:55:19 jkd kernel: Call Trace: Feb 5 07:55:19 jkd kernel: [pg0+962783899/1068745728] sbp2scsi_abort+0x3b/0xa0 [sbp2] Feb 5 07:55:19 jkd kernel: [f9af0a9b] sbp2scsi_abort+0x3b/0xa0 [sbp2] Feb 5 07:55:19 jkd kernel: [pg0+960244221/1068745728] scsi_try_to_abort_cmd+0x4d/0x90 [scsi_mod] Feb 5 07:55:19 jkd kernel: [f98849fd] scsi_try_to_abort_cmd+0x4d/0x90 [scsi_mod] Feb 5 07:55:19 jkd kernel: [pg0+960244553/1068745728] scsi_eh_abort_cmds+0x39/0x90 [scsi_mod] Feb 5 07:55:19 jkd kernel: [f9884b49] scsi_eh_abort_cmds+0x39/0x90 [scsi_mod] Feb 5 07:55:19 jkd kernel: [pg0+960247804/1068745728] scsi_unjam_host+0xbc/0xf0 [scsi_mod] Feb 5 07:55:19 jkd kernel: [f98857fc] scsi_unjam_host+0xbc/0xf0 [scsi_mod] Feb 5 07:55:19 jkd kernel: [pg0+960248017/1068745728] scsi_error_handler+0xa1/0xd0 [scsi_mod] Feb 5 07:55:19 jkd kernel: [f98858d1] scsi_error_handler+0xa1/0xd0 [scsi_mod] Feb 5 07:55:19 jkd kernel: [pg0+960247856/1068745728] scsi_error_handler+0x0/0xd0 [scsi_mod] Feb 5 07:55:19 jkd kernel: [f9885830] scsi_error_handler+0x0/0xd0 [scsi_mod] Feb 5 07:55:19 jkd kernel: [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 Feb 5 07:55:19 jkd kernel: [c01012f5] kernel_thread_helper+0x5/0x10 Feb 5 07:55:19 jkd kernel: Code: 55 57 56 53 8b 5c 24 14 8b 6c 24 18 9c 5e fa b8 01 00 00 00 e8 97 b2 62 c6 8b 83 88 00 00 00 8d 93 88 0 0 00 00 39 d0 74 2b 89 c3 8b 00 0f 18 00 90 39 da 74 1f bf 00 f0 ff ff 21 e7 8d 74 26 00 Feb 5 07:55:19 jkd kernel: 6note: scsi_eh_1[4417] exited with preempt_count 2 -- http://www.skycon.net/ AIM: JasonRStraight ICQ: 1796276 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
