Re: iSCSI initiator driver beta version, testers wanted
Amir Tahmasebi wrote: Hello Danny, Do you know if there is any problem with ISCSI initiator when using FreeBSD version 6.x? Thanks I was able to backport the driver from 7 fairly easily. If there is some interest, here is a small diff. Simply copying the iscontrol from RELENG_7 into RELENG_6 and changing the makefiles worked for me. isc_cam.c 399,400d398 #if __FreeBSD_version = 70 402,404d399 #else if(xpt_bus_register(sim, 0/*bus_number*/) != CAM_SUCCESS) #endif Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator driver beta version, testers wanted
On Tue, Mar 08, 2005 at 09:06:19AM +0200, Danny Braniss typed: well, i guess all is ok, since im not getting much feedback :-) Actually, I've been on a holliday and wasn't able to do testing until yesterday. When I try to connect to the target (an Equallogic PS200E) the system panics (trace see below). This is 5.4-PRE running under vmware. I had a panic with 5.3-RELEASE as well (but no trace). Anything I can do to help, I have some spare time. greetings, Ruben FreeBSD 5.4-PRERELEASE (DBG) #0: Wed Mar 16 01:28:18 UTC 2005 x226220# kldload iscsi iscsi_kld_start: iscsi start ic_action: called ic_action: func_code=0x4 flags=0x0 status=0x0 target=-1 lun=-1 retry_count=0 ti0 _inq: called ic_init: cam subsystem initialized x226220# iscontrol -v -t 172.17.24.100 iscsi_ioctl: called iscsi_ioctl: dev=4 cmd=1 i_create_session: called 0] i_create_session: sessionID=0 ism_start: called ism_proc: called proc_in: called proc_out: called 0] ism_proc: idone=0 odone=0 iscsi_close: called iscsi_ioctl: called iscsi_ioctl: dev=0 cmd=2 isc_start_receiver: called isc_soc: called so_getbhs: called iscsi_ioctl: called iscsi_ioctl: dev=0 cmd=5 i_setopt: opt.targetAddr='172.17.24.100' iscsi_ioctl: called iscsi_ioctl: dev=0 cmd=10 i_send: called kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc063787a stack pointer = 0x10:0xc92a0b3c frame pointer = 0x10:0xc92a0b3c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 450 (iscontrol) [thread pid 450 tid 100068 ] Stopped at turnstile_head+0x6: movl0(%eax),%eax db trace Tracing pid 450 tid 100068 td 0xc141dc80 turnstile_head(0,c156e080,c1714ae0,c16d7d00,c92a0b6c) at turnstile_head+0x6 _mtx_unlock_sleep(c1714b30,0,c1712f40,e5) at _mtx_unlock_sleep+0x40 _mtx_unlock_flags(c1714b30,0,c1712f40,e5,5) at _mtx_unlock_flags+0x2e i_send(c16d7d00,c156f200,c141dc80,c1706c00,1) at i_send+0x149 iscsi_ioctl(c16d7d00,8050690a,c156f200,3,c141dc80) at iscsi_ioctl+0x17e spec_ioctl(c92a0c08,c92a0cb4,c0677506,c92a0c08,c08cbc60) at spec_ioctl+0xb5 spec_vnoperate(c92a0c08) at spec_vnoperate+0x13 vn_ioctl(c152b990,8050690a,c156f200,c156e400,c141dc80) at vn_ioctl+0x20a ioctl(c141dc80,c92a0d14,3,c,10296) at ioctl+0x40f syscall(2f,2f,2f,804d000,bfbfec00) at syscall+0x27b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280c413b, esp = 0xbfbfeb9c, ebp- db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator driver beta version, testers wanted
things are looking much better 2day, got tag queuing to work, and now it's much faster. Q: how can the driver tell the cam to enable queing (ie: camcontrol tag 0:0:0 -Nn), and Q: is there a rule of thumb as to how many tag'ed? thanks, danny PS: soon there will be a new beta, any news with the old one? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator driver beta version, testers wanted
Danny Braniss wrote: things are looking much better 2day, got tag queuing to work, and now it's much faster. Q: how can the driver tell the cam to enable queing (ie: camcontrol tag 0:0:0 -Nn), and case XPT_PATH_INQ: cpi-hba_inquiry = PI_TAG_ABLE Q: is there a rule of thumb as to how many tag'ed? When you call cam_sim_alloc(), there are arguments for how many concurrent tagged and untagged transactions the driver can handle. I don't know how tags work in iscsi, so I can't say what a good number is here. Note that tag management is left completely up to the driver; CAM will tell you whether or not to use a tag for a particular CCB, but it's up to the driver to assign and track the tag number. thanks, danny PS: soon there will be a new beta, any news with the old one? Sorry, I haven't had much time to review the old one yet. Sounds like you're making really good progress, though. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator driver beta version, testers wanted
In the last episode (Mar 15), Scott Long said: Danny Braniss wrote: things are looking much better 2day, got tag queuing to work, and now it's much faster. Q: how can the driver tell the cam to enable queing (ie: camcontrol tag 0:0:0 -Nn), and case XPT_PATH_INQ: cpi-hba_inquiry = PI_TAG_ABLE Q: is there a rule of thumb as to how many tag'ed? When you call cam_sim_alloc(), there are arguments for how many concurrent tagged and untagged transactions the driver can handle. I don't know how tags work in iscsi, so I can't say what a good number is here. Note that tag management is left completely up to the driver; CAM will tell you whether or not to use a tag for a particular CCB, but it's up to the driver to assign and track the tag number. I would guess that tags would be even more useful for iscsi than direct-attached scsi, due to the extra latency. The more the better. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator driver beta version, testers wanted
Danny Braniss wrote: well, i guess all is ok, since im not getting much feedback :-) anyways, this is my new problem: o- the target accepts the login, but does not supply a valid device, usually because some admin. problem. I would like to be able to report the problem to the initiator and I need some clues. The cam will, if successful create /dev/da*, on failure nothing, so Q: how can this be found out without getting into the actual SCSI transactions? Is there a target mode implementation of this for FreeBSD yet? Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology I have seen the future and it is just like the present, only longer. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator driver beta version, testers wanted
Danny Braniss wrote: well, i guess all is ok, since im not getting much feedback :-) anyways, this is my new problem: o- the target accepts the login, but does not supply a valid device, usually because some admin. problem. I would like to be able to report the problem to the initiator and I need some clues. The cam will, if successful create /dev/da*, on failure nothing, so Q: how can this be found out without getting into the actual SCSI transactions? Is there a target mode implementation of this for FreeBSD yet? speakin for myself, at the moment im trying to get the initiator working, and up to speed, after that i might try and tackle the target, but though there is alot of symmetry, there is much more administrativia involved. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator driver beta version, testers wanted
Danny Braniss wrote: Danny Braniss wrote: well, i guess all is ok, since im not getting much feedback :-) anyways, this is my new problem: o- the target accepts the login, but does not supply a valid device, usually because some admin. problem. I would like to be able to report the problem to the initiator and I need some clues. The cam will, if successful create /dev/da*, on failure nothing, so Q: how can this be found out without getting into the actual SCSI transactions? Is there a target mode implementation of this for FreeBSD yet? speakin for myself, at the moment im trying to get the initiator working, and up to speed, after that i might try and tackle the target, but though there is alot of symmetry, there is much more administrativia involved. I'd help you test, but I have no iscsi targets to test against :) Eirc -- Eric AndersonSr. Systems AdministratorCentaur Technology I have seen the future and it is just like the present, only longer. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI initiator driver beta version, testers wanted
well, i guess all is ok, since im not getting much feedback :-) anyways, this is my new problem: o- the target accepts the login, but does not supply a valid device, usually because some admin. problem. I would like to be able to report the problem to the initiator and I need some clues. The cam will, if successful create /dev/da*, on failure nothing, so Q: how can this be found out without getting into the actual SCSI transactions? thanks, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
