From erich at fuujinnetworks.com Mon Sep 1 09:00:43 2008 From: erich at fuujinnetworks.com (Fuujin Networks LLC) Date: Mon Sep 1 09:00:50 2008 Subject: Qlogic FC scsi_target ISP2310 In-Reply-To: <3c0b01820808311012n7e83a948t732e6544ddb0d703@mail.gmail.com> References: <48B4CF57.30603@fuujinnetworks.com> <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> <48B733CF.5000105@fuujinnetworks.com> <3c0b01820808290914s638c970ejeae1d4f8c8c8a9d9@mail.gmail.com> <3c0b01820808290915t4e964182y784c215e28977252@mail.gmail.com> <48B8E879.7020809@fuujinnetworks.com> <3c0b01820808300708s5ed5cb18o5199e0e4ec1dcbba@mail.gmail.com> <48BA87C6.5070008@fuujinnetworks.com> <3c0b01820808311012n7e83a948t732e6544ddb0d703@mail.gmail.com> Message-ID: <48BBBD16.80402@fuujinnetworks.com> Alex: So here's something interesting. The target decided to panic on me just now. Here's the last message from the target before it rebooted: scsi_target: main loop beginning scsi_target: read ready scsi_target: event -1 done scsi_target: Working on ATIO 0x800b7fe20 scsi_target: tcmd_handle atio 0x800b7fe20 ctio 0x800b85040 atioflags 0x8000 scsi_target: INQUIRY from 0: 12 0 0 0 24 0 The initiator just sits there and says the rescan was successful with no events or errors..... Here's the panic: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff8022f128 stack pointer = 0x10:0xffffffffae3c1650 frame pointer = 0x10:0xffffffffae3c16e0 code segment = base 0x0, limit oxfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 777 (scsi_target) [thread pid 777 tid 100075 ] Stopped at isp_pci_dmasetup+0x1d8: movq 0x8(%rax),%rsi Here's the bt: Tracing pid 777 tid 100075 td 0xffffff00016e100 isp_pci_dmasetup() at isp_dmasetup+0x1d8 isp_action() at isp_action+0x1089 xpt_run_dev_sendq() at xpt_run_dev_sendq+0x1c4 xpt_action() at xpt_action+0x796 targsendccb() at targsendccb+0x9e targstart() at targstart+0x130 xpt_run_dev_allocq() at xpt_run_dev_allocq+0xd4 targwrite() at targwrite+0x184 giant_write() at giant_write+0x60 devfs_write_f() at devfs_write_f+0x75 dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x4c write() at write+0x54 syscall() at syscall+0x254 Xfast_syscall() at Xfast_syscall+0xab --- syscall (4, FreeBSD ELF64, write), rip = 0x800929d3c, rsp = 0x7fffffff4908, rbp = 0x800b83440 --- Please note the above trace was copied by hand because I couldn't get console redirection to stay up when this died. Does anyone know how to get this data into a file or out via serial (vt100 perhaps??) or is this pretty much a manual process?? Erich M. Jenkins Fuujin Networks, LLC PO Box 792 Brainerd, MN 56401 (p) 218-824-5038 (f) 218-824-7516 "You should never, never doubt what no one is sure about." -- Gene Wilder Alexander Sack wrote: > On Sun, Aug 31, 2008 at 8:00 AM, Fuujin Networks LLC > wrote: >> I apologize for not being more specific in my questions. I understand that >> we're loading the firmware via the kernel, but my question was why not load >> it from the card? If I have an HP SmartArray 5300 card and the firmware is >> out of date, I'm expected to update it, not load a kernel module to do it >> for me. This makes sense for many reasons, not he least of which is >> compatibility. I'm in no position to suggest what is proper from the >> standpoint of this particular problem, but I'm trying to understand the >> reason for choosing a kernel module rather than an sys admin as with nearly >> all other devices. > > We do both! QLogic ships each card with some version of the firmware > on it that boots up at runtime. One of the nice features of the ISP > is that its RISC based firmware can be updated at runtime ensuring you > are always running the latest. The ispfw driver is strictly used to > register firmwares with the generic firmware driver (the real action > happens in isp during isp_reset()). > > I think the driver should really check to see if the ispfw version is > less than the resident driver and do the right thing. I think it used > to do that but was taken out, I don't know why - I'm actually thinking > of maybe it should be added back. > > In any event, if you want to disable loading of the firmware you can > set in your hints file: > > hint.isp.0.fwload_disable=1 > > That should prevent the driver from loading the ispfw version (please > check during bootup what version your resident firmware is at to > determine which is newer). If you do this then you should see: > > isp0: Board Type 2300, Chip Revision 0x1, resident F/W Revision > > instead of > > isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision > > Having a separate utility (typically DOS or Windows based) is not that > great in my eyes but to each his own. Bottom line is you should run > the latest ISP firmware (whether its the one that was flashed from > QLogic or the one in the ispfw driver). I'm thinking that perhaps and > audit should be done and we should ship the latest firmware off the > QLogic website. What version is shipped with your card? Looks like > 3.3.25 is the latest for 23xx cards. Hmmm.... > >> I misunderstood the purpose of your patch as well. I thought the problem >> was a firmware loading issue, but as you mentioned, this does not appear to >> be the case. > > Right, it seems something else. > >> I did see your message with the patch and it was correctly applied and the >> kernel was correctly compiled. I did, however, reinstall the OS because of >> all the fiddling I did to this point. Funny thing is that I can't get it to >> crash anymore. I tried it clean, and the system tanked, but after I applied >> your patch, I can't get it to panic anymore. The loop looks like it comes >> up, but when I rescan with the initiator, the target stays up without >> incident, but nothing shows up in camcontrol as an emulated disk: >> >> amd_svr0-01# camcontrol devlist -v >> scbus0 on isp0 bus 0: >> < > at scbus0 target -1 lun -1 () >> scbus-1 on xpt0 bus 0: >> < > at scbus-1 target -1 lun -1 (xpt0) >> >> I do get this on the initiator though: >> >> [snip] >> Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.5 (count 36, resid 36, >> status not marked) >> Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.6 (count 36, resid 36, >> status not marked) >> Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.5 (count 36, resid 36, >> status not marked) >> Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.6 (count 36, resid 36, >> status not marked) >> Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.5 (count 36, resid 36, >> status not marked) >> Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.6 (count 36, resid 36, >> status not marked) >> Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.5 (count 36, resid 36, >> status not marked) >> Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.6 (count 36, resid 36, >> status not marked) >> Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.6 (count 36, resid 36, >> status not marked) >> Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.7 (count 36, resid 36, >> status not marked) >> [snip] >> >> After a clean install, this is what I see from dmesg on the target: >> >> [snip] >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> isp0: port 0x3000-0x30ff mem >> 0xfe020000-0xfe020fff irq 25 at device 1.0 on pci2 >> isp0: [ITHREAD] >> isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1008 >> isp0: target notify code 0x1006 >> [snip] > > Is this with or without the isp patch I sent regarding the firmware? > I noticed its not trying to get isp_2300_it like before (I'm hoping > that's due to the patch I sent otherwise I'm confused this holiday > weekend). > >> Here's the complete kernel, also after a fresh install and the removal of >> unnecessary options/devices (stuff not in the server): > >> # SCSI Controllers >> device isp # Qlogic family >> device ispfw # Firmware for QLogic HBAs- normally a >> module >> options ISP_TARGET_MODE # for ISP cards to operate in target mode >> device targ # SCSI Target device >> device targbh # SCSI Target Black Hole >> options CAMDEBUG >> options VFS_AIO > > Thanks for this, I just wanted to verify your build options look good. > >> Not sure what to make of this.... Would you recommend a different FC card? >> Emulex? > > I have no direct experience with Emulex with FreeBSD so I'm not the > right person to ask. I was under the impression that the 23xx target > mode was working. Did you enable target mode in the BIOS by chance > (or disable it, I think on my 24xx BIOS I have that option but I'm not > in front of it yet). Just verify your BIOS version number and options > before completely giving up! :D > > -aps From bugmaster at FreeBSD.org Mon Sep 1 11:07:02 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 1 11:08:54 2008 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200809011107.m81B71Xc068560@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/120487 scsi [sg] scsi_sg incompatible with scanners o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o kern/123674 scsi [ahc] ahc driver dumping o kern/126866 scsi [isp] [panic] kernel panic on card initialization 11 problems total. From westr at connection.ca Tue Sep 2 16:52:08 2008 From: westr at connection.ca (Ross) Date: Tue Sep 2 16:52:15 2008 Subject: isp(4) - kernel panic on initialization of driver In-Reply-To: <3c0b01820808291515j759236e6h262c533846587d57@mail.gmail.com> References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> <86689256.20080827112751@connection.ca> <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> <34442830.20080829103621@connection.ca> <3c0b01820808290822tce5619bie11b8e97fe9a9062@mail.gmail.com> <08661720.20080829151750@connection.ca> <3c0b01820808291515j759236e6h262c533846587d57@mail.gmail.com> Message-ID: <479922773.20080902125207@connection.ca> AS> I think your doing some great work but I don't think this is the AS> *right* direction to take. The bottom line is the ISP should have AS> interrupts disabled until it completes a full reset and loads the AS> firmware, period. You shouldn't have to ignore ASYNC events during a AS> reset - that doesn't make sense to me....yet....! I've created a small patch that so far seems to be working (survived ~10+ reboots). From what I can tell, using the ISP_ENABLE_INTS & ISP_DISABLE_INTS functions won't do anything to stop the problem. Basically my hypotheses is that the ASYNC command is already sitting around in the mailbox of the card waiting to be read, so no interrupt is actually being generated during the time the driver is starting up - so you can't disable it. (The card is active with a valid running rom before freebsd gets it's paws on it, so it's probably already cleanly read it, but hasn't acted upon it) The crash is located with the very first mailbox read, where if it doesn't recognize the mailbox response, it parses it anyways (in case it's something that needs to be done), and exit out if there's an error. But the isp_parse_async() function makes the assumption that isp_state == ISP_RUNSTATE, so it's safe to do anything. Where in fact is actually gets called when not in ISP_RUNSTATE (with the assumption that no problematic async command could be generated at this point). I'm guessing the true fix would be upon startup to somehow make sure the mailbox queue is emptied before attempting to query the card (for the firmware version). But how to do that is beyond me. Let me know what you think. Ross. -= start [~/isp]$ diff -u isp.c.orig isp.c --- isp.c.orig 2008-08-22 16:32:57.000000000 -0400 +++ isp.c 2008-09-02 11:48:18.000000000 -0400 @@ -4557,8 +4557,10 @@ isp_prt(isp, ISP_LOGWARN, "mailbox cmd (0x%x) with no waiters", mbox); } - } else if (isp_parse_async(isp, mbox) < 0) { - return; + } else if (isp->isp_state == ISP_RUNSTATE) { + if (isp_parse_async(isp, mbox) < 0) { + return; + } } if ((IS_FC(isp) && mbox != ASYNC_RIO_RESP) || isp->isp_state != ISP_RUNSTATE) { -= -- Ross West Tel: +1 416 967 6767 Network Manager Fax: +1 416 967 7777 Network Connection Email: westr@connection.ca From pisymbol at gmail.com Tue Sep 2 18:42:14 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Tue Sep 2 18:42:21 2008 Subject: isp(4) - kernel panic on initialization of driver In-Reply-To: <479922773.20080902125207@connection.ca> References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> <86689256.20080827112751@connection.ca> <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> <34442830.20080829103621@connection.ca> <3c0b01820808290822tce5619bie11b8e97fe9a9062@mail.gmail.com> <08661720.20080829151750@connection.ca> <3c0b01820808291515j759236e6h262c533846587d57@mail.gmail.com> <479922773.20080902125207@connection.ca> Message-ID: <3c0b01820809021142v1192123aq1116c5528dda4920@mail.gmail.com> On Tue, Sep 2, 2008 at 12:52 PM, Ross wrote: > > AS> I think your doing some great work but I don't think this is the > AS> *right* direction to take. The bottom line is the ISP should have > AS> interrupts disabled until it completes a full reset and loads the > AS> firmware, period. You shouldn't have to ignore ASYNC events during a > AS> reset - that doesn't make sense to me....yet....! > > I've created a small patch that so far seems to be working (survived > ~10+ reboots). From what I can tell, using the ISP_ENABLE_INTS & > ISP_DISABLE_INTS functions won't do anything to stop the problem. Yes Ross, I just discovered this myself that AYNC events are let through to the host regardless of ISP_ENABLE_INTS. > Basically my hypotheses is that the ASYNC command is already sitting > around in the mailbox of the card waiting to be read, so no interrupt > is actually being generated during the time the driver is starting up > - so you can't disable it. That's right but the ISP should be reset. YWe actually issue mailbox commands BEFORE we do the RISC reset. I think that maybe ultimately the bug. > (The card is active with a valid running rom before freebsd gets it's > paws on it, so it's probably already cleanly read it, but hasn't acted > upon it) Yes I believe your right. > The crash is located with the very first mailbox read, where if it > doesn't recognize the mailbox response, it parses it anyways > (in case it's something that needs to be done), and exit out if > there's an error. > > But the isp_parse_async() function makes the assumption that isp_state > == ISP_RUNSTATE, so it's safe to do anything. Where in fact is > actually gets called when not in ISP_RUNSTATE (with the assumption > that no problematic async command could be generated at this point). > > I'm guessing the true fix would be upon startup to somehow make sure > the mailbox queue is emptied before attempting to query the card > (for the firmware version). But how to do that is beyond me. Are you ok with trying another patch to maybe do exactly that? Let me take a look at your patch as well. Thanks! -aps From pisymbol at gmail.com Tue Sep 2 23:42:58 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Tue Sep 2 23:43:03 2008 Subject: Qlogic FC scsi_target ISP2310 In-Reply-To: <48BBBD16.80402@fuujinnetworks.com> References: <48B4CF57.30603@fuujinnetworks.com> <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> <48B733CF.5000105@fuujinnetworks.com> <3c0b01820808290914s638c970ejeae1d4f8c8c8a9d9@mail.gmail.com> <3c0b01820808290915t4e964182y784c215e28977252@mail.gmail.com> <48B8E879.7020809@fuujinnetworks.com> <3c0b01820808300708s5ed5cb18o5199e0e4ec1dcbba@mail.gmail.com> <48BA87C6.5070008@fuujinnetworks.com> <3c0b01820808311012n7e83a948t732e6544ddb0d703@mail.gmail.com> <48BBBD16.80402@fuujinnetworks.com> Message-ID: <3c0b01820809021642s70edbea6k7cadd0b8f051357c@mail.gmail.com> On Mon, Sep 1, 2008 at 5:59 AM, Fuujin Networks LLC wrote: > Alex: > > So here's something interesting. The target decided to panic on me just now. > Here's the last message from the target before it rebooted: > > scsi_target: main loop beginning > scsi_target: read ready > scsi_target: event -1 done > scsi_target: Working on ATIO 0x800b7fe20 > scsi_target: tcmd_handle atio 0x800b7fe20 ctio 0x800b85040 atioflags 0x8000 > scsi_target: INQUIRY from 0: 12 0 0 0 24 0 > > The initiator just sits there and says the rescan was successful with no > events or errors..... > > > Here's the panic: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff8022f128 > stack pointer = 0x10:0xffffffffae3c1650 > frame pointer = 0x10:0xffffffffae3c16e0 > code segment = base 0x0, limit oxfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 777 (scsi_target) > [thread pid 777 tid 100075 ] > Stopped at isp_pci_dmasetup+0x1d8: movq 0x8(%rax),%rsi > > Here's the bt: > > Tracing pid 777 tid 100075 td 0xffffff00016e100 > isp_pci_dmasetup() at isp_dmasetup+0x1d8 > isp_action() at isp_action+0x1089 > xpt_run_dev_sendq() at xpt_run_dev_sendq+0x1c4 > xpt_action() at xpt_action+0x796 > targsendccb() at targsendccb+0x9e > targstart() at targstart+0x130 > xpt_run_dev_allocq() at xpt_run_dev_allocq+0xd4 > targwrite() at targwrite+0x184 > giant_write() at giant_write+0x60 > devfs_write_f() at devfs_write_f+0x75 > dofilewrite() at dofilewrite+0x85 > kern_writev() at kern_writev+0x4c > write() at write+0x54 > syscall() at syscall+0x254 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (4, FreeBSD ELF64, write), rip = 0x800929d3c, rsp = > 0x7fffffff4908, rbp = 0x800b83440 --- > > Please note the above trace was copied by hand because I couldn't get > console redirection to stay up when this died. Does anyone know how to get > this data into a file or out via serial (vt100 perhaps??) or is this pretty > much a manual process?? Erich, if you had a gdb session you could log it or use print screen I suppose. But yea it can be a pain in the butt to copy stack traces. I don't know why you panic'ed and I haven't had a single cycle to look a this particular issue. So it seems you and Sean (see other thread) are having trouble using the QLA2[34]xx cards in target mode. Seems like there needs to be more testing involved. I'll see if tomorrow I can build target mode in on my box and reproduce the panic (a panic, hopefully with a similar stacktrace!). Thanks for this, stay tuned... -aps From klapperzhu at gmail.com Wed Sep 3 20:15:45 2008 From: klapperzhu at gmail.com (Klapper Zhu) Date: Wed Sep 3 20:15:51 2008 Subject: build/install a single module (isp) Message-ID: Hi, This is a newbie question. But how do I quickly build/install a single module (/usr/src/sys/dev/isp) in the kernel source ? From klapperzhu at gmail.com Wed Sep 3 21:17:44 2008 From: klapperzhu at gmail.com (Klapper Zhu) Date: Wed Sep 3 21:17:51 2008 Subject: build/install a single module (isp) In-Reply-To: References: Message-ID: I found the answer..... On Wed, Sep 3, 2008 at 3:47 PM, Klapper Zhu wrote: > Hi, > > This is a newbie question. But how do I quickly build/install a single > module (/usr/src/sys/dev/isp) in the kernel source ? > From josh at tcbug.org Wed Sep 3 22:14:28 2008 From: josh at tcbug.org (Josh Paetzel) Date: Wed Sep 3 22:14:34 2008 Subject: Success with SAS in FreeBSD finally Message-ID: <200809031656.36558.josh@tcbug.org> Just tossing this out there for the archives really, but the 3ware 9690SA is a really nice solution for SAS on FreeBSD. Also, if you have one grab the firmware 3ware released yesterday, it's good for a substantial performance increase. (This also applies to 9650 SATA controllers as well) For even bigger bonus you can do the firmware update in OS from FreeBSD with tw_cli I've used the Dell Perc/5 and an LSI 3041R-E HBA and neither one have the performance or in os monitoring that this 3ware does. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-scsi/attachments/20080903/aef13cfa/attachment.pgp From jhs at berklix.org Wed Sep 3 22:48:13 2008 From: jhs at berklix.org (Julian Stacey) Date: Wed Sep 3 22:48:20 2008 Subject: how to format an ide hard disc in a usb enclosure Message-ID: <200809032233.m83MXVRe015145@fire.js.berklix.net> Hi freebsd-scsi@, How does one reformat an IDE disc in a USB enclosure appearing on 7.0-Release via devd as /dev/ da0 da0s1 da0s1a da0s1c pass1 ? su camcontrol devlist at scbus2 target 0 lun 0 (pass0,cd0) at scbus3 target 0 lun 0 (pass1,da0) camcontrol format da0 You are about to REMOVE ALL DATA from the following device: camcontrol: scsiformat: error sending inquiry camcontrol format 3:0:0 You are about to REMOVE ALL DATA from the following device: camcontrol: scsiformat: error sending inquiry Should I be using something from ports/ ? eg cd /usr/ports/sysutils/smartmontools ... smartctl -i -T verypermissive /dev/da0 Device: USB 2.0 Storage Device Version: 0100 >> Terminate command early due to bad response to IEC mode page A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. cd /usr/ports/sysutils/sformat ... sformat -auto 0 0 3 ... Enter number of heads -1 (1 - 255)/: ... too many questions I dont know answer to, I just want to reformat whole device. Background Yes, perhaps as the disc is throwing errors, it might be dieing, &/or bad disc sector list might be full/ filling, but that doesn't worry me: I had to power cycle it rapidly while travelling, might have been the reason, &/or maybe USB hub didnt deliver enough power then (despite doubler cable, thus 1.0A not 0.5A), but theres' nothing vital on that disk, it's just a scratch space for experiments, so I'd like to reformat. Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From pisymbol at gmail.com Thu Sep 4 20:51:16 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Thu Sep 4 20:51:37 2008 Subject: how to format an ide hard disc in a usb enclosure In-Reply-To: <200809032233.m83MXVRe015145@fire.js.berklix.net> References: <200809032233.m83MXVRe015145@fire.js.berklix.net> Message-ID: <3c0b01820809041351lfedc31bla7ba0e3142c3fa85@mail.gmail.com> On Wed, Sep 3, 2008 at 6:33 PM, Julian Stacey wrote: > Hi freebsd-scsi@, > How does one reformat an IDE disc in a USB enclosure appearing on > 7.0-Release via devd as /dev/ da0 da0s1 da0s1a da0s1c pass1 ? > > su > camcontrol devlist > at scbus2 target 0 lun 0 (pass0,cd0) > at scbus3 target 0 lun 0 (pass1,da0) > camcontrol format da0 > You are about to REMOVE ALL DATA from the following device: > camcontrol: scsiformat: error sending inquiry > camcontrol format 3:0:0 > You are about to REMOVE ALL DATA from the following device: > camcontrol: scsiformat: error sending inquiry > > Should I be using something from ports/ ? eg > > cd /usr/ports/sysutils/smartmontools ... > smartctl -i -T verypermissive /dev/da0 > Device: USB 2.0 Storage Device Version: 0100 >>> Terminate command early due to bad response to IEC mode page > A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. > > cd /usr/ports/sysutils/sformat ... sformat -auto 0 0 3 > ... > Enter number of heads -1 (1 - 255)/: > ... too many questions I dont know answer to, > I just want to reformat whole device. > > Background > Yes, perhaps as the disc is throwing errors, it might be dieing, > &/or bad disc sector list might be full/ filling, but that doesn't > worry me: I had to power cycle it rapidly while travelling, might > have been the reason, &/or maybe USB hub didnt deliver enough power > then (despite doubler cable, thus 1.0A not 0.5A), but theres' nothing > vital on that disk, it's just a scratch space for experiments, so > I'd like to reformat. Julian are you trying low-level format the drive (something I don't recommend) or just write a new filesystem (a much better approach)? I would look at mkfs/bsdlabel commands to remake the filesystem so you can mount it again. Actually you can probably run sysinstall and use the disk creation options to do the dirty work as well. -aps From jhs at berklix.org Thu Sep 4 21:00:11 2008 From: jhs at berklix.org (Julian Stacey) Date: Thu Sep 4 21:00:40 2008 Subject: how to format an ide hard disc in a usb enclosure In-Reply-To: Your message "Thu, 04 Sep 2008 16:51:14 EDT." <3c0b01820809041351lfedc31bla7ba0e3142c3fa85@mail.gmail.com> Message-ID: <200809042059.m84KxeQA010430@fire.js.berklix.net> Hi, Reference: > From: "Alexander Sack" > Date: Thu, 4 Sep 2008 16:51:14 -0400 > Message-id: <3c0b01820809041351lfedc31bla7ba0e3142c3fa85@mail.gmail.com> "Alexander Sack" wrote: > On Wed, Sep 3, 2008 at 6:33 PM, Julian Stacey wrote: > > Hi freebsd-scsi@, > > How does one reformat an IDE disc in a USB enclosure appearing on > > 7.0-Release via devd as /dev/ da0 da0s1 da0s1a da0s1c pass1 ? > > > > su > > camcontrol devlist > > at scbus2 target 0 lun 0 (pass0,cd0) > > at scbus3 target 0 lun 0 (pass1,da0) > > camcontrol format da0 > > You are about to REMOVE ALL DATA from the following device: > > camcontrol: scsiformat: error sending inquiry > > camcontrol format 3:0:0 > > You are about to REMOVE ALL DATA from the following device: > > camcontrol: scsiformat: error sending inquiry > > > > Should I be using something from ports/ ? eg > > > > cd /usr/ports/sysutils/smartmontools ... > > smartctl -i -T verypermissive /dev/da0 > > Device: USB 2.0 Storage Device Version: 0100 > >>> Terminate command early due to bad response to IEC mode page > > A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. > > > > cd /usr/ports/sysutils/sformat ... sformat -auto 0 0 3 > > ... > > Enter number of heads -1 (1 - 255)/: > > ... too many questions I dont know answer to, > > I just want to reformat whole device. > > > > Background > > Yes, perhaps as the disc is throwing errors, it might be dieing, > > &/or bad disc sector list might be full/ filling, but that doesn't > > worry me: I had to power cycle it rapidly while travelling, might > > have been the reason, &/or maybe USB hub didnt deliver enough power > > then (despite doubler cable, thus 1.0A not 0.5A), but theres' nothing > > vital on that disk, it's just a scratch space for experiments, so > > I'd like to reformat. > > Julian are you trying low-level format the drive Yes > (something I don't > recommend) I know, hence the background, yes I'm fully aware of all repercusions thanks :-) > or just write a new filesystem (a much better approach)? I Nope I Really want to low level formt. > would look at mkfs/bsdlabel commands to remake the filesystem so you > can mount it again. Actually you can probably run sysinstall and use > the disk creation options to do the dirty work as well. Yup, thanks good tip for other times, I do indeed use sysinstall some times, when I'm feeling lazy :-) This time I Really want to low level format though. Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From pisymbol at gmail.com Thu Sep 4 21:57:13 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Thu Sep 4 21:57:19 2008 Subject: how to format an ide hard disc in a usb enclosure In-Reply-To: <200809042059.m84KxeQA010430@fire.js.berklix.net> References: <3c0b01820809041351lfedc31bla7ba0e3142c3fa85@mail.gmail.com> <200809042059.m84KxeQA010430@fire.js.berklix.net> Message-ID: <3c0b01820809041457wc629c60i3b876b3895dc9e3d@mail.gmail.com> On Thu, Sep 4, 2008 at 4:59 PM, Julian Stacey wrote: > I know, hence the background, yes I'm fully aware of all repercusions thanks :-) Then if you understand IDE, understand what a low-level format really is (was), then you know that this is probably NOT what you want to do on your disk and understand it will NOT fix your problem. Other than some special vendor utility or BIOS utility, low-level format doesn't make sense for IDE disks. There is no command for "format" and trying to reset the geometry like the old days doesn't even apply to modern disks. If you want to try a low-level format tool (for IDE that is probably just writing 0's or 1's to every sector on the disk and letting the hard disk automatically map bad blocks), I would just dd all zero's to it then try to create a filesystem. If you still get media errors, your disk is foobar or about to be foobar, its cheap and you already stated you don't have any critical data on it so buy a new disk! :D In fact Seagate offers a Windows too to do exactly this called ZeroFill: http://www.seagate.com/ww/v/index.jsp?vgnextoid=65a8783c970ce010VgnVCM100000dd04090aRCRD&locale=en-GB Not trying to be too cheeky here, but I think what you are asking doesn't makes sense...at least to me.... Thanks! -aps From jhs at berklix.org Fri Sep 5 08:08:30 2008 From: jhs at berklix.org (Julian Stacey) Date: Fri Sep 5 08:08:39 2008 Subject: how to format an ide hard disc in a usb enclosure In-Reply-To: Your message "Thu, 04 Sep 2008 17:57:12 EDT." <3c0b01820809041457wc629c60i3b876b3895dc9e3d@mail.gmail.com> Message-ID: <200809050808.m8588BFx006299@fire.js.berklix.net> Hi, Reference: > From: "Alexander Sack" > Date: Thu, 4 Sep 2008 17:57:12 -0400 > Message-id: <3c0b01820809041457wc629c60i3b876b3895dc9e3d@mail.gmail.com> "Alexander Sack" wrote: > On Thu, Sep 4, 2008 at 4:59 PM, Julian Stacey wrote: > > I know, hence the background, yes I'm fully aware of all repercusions thanks :-) > > Then if you understand IDE, understand what a low-level format really > is (was), then you know that this is probably NOT what you want to do > on your disk and understand it will NOT fix your problem. > > Other than some special vendor utility or BIOS utility, low-level > format doesn't make sense for IDE disks. There is no command for > "format" and trying to reset the geometry like the old days doesn't > even apply to modern disks. > > If you want to try a low-level format tool (for IDE that is probably > just writing 0's or 1's to every sector on the disk and letting the > hard disk automatically map bad blocks), I would just dd all zero's to > it then try to create a filesystem. If you still get media errors, > your disk is foobar or about to be foobar, its cheap and you already > stated you don't have any critical data on it so buy a new disk! :D > > In fact Seagate offers a Windows too to do exactly this called ZeroFill: > > http://www.seagate.com/ww/v/index.jsp?vgnextoid=65a8783c970ce010VgnVCM100000dd04090aRCRD&locale=en-GB > > Not trying to be too cheeky here, but I think what you are asking > doesn't makes sense...at least to me.... > > Thanks! I do not run Windows, I run FreeBSD. Repeat: How can I low level format this dik under FreeBSD ? Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From lists at jnielsen.net Fri Sep 5 14:09:57 2008 From: lists at jnielsen.net (John Nielsen) Date: Fri Sep 5 14:10:10 2008 Subject: how to format an ide hard disc in a usb enclosure In-Reply-To: <200809050808.m8588BFx006299@fire.js.berklix.net> References: <200809050808.m8588BFx006299@fire.js.berklix.net> Message-ID: <200809050956.53652.lists@jnielsen.net> On Friday 05 September 2008, Julian Stacey wrote: > "Alexander Sack" wrote: > > On Thu, Sep 4, 2008 at 4:59 PM, Julian Stacey wrote: > > > I know, hence the background, yes I'm fully aware of all repercusions > > > thanks :-) > > > > Then if you understand IDE, understand what a low-level format really > > is (was), then you know that this is probably NOT what you want to do > > on your disk and understand it will NOT fix your problem. > > > > Other than some special vendor utility or BIOS utility, low-level > > format doesn't make sense for IDE disks. There is no command for > > "format" and trying to reset the geometry like the old days doesn't > > even apply to modern disks. > > > > If you want to try a low-level format tool (for IDE that is probably > > just writing 0's or 1's to every sector on the disk and letting the > > hard disk automatically map bad blocks), I would just dd all zero's to > > it then try to create a filesystem. If you still get media errors, > > your disk is foobar or about to be foobar, its cheap and you already > > stated you don't have any critical data on it so buy a new disk! :D > > > > In fact Seagate offers a Windows too to do exactly this called > > ZeroFill: > > > > http://www.seagate.com/ww/v/index.jsp?vgnextoid=65a8783c970ce010VgnVCM1 > >00000dd04090aRCRD&locale=en-GB > > > > Not trying to be too cheeky here, but I think what you are asking > > doesn't makes sense...at least to me.... > > I do not run Windows, I run FreeBSD. > Repeat: How can I low level format this dik under FreeBSD ? Alexander told you above. It's not a low-level format in the traditional (circa early 1990's) sense, but will have the same practical result on modern drives: dd all zero's to the disk. Specifically, something like the following will do the trick. I'm using da0 since that's what you mentioned in your original e-mail Make sure it's still the correct device.. dd if=/dev/zero of=/dev/da0 bs=1m The bs flag isn't mandatory but will let it run quite a bit faster than the default 512 bytes. If you then want to put a UFS2 filesystem on it, I'd suggest the following: fdisk -I /dev/da0 bsdlabel -w /dev/da0 newfs -L myscratchdisk /dev/da0s1a If you ever expect to want to boot from the drive, add a -B flag to the fdisk and bsdlabel commands. Supplying a label to newfs will make the filesystem show up by name under /dev/ufs/myscratchdisk (or whatever you call it) so you can mount it reliably even if the device node changes. JN From jhs at berklix.org Fri Sep 5 14:48:18 2008 From: jhs at berklix.org (Julian Stacey) Date: Fri Sep 5 14:49:42 2008 Subject: how to format an ide hard disc in a usb enclosure In-Reply-To: Your message "Fri, 05 Sep 2008 09:56:53 EDT." <200809050956.53652.lists@jnielsen.net> Message-ID: <200809051448.m85Em223012180@fire.js.berklix.net> Hi, Reference: > From: John Nielsen > Date: Fri, 5 Sep 2008 09:56:53 -0400 > Message-id: <200809050956.53652.lists@jnielsen.net> John Nielsen wrote: > On Friday 05 September 2008, Julian Stacey wrote: > > "Alexander Sack" wrote: > > > On Thu, Sep 4, 2008 at 4:59 PM, Julian Stacey wrote: > > > > I know, hence the background, yes I'm fully aware of all repercusions > > > > thanks :-) > > > > > > Then if you understand IDE, understand what a low-level format really > > > is (was), then you know that this is probably NOT what you want to do > > > on your disk and understand it will NOT fix your problem. > > > > > > Other than some special vendor utility or BIOS utility, low-level > > > format doesn't make sense for IDE disks. There is no command for > > > "format" and trying to reset the geometry like the old days doesn't > > > even apply to modern disks. > > > > > > If you want to try a low-level format tool (for IDE that is probably > > > just writing 0's or 1's to every sector on the disk and letting the > > > hard disk automatically map bad blocks), I would just dd all zero's to > > > it then try to create a filesystem. If you still get media errors, > > > your disk is foobar or about to be foobar, its cheap and you already > > > stated you don't have any critical data on it so buy a new disk! :D > > > > > > In fact Seagate offers a Windows too to do exactly this called > > > ZeroFill: > > > > > > http://www.seagate.com/ww/v/index.jsp?vgnextoid=65a8783c970ce010VgnVCM1 > > >00000dd04090aRCRD&locale=en-GB > > > > > > Not trying to be too cheeky here, but I think what you are asking > > > doesn't makes sense...at least to me.... > > > > I do not run Windows, I run FreeBSD. > > Repeat: How can I low level format this dik under FreeBSD ? > > Alexander told you above. It's not a low-level format in the traditional > (circa early 1990's) sense, but will have the same practical result on > modern drives: dd all zero's to the disk. > > Specifically, something like the following will do the trick. I'm using da0 > since that's what you mentioned in your original e-mail Make sure it's > still the correct device.. > dd if=/dev/zero of=/dev/da0 bs=1m > > The bs flag isn't mandatory but will let it run quite a bit faster than the > default 512 bytes. > > If you then want to put a UFS2 filesystem on it, I'd suggest the following: > fdisk -I /dev/da0 > bsdlabel -w /dev/da0 > newfs -L myscratchdisk /dev/da0s1a > > If you ever expect to want to boot from the drive, add a -B flag to the > fdisk and bsdlabel commands. Supplying a label to newfs will make the > filesystem show up by name under /dev/ufs/myscratchdisk (or whatever you > call it) so you can mount it reliably even if the device node changes. > > JN > Aargh ! Please, no more superficial responses', if people don't know: Don't answer ! Label & dd noise is Irrelevant. Facts: I want to _Format_ the hardware. Whether others personaly dont _reccomend_ that is irrelevant. FreeBSD Did used to support issuing SCSI commands to low level format a device, at least over scsi cable. IDE devices do support low level format, whether others approve or not, I've `low level (*)' formatted both IDE & SCSI disks lots of times over decades, using eg adapter cards, DOS progs etc, & yes FreeBSD too for scsi (once was a command scsiformat I recall too). Thanks to both for trying, but I still hope for a 1st usefull response. Repeat: Can FreeBSD generate & pass scsi commands over USB that a ISB to IDE enclosure will take & use to format. (*) 'Low Level:' Even the term indicates wrong thinking. 'Format' to people of my background automatically means low level. Prepending 'low level' is just verbiage pandering to [ex] MS community too ignorant to know format for them just meant (on a hard disc) creating an FS, blather about `low level' allows others to distract to labels & personal recomendations etc. I want to _Format_ the disk !! Can FreeBSD do it ? How ? Or must one take disk out of USB enclosure & attach a laptop- to- 3.5"- IDE- size- adapter to format ? Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From westr at connection.ca Fri Sep 5 14:59:10 2008 From: westr at connection.ca (Ross) Date: Fri Sep 5 14:59:16 2008 Subject: how to format an ide hard disc in a usb enclosure In-Reply-To: <200809051448.m85Em223012180@fire.js.berklix.net> References: Your message "Fri, 05 Sep 2008 09:56:53 EDT." <200809050956.53652.lists@jnielsen.net> <200809051448.m85Em223012180@fire.js.berklix.net> Message-ID: <1741743380.20080905105705@connection.ca> JS> Thanks to both for trying, but I still hope for a 1st usefull response. JS> Repeat: Can FreeBSD generate & pass scsi commands JS> over USB that a ISB to IDE enclosure will take & use to format. Do you know about "camcontrol" - it allows you to issue pretty well any scsi command to devices. Whether it'll do it over a usb device, I don't know - I've never tried. Ross. -- From jhs at berklix.org Fri Sep 5 15:18:47 2008 From: jhs at berklix.org (Julian Stacey) Date: Fri Sep 5 15:18:53 2008 Subject: how to format an ide hard disc in a usb enclosure In-Reply-To: Your message "Fri, 05 Sep 2008 10:57:05 EDT." <1741743380.20080905105705@connection.ca> Message-ID: <200809051518.m85FILKc012983@fire.js.berklix.net> Hi, Reference: > From: Ross > Reply-to: Ross > Date: Fri, 5 Sep 2008 10:57:05 -0400 > Message-id: <1741743380.20080905105705@connection.ca> Ross wrote: > > JS> Thanks to both for trying, but I still hope for a 1st usefull response. > JS> Repeat: Can FreeBSD generate & pass scsi commands > JS> over USB that a ISB to IDE enclosure will take & use to format. > > Do you know about "camcontrol" - it allows you to issue pretty well > any scsi command to devices. > > Whether it'll do it over a usb device, I don't know - I've never > tried. Thanks Ross, per my original post: camcontrol format da0 You are about to REMOVE ALL DATA from the following device: camcontrol: scsiformat: error sending inquiry camcontrol format 3:0:0 You are about to REMOVE ALL DATA from the following device: camcontrol: scsiformat: error sending inquiry yes I tried it, though I'm not experienced with it either, I'm hoping someone here on scsi@ might know if it shoudl work over USB bus (or if no one knows I could later ask on usb@ list. Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From lists at jnielsen.net Fri Sep 5 16:11:43 2008 From: lists at jnielsen.net (John Nielsen) Date: Fri Sep 5 16:11:50 2008 Subject: how to format an ide hard disc in a usb enclosure In-Reply-To: <200809051518.m85FILKc012983@fire.js.berklix.net> References: <200809051518.m85FILKc012983@fire.js.berklix.net> Message-ID: <200809051212.29727.lists@jnielsen.net> On Friday 05 September 2008, Julian Stacey wrote: > Hi, > > Reference: > > From: Ross > > Reply-to: Ross > > Date: Fri, 5 Sep 2008 10:57:05 -0400 > > Message-id: <1741743380.20080905105705@connection.ca> > > Ross wrote: > > JS> Thanks to both for trying, but I still hope for a 1st usefull > > response. JS> Repeat: Can FreeBSD generate & pass scsi commands > > JS> over USB that a ISB to IDE enclosure will take & use to format. > > > > Do you know about "camcontrol" - it allows you to issue pretty well > > any scsi command to devices. > > > > Whether it'll do it over a usb device, I don't know - I've never > > tried. > > Thanks Ross, > per my original post: > camcontrol format da0 > You are about to REMOVE ALL DATA from the following device: > camcontrol: scsiformat: error sending inquiry > camcontrol format 3:0:0 > You are about to REMOVE ALL DATA from the following device: > camcontrol: scsiformat: error sending inquiry > > yes I tried it, though I'm not experienced with it either, > I'm hoping someone here on scsi@ might know if it shoudl work over USB > bus (or if no one knows I could later ask on usb@ list. Might require a custom kernel (to remove umass), but you could try atausb instead to give you a more native interface to the drive. What you'd do to format it from there I'm not sure but perhaps you know. JN From pisymbol at gmail.com Sat Sep 6 14:05:27 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Sat Sep 6 14:05:34 2008 Subject: how to format an ide hard disc in a usb enclosure In-Reply-To: <200809051448.m85Em223012180@fire.js.berklix.net> References: <200809050956.53652.lists@jnielsen.net> <200809051448.m85Em223012180@fire.js.berklix.net> Message-ID: <3c0b01820809060705p74261c59s9f5e97a5e0a6a28c@mail.gmail.com> On Fri, Sep 5, 2008 at 10:48 AM, Julian Stacey wrote: > Aargh ! Please, no more superficial responses', if people don't > know: Don't answer ! Label & dd noise is Irrelevant. Facts: I > want to _Format_ the hardware. Whether others personaly dont > _reccomend_ that is irrelevant. > > FreeBSD Did used to support issuing SCSI commands to low level > format a device, at least over scsi cable. IDE devices do support > low level format, whether others approve or not, I've `low level > (*)' formatted both IDE & SCSI disks lots of times over decades, > using eg adapter cards, DOS progs etc, & yes FreeBSD too for scsi > (once was a command scsiformat I recall too). Its not superficial, IDE does not support the *format* command. Check the ATA spec: http://www.real-world-systems.com/docs/e07163r2-Comments_on_ATA8-ACS_revision_4a.pdf.gz (or T13.org AT Group etc.) THERE IS NO FORMAT COMMAND. Check the spec, there is nothing *superficial* in what we are saying to you. Using camcontrol to send SCSI CDBs to an IDE disk is not going to work (it speaks ATA not SCSI). This is what we are trying to tell you. This isn't a BSD issue, this isn't an OS issue, this isn't a USB issue (go ahead ask, you will get the same answer), this is a hard disk issue in terms of what IDE supports. The old days of low-level format are now buried with the manufacturer and not available to the OS/system software. Low-level format for IDE is only achieved via a special vendor utility that can low-level format it and reset the partition geometry. No modern drive from a modern manufacturer is going to make that utility freely available (and it doesn't speak IDE either its probably at the firmware level of the drive, i.e. this would be a BIOS utility). Whether you use umass, atausb, or some magical driver you write, there is no command to send to this drive to "low-level format" it. Technically speaking if the USB enclosure was made by the hard disk manufacturer and could talk to the drive at its firmware level then I suppose you could send a SCSI CDB via USB umass which would get magically translated/converted to do the *right* vendor specific thing....you see how far-fetched this is? We are trying to save you some time and energy on an endeavor that makes no TECHNICAL sense! :D Thanks! -aps From bugmaster at FreeBSD.org Mon Sep 8 02:22:27 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 8 02:24:10 2008 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200809080222.m882MQuH006806@freefall.freebsd.org> The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/126866 scsi [isp] [panic] kernel panic on card initialization o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 26 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From kolpanen at kearfott.com Tue Sep 9 21:28:18 2008 From: kolpanen at kearfott.com (Dennis R. Kolpanen) Date: Tue Sep 9 21:28:24 2008 Subject: iscsi initiator - system hang Message-ID: <20080909211532.GA16009@qads.kearfott.com> On a FreeBSD 7.0 system, certain commands issued against any of the three mounted iscsi drives causes the system to "hang". In this context, hang means: the system continues to respond to pings sendmail stops accepting connections imapd stops accepting connections sshd stops accepting connections shell sessions already established stop accepting commands login at the system console is not possible The problem has been caused, so far, by dump, restore, and pax. These commands work perfectly if they are directed against one of the internal drives and not the iscsi drives. The failures noted above do not normally happen immediately after issuing one of these commands. The problems seem to build over a period of minutes or tens of minutes. Note that the dump/restore/pax commands can take hours to run. Nothing is written to the system console or any of the log files indicating a problem. The only way to recover from the hang is by means of the hardware reset button. When the system was first being set up and no other users were on it, shutting down all but one of the CPUs by means of sysctl and "machdep.hlt_cpus" allowed restoring about 150gb to the three iscsi drives. Once the machine was placed into production, massive hardware problems on an old server required this to be done immediately, this trick no longer works. An overview of the hardware involved: dual, quad-core Intel Xeon processors 16 gb RAM FreeBSD 7.0 amd64 release NetworkAppliance FAS2020 SAN generic kernel A complete dmesg output can be provided if desired. By default, iscontrol creates the iscsi drives with the number of tags set to one. The performance of the iscsi drives with this default setting was quite poor. Based on a recommendation made on a mailing list some time ago, /etc/iscsi.conf was changed to set the tags to 128. This had a dramatic improvement on the iscsi performance. Testing on the system that was rushed into production is not really possible. However, within the next week or so, a nearly identical system should become available and this one could be used for testing. Any ideas on what could be wrong? Any solutions? Thanks for your help. Dennis R. Kolpanen From danny at cs.huji.ac.il Wed Sep 10 07:01:07 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Sep 10 07:01:14 2008 Subject: iscsi initiator - system hang In-Reply-To: <20080909211532.GA16009@qads.kearfott.com> References: <20080909211532.GA16009@qads.kearfott.com> Message-ID: > On a FreeBSD 7.0 system, certain commands issued against any of the > three mounted iscsi drives causes the system to "hang". In this > context, hang means: > > the system continues to respond to pings > sendmail stops accepting connections > imapd stops accepting connections > sshd stops accepting connections > shell sessions already established stop accepting commands > login at the system console is not possible > > The problem has been caused, so far, by dump, restore, and pax. These > commands work perfectly if they are directed against one of the > internal drives and not the iscsi drives. The failures noted above do > not normally happen immediately after issuing one of these commands. > The problems seem to build over a period of minutes or tens of > minutes. Note that the dump/restore/pax commands can take hours to > run. > > Nothing is written to the system console or any of the log files > indicating a problem. The only way to recover from the hang is by > means of the hardware reset button. > > When the system was first being set up and no other users were on it, > shutting down all but one of the CPUs by means of sysctl and > "machdep.hlt_cpus" allowed restoring about 150gb to the three iscsi > drives. Once the machine was placed into production, massive hardware > problems on an old server required this to be done immediately, this > trick no longer works. > > An overview of the hardware involved: > > dual, quad-core Intel Xeon processors > 16 gb RAM FreeBSD 7.0 amd64 release > NetworkAppliance FAS2020 SAN > generic kernel > > A complete dmesg output can be provided if desired. > > By default, iscontrol creates the iscsi drives with the number of tags > set to one. The performance of the iscsi drives with this default > setting was quite poor. Based on a recommendation made on a mailing > list some time ago, /etc/iscsi.conf was changed to set the tags to > 128. This had a dramatic improvement on the iscsi performance. > > Testing on the system that was rushed into production is not really > possible. However, within the next week or so, a nearly identical > system should become available and this one could be used for testing. > > Any ideas on what could be wrong? Any solutions? > maybe, but first, can you send me the output of 'sysctl net.iscsi'? danny > Thanks for your help. > > Dennis R. Kolpanen > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From kolpanen at kearfott.com Wed Sep 10 11:52:28 2008 From: kolpanen at kearfott.com (Dennis R. Kolpanen) Date: Wed Sep 10 11:52:34 2008 Subject: iscsi initiator - system hang In-Reply-To: References: <20080909211532.GA16009@qads.kearfott.com> Message-ID: <20080910115159.GA28900@qads.kearfott.com> On Wed, Sep 10, 2008 at 09:32:01AM +0300, Danny Braniss wrote: > > On a FreeBSD 7.0 system, certain commands issued against any of the > > three mounted iscsi drives causes the system to "hang". In this > > context, hang means: > > > > the system continues to respond to pings > > sendmail stops accepting connections > > imapd stops accepting connections > > sshd stops accepting connections > > shell sessions already established stop accepting commands > > login at the system console is not possible > > > > The problem has been caused, so far, by dump, restore, and pax. These > > commands work perfectly if they are directed against one of the > > internal drives and not the iscsi drives. The failures noted above do > > not normally happen immediately after issuing one of these commands. > > The problems seem to build over a period of minutes or tens of > > minutes. Note that the dump/restore/pax commands can take hours to > > run. > > > > Nothing is written to the system console or any of the log files > > indicating a problem. The only way to recover from the hang is by > > means of the hardware reset button. > > > > When the system was first being set up and no other users were on it, > > shutting down all but one of the CPUs by means of sysctl and > > "machdep.hlt_cpus" allowed restoring about 150gb to the three iscsi > > drives. Once the machine was placed into production, massive hardware > > problems on an old server required this to be done immediately, this > > trick no longer works. > > > > An overview of the hardware involved: > > > > dual, quad-core Intel Xeon processors > > 16 gb RAM FreeBSD 7.0 amd64 release > > NetworkAppliance FAS2020 SAN > > generic kernel > > > > A complete dmesg output can be provided if desired. > > > > By default, iscontrol creates the iscsi drives with the number of tags > > set to one. The performance of the iscsi drives with this default > > setting was quite poor. Based on a recommendation made on a mailing > > list some time ago, /etc/iscsi.conf was changed to set the tags to > > 128. This had a dramatic improvement on the iscsi performance. > > > > Testing on the system that was rushed into production is not really > > possible. However, within the next week or so, a nearly identical > > system should become available and this one could be used for testing. > > > > Any ideas on what could be wrong? Any solutions? > > > > maybe, but first, can you send me the output of 'sysctl net.iscsi'? > > danny > Danny, No problem. Here it is: net.iscsi.driver_version: 2.0.99 net.iscsi.isid: DIB00 net.iscsi.sessions: 1 net.iscsi.0.targetname: iqn.1992-08.com.netapp:sn.135029528 net.iscsi.0.targeaddress: 10.172.172.1 net.iscsi.0.stats: recv=1288005 sent=1287999 flags=0x0000011b pdus-alloc=0 pdus-max=220 cws=64 cmd=afa32 exp=afa32 max=afa71 stat=afa32 itt=afa32 net.iscsi.0.pid: 916 Thanks. Dennis From bugmaster at FreeBSD.org Mon Sep 15 15:18:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 15 15:20:57 2008 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200809151518.m8FFItrB019021@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/126866 scsi [isp] [panic] kernel panic on card initialization o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 26 problems total. From westr at connection.ca Mon Sep 15 16:10:05 2008 From: westr at connection.ca (Ross West) Date: Mon Sep 15 16:10:10 2008 Subject: kern/126866: [isp] [panic] kernel panic on card initialization Message-ID: <200809151610.m8FGA4Jh025158@freefall.freebsd.org> The following reply was made to PR kern/126866; it has been noted by GNATS. From: Ross West To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/126866: [isp] [panic] kernel panic on card initialization Date: Mon, 15 Sep 2008 11:42:59 -0400 Bug solved: issue is with the driver not doing a reset of the HBA before attempting to read the firmware version from the HBA mailbox and getting a different response than expected. Patch that appears to fix the issue by doing the HBA reset first, then full card initialization. Many thanks to Alexander Sack (pisymbol@gmail.com) for the hard work in finding the proper solution. Patch as follows: -= start --- isp.c 2008-09-02 12:45:07.000000000 -0400 +++ isp.c.0 2008-09-02 11:06:55.000000000 -0400 @@ -171,61 +171,6 @@ isp->isp_state = ISP_NILSTATE; - /* - * Basic types (SCSI, FibreChannel and PCI or SBus) - * have been set in the MD code. We figure out more - * here. Possibly more refined types based upon PCI - * identification. Chip revision has been gathered. - * - * After we've fired this chip up, zero out the conf1 register - * for SCSI adapters and do other settings for the 2100. - */ - - /* - * Get the current running firmware revision out of the - * chip before we hit it over the head (if this is our - * first time through). Note that we store this as the - * 'ROM' firmware revision- which it may not be. In any - * case, we don't really use this yet, but we may in - * the future. - */ - if (isp->isp_touched == 0) { - /* - * First see whether or not we're sitting in the ISP PROM. - * If we've just been reset, we'll have the string "ISP " - * spread through outgoing mailbox registers 1-3. We do - * this for PCI cards because otherwise we really don't - * know what state the card is in and we could hang if - * we try this command otherwise. - * - * For SBus cards, we just do this because they almost - * certainly will be running firmware by now. - */ - if (ISP_READ(isp, OUTMAILBOX1) != 0x4953 || - ISP_READ(isp, OUTMAILBOX2) != 0x5020 || - ISP_READ(isp, OUTMAILBOX3) != 0x2020) { - /* - * Just in case it was paused... - */ - if (IS_24XX(isp)) { - ISP_WRITE(isp, BIU2400_HCCR, - HCCR_2400_CMD_RELEASE); - } else { - ISP_WRITE(isp, HCCR, HCCR_CMD_RELEASE); - } - MEMZERO(&mbs, sizeof (mbs)); - mbs.param[0] = MBOX_ABOUT_FIRMWARE; - mbs.logval = MBLOGNONE; - isp_mboxcmd(isp, &mbs); - if (mbs.param[0] == MBOX_COMMAND_COMPLETE) { - isp->isp_romfw_rev[0] = mbs.param[1]; - isp->isp_romfw_rev[1] = mbs.param[2]; - isp->isp_romfw_rev[2] = mbs.param[3]; - } - } - isp->isp_touched = 1; - } - ISP_DISABLE_INTS(isp); /* @@ -254,7 +199,6 @@ return; } - /* * Set up default request/response queue in-pointer/out-pointer * register indices. @@ -680,7 +624,6 @@ ISP_WRITE(isp, isp->isp_respinrp, 0); ISP_WRITE(isp, isp->isp_respoutrp, 0); - /* * Do MD specific post initialization */ @@ -706,6 +649,52 @@ } } } + + /* + * Basic types (SCSI, FibreChannel and PCI or SBus) + * have been set in the MD code. We figure out more + * here. Possibly more refined types based upon PCI + * identification. Chip revision has been gathered. + * + * After we've fired this chip up, zero out the conf1 register + * for SCSI adapters and do other settings for the 2100. + */ + if (isp->isp_touched == 0) { + /* + * First see whether or not we're sitting in the ISP PROM. + * If we've just been reset, we'll have the string "ISP " + * spread through outgoing mailbox registers 1-3. We do + * this for PCI cards because otherwise we really don't + * know what state the card is in and we could hang if + * we try this command otherwise. + * + * For SBus cards, we just do this because they almost + * certainly will be running firmware by now. + */ + if (ISP_READ(isp, OUTMAILBOX1) != 0x4953 || + ISP_READ(isp, OUTMAILBOX2) != 0x5020 || + ISP_READ(isp, OUTMAILBOX3) != 0x2020) { + /* + * Just in case it was paused... + */ + if (IS_24XX(isp)) { + ISP_WRITE(isp, BIU2400_HCCR, + HCCR_2400_CMD_RELEASE); + } else { + ISP_WRITE(isp, HCCR, HCCR_CMD_RELEASE); + } + MEMZERO(&mbs, sizeof (mbs)); + mbs.param[0] = MBOX_ABOUT_FIRMWARE; + mbs.logval = MBLOGNONE; + isp_mboxcmd(isp, &mbs); + if (mbs.param[0] == MBOX_COMMAND_COMPLETE) { + isp->isp_romfw_rev[0] = mbs.param[1]; + isp->isp_romfw_rev[1] = mbs.param[2]; + isp->isp_romfw_rev[2] = mbs.param[3]; + } + } + isp->isp_touched = 1; + } /* * Up until this point we've done everything by just reading or -= end From pisymbol at gmail.com Mon Sep 15 21:34:04 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Mon Sep 15 21:34:11 2008 Subject: kern/126866: [isp] [panic] kernel panic on card initialization In-Reply-To: <200809151610.m8FGA4Jh025158@freefall.freebsd.org> References: <200809151610.m8FGA4Jh025158@freefall.freebsd.org> Message-ID: <3c0b01820809151434g61caec66s44c87e122ce786b2@mail.gmail.com> Ross: On Mon, Sep 15, 2008 at 12:10 PM, Ross West wrote: > The following reply was made to PR kern/126866; it has been noted by GNATS. > > From: Ross West > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/126866: [isp] [panic] kernel panic on card initialization > Date: Mon, 15 Sep 2008 11:42:59 -0400 > > Bug solved: issue is with the driver not doing a reset of the HBA > before attempting to read the firmware version from the HBA mailbox > and getting a different response than expected. > > Patch that appears to fix the issue by doing the HBA reset first, then > full card initialization. > > Many thanks to Alexander Sack (pisymbol@gmail.com) for the hard work > in finding the proper solution. > > Patch as follows: > -= start > --- isp.c 2008-09-02 12:45:07.000000000 -0400 > +++ isp.c.0 2008-09-02 11:06:55.000000000 -0400 > @@ -171,61 +171,6 @@ > > isp->isp_state = ISP_NILSTATE; > > - /* > - * Basic types (SCSI, FibreChannel and PCI or SBus) > - * have been set in the MD code. We figure out more > - * here. Possibly more refined types based upon PCI > - * identification. Chip revision has been gathered. > - * > - * After we've fired this chip up, zero out the conf1 register > - * for SCSI adapters and do other settings for the 2100. > - */ > - > - /* > - * Get the current running firmware revision out of the > - * chip before we hit it over the head (if this is our > - * first time through). Note that we store this as the > - * 'ROM' firmware revision- which it may not be. In any > - * case, we don't really use this yet, but we may in > - * the future. > - */ > - if (isp->isp_touched == 0) { > - /* > - * First see whether or not we're sitting in the ISP PROM. > - * If we've just been reset, we'll have the string "ISP " > - * spread through outgoing mailbox registers 1-3. We do > - * this for PCI cards because otherwise we really don't > - * know what state the card is in and we could hang if > - * we try this command otherwise. > - * > - * For SBus cards, we just do this because they almost > - * certainly will be running firmware by now. > - */ > - if (ISP_READ(isp, OUTMAILBOX1) != 0x4953 || > - ISP_READ(isp, OUTMAILBOX2) != 0x5020 || > - ISP_READ(isp, OUTMAILBOX3) != 0x2020) { > - /* > - * Just in case it was paused... > - */ > - if (IS_24XX(isp)) { > - ISP_WRITE(isp, BIU2400_HCCR, > - HCCR_2400_CMD_RELEASE); > - } else { > - ISP_WRITE(isp, HCCR, HCCR_CMD_RELEASE); > - } > - MEMZERO(&mbs, sizeof (mbs)); > - mbs.param[0] = MBOX_ABOUT_FIRMWARE; > - mbs.logval = MBLOGNONE; > - isp_mboxcmd(isp, &mbs); > - if (mbs.param[0] == MBOX_COMMAND_COMPLETE) { > - isp->isp_romfw_rev[0] = mbs.param[1]; > - isp->isp_romfw_rev[1] = mbs.param[2]; > - isp->isp_romfw_rev[2] = mbs.param[3]; > - } > - } > - isp->isp_touched = 1; > - } > - > ISP_DISABLE_INTS(isp); > > /* > @@ -254,7 +199,6 @@ > return; > } > > - > /* > * Set up default request/response queue in-pointer/out-pointer > * register indices. > @@ -680,7 +624,6 @@ > ISP_WRITE(isp, isp->isp_respinrp, 0); > ISP_WRITE(isp, isp->isp_respoutrp, 0); > > - > /* > * Do MD specific post initialization > */ > @@ -706,6 +649,52 @@ > } > } > } > + > + /* > + * Basic types (SCSI, FibreChannel and PCI or SBus) > + * have been set in the MD code. We figure out more > + * here. Possibly more refined types based upon PCI > + * identification. Chip revision has been gathered. > + * > + * After we've fired this chip up, zero out the conf1 register > + * for SCSI adapters and do other settings for the 2100. > + */ > + if (isp->isp_touched == 0) { > + /* > + * First see whether or not we're sitting in the ISP PROM. > + * If we've just been reset, we'll have the string "ISP " > + * spread through outgoing mailbox registers 1-3. We do > + * this for PCI cards because otherwise we really don't > + * know what state the card is in and we could hang if > + * we try this command otherwise. > + * > + * For SBus cards, we just do this because they almost > + * certainly will be running firmware by now. > + */ > + if (ISP_READ(isp, OUTMAILBOX1) != 0x4953 || > + ISP_READ(isp, OUTMAILBOX2) != 0x5020 || > + ISP_READ(isp, OUTMAILBOX3) != 0x2020) { > + /* > + * Just in case it was paused... > + */ > + if (IS_24XX(isp)) { > + ISP_WRITE(isp, BIU2400_HCCR, > + HCCR_2400_CMD_RELEASE); > + } else { > + ISP_WRITE(isp, HCCR, HCCR_CMD_RELEASE); > + } > + MEMZERO(&mbs, sizeof (mbs)); > + mbs.param[0] = MBOX_ABOUT_FIRMWARE; > + mbs.logval = MBLOGNONE; > + isp_mboxcmd(isp, &mbs); > + if (mbs.param[0] == MBOX_COMMAND_COMPLETE) { > + isp->isp_romfw_rev[0] = mbs.param[1]; > + isp->isp_romfw_rev[1] = mbs.param[2]; > + isp->isp_romfw_rev[2] = mbs.param[3]; > + } > + } > + isp->isp_touched = 1; > + } > I have more patches and that's why I haven't submitted them formally. Was going to run it by jkim (friend and colleague) as well. We have some other issues: - 6.x tree won't load any firmware because the code was removed (I have a patch to put it back for <7.x releases) in favor of the generic firmware stuff (but that doesn't work on 6.x to my knowledge) - I'm surprised no one has reported this, if so point me to the bugzilla so we can clean up - the above line has to be trimmed, the check for 0x2020 is WRONG since that is checking for the ISP ID (2422, 2312, etc.) - I discovered that late last week - have to revise slightly the above patch since the ABOUT FIRMWARE command really doesn't do anything after the ISP has been reset and the firmware hasn't been executed (its harmless but needs to be moved out there) - there are some target mode panics running around that I have not had a chance to look at (damn day job) - maybe they should be new bugzilla's (I'll ask the parties involved to file some) - don't try to load the isp_*_it versions of firmware for any FC release (need to incorporate that as well) Can I have a couple of days to send in a revised patch to fix the above issue as well as some others? It would be good for 6.x and 7 (haven't tested it against HEAD). Sorry for being silent about this, I meant to update the incident myself, just swamped with other stuff right now!!! :D -aps From danny at cs.huji.ac.il Tue Sep 16 13:14:12 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Sep 16 13:16:05 2008 Subject: PERC6/i/e cli Message-ID: hi, mfi is ok, mfi0@pci0:1:0:0: class=0x010400 card=0x1f0c1028 chip=0x00601000 rev=0x04 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS1078 PCI-X Fusion-MPT SAS' class = mass storage subclass = RAID mfi1@pci0:10:0:0: class=0x010400 card=0x1f0a1028 chip=0x00601000 rev=0x04 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS1078 PCI-X Fusion-MPT SAS' class = mass storage subclass = RAID ... mfi0: port 0xec00-0xecff mem 0xfc980000-0xfc9bffff,0xfc940000-0xf c97ffff irq 16 at device 0.0 on pci1 mfi0: Megaraid SAS driver Ver 2.00 mfi0: [ITHREAD] pcib8: at device 4.0 on pci0 pci10: on pcib8 mfi1: port 0xdc00-0xdcff mem 0xfc780000-0xfc7bffff,0xfc740000-0xf c77ffff irq 16 at device 0.0 on pci10 mfi1: Megaraid SAS driver Ver 2.00 mfi1: [ITHREAD] ... mfid0: on mfi0 mfid0: 953344MB (1952448512 sectors) RAID volume '' is optimal mfid1: on mfi1 mfid1: 13346816MB (27334279168 sectors) RAID volume '' is optimal but megacli does not talk to it, am I missing something, or is there another cli that does work? thanks, danny From westr at connection.ca Tue Sep 16 13:27:26 2008 From: westr at connection.ca (Ross) Date: Tue Sep 16 13:31:19 2008 Subject: kern/126866: [isp] [panic] kernel panic on card initialization In-Reply-To: <3c0b01820809151434g61caec66s44c87e122ce786b2@mail.gmail.com> References: <200809151610.m8FGA4Jh025158@freefall.freebsd.org> <3c0b01820809151434g61caec66s44c87e122ce786b2@mail.gmail.com> Message-ID: <56802665.20080916092725@connection.ca> AS> Can I have a couple of days to send in a revised patch to fix the AS> above issue as well as some others? AS> It would be good for 6.x and 7 (haven't tested it against HEAD). AS> Sorry for being silent about this, I meant to update the incident AS> myself, just swamped with other stuff right now!!! :D Whoops! I was just cleaning up my "mess" (open pr), so please go ahead and do what you've got planned when you're able to, since it's much more complete. Cheers, Ross. From stefan.lambrev at moneybookers.com Tue Sep 16 13:49:58 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue Sep 16 13:51:56 2008 Subject: PERC6/i/e cli In-Reply-To: References: Message-ID: <48CFB56D.3070908@moneybookers.com> Greetings, Danny Braniss wrote: > hi, mfi is ok, > > mfi0@pci0:1:0:0: class=0x010400 card=0x1f0c1028 chip=0x00601000 > rev=0x04 hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > device = 'SAS1078 PCI-X Fusion-MPT SAS' > class = mass storage > subclass = RAID > mfi0@pci0:1:0:0: class=0x010400 card=0x1f0c1028 chip=0x00601000 rev=0x04 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS1078 PCI-X Fusion-MPT SAS' class = mass storage subclass = RAID (exactly the same model) and linux-megacli-1.01.40_1 works well with it. (freebsd 7 - amd64) If you search the mailing lists you will find that similar problems can happen if modules are not loaded in the proper way. I have in /boot/loader.conf: linux_load="YES" mfi_linux_load="YES" which loads: linux.ko mfi_linux.ko and also: (because of fstab) linprocfs.ko linsysfs.ko Then you can put in your periodic.conf - daily_status_mfi_raid_enable="YES" and you will receive in your daily mails something like: Virtual Drive Information: VD DRV RLP RLS RLQ STS SIZE STATE NAME 0 2 1 0 0 64kB 139392MB Optimal Ah and btw I think it was mandatory to have compat.linux.osrelease=2.6.12 (2.6.16 works too but you have to fix the script to not complain - i think the port is still not fixed?) > mfi1@pci0:10:0:0: class=0x010400 card=0x1f0a1028 chip=0x00601000 > rev=0x04 hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > device = 'SAS1078 PCI-X Fusion-MPT SAS' > class = mass storage > subclass = RAID > > ... > mfi0: port 0xec00-0xecff mem 0xfc980000-0xfc9bffff,0xfc940000-0xf > c97ffff irq 16 at device 0.0 on pci1 > mfi0: Megaraid SAS driver Ver 2.00 > mfi0: [ITHREAD] > pcib8: at device 4.0 on pci0 > pci10: on pcib8 > mfi1: port 0xdc00-0xdcff mem 0xfc780000-0xfc7bffff,0xfc740000-0xf > c77ffff irq 16 at device 0.0 on pci10 > mfi1: Megaraid SAS driver Ver 2.00 > mfi1: [ITHREAD] > ... > mfid0: on mfi0 > mfid0: 953344MB (1952448512 sectors) RAID volume '' is optimal > mfid1: on mfi1 > mfid1: 13346816MB (27334279168 sectors) RAID volume '' is optimal > > but megacli does not talk to it, am I missing something, or is there another > cli that does work? > > thanks, > danny > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From danny at cs.huji.ac.il Tue Sep 16 14:40:01 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Sep 16 14:40:07 2008 Subject: PERC6/i/e cli In-Reply-To: <48CFB56D.3070908@moneybookers.com> References: <48CFB56D.3070908@moneybookers.com> Message-ID: > Greetings, > > Danny Braniss wrote: > > hi, mfi is ok, > > > > mfi0@pci0:1:0:0: class=0x010400 card=0x1f0c1028 chip=0x00601000 > > rev=0x04 hdr=0x00 > > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > > device = 'SAS1078 PCI-X Fusion-MPT SAS' > > class = mass storage > > subclass = RAID > > > > mfi0@pci0:1:0:0: class=0x010400 card=0x1f0c1028 chip=0x00601000 > rev=0x04 hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > device = 'SAS1078 PCI-X Fusion-MPT SAS' > class = mass storage > subclass = RAID > (exactly the same model) > and linux-megacli-1.01.40_1 works well with it. (freebsd 7 - amd64) > > If you search the mailing lists you will find that similar problems can > happen if > modules are not loaded in the proper way. > > I have in /boot/loader.conf: > linux_load="YES" > mfi_linux_load="YES" > > which loads: > linux.ko > mfi_linux.ko > and also: (because of fstab) > linprocfs.ko > linsysfs.ko > > Then you can put in your periodic.conf - daily_status_mfi_raid_enable="YES" > and you will receive in your daily mails something like: > > Virtual Drive Information: > VD DRV RLP RLS RLQ STS SIZE STATE NAME > 0 2 1 0 0 64kB 139392MB Optimal > > Ah and btw I think it was mandatory to have compat.linux.osrelease=2.6.12 > (2.6.16 works too but you have to fix the script to not complain - i > think the port is still not fixed?) > Ah, the order does affect the result! great, it now works for me too. thanks! > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > From jselwitz at vvisions.com Tue Sep 16 15:03:35 2008 From: jselwitz at vvisions.com (Jason Selwitz) Date: Tue Sep 16 15:07:14 2008 Subject: scsi errors when trying to move tapes. Message-ID: <48CFC480.804@vvisions.com> Hi there , I was hoping someone here could tell me if I was missing something.. here is the story. I am running a FreeBSD 7.0 server with a Qlogic 2460 FC HBA installed and directl connected t othe HBA is a Spectra Logic Tape library, the Library contains 50 slots, one picker and one IBM Ultrium LTO-4 drive. the system boots and ercognizes all of the hardware however the isp drive sees the Qlogic card as a 2432 see below. isp0: port 0x5000-0x50ff mem 0xc6ffc000-0xc6ffffff irq 19 at device 0.0 on pci7 sa0 at isp0 bus 0 target 0 lun 0 sa0: Removable Sequential Access SCSI-3 device sa0: 400.000MB/s transfers sa0: Command Queueing Enabled ch0 at isp0 bus 0 target 0 lun 1 ch0: Removable Changer SCSI-3 device ch0: 400.000MB/s transfers ch0: Command Queueing Enabled ch0: 50 slots, 1 drive, 1 picker, 0 portals For some reason I can query status and get Barcode information back from the changer with both chio and mtx however when I try to move media into the drive I get errors see below. valbbacula# camcontrol devlist at scbus0 target 0 lun 0 (sa0,pass0) at scbus0 target 0 lun 1 (ch0,pass1) vvalbbacula# chio params /dev/ch0: 50 slots, 1 drive, 1 picker /dev/ch0: current picker: 0 vvalbbacula# chio status -a picker 0: sense: <0x00/0x00> voltag: <:0> avoltag: <:0> source: <> intaddr: <1> scsi: slot 0: sense: <0x00/0x00> voltag: <027734L4:8224> avoltag: <:0> source: <> intaddr: <4096> scsi: slot 1: sense: <0x00/0x00> voltag: <027733L4:8224> avoltag: <:0> source: <> intaddr: <4097> scsi: slot 2: sense: <0x00/0x00> voltag: <027732L4:8224> avoltag: <:0> source: <> intaddr: <4098> scsi: slot 3: sense: <0x00/0x00> voltag: <027731L4:8224> avoltag: <:0> source: <> intaddr: <4099> scsi: slot 4: sense: <0x00/0x00> voltag: <027730L4:8224> avoltag: <:0> source: <> intaddr: <4100> scsi: slot 5: sense: <0x00/0x00> voltag: <027739L4:8224> avoltag: <:0> source: <> intaddr: <4101> scsi: slot 6: sense: <0x00/0x00> voltag: <027738L4:8224> avoltag: <:0> source: <> intaddr: <4102> scsi: slot 7: sense: <0x00/0x00> voltag: <027737L4:8224> avoltag: <:0> source: <> intaddr: <4103> scsi: slot 8: sense: <0x00/0x00> voltag: <027736L4:8224> avoltag: <:0> source: <> intaddr: <4104> scsi: slot 9: sense: <0x00/0x00> voltag: <027735L4:8224> avoltag: <:0> source: <> intaddr: <4105> scsi: slot 10: sense: <0x00/0x00> voltag: <027944L4:8224> avoltag: <:0> source: <> intaddr: <4106> scsi: slot 11: sense: <0x00/0x00> voltag: <027943L4:8224> avoltag: <:0> source: <> intaddr: <4107> scsi: slot 12: sense: <0x00/0x00> voltag: <027942L4:8224> avoltag: <:0> source: <> intaddr: <4108> scsi: slot 13: sense: <0x00/0x00> voltag: <027941L4:8224> avoltag: <:0> source: <> intaddr: <4109> scsi: slot 14: sense: <0x00/0x00> voltag: <027940L4:8224> avoltag: <:0> source: <> intaddr: <4110> scsi: slot 15: sense: <0x00/0x00> voltag: <027949L4:8224> avoltag: <:0> source: <> intaddr: <4111> scsi: slot 16: sense: <0x00/0x00> voltag: <027948L4:8224> avoltag: <:0> source: <> intaddr: <4112> scsi: slot 17: sense: <0x00/0x00> voltag: <027947L4:8224> avoltag: <:0> source: <> intaddr: <4113> scsi: slot 18: sense: <0x00/0x00> voltag: <027946L4:8224> avoltag: <:0> source: <> intaddr: <4114> scsi: slot 19: sense: <0x00/0x00> voltag: <027945L4:8224> avoltag: <:0> source: <> intaddr: <4115> scsi: slot 20: sense: <0x00/0x00> voltag: <028314L4:8224> avoltag: <:0> source: <> intaddr: <4116> scsi: slot 21: sense: <0x00/0x00> voltag: <028313L4:8224> avoltag: <:0> source: <> intaddr: <4117> scsi: slot 22: sense: <0x00/0x00> voltag: <028312L4:8224> avoltag: <:0> source: <> intaddr: <4118> scsi: slot 23: sense: <0x00/0x00> voltag: <028311L4:8224> avoltag: <:0> source: <> intaddr: <4119> scsi: slot 24: sense: <0x00/0x00> voltag: <028310L4:8224> avoltag: <:0> source: <> intaddr: <4120> scsi: slot 25: sense: <0x00/0x00> voltag: <028319L4:8224> avoltag: <:0> source: <> intaddr: <4121> scsi: slot 26: sense: <0x00/0x00> voltag: <028318L4:8224> avoltag: <:0> source: <> intaddr: <4122> scsi: slot 27: sense: <0x00/0x00> voltag: <028317L4:8224> avoltag: <:0> source: <> intaddr: <4123> scsi: slot 28: sense: <0x00/0x00> voltag: <028316L4:8224> avoltag: <:0> source: <> intaddr: <4124> scsi: slot 29: sense: <0x00/0x00> voltag: <028315L4:8224> avoltag: <:0> source: <> intaddr: <4125> scsi: slot 30: sense: <0x00/0x00> voltag: <028774L4:8224> avoltag: <:0> source: <> intaddr: <4126> scsi: slot 31: sense: <0x00/0x00> voltag: <028773L4:8224> avoltag: <:0> source: <> intaddr: <4127> scsi: slot 32: sense: <0x00/0x00> voltag: <028772L4:8224> avoltag: <:0> source: <> intaddr: <4128> scsi: slot 33: sense: <0x00/0x00> voltag: <028771L4:8224> avoltag: <:0> source: <> intaddr: <4129> scsi: slot 34: sense: <0x00/0x00> voltag: <028770L4:8224> avoltag: <:0> source: <> intaddr: <4130> scsi: slot 35: sense: <0x00/0x00> voltag: <028779L4:8224> avoltag: <:0> source: <> intaddr: <4131> scsi: slot 36: sense: <0x00/0x00> voltag: <028778L4:8224> avoltag: <:0> source: <> intaddr: <4132> scsi: slot 37: sense: <0x00/0x00> voltag: <028777L4:8224> avoltag: <:0> source: <> intaddr: <4133> scsi: slot 38: sense: <0x00/0x00> voltag: <028776L4:8224> avoltag: <:0> source: <> intaddr: <4134> scsi: slot 39: sense: <0x00/0x00> voltag: <028775L4:8224> avoltag: <:0> source: <> intaddr: <4135> scsi: slot 40: sense: <0x00/0x00> voltag: <029134L4:8224> avoltag: <:0> source: <> intaddr: <4136> scsi: slot 41: sense: <0x00/0x00> voltag: <029133L4:8224> avoltag: <:0> source: <> intaddr: <4137> scsi: slot 42: sense: <0x00/0x00> voltag: <029132L4:8224> avoltag: <:0> source: <> intaddr: <4138> scsi: slot 43: sense: <0x00/0x00> voltag: <029131L4:8224> avoltag: <:0> source: <> intaddr: <4139> scsi: slot 44: sense: <0x00/0x00> voltag: <029130L4:8224> avoltag: <:0> source: <> intaddr: <4140> scsi: slot 45: sense: <0x00/0x00> voltag: <029139L4:8224> avoltag: <:0> source: <> intaddr: <4141> scsi: slot 46: sense: <0x00/0x00> voltag: <029138L4:8224> avoltag: <:0> source: <> intaddr: <4142> scsi: slot 47: sense: <0x00/0x00> voltag: <029137L4:8224> avoltag: <:0> source: <> intaddr: <4143> scsi: slot 48: sense: <0x00/0x00> voltag: <029136L4:8224> avoltag: <:0> source: <> intaddr: <4144> scsi: slot 49: sense: <0x00/0x00> voltag: <029135L4:8224> avoltag: <:0> source: <> intaddr: <4145> scsi: drive 0: sense: <0x00/0x00> voltag: <:0> avoltag: <:0> source: <> intaddr: <256> scsi: vvalbbacula# chio move slot 0 drive 0 chio: /dev/ch0: CHIOMOVE: Device not configured vvalbbacula# tail /var/log/messages Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): MOVE MEDIUM. CDB: a5 0 0 1 10 0 1 0 0 0 0 0 Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): CAM Status: SCSI Status Error Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): SCSI Status: Check Condition Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): ILLEGAL REQUEST asc:25,0 Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): Logical unit not supported Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): Unretryable error acula# mtx -f /dev/pass1 status Storage Changer /dev/pass1:1 Drives, 50 Slots ( 0 Import/Export ) Data Transfer Element 0:Empty Storage Element 1:Full :VolumeTag=027734L4 Storage Element 2:Full :VolumeTag=027733L4 Storage Element 3:Full :VolumeTag=027732L4 Storage Element 4:Full :VolumeTag=027731L4 Storage Element 5:Full :VolumeTag=027730L4 Storage Element 6:Full :VolumeTag=027739L4 Storage Element 7:Full :VolumeTag=027738L4 Storage Element 8:Full :VolumeTag=027737L4 Storage Element 9:Full :VolumeTag=027736L4 Storage Element 10:Full :VolumeTag=027735L4 Storage Element 11:Full :VolumeTag=027944L4 Storage Element 12:Full :VolumeTag=027943L4 Storage Element 13:Full :VolumeTag=027942L4 Storage Element 14:Full :VolumeTag=027941L4 Storage Element 15:Full :VolumeTag=027940L4 Storage Element 16:Full :VolumeTag=027949L4 Storage Element 17:Full :VolumeTag=027948L4 Storage Element 18:Full :VolumeTag=027947L4 Storage Element 19:Full :VolumeTag=027946L4 Storage Element 20:Full :VolumeTag=027945L4 Storage Element 21:Full :VolumeTag=028314L4 Storage Element 22:Full :VolumeTag=028313L4 Storage Element 23:Full :VolumeTag=028312L4 Storage Element 24:Full :VolumeTag=028311L4 Storage Element 25:Full :VolumeTag=028310L4 Storage Element 26:Full :VolumeTag=028319L4 Storage Element 27:Full :VolumeTag=028318L4 Storage Element 28:Full :VolumeTag=028317L4 Storage Element 29:Full :VolumeTag=028316L4 Storage Element 30:Full :VolumeTag=028315L4 Storage Element 31:Full :VolumeTag=028774L4 Storage Element 32:Full :VolumeTag=028773L4 Storage Element 33:Full :VolumeTag=028772L4 Storage Element 34:Full :VolumeTag=028771L4 Storage Element 35:Full :VolumeTag=028770L4 Storage Element 36:Full :VolumeTag=028779L4 Storage Element 37:Full :VolumeTag=028778L4 Storage Element 38:Full :VolumeTag=028777L4 Storage Element 39:Full :VolumeTag=028776L4 Storage Element 40:Full :VolumeTag=028775L4 Storage Element 41:Full :VolumeTag=029134L4 Storage Element 42:Full :VolumeTag=029133L4 Storage Element 43:Full :VolumeTag=029132L4 Storage Element 44:Full :VolumeTag=029131L4 Storage Element 45:Full :VolumeTag=029130L4 Storage Element 46:Full :VolumeTag=029139L4 Storage Element 47:Full :VolumeTag=029138L4 Storage Element 48:Full :VolumeTag=029137L4 Storage Element 49:Full :VolumeTag=029136L4 Storage Element 50:Full :VolumeTag=029135L4 vvalbbacula# mtx -f /dev/pass1 inquiry Product Type: Medium Changer Vendor ID: 'SPECTRA ' Product ID: 'PYTHON ' Revision: '2000' Attached Changer API: No bacula# mtx -f /dev/pass1 load 1 0 Loading media from Storage Element 1 into drive 0...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Illegal Request mtx: Request Sense: FileMark=no mtx: Request Sense: EOM=no mtx: Request Sense: ILI=no mtx: Request Sense: Additional Sense Code = 25 mtx: Request Sense: Additional Sense Qualifier = 00 mtx: Request Sense: BPV=no mtx: Request Sense: Error in CDB=no mtx: Request Sense: SKSV=no MOVE MEDIUM from Element Address 4096 to 256 Failed any help wouldf be greatly appreciated.. please feel free to ask anything I may have overlooked. Tkanks Jason From pisymbol at gmail.com Tue Sep 16 17:47:46 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Tue Sep 16 17:50:00 2008 Subject: scsi errors when trying to move tapes. In-Reply-To: <48CFC480.804@vvisions.com> References: <48CFC480.804@vvisions.com> Message-ID: <3c0b01820809161047s4c34f5dbsd842c926b870b274@mail.gmail.com> On Tue, Sep 16, 2008 at 10:36 AM, Jason Selwitz wrote: > I am running a FreeBSD 7.0 server with a Qlogic 2460 FC HBA installed and > directl connected t othe HBA is a Spectra Logic Tape library, the Library > contains 50 slots, one picker and one IBM Ultrium LTO-4 drive. the system > boots and ercognizes all of the hardware however the isp drive sees the > Qlogic card as a 2432 see below. > > isp0: port 0x5000-0x50ff mem > 0xc6ffc000-0xc6ffffff irq 19 at device 0.0 on pci7 Its the version of the ISP I believe on the card, not the card itself - so the 2460 FC HBA uses a 2432 ISP chip. We couldn't care less what QLogic calls it! :D Trimming the rest which is also useful but I have some basic questions: - I looked up your tape device because I remember from FC tape that one of the commands got deprecated (I think A7 not A5) and the Python 2K is a SCSI tape device, can I assume you are using the ATTO SCSI/FC bridge which Spectra recommends/ships with it? If so, are you sure that is configured properly to relay all commands (apparently you can login into the bridge and verify the unit)? - Is FC tape support enabled in the QLogic BIOS out of curiosity? [what's weird is I have no idea what the SCSI/FC bridge thing does in this scenario] These are just some basic questions to get started. I haven't used or seen a tape changer in a long time! :D -aps From dnelson at allantgroup.com Tue Sep 16 22:35:53 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Tue Sep 16 22:36:02 2008 Subject: scsi errors when trying to move tapes. In-Reply-To: <48CFC480.804@vvisions.com> References: <48CFC480.804@vvisions.com> Message-ID: <20080916222415.GA66380@dan.emsphone.com> In the last episode (Sep 16), Jason Selwitz said: > For some reason I can query status and get Barcode information back from the changer with both chio and mtx however when I try to move media into the drive I get errors see below. > > valbbacula# camcontrol devlist > at scbus0 target 0 lun 0 (sa0,pass0) > at scbus0 target 0 lun 1 (ch0,pass1) > > vvalbbacula# chio params > /dev/ch0: 50 slots, 1 drive, 1 picker > /dev/ch0: current picker: 0 > > vvalbbacula# chio status -a > picker 0: sense: <0x00/0x00> voltag: <:0> avoltag: <:0> source: <> intaddr: <1> scsi: > slot 0: sense: <0x00/0x00> voltag: <027734L4:8224> avoltag: <:0> source: <> intaddr: <4096> scsi: [...] > slot 49: sense: <0x00/0x00> voltag: <029135L4:8224> avoltag: <:0> source: <> intaddr: <4145> scsi: > drive 0: sense: <0x00/0x00> voltag: <:0> avoltag: <:0> source: <> intaddr: <256> scsi: > > vvalbbacula# chio move slot 0 drive 0 > chio: /dev/ch0: CHIOMOVE: Device not configured > > vvalbbacula# tail /var/log/messages > Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): MOVE MEDIUM. CDB: a5 0 0 1 10 0 1 0 0 0 0 0 > Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): CAM Status: SCSI Status Error > Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): SCSI Status: Check Condition > Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): ILLEGAL REQUEST asc:25,0 > Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): Logical unit not supported > Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): Unretryable error Depending on how smart the changer is, you may have to split that move into two: move slot 0 picker 0 move picker 0 drive 0 SCSI Mode page 1F has a table of bits that tell you what source and destinations are allowed in a MOVE MEDIUM command. If you have a T-50 loader, then according to http://www.spectralogic.com/index.cfm?fuseaction=home.displayFile&DocID=286 , the ST->DT bit should be set to 1, so your original command should have worked. The ->MT bits are all zero, though, as if there really isn't a picker at all, so my suggestion to split the command may not work, either. -- Dan Nelson dnelson@allantgroup.com From stefan.lambrev at moneybookers.com Wed Sep 17 09:17:49 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Wed Sep 17 09:17:56 2008 Subject: PERC6/i/e cli In-Reply-To: <20080917111035.12175aklikhtltcs@webmail.leidinger.net> References: <48CFB56D.3070908@moneybookers.com> <20080917111035.12175aklikhtltcs@webmail.leidinger.net> Message-ID: <48D0CB34.4020207@moneybookers.com> Alexander Leidinger wrote: > Quoting "Stefan Lambrev" (from Tue, > 16 Sep 2008 16:32:29 +0300): > >> Virtual Drive Information: >> VD DRV RLP RLS RLQ STS SIZE STATE NAME >> 0 2 1 0 0 64kB 139392MB Optimal Ah and btw I >> think it was mandatory to have compat.linux.osrelease=2.6.12 >> (2.6.16 works too but you have to fix the script to not complain - i >> think the port is still not fixed?) > > Not related to $Subject, but related to the linuxulator: Only use the > default osrelease value or 2.6.16. Anything else may open pandoras box. The port comes with a shell script/wrapper which require you to use 2.6.12. I think the maintainer promised to change it to >= 2.6.12 I personally use 2.6.16 and fixed the wrapper by myself to work only with this version. The point of the maintainer is that if it works with 2.6.12, why we should disable it? For me it's enough to work with default 2.6.16 value, but someone may want to experiment .. not that a small shell script will stop them .. > > Bye, > Alexander. > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From Alexander at Leidinger.net Wed Sep 17 09:21:08 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed Sep 17 09:21:14 2008 Subject: PERC6/i/e cli In-Reply-To: <48CFB56D.3070908@moneybookers.com> References: <48CFB56D.3070908@moneybookers.com> Message-ID: <20080917111035.12175aklikhtltcs@webmail.leidinger.net> Quoting "Stefan Lambrev" (from Tue, 16 Sep 2008 16:32:29 +0300): > Virtual Drive Information: > VD DRV RLP RLS RLQ STS SIZE STATE NAME > 0 2 1 0 0 64kB 139392MB Optimal Ah and btw I > think it was mandatory to have compat.linux.osrelease=2.6.12 > (2.6.16 works too but you have to fix the script to not complain - i > think the port is still not fixed?) Not related to $Subject, but related to the linuxulator: Only use the default osrelease value or 2.6.16. Anything else may open pandoras box. Bye, Alexander. -- I got the bill for my surgery. Now I know what those doctors were wearing masks for. -- James Boren http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From Alexander at Leidinger.net Wed Sep 17 10:00:27 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed Sep 17 10:00:36 2008 Subject: PERC6/i/e cli In-Reply-To: <48D0CB34.4020207@moneybookers.com> References: <48CFB56D.3070908@moneybookers.com> <20080917111035.12175aklikhtltcs@webmail.leidinger.net> <48D0CB34.4020207@moneybookers.com> Message-ID: <20080917120006.13141ndfdhnpaczo@webmail.leidinger.net> Quoting "Stefan Lambrev" (from Wed, 17 Sep 2008 12:17:40 +0300): > > > Alexander Leidinger wrote: >> Quoting "Stefan Lambrev" (from >> Tue, 16 Sep 2008 16:32:29 +0300): >> >>> Virtual Drive Information: >>> VD DRV RLP RLS RLQ STS SIZE STATE NAME >>> 0 2 1 0 0 64kB 139392MB Optimal Ah and btw I >>> think it was mandatory to have compat.linux.osrelease=2.6.12 >>> (2.6.16 works too but you have to fix the script to not complain - >>> i think the port is still not fixed?) >> >> Not related to $Subject, but related to the linuxulator: Only use >> the default osrelease value or 2.6.16. Anything else may open >> pandoras box. > The port comes with a shell script/wrapper which require you to use > 2.6.12. I think the maintainer promised to change it to >= 2.6.12 > I personally use 2.6.16 and fixed the wrapper by myself to work only > with this version. > The point of the maintainer is that if it works with 2.6.12, why we > should disable it? > For me it's enough to work with default 2.6.16 value, but someone > may want to experiment .. not that a small shell script will stop > them .. The linuxulator (kernel) will only switch to 2.6 mode with 2.6.16, with everything else it will stay in 2.4 mode. The linux infrastructure (ports) may decide to do their own stuff based upon the value of osversion. In the linux_base-fc6 this is the case for sure (libc and so on). The port you use may do the same. You've been warned... Bye, Alexander. -- You know it's going to be a bad day when you want to put on the clothes you wore home from the party and there aren't any. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From rdivacky at FreeBSD.org Wed Sep 17 10:34:57 2008 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Wed Sep 17 10:35:03 2008 Subject: PERC6/i/e cli In-Reply-To: <20080917120006.13141ndfdhnpaczo@webmail.leidinger.net> References: <48CFB56D.3070908@moneybookers.com> <20080917111035.12175aklikhtltcs@webmail.leidinger.net> <48D0CB34.4020207@moneybookers.com> <20080917120006.13141ndfdhnpaczo@webmail.leidinger.net> Message-ID: <20080917101605.GA91263@freebsd.org> On Wed, Sep 17, 2008 at 12:00:06PM +0200, Alexander Leidinger wrote: > Quoting "Stefan Lambrev" (from Wed, > 17 Sep 2008 12:17:40 +0300): > > > > > > >Alexander Leidinger wrote: > >>Quoting "Stefan Lambrev" (from > >>Tue, 16 Sep 2008 16:32:29 +0300): > >> > >>>Virtual Drive Information: > >>>VD DRV RLP RLS RLQ STS SIZE STATE NAME > >>>0 2 1 0 0 64kB 139392MB Optimal Ah and btw I > >>>think it was mandatory to have compat.linux.osrelease=2.6.12 > >>>(2.6.16 works too but you have to fix the script to not complain - > >>>i think the port is still not fixed?) > >> > >>Not related to $Subject, but related to the linuxulator: Only use > >>the default osrelease value or 2.6.16. Anything else may open > >>pandoras box. > >The port comes with a shell script/wrapper which require you to use > >2.6.12. I think the maintainer promised to change it to >= 2.6.12 > >I personally use 2.6.16 and fixed the wrapper by myself to work only > >with this version. > >The point of the maintainer is that if it works with 2.6.12, why we > >should disable it? > >For me it's enough to work with default 2.6.16 value, but someone > >may want to experiment .. not that a small shell script will stop > >them .. > > The linuxulator (kernel) will only switch to 2.6 mode with 2.6.16, > with everything else it will stay in 2.4 mode. The linux > infrastructure (ports) may decide to do their own stuff based upon the > value of osversion. In the linux_base-fc6 this is the case for sure > (libc and so on). The port you use may do the same. You've been > warned... actually linuxulator checks if the "osrelease" string is at least 3 chars long and if the 3rd char is "6" so "2.6.16" works exactly the same as "9.6.IamAlittleBUTTERFLY".... the fact is that we officially support only 2.6.16 as this is what is most testing done with. On the other hand I think that anything below 16 (2.6.0 -> 2.6.15) should work exactly as good. The problem might be with version > 16. Anyway - the port should be fixed. In 8-CURRENT we default to "2.6.16" so the port doesnt work... roman From danny at cs.huji.ac.il Wed Sep 17 10:48:13 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Sep 17 10:48:26 2008 Subject: PERC6/i/e cli In-Reply-To: <48D0CB34.4020207@moneybookers.com> References: <48CFB56D.3070908@moneybookers.com> <20080917111035.12175aklikhtltcs@webmail.leidinger.net> <48D0CB34.4020207@moneybookers.com> Message-ID: > > > Alexander Leidinger wrote: > > Quoting "Stefan Lambrev" (from Tue, > > 16 Sep 2008 16:32:29 +0300): > > > >> Virtual Drive Information: > >> VD DRV RLP RLS RLQ STS SIZE STATE NAME > >> 0 2 1 0 0 64kB 139392MB Optimal Ah and btw I > >> think it was mandatory to have compat.linux.osrelease=2.6.12 > >> (2.6.16 works too but you have to fix the script to not complain - i > >> think the port is still not fixed?) > > > > Not related to $Subject, but related to the linuxulator: Only use the > > default osrelease value or 2.6.16. Anything else may open pandoras box. > The port comes with a shell script/wrapper which require you to use > 2.6.12. I think the maintainer promised to change it to >= 2.6.12 > I personally use 2.6.16 and fixed the wrapper by myself to work only > with this version. > The point of the maintainer is that if it works with 2.6.12, why we > should disable it? > For me it's enough to work with default 2.6.16 value, but someone may > want to experiment .. not that a small shell script will stop them .. > > personaly, I am using /usr/local/lib/MegaCli directly, since from experimentation, the mfi_linux module MUST be loaded before mounting linsysfs, and the shell script is missleading. I modified /etc/rc.d/abi to do it correctly. danny > > Bye, > > Alexander. > > > > -- > > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > From sbruno at miralink.com Wed Sep 17 19:00:35 2008 From: sbruno at miralink.com (Sean Bruno) Date: Wed Sep 17 19:00:45 2008 Subject: [RELENG_6] Minor CAM patch Message-ID: <48D153D2.7050907@miralink.com> Just a patch from my company's tree. I'd like to merge it ... don't worry, there will be more shortly. :) -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com -------------- next part -------------- Index: cam.h =================================================================== --- cam.h (revision 183088) +++ cam.h (working copy) @@ -129,6 +129,7 @@ * requests for the target at the sim level * back into the XPT queue. */ + CAM_SCSI_IT_NEXUS_LOST, /* Initiator/Target Nexus lost. */ CAM_IDE = 0x33, /* Initiator Detected Error */ CAM_RESRC_UNAVAIL, /* Resource Unavailable */ CAM_UNACKED_EVENT, /* Unacknowledged Event by Host */ From andy at mx.ru Thu Sep 18 07:28:12 2008 From: andy at mx.ru (AndrewV) Date: Thu Sep 18 07:28:26 2008 Subject: (probe30:iir0:2:0:0): inquiry data fails comparison at DV1 step In-Reply-To: <47F55D25.9040900@samsco.org> References: <1207131421.2910.11.camel@frodon.be-bif.ulb.ac.be> <47F54966.9020500@samsco.org> <47F55D25.9040900@samsco.org> Message-ID: <19547250.post@talk.nabble.com> Scott Long-2 wrote: > > Scott Long wrote: >> Julien wrote: >>> Hello, >>> >>> I'm using FreeBSD 7.0 with an Intel SRCZCR >>> (http://support.intel.com/support/motherboards/server/srczcr/) RAID >>> controller. The machine is configured as the following: >>> - RAID 1 + one spare disk where the system is installed >>> - RAID 5 + one spare disk mounted under /usr >>> >>> The disks are from Seagate (146 GB, U320). >>> It seems to work fine (it's a fresh install) except that I have this >>> message on boot : >>> >>> (probe30:iir0:2:0:0): inquiry data fails comparison at DV1 step >>> > > Oops, my apologies, so many drivers, so little brainpower. This problem > may have been fixed back in January, but only in 8-CURRENT. I'll look > into merging the fix into FreeBSD 7. > > Any chance to see this fix in upcoming release? We also have the same problem: Waiting 3 seconds for SCSI devices to settle (probe131:ahd0:0:5:0): inquiry data fails comparison at DV1 step (probe131:ahd0:0:5:0): inquiry data fails comparison at DV1 step (probe131:ahd0:0:5:0): inquiry data fails comparison at DV1 step (probe131:ahd0:0:5:0): inquiry data fails comparison at DV1 step (probe131:ahd0:0:5:0): inquiry data fails comparison at DV1 step ... a5 at ahd0 bus 0 target 5 lun 0 da5: Fixed Direct Access SCSI-4 device da5: 6.600MB/s transfers (16bit) da5: Command Queueing Enabled 6.6 MB/s is too slow these days :(( Working good with 6.x, damaged in 7.x ________ ANDY -- View this message in context: http://www.nabble.com/%28probe30%3Aiir0%3A2%3A0%3A0%29%3A-inquiry-data-fails-comparison-at-DV1-step-tp16445635p19547250.html Sent from the freebsd-scsi mailing list archive at Nabble.com. From Alexander at Leidinger.net Thu Sep 18 08:00:52 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Sep 18 08:01:20 2008 Subject: PERC6/i/e cli In-Reply-To: <20080917101605.GA91263@freebsd.org> References: <48CFB56D.3070908@moneybookers.com> <20080917111035.12175aklikhtltcs@webmail.leidinger.net> <48D0CB34.4020207@moneybookers.com> <20080917120006.13141ndfdhnpaczo@webmail.leidinger.net> <20080917101605.GA91263@freebsd.org> Message-ID: <20080918100042.58673tw6ihyqahs0@webmail.leidinger.net> Quoting "Roman Divacky" (from Wed, 17 Sep 2008 12:16:05 +0200): > On Wed, Sep 17, 2008 at 12:00:06PM +0200, Alexander Leidinger wrote: >> Quoting "Stefan Lambrev" (from Wed, >> 17 Sep 2008 12:17:40 +0300): >> >> > >> > >> >Alexander Leidinger wrote: >> >>Quoting "Stefan Lambrev" (from >> >>Tue, 16 Sep 2008 16:32:29 +0300): >> >> >> >>>Virtual Drive Information: >> >>>VD DRV RLP RLS RLQ STS SIZE STATE NAME >> >>>0 2 1 0 0 64kB 139392MB Optimal Ah and btw I >> >>>think it was mandatory to have compat.linux.osrelease=2.6.12 >> >>>(2.6.16 works too but you have to fix the script to not complain - >> >>>i think the port is still not fixed?) >> >> >> >>Not related to $Subject, but related to the linuxulator: Only use >> >>the default osrelease value or 2.6.16. Anything else may open >> >>pandoras box. >> >The port comes with a shell script/wrapper which require you to use >> >2.6.12. I think the maintainer promised to change it to >= 2.6.12 >> >I personally use 2.6.16 and fixed the wrapper by myself to work only >> >with this version. >> >The point of the maintainer is that if it works with 2.6.12, why we >> >should disable it? >> >For me it's enough to work with default 2.6.16 value, but someone >> >may want to experiment .. not that a small shell script will stop >> >them .. >> >> The linuxulator (kernel) will only switch to 2.6 mode with 2.6.16, >> with everything else it will stay in 2.4 mode. The linux >> infrastructure (ports) may decide to do their own stuff based upon the >> value of osversion. In the linux_base-fc6 this is the case for sure >> (libc and so on). The port you use may do the same. You've been >> warned... > > actually linuxulator checks if the "osrelease" string is at least 3 chars > long and if the 3rd char is "6" so "2.6.16" works exactly the same as > "9.6.IamAlittleBUTTERFLY".... Ups... sorry. It seems my memory fades away regarding this. Bye, Alexander. -- A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From pisymbol at gmail.com Thu Sep 18 12:12:32 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Thu Sep 18 12:12:38 2008 Subject: scsi errors when trying to move tapes. In-Reply-To: <20080916222415.GA66380@dan.emsphone.com> References: <48CFC480.804@vvisions.com> <20080916222415.GA66380@dan.emsphone.com> Message-ID: <3c0b01820809180512v178154a6h6d1190a300a5d519@mail.gmail.com> On Tue, Sep 16, 2008 at 6:24 PM, Dan Nelson wrote: > In the last episode (Sep 16), Jason Selwitz said: >> For some reason I can query status and get Barcode information back from the changer with both chio and mtx however when I try to move media into the drive I get errors see below. >> >> valbbacula# camcontrol devlist >> at scbus0 target 0 lun 0 (sa0,pass0) >> at scbus0 target 0 lun 1 (ch0,pass1) >> >> vvalbbacula# chio params >> /dev/ch0: 50 slots, 1 drive, 1 picker >> /dev/ch0: current picker: 0 >> >> vvalbbacula# chio status -a >> picker 0: sense: <0x00/0x00> voltag: <:0> avoltag: <:0> source: <> intaddr: <1> scsi: >> slot 0: sense: <0x00/0x00> voltag: <027734L4:8224> avoltag: <:0> source: <> intaddr: <4096> scsi: > [...] >> slot 49: sense: <0x00/0x00> voltag: <029135L4:8224> avoltag: <:0> source: <> intaddr: <4145> scsi: >> drive 0: sense: <0x00/0x00> voltag: <:0> avoltag: <:0> source: <> intaddr: <256> scsi: >> >> vvalbbacula# chio move slot 0 drive 0 >> chio: /dev/ch0: CHIOMOVE: Device not configured >> >> vvalbbacula# tail /var/log/messages >> Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): MOVE MEDIUM. CDB: a5 0 0 1 10 0 1 0 0 0 0 0 >> Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): CAM Status: SCSI Status Error >> Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): SCSI Status: Check Condition >> Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): ILLEGAL REQUEST asc:25,0 >> Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): Logical unit not supported >> Sep 16 10:11:10 vvalbbacula kernel: (ch0:isp0:0:0:1): Unretryable error > > Depending on how smart the changer is, you may have to split that move > into two: > > move slot 0 picker 0 > move picker 0 drive 0 > > SCSI Mode page 1F has a table of bits that tell you what source and > destinations are allowed in a MOVE MEDIUM command. If you have a T-50 > loader, then according to > > http://www.spectralogic.com/index.cfm?fuseaction=home.displayFile&DocID=286 > > , the ST->DT bit should be set to 1, so your original command should > have worked. The ->MT bits are all zero, though, as if there really > isn't a picker at all, so my suggestion to split the command may not > work, either. > > -- > Dan Nelson > dnelson@allantgroup.com > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > I agree with the above too. I'm not sure about splitting the commands up though (I also thought the right picker would just be automatically chosen based on the drive). Because though he is getting LUN unit not supported I'm wondering if there is an issue with configuring the tape on the FC fabric itself. I mean most of the commands that do go through I believe are mandatory (INQUIRY, etc.). You mentioned the tape can be put into several modes - can you consult the documentation about the recommended way the tape should be set up? I'm speculating here since I'm not familiar with your device. -aps From bugmaster at FreeBSD.org Mon Sep 22 11:07:03 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 22 11:07:48 2008 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200809221107.m8MB72D3015499@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/126866 scsi [isp] [panic] kernel panic on card initialization o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 26 problems total. From klapperzhu at gmail.com Tue Sep 23 01:45:57 2008 From: klapperzhu at gmail.com (Klapper Zhu) Date: Tue Sep 23 01:45:59 2008 Subject: Qlogic FC scsi_target ISP2310 Message-ID: Erich and Alexander, Have you made any progress on running QLA23xx in target mode ? I am running a QLA2312 in target mode and it has the same behavior as Erich encountered. Thanks, From pisymbol at gmail.com Tue Sep 23 01:55:13 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Tue Sep 23 01:55:16 2008 Subject: Qlogic FC scsi_target ISP2310 In-Reply-To: References: Message-ID: <3c0b01820809221855o6ed1969cr7057871b6f81bad8@mail.gmail.com> Hey Guys, Can you please file a PR? I'm finishing up the patch to fix some firmware related issues and general bug fixes. I will try to reproduce the target mode issue with my QLA24xx. Thanks! -aps On Mon, Sep 22, 2008 at 9:45 PM, Klapper Zhu wrote: > Erich and Alexander, > > Have you made any progress on running QLA23xx in target mode ? > > I am running a QLA2312 in target mode and it has the same behavior as Erich > encountered. > > Thanks, > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From klapperzhu at gmail.com Tue Sep 23 02:27:14 2008 From: klapperzhu at gmail.com (Klapper Zhu) Date: Tue Sep 23 02:27:17 2008 Subject: QLA2432 Target Mode Broken Message-ID: Hi Sean, I am very interested in how you got 23XX card working in target mode. 1) are you following exactly the instructions at http://www.root.org/~nate/freebsd/scsi/README.targ 2) did you see on initiator box on running "camcontrol devlist" ? I assume you used a freebsd box as initiator. 3) Are you using Freebsd "Production Release 7.0" and isp(4) included without any patch for both initiator and target boxes ? Thanks, --K. Zhu On Aug 29, 1:54 pm, Sean Bruno wrote: - Hide quoted text - - Show quoted text - > A 23XX card in it's place works just fine. > I believe, due to the architecture difference between the 4G/8G and 2G > cards that it just doesn't work right now. > The 4G/8G architecture does nothing in target mode except DMA the > incoming data. the 2G cards do some things > for the driver. > I was hoping that someone has some patches in their trees just lying > around that I could look over and test for > 4G target mode support. :) > -- > Sean Bruno > MiraLink Corporation > 6015 NE 80th Ave, Ste 100 > Portland, OR 97218 > Phone 503-621-5143 From sbruno at miralink.com Tue Sep 23 02:29:05 2008 From: sbruno at miralink.com (Sean Bruno) Date: Tue Sep 23 02:29:07 2008 Subject: QLA2432 Target Mode Broken In-Reply-To: References: Message-ID: <48D85470.8030608@miralink.com> Klapper Zhu wrote: > Hi Sean, > > I am very interested in how you got 23XX card working in target mode. > > 1) are you following exactly the instructions at > http://www.root.org/~nate/freebsd/scsi/README.targ > 2) did you see on initiator box on running > "camcontrol devlist" ? I assume you used a freebsd box as initiator. > 3) Are you using Freebsd "Production Release 7.0" and isp(4) included > without any patch for both initiator and target boxes ? > > Thanks, > > --K. Zhu > I am not following those instructions at all. I have a proprietary target at my disposal. We are using FreeBSD 6 here, so perhaps going back to BSD 6 to see what you can get working there? Sean From ml at t-b-o-h.net Wed Sep 24 08:42:33 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed Sep 24 08:42:40 2008 Subject: Smartd, twe0 and HELP!! ;) Message-ID: <200809240842.m8O8gHEr006778@himinbjorg.tucs-beachin-obx-house.com> Hi, We lost primary and secondary power at our datacenter, and now we are having issues on a server... FreeBSD 5.5 (I'm sorry, its just one of those that can't be upgraded) Its running smartd 5.36 (Again, I can't upgrade software on here. Its scheduled for replacement, but the system replacing it took a hit and has locked up twice in 2 hours, so I'm pretty stuffed) The dmesg saw : Sep 24 01:34:05 erda kernel: twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0xb800-0xb80f mem 0xfe000000-0xfe7fffff irq 24 at device 3.0 on pci3 Sep 24 01:34:05 erda kernel: twe0: AEN: Sep 24 01:34:05 erda kernel: twe0: 8 ports, Firmware FE7S 1.05.00.050, BIOS BE 7X 1.08.00.046 Sep 24 01:34:05 erda kernel: twed0: on twe0 Sep 24 01:34:05 erda kernel: twed0: 1430844MB (2930370048 sectors) Sep 24 01:34:05 erda kernel: Mounting root from ufs:/dev/twed0s1a Sep 24 01:34:05 erda kernel: kernel dumps on /dev/twed0s1b Sep 24 01:34:05 erda kernel: swapon: adding /dev/twed0s1b as swap device Sep 24 01:34:05 erda kernel: /dev/twed0s1a: 1915 files, 33896 used, 472591 free (423 frags, 59021 blocks, 0.1% fragmentation) Sep 24 01:34:05 erda kernel: /dev/twed0s1g: DEFER FOR BACKGROUND CHECKING Sep 24 01:34:05 erda kernel: /dev/twed0s1e: DEFER FOR BACKGROUND CHECKING Sep 24 01:34:05 erda kernel: /dev/twed0s1f: DEFER FOR BACKGROUND CHECKING Sep 24 01:34:05 erda kernel: /dev/twed0s1d: DEFER FOR BACKGROUND CHECKING Smartmon started as : Sep 24 01:35:27 erda kernel: Starting smartd. Sep 24 01:35:27 erda smartd[700]: smartd version 5.36 [i386-portbld-freebsd5.3] Copyright (C) 2002-6 Bruce Allen Sep 24 01:35:27 erda smartd[700]: Home page is http://smartmontools.sourceforge. net/ Sep 24 01:35:27 erda smartd[700]: Opened configuration file /usr/local/etc/smart d.conf Sep 24 01:35:27 erda smartd[700]: Drive: /dev/twe0 [3ware_disk_00], implied '-a' Directive on line 24 of file /usr/local/etc/smartd.conf Sep 24 01:35:27 erda smartd[700]: Configuration file /usr/local/etc/smartd.conf parsed. Sep 24 01:35:27 erda smartd[700]: Device: /dev/twe0 [3ware_disk_00], opened Sep 24 01:35:27 erda smartd[700]: Device: /dev/twe0 [3ware_disk_00], found in sm artd database. Sep 24 01:35:27 erda smartd[700]: Device: /dev/twe0 [3ware_disk_00], is SMART ca pable. Adding to "monitor" list. Sep 24 01:35:27 erda smartd[700]: Monitoring 1 ATA and 0 SCSI devices Sep 24 01:35:28 erda smartd[703]: smartd has fork()ed into background mode. New PID=703. Sep 24 01:35:28 erda smartd[703]: file /var/run/smartd.pid written containing PI D 703 but later on did : Sep 24 02:20:16 erda kernel: twe0: AEN: Sep 24 02:20:57 erda kernel: twe0: AEN: Sep 24 02:25:09 erda kernel: twe0: AEN: Sep 24 02:26:12 erda kernel: twe0: AEN: Sep 24 02:26:41 erda kernel: twe0: AEN: Sep 24 02:26:48 erda kernel: twe0: AEN: Sep 24 02:28:49 erda kernel: twe0: AEN: Sep 24 02:29:35 erda kernel: twe0: AEN: Sep 24 02:30:11 erda kernel: twe0: AEN: Sep 24 02:30:43 erda kernel: twe0: AEN: Sep 24 02:31:18 erda kernel: twe0: AEN: Sep 24 02:31:28 erda kernel: twe0: AEN: Sep 24 02:35:28 erda smartd[703]: Command failed, ata.status=(0xc8), ata.command =(0x50), ata.flags=(0x2c) Sep 24 02:35:28 erda smartd[703]: Device: /dev/twe0 [3ware_disk_00], not capable of SMART self-check Sep 24 02:35:28 erda smartd[703]: Command failed, ata.status=(0xc8), ata.command =(0x50), ata.flags=(0x2c) Sep 24 02:35:28 erda smartd[703]: Error SMART Values Read failed: Input/output e rror Sep 24 02:35:28 erda smartd[703]: Device: /dev/twe0 [3ware_disk_00], failed to r ead SMART Attribute Data Sep 24 02:35:28 erda kernel: Sep 24 02:35:28 erda smartd[703]: Device: /dev/twe0 [3ware_disk_00], failed to read SMART Attribute Data Sep 24 02:35:28 erda smartd[703]: Command failed, ata.status=(0xc8), ata.command =(0x50), ata.flags=(0x2c) Sep 24 02:35:28 erda smartd[703]: Error SMART Error Self-Test Log Read failed: I nput/output error Sep 24 02:35:28 erda smartd[703]: Device: /dev/twe0 [3ware_disk_00], Read SMART Self Test Log Failed Sep 24 02:35:28 erda smartd[703]: Command failed, ata.status=(0xc8), ata.command =(0x50), ata.flags=(0x2c) Sep 24 02:35:28 erda smartd[703]: Error SMART Error Log Read failed: Input/outpu t error Sep 24 02:35:28 erda smartd[703]: Device: /dev/twe0 [3ware_disk_00], Read SMARTError Log Failed and Sep 24 03:05:28 erda smartd[703]: Command failed, ata.status=(0xc8), ata.command =(0x50), ata.flags=(0x2c) Sep 24 03:05:28 erda smartd[703]: Device: /dev/twe0 [3ware_disk_00], not capable of SMART self-check Sep 24 03:05:28 erda smartd[703]: Command failed, ata.status=(0xc8), ata.command =(0x50), ata.flags=(0x2c) Sep 24 03:05:28 erda smartd[703]: Error SMART Values Read failed: Input/output e rror Sep 24 03:05:28 erda smartd[703]: Device: /dev/twe0 [3ware_disk_00], failed to r ead SMART Attribute Data Sep 24 03:05:28 erda kernel: Sep 24 03:05:28 erda smartd[703]: Device: /dev/twe0 [3ware_disk_00], failed to read SMART Attribute Data Sep 24 03:05:28 erda smartd[703]: Command failed, ata.status=(0xc8), ata.command =(0x50), ata.flags=(0x2c) Sep 24 03:05:28 erda smartd[703]: Error SMART Error Self-Test Log Read failed: I nput/output error Sep 24 03:05:28 erda smartd[703]: Device: /dev/twe0 [3ware_disk_00], Read SMART Self Test Log Failed Sep 24 03:05:28 erda smartd[703]: Command failed, ata.status=(0xc8), ata.command =(0x50), ata.flags=(0x2c) Sep 24 03:05:28 erda smartd[703]: Error SMART Error Log Read failed: Input/outpu t error Sep 24 03:05:28 erda smartd[703]: Device: /dev/twe0 [3ware_disk_00], Read SMART Error Log Failed I contacted the smartd people, the author replied he's not sure whats wrong. SIGH.... I contacted the twe author and then realized maybe posting here is a good idea. Any ideas/thoughts/suggestions/etc for whats happening? Pointers? Thanks, Tuc From pprocacci at datapipe.com Thu Sep 25 09:10:04 2008 From: pprocacci at datapipe.com (Paul A. Procacci) Date: Thu Sep 25 09:10:11 2008 Subject: kern/126866: [isp] [panic] kernel panic on card initialization Message-ID: <200809250910.m8P9A4MY047099@freefall.freebsd.org> The following reply was made to PR kern/126866; it has been noted by GNATS. From: "Paul A. Procacci" To: bug-followup@FreeBSD.org, westr@connection.ca Cc: Subject: Re: kern/126866: [isp] [panic] kernel panic on card initialization Date: Thu, 25 Sep 2008 03:56:10 -0500 Hello, I am having the same exact problem you were having using the same device. I started receiving this error on FBSD7-RELEASE and thought it was specific to that version. Naturally I upgraded to FBSD7-Stable as of today (9/25/2008), but still haven't been able to resolve this error, even with the patch presented here. Like you had mentioned on freebsd-scsi, the machine panic's roughly 50% of the time during boot. Here is my `trap` with the patch applied. Due note that this is typed by hand as the kvm I'm on doesn't allow for copy and paste: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x8 :0xffffffff80187350 stack pointer = 0x10 :ffffffffac499810 frame pointer = 0x10 : ffffff0003782320 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32, 0, ran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 5 (thread taskq) trap number = 12 panic: page fault cpuid = 0 Uptime 5s ---------------------------------------------------------------- I wish I had further information to give. The information I provided almost certainly pales in comparison to the submitters, but I believe it relevant given the symptoms / deice are identical. From pisymbol at gmail.com Thu Sep 25 13:51:20 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Thu Sep 25 13:51:27 2008 Subject: kern/126866: [isp] [panic] kernel panic on card initialization In-Reply-To: <200809250910.m8P9A4MY047099@freefall.freebsd.org> References: <200809250910.m8P9A4MY047099@freefall.freebsd.org> Message-ID: <3c0b01820809250651p6053d597i9b315909e8e65000@mail.gmail.com> On Thu, Sep 25, 2008 at 5:10 AM, Paul A. Procacci wrote: > The following reply was made to PR kern/126866; it has been noted by GNATS. > > From: "Paul A. Procacci" > To: bug-followup@FreeBSD.org, westr@connection.ca > Cc: > Subject: Re: kern/126866: [isp] [panic] kernel panic on card initialization > Date: Thu, 25 Sep 2008 03:56:10 -0500 > > Hello, > > I am having the same exact problem you were having using the same > device. I started receiving this error on FBSD7-RELEASE and thought it > was specific to that version. Naturally I upgraded to FBSD7-Stable as > of today (9/25/2008), but still haven't been able to resolve this error, > even with the patch presented here. Like you had mentioned on > freebsd-scsi, the machine panic's roughly 50% of the time during boot. > > Here is my `trap` with the patch applied. Due note that this is typed > by hand as the kvm I'm on doesn't allow for copy and paste: Patch is almost done, I'm actively working on it now (should be good for 6.x and 7.x trees minimally). The issue I'm facing is that though this is fixed, when you don't load the firmware at all you get the "f/w doesn't really start message!" Uggh, there is also some minor bugs regarding the reset signature that will be in this patch as well. -aps From westr at connection.ca Thu Sep 25 15:32:16 2008 From: westr at connection.ca (Ross) Date: Thu Sep 25 15:32:22 2008 Subject: kern/126866: [isp] [panic] kernel panic on card initialization In-Reply-To: <200809250910.m8P9A4MY047099@freefall.freebsd.org> References: <200809250910.m8P9A4MY047099@freefall.freebsd.org> Message-ID: <835218108.20080925113214@connection.ca> PAP> I am having the same exact problem you were having using the same PAP> device. I started receiving this error on FBSD7-RELEASE and thought it PAP> was specific to that version. Naturally I upgraded to FBSD7-Stable as PAP> of today (9/25/2008), but still haven't been able to resolve this error, PAP> even with the patch presented here. Like you had mentioned on PAP> freebsd-scsi, the machine panic's roughly 50% of the time during boot. Actually, going over the trap output, it looks different than the output I had, so it might be a different issue in the end. Which kernel are you running? (i386/amd64), and is it possible to get the output of a dmesg, so we know what chipset the driver thinks it is? (Are you running an HP Blade w QHM6432 like I am?) Also, if you can set 'hint.isp.[01].debug=0x11F' in your /boot/device.hints file, it'll hopefully give some additional output to help track the problem down. Obviously the best is to compile in the kernel debugger as that'll give the exact place it crashes. Thanks, Ross. -- Ross West Tel: +1 416 967 6767 Network Manager Fax: +1 416 967 7777 Network Connection Email: westr@connection.ca From pisymbol at gmail.com Thu Sep 25 17:51:24 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Thu Sep 25 17:51:30 2008 Subject: kern/126866: [isp] [panic] kernel panic on card initialization In-Reply-To: <835218108.20080925113214@connection.ca> References: <200809250910.m8P9A4MY047099@freefall.freebsd.org> <835218108.20080925113214@connection.ca> Message-ID: <3c0b01820809251051q34a33fa5od5ec9fe9d853612@mail.gmail.com> On Thu, Sep 25, 2008 at 11:32 AM, Ross wrote: > > PAP> I am having the same exact problem you were having using the same > PAP> device. I started receiving this error on FBSD7-RELEASE and thought it > PAP> was specific to that version. Naturally I upgraded to FBSD7-Stable as > PAP> of today (9/25/2008), but still haven't been able to resolve this error, > PAP> even with the patch presented here. Like you had mentioned on > PAP> freebsd-scsi, the machine panic's roughly 50% of the time during boot. > > Actually, going over the trap output, it looks different than the > output I had, so it might be a different issue in the end. > > Which kernel are you running? (i386/amd64), and is it possible to get > the output of a dmesg, so we know what chipset the driver thinks it is? > (Are you running an HP Blade w QHM6432 like I am?) > > Also, if you can set 'hint.isp.[01].debug=0x11F' in your > /boot/device.hints file, it'll hopefully give some additional output > to help track the problem down. > > Obviously the best is to compile in the kernel debugger as that'll > give the exact place it crashes. Yea totally. If you can get a stack trace that would be great (just compile in the debugger support, reboot, and when you hit the panic do a trace and just give us the function output (again exact addresses not so much)). -aps From daniel at dgnetwork.com.br Thu Sep 25 23:46:47 2008 From: daniel at dgnetwork.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Thu Sep 25 23:47:30 2008 Subject: FreeBSD and ISCSI, Strange Problem Message-ID: <48DC1CA3.5030609@dgnetwork.com.br> I'm with a very strange problem in the FreeBSD 7.0R I use the iscsi_initiator to mount two devices of a Dell MD3000i, the file system is UFS. The problem occurs when I make a copy of a great directory for inside of the /data/email directory, passed some minutes of beginning of copy, the SSH connection stops to answer, when trying to open a new connection " Password: " it isn't requested, in the console, when typing the user "root" e to press enter, " Password: " also it isn't requested. The only way to come back is restarting the FreeBSD. When press CTRL+T during the freeze it is shown: # ssh root@10.0.20.10 load: 0.76 cmd: ssh 86930 [sbwait] 0.00u 0.01s 0% 2076k In another freeze it showed state [ufs] During freeze, send and receive pings work fine, but no service runing work. I already verified for some related LOG, however not see nothing related. MOUNT: /dev/da0s1g on /home (ufs, local, soft-updates) /dev/da0s1f on /tmp (ufs, local, soft-updates) /dev/da0s1d on /usr (ufs, local, soft-updates) /dev/da0s1e on /var (ufs, NFS exported, local, soft-updates) /dev/da2s1d on /data/db (ufs, NFS exported, local, soft-updates) /dev/da3s1d on /data/email (ufs, NFS exported, local, soft-updates) DMESG: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #0: Mon Sep 15 20:00:35 BRT 2008 root@srvdata1:/usr/src/sys/i386/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2329.84-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 4 real memory = 3484745728 (3323 MB) avail memory = 3405615104 (3247 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Sep 15 2008 20:00:23) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est3 attach returned 6 p4tcc3: on cpu3 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci4: on pcib1 pcib2: at device 0.0 on pci4 pci5: on pcib2 pcib3: at device 0.0 on pci5 pci6: on pcib3 pcib4: at device 0.0 on pci6 pci7: on pcib4 bce0: mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci7 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: Ethernet address: 00:1e:c9:b4:e5:2b bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x04000305); Flags( MFW MSI ) pcib5: at device 1.0 on pci5 pci8: on pcib5 pcib6: at device 0.3 on pci4 pci9: on pcib6 pcib7: at device 3.0 on pci0 pci1: on pcib7 mpt0: port 0xec00-0xecff mem 0xfc8fc000-0xfc8fffff,0xfc8e0000-0xfc8effff irq 16 at device 0.0 on pci1 mpt0: [ITHREAD] mpt0: MPI Version=1.5.14.0 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x21 mpt0: mpt_cam_event: 0x21 pcib8: at device 4.0 on pci0 pci10: on pcib8 em0: port 0xdce0-0xdcff mem 0xfc5e0000-0xfc5fffff,0xfc5c0000-0xfc5dffff irq 16 at device 0.0 on pci10 em0: Using MSI interrupt em0: Ethernet address: 00:15:17:8b:23:12 em0: [FILTER] pcib9: at device 5.0 on pci0 pci11: on pcib9 pcib10: at device 6.0 on pci0 pci12: on pcib10 em1: port 0xcce0-0xccff mem 0xfc3e0000-0xfc3fffff,0xfc3c0000-0xfc3dffff irq 16 at device 0.0 on pci12 em1: Using MSI interrupt em1: Ethernet address: 00:15:17:8b:4f:92 em1: [FILTER] pcib11: at device 7.0 on pci0 pci13: on pcib11 pci0: at device 8.0 (no driver attached) pcib12: at device 28.0 on pci0 pci2: on pcib12 pcib13: at device 0.0 on pci2 pci3: on pcib13 bce1: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce1: Ethernet address: 00:1e:c9:b4:e5:29 bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x04000305); Flags( MFW MSI ) uhci0: port 0xace0-0xacff irq 21 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xacc0-0xacdf irq 20 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xaca0-0xacbf irq 21 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xac80-0xac9f irq 20 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfca00000-0xfca003ff irq 21 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered uhub5: on uhub4 uhub5: multiple transaction translators uhub5: 4 ports with 4 removable, self powered ukbd0: on uhub5 kbd2 at ukbd0 uhid0: on uhub5 umass0: on uhub4 pcib14: at device 30.0 on pci0 pci14: on pcib14 vgapci0: port 0xbc00-0xbcff mem 0xd8000000-0xdfffffff,0xfc2d0000-0xfc2dffff irq 19 at device 13.0 on pci14 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc8fff,0xcf000-0xcffff,0xec000-0xeffff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec hptrr: no controller detected. acd0: CDRW at ata0-master UDMA33 ses0 at mpt0 bus 0 target 8 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 300.000MB/s transfers ses0: SCSI-3 SES Device da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing Enabled da0: 237464MB (486326272 512 byte sectors: 255H 63S/T 30272C) da1 at umass-sim0 bus 0 target 0 lun 0 da1: Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 959MB (1964032 512 byte sectors: 64H 32S/T 959C) SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! GEOM_LABEL: Label for provider da1s4 is msdosfs/Hypervisor0. GEOM_LABEL: Label for provider da1s5 is msdosfs/Hypervisor1. GEOM_LABEL: Label for provider da1s6 is msdosfs/Hypervisor2. GEOM_LABEL: Label for provider da1s8 is msdosfs/Hypervisor3. Trying to mount root from ufs:/dev/da0s1a bce0: link state changed to UP em0: link state changed to UP lagg0: link state changed to UP em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP ic_init: cam subsystem initialized 0] i_create_session: sessionID=0 0] i_create_session: error=0 0] i_setopt: maxRecvDataSegmentLength=65535 0] i_setopt: maXmitDataSegmentLength=8192 0] i_setopt: maxBurstLength=131072 0] i_setopt: maxRecvDataSegmentLength=65535 0] i_setopt: maXmitDataSegmentLength=65024 0] i_setopt: maxBurstLength=131072 0] i_setopt: opt.headerDigest='None' 0] ism_fullfeature: flag=1 0] _scan_target: target=0 da2 at iscsi0 bus 0 target 0 lun 0 da2: Fixed Direct Access SCSI-5 device da3 at iscsi0 bus 0 target 0 lun 1 da3: Fixed Direct Access SCSI-5 device Somebody can help me ? Thanks. Daniel From danny at cs.huji.ac.il Fri Sep 26 06:21:35 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Sep 26 06:21:42 2008 Subject: FreeBSD and ISCSI, Strange Problem In-Reply-To: <48DC1C97.6010701@dgnetwork.com.br> References: <48DC1C97.6010701@dgnetwork.com.br> Message-ID: > I'm with a very strange problem in the FreeBSD 7.0R > I use the iscsi_initiator to mount two devices of a Dell MD3000i, the > file system is UFS. > The problem occurs when I make a copy of a great directory for inside of > the /data/email directory, passed some minutes of beginning of copy, the > SSH connection stops to answer, when trying to open a new connection " > Password: " it isn't requested, in the console, when typing the user > "root" e to press enter, " Password: " also it isn't requested. The only > way to come back is restarting the FreeBSD. > > When press CTRL+T during the freeze it is shown: > # ssh root@10.0.20.10 > load: 0.76 cmd: ssh 86930 [sbwait] 0.00u 0.01s 0% 2076k > > In another freeze it showed state [ufs] > During freeze, send and receive pings work fine, but no service runing work. > > I already verified for some related LOG, however not see nothing related. hi Daniel, the problem is probably that iscsi is deadlocked, so fetch ftp://ftp/users/danny/freebsd/iscsi-2.1.tar.gz cd /usr/src tar xpzf /path-to-tar-file/iscsi-2.1.tar.gz (cd sys/modules/iscsi/initiator; make; make install) (cd sbin/iscontrol;make; make install) probably the safest is now to reboot. Let me know what happens. obrigado (thanks?), danny From daniel at dgnetwork.com.br Fri Sep 26 13:12:36 2008 From: daniel at dgnetwork.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Fri Sep 26 13:13:36 2008 Subject: FreeBSD and ISCSI, Strange Problem In-Reply-To: References: <48DC1C97.6010701@dgnetwork.com.br> Message-ID: <48DCD95D.9020400@dgnetwork.com.br> Danny Braniss escreveu: >> I'm with a very strange problem in the FreeBSD 7.0R >> I use the iscsi_initiator to mount two devices of a Dell MD3000i, the >> file system is UFS. >> The problem occurs when I make a copy of a great directory for inside of >> the /data/email directory, passed some minutes of beginning of copy, the >> SSH connection stops to answer, when trying to open a new connection " >> Password: " it isn't requested, in the console, when typing the user >> "root" e to press enter, " Password: " also it isn't requested. The only >> way to come back is restarting the FreeBSD. >> >> When press CTRL+T during the freeze it is shown: >> # ssh root@10.0.20.10 >> load: 0.76 cmd: ssh 86930 [sbwait] 0.00u 0.01s 0% 2076k >> >> In another freeze it showed state [ufs] >> During freeze, send and receive pings work fine, but no service runing work. >> >> I already verified for some related LOG, however not see nothing related. >> > > hi Daniel, > the problem is probably that iscsi is deadlocked, so fetch > ftp://ftp/users/danny/freebsd/iscsi-2.1.tar.gz > cd /usr/src > tar xpzf /path-to-tar-file/iscsi-2.1.tar.gz > (cd sys/modules/iscsi/initiator; make; make install) > (cd sbin/iscontrol;make; make install) > probably the safest is now to reboot. > > Let me know what happens. > > obrigado (thanks?), > danny > > > > > Danny, You typed the ftp wrong. Obrigado, thanks !! =) Daniel From westr at connection.ca Fri Sep 26 13:50:56 2008 From: westr at connection.ca (Ross) Date: Fri Sep 26 13:51:03 2008 Subject: dmesg output overlapping for multi isp(x) driver Message-ID: <349105225.20080926095055@connection.ca> (Running a 2 port qlogic/isp card on Freebsd 7.0/i386) Got a bunch of lines of kernel event logs from the isp driver that are overlapping due to a simultaneous event that both cards see (eg: fc fabric update) So I get output like this: -= start isp0: Name Server Database Changed isp0: PortID 0x020200 handle 0x1 role Initiator stayed WWNN 0x5001438001fff1dd WWPN 0x5001438001fff1dc isp0: PortID 0x020300 handle 0x2 role Initiator stayed i s p 1 : WNWaNmNe 0Sxer5v0e0r1 4D3a8t0a0b2a2s1e1 aC1hda nWgWePdN 0x5001438002211a1c isp0: PortID 0x020d00 handle 0x3 role Initiator stayed i s p 1 : PWoWrNtNI D0 x05x0001340328000 0h1afnfdfl2e2 d0 xW1W PrNo l0ex 50I0n1i4t3i8a0to0r1 fsftfa2y2ecd i s p 0 : PWoWrNtNI D0 x0x50002104e30800 h0a1nfdflfe1 d0fx 4W WrPoNl 0ex I5n00i1t4i3a8t0or0 1sftfafy1edde i s p 1 : PWoWrNtNI D0 x05x0001340338000 0h2a2n1d1l0ec 50 xW2W PrNo l0ex 5I0n0i1t4i3a8t0o0r2 2s1t1a0yce4d -= end (every other character is for isp0 then isp1) I've looked into how the driver does it's logging, and it's the same as many other drivers, so I don't see anything weird. Anyone have any ideas? Or is this more of a true kernel issue for not buffering the output properly? Cheers, Ross. -- From danny at cs.huji.ac.il Fri Sep 26 14:38:00 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Sep 26 14:38:12 2008 Subject: FreeBSD and ISCSI, Strange Problem In-Reply-To: Your message of Fri, 26 Sep 2008 09:45:17 -0300 . Message-ID: > the problem is probably that iscsi is deadlocked, so fetch > ftp://ftp/users/danny/freebsd/iscsi-2.1.tar.gzs;/ftp/;/&.cs.huji.ac.il; > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.1.tar.gz > Danny, > > You typed the ftp wrong. > > hi Daniel, oh well, it was before coffee :-) > Obrigado, thanks !! =) > > Daniel > > From bugmaster at FreeBSD.org Mon Sep 29 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 29 11:08:44 2008 Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org Message-ID: <200809291106.m8TB6u1a040929@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/126866 scsi [isp] [panic] kernel panic on card initialization o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 26 problems total. From johan at stromnet.se Tue Sep 30 15:11:49 2008 From: johan at stromnet.se (=?ISO-8859-1?Q?Johan_Str=F6m?=) Date: Tue Sep 30 15:12:22 2008 Subject: state of iscsi_initiator? Message-ID: <35FAB782-F576-4FB7-8633-67CFB63D9389@stromnet.se> Hi list, I'm looking into FreeBSDs iSCSI initiator capabilities, and I'm wondering how stable/used this is? Judging from the commits (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/iscsi/initiator/ ) there haven't been very much (iSCSI specific) activity since imported 14 months ago. Either nobody is using it thus not reporting bugs, or it is working very well ;) So, what I'm wondering is, how stable is this? Anyone using it successfully in production? Checking this list's archive I've seen some people with deadlock problems, but are there anyone using it without these problems? Or is the userbase that small? How about performance? Thanks! -- Johan From pisymbol at gmail.com Tue Sep 30 21:16:41 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Tue Sep 30 21:16:47 2008 Subject: kern/126866: [isp] [panic] kernel panic on card initialization In-Reply-To: <3c0b01820809251051q34a33fa5od5ec9fe9d853612@mail.gmail.com> References: <200809250910.m8P9A4MY047099@freefall.freebsd.org> <835218108.20080925113214@connection.ca> <3c0b01820809251051q34a33fa5od5ec9fe9d853612@mail.gmail.com> Message-ID: <3c0b01820809301416v416460e5gc0b4689febcf0905@mail.gmail.com> On Thu, Sep 25, 2008 at 1:51 PM, Alexander Sack wrote: > On Thu, Sep 25, 2008 at 11:32 AM, Ross wrote: >> >> PAP> I am having the same exact problem you were having using the same >> PAP> device. I started receiving this error on FBSD7-RELEASE and thought it >> PAP> was specific to that version. Naturally I upgraded to FBSD7-Stable as >> PAP> of today (9/25/2008), but still haven't been able to resolve this error, >> PAP> even with the patch presented here. Like you had mentioned on >> PAP> freebsd-scsi, the machine panic's roughly 50% of the time during boot. >> >> Actually, going over the trap output, it looks different than the >> output I had, so it might be a different issue in the end. >> >> Which kernel are you running? (i386/amd64), and is it possible to get >> the output of a dmesg, so we know what chipset the driver thinks it is? >> (Are you running an HP Blade w QHM6432 like I am?) >> >> Also, if you can set 'hint.isp.[01].debug=0x11F' in your >> /boot/device.hints file, it'll hopefully give some additional output >> to help track the problem down. >> >> Obviously the best is to compile in the kernel debugger as that'll >> give the exact place it crashes. > > > Yea totally. If you can get a stack trace that would be great (just > compile in the debugger support, reboot, and when you hit the panic do > a trace and just give us the function output (again exact addresses > not so much)). Paul do you have any update with this issue? I have my patches ready and I want to try to resolve yours if it indeed turns out to be a similar bug. Please let me know, -aps