From owner-freebsd-scsi@FreeBSD.ORG Mon May 16 11:07:13 2011 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD4491065677 for ; Mon, 16 May 2011 11:07:13 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CA56C8FC16 for ; Mon, 16 May 2011 11:07:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4GB7Dl1071325 for ; Mon, 16 May 2011 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4GB7Dx1071323 for freebsd-scsi@FreeBSD.org; Mon, 16 May 2011 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 May 2011 11:07:13 GMT Message-Id: <201105161107.p4GB7Dx1071323@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 11:07:14 -0000 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/154432 scsi [xpt] run_interrupt_driven_hooks: still waiting after o kern/153361 scsi [ciss] Smart Array 5300 boot/detect drive problem o kern/152250 scsi [ciss] [patch] Kernel panic when hw.ciss.expose_hidden o kern/151564 scsi [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 10 o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c s kern/149927 scsi [cam] hard drive not stopped before removing power dur o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/141934 scsi [cam] [patch] add support for SEAGATE DAT Scopion 130 o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/127717 scsi [ata] [patch] [request] - support write cache toggling o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123520 scsi [ahd] unable to boot from net while using ahd 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/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/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 bin/57088 scsi [cam] [patch] for a possible fd leak in libcam.c 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/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 45 problems total. From owner-freebsd-scsi@FreeBSD.ORG Tue May 17 19:51:49 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B679106564A for ; Tue, 17 May 2011 19:51:49 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [213.184.43.8]) by mx1.freebsd.org (Postfix) with ESMTP id 49F888FC0A for ; Tue, 17 May 2011 19:51:49 +0000 (UTC) Received: from kuller.raad.tartu.ee (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 892543986F for ; Tue, 17 May 2011 22:32:22 +0300 (EEST) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by kuller.raad.tartu.ee (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AOSAlMjHF27A for ; Tue, 17 May 2011 22:32:21 +0300 (EEST) Received: by kuller.raad.tartu.ee (Postfix, from userid 80) id 3E4EA3983E; Tue, 17 May 2011 22:32:21 +0300 (EEST) Received: from 226.16.50.84.dyn.estpak.ee (226.16.50.84.dyn.estpak.ee [84.50.16.226]) by webmail.raad.tartu.ee (Horde Framework) with HTTP; Tue, 17 May 2011 22:32:21 +0300 Message-ID: <20110517223221.42331bryjddv87y8@webmail.raad.tartu.ee> Date: Tue, 17 May 2011 22:32:21 +0300 From: Toomas Aas To: freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) X-Originating-IP: 84.50.16.226 X-Mailman-Approved-At: Tue, 17 May 2011 20:57:59 +0000 Subject: iscsi-2.3.1 on FreeBSD 7.3 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 19:51:49 -0000 Hello! Should the iSCSI initiator ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.3.1.tar.gz work on FreeBSD 7.3? I tried to install it, but iscsi_initiator.ko refuses to load: link_elf_obj: symbol calculate_crc32c undefined KLD file iscsi_initiator.ko - could not finalize loading Or maybe my installation procedure is wrong. I just copied the files in the distribution into corresponding directories under /usr/src where I have the full source tree and re-built and re-installed the kernel. Should I be doing something else? -- Toomas Aas From owner-freebsd-scsi@FreeBSD.ORG Wed May 18 06:04:31 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF83C106566B for ; Wed, 18 May 2011 06:04:31 +0000 (UTC) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1A6788FC12 for ; Wed, 18 May 2011 06:04:30 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 70DF11E; Wed, 18 May 2011 08:04:29 +0200 (MET DST) Date: Wed, 18 May 2011 08:04:29 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org, Kostik Belousov Message-ID: <20110518060429.GA4146@uriah.heep.sax.de> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua> <20110508104543.GB5364@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110508104543.GB5364@uriah.heep.sax.de> X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: Panic when removing a SCSI device entry X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 06:04:32 -0000 As Joerg Wunsch wrote: > > Please provide the full printout from the panic. Also, it would > > be useful to get the dump and do "p *dev" from the frame of > > destroy_devl(). I might need further information after the requested > > data is provided. > > Unfortunately, I somehow cannot get the system to provide a coredump. OK, it happened again last night, and I've got a DDB trace now. The panic is at a slightly different location (in notify_destroy()), but still a null pointer (apparently, dev->si_name is NULL now). [thread pid 33502 tid 100246 ] Stopped at strlen+0x8: cmpb $0,0(%edx) db> bt Tracing pid 33502 tid 100246 td 0xc8be92e0 strlen(0,c6dfc804,cc0b0e80,cc6e6800,e98804b8,...) at strlen+0x8 notify(ce0dc900,0,0,cc6e6800,c05ac3fb,...) at notify+0x3f destroy_devl(e98804f4,c0470a2b,ce0dc900,c07e9284,1,...) at destroy_devl+0x17b destroy_dev(ce0dc900,c07e9284,1,0,e988051c,...) at destroy_dev+0x10 sacleanup(cc0b0e80,c07f161b,12,0,e9880570,...) at sacleanup+0x8b camperiphfree(50,e9880994,c044b4de,e98809ac,c6e83c80,...) at camperiphfree+0x8f cam_periph_release_locked(cc0b0e80,0,cc0b0e80,e98809bc,c044b762,...) at cam_periph_release_locked+0x55 cam_periph_release(cc0b0e80,14c,cc814200,e98809fc,e98809e8,...) at cam_periph_release+0x60 saopen(cc814200,1,2000,c8be92e0,c07cc465,...) at saopen+0x263 giant_open(cc814200,1,2000,c8be92e0,e9880b08,...) at giant_open+0x93 devfs_open(e9880b08,e9880b30,c061c4fa,c0840e60,e9880b08,...) at devfs_open+0x102 VOP_OPEN_APV(c0840e60,e9880b08,c075ad1a,cacbe788,0,...) at VOP_OPEN_APV+0x42 vn_open_cred(e9880b78,e9880c2c,0,0,c7fba280,...) at vn_open_cred+0x4ba vn_open(e9880b78,e9880c2c,0,c7f49150,3,...) at vn_open+0x3b kern_openat(c8be92e0,ffffff9c,804a0bb,0,1,...) at kern_openat+0x12c kern_open(c8be92e0,804a0bb,0,0,6,...) at kern_open+0x35 open(c8be92e0,e9880cec,0,c,28176088,...) at open+0x30 syscallenter(c8be92e0,e9880ce4,e9880d1c,c07ad276,c8be92e0,...) at syscallenter+0x329 syscall(e9880d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 syscall (5, FreeBSD ELF32, open), eip = 0x2817608f, esp = 0xbfbfec7c, ebp = 0xbfbfee18 --- db> show reg cs 0x20 ds 0x28 es 0x28 fs 0x8 ss 0x28 eax 0 ecx 0x8 edx 0 ebx 0x2 esp 0xe9880468 ebp 0xe9880468 esi 0xce0dc900 edi 0xcc6e6800 eip 0xc0620568 strlen+0x8 efl 0x10202 strlen+0x8: cmpb $0,0(%edx) db> show cdev geom.ctl 0xc6d1a100 devctl 0xc6ccc700 console 0xc6ccc600 sndstat 0xc6ccc500 ptmx 0xc6ccc400 ctty 0xc6ccc300 mem 0xc6ccc200 kmem 0xc6db3800 audit 0xc6db3700 bpf 0xc6db3600 bpf0 0xc6db3500 null 0xc6db3400 zero 0xc6db3300 fd/0 0xc6db3200 stdin 0xc6db3100 fd/1 0xc6db3000 stdout 0xc6db2e00 fd/2 0xc6db2d00 stderr 0xc6db2c00 klog 0xc6db2b00 pci 0xc6db2a00 midistat 0xc6db2900 kbdmux0 0xc6db2700 kbd0 0xc6db2600 random 0xc6db2400 urandom 0xc6db2300 sysmouse 0xc6db2200 io 0xc6db2100 speaker 0xc6db2000 fido 0xc6d1be00 ata 0xc6d1bd00 acpi 0xc6d1b800 ttyu2 0xc6e7dd00 ttyu2.init 0xc6e7d800 ttyu2.lock 0xc6e7d700 cuau2 0xc6e7d600 cuau2.init 0xc6e7d500 cuau2.lock 0xc6e7d400 ttyu3 0xc6e7d000 ttyu3.init 0xc6e7ce00 ttyu3.lock 0xc6e7cd00 cuau3 0xc6e7cc00 cuau3.init 0xc6e7cb00 cuau3.lock 0xc6e7ca00 ttyu4 0xc6e7c600 ttyu4.init 0xc6e7c500 ttyu4.lock 0xc6e7c800 cuau4 0xc6e7c900 cuau4.init 0xc6e7d200 cuau4.lock 0xc6e7d300 ttyu5 0xc6e7e400 ttyu5.init 0xc6e7e500 ttyu5.lock 0xc6e7e600 cuau5 0xc6e7e700 cuau5.init 0xc6e7e800 cuau5.lock 0xc6e7e900 ttyu6 0xc6e7e000 ttyu6.init 0xc6f01e00 ttyu6.lock 0xc6f01d00 cuau6 0xc6f01c00 cuau6.init 0xc6f01b00 cuau6.lock 0xc6f01a00 ttyu7 0xc6f01600 ttyu7.init 0xc6f01500 ttyu7.lock 0xc6f01400 cuau7 0xc6f01300 cuau7.init 0xc6f01200 cuau7.lock 0xc6f01100 ttyu8 0xc6f00c00 ttyu8.init 0xc6f00b00 ttyu8.lock 0xc6f00a00 cuau8 0xc6f00900 cuau8.init 0xc6f00800 cuau8.lock 0xc6f00700 ttyu9 0xc6f00300 ttyu9.init 0xc6f00200 ttyu9.lock 0xc6f00100 cuau9 0xc6f00000 cuau9.init 0xc6e7fe00 cuau9.lock 0xc6e7fd00 ttyv0 0xc6f01000 ttyv1 0xc6f01800 ttyv2 0xc6fa5d00 ttyv3 0xc6fa5c00 ttyv4 0xc6fa5b00 ttyv5 0xc6fa5a00 ttyv6 0xc6fa5900 ttyv7 0xc6fa5800 ttyv8 0xc6fa5700 ttyv9 0xc6fa5600 ttyva 0xc6fa5500 ttyvb 0xc6fa5400 ttyvc 0xc6fa5300 ttyvd 0xc6fa5200 ttyve 0xc6fa5100 ttyvf 0xc6fa5000 consolectl 0xc6fa4e00 lpt0 0xc6fa4b00 lpt0.ctl 0xc6fa4a00 ppi0 0xc6fa4900 ttyu0 0xc6fa4600 ttyu0.init 0xc6fa4500 ttyu0.lock 0xc6fa4400 cuau0 0xc6fa4300 cuau0.init 0xc6fa4200 cuau0.lock 0xc6fa4100 usbctl 0xc71d6d00 mdctl 0xc71d6b00 devstat 0xc71d6a00 fd0 0xc71d6900 usb/0.1.0 0xc71d6700 ugen0.1 0xc71d6600 usb/1.1.0 0xc71d6500 ugen1.1 0xc71d6400 usb/0.1.1 0xc71d6300 usb/1.1.1 0xc71d5d00 xpt0 0xc71d5800 mixer0 0xc71d4a00 mixer1 0xc71d4000 mixer2 0xc7216a00 acd0 0xc7216100 ad4 0xc7216000 ad4s1 0xc7215e00 ad4s1b 0xc7215d00 ad4s1h 0xc7215c00 gvinum/sound 0xc728de00 gvinum/squid 0xc728dd00 gvinum/camel 0xc728dc00 gvinum/tmp 0xc728db00 gvinum/dump 0xc728da00 gvinum/bacula_db 0xc728d900 gvinum/junk 0xc728d800 gvinum/home 0xc728d700 gvinum/home_cvs 0xc728d600 gvinum/var 0xc728d500 gvinum/usr 0xc728d400 gvinum/local 0xc728d300 gvinum/root 0xc728d200 gvinum/obj 0xc728d100 gvinum/upload 0xc728d000 gvinum/mysql 0xc72a4400 gvinum/pdf 0xc72a4300 gvinum/distfiles 0xc72a4200 gvinum/news 0xc72a4100 gvinum/src 0xc72a4000 gvinum/ports 0xc72a3e00 gvinum/temp 0xc72a3d00 ufsid/4dd10a3a6f636a7d 0xc72a3100 usb/1.2.0 0xc72a2700 ugen1.2 0xc72a2600 usb/1.2.1 0xc7290800 cd0 0xc7290500 pass0 0xc7290700 pass1 0xc7290d00 pass2 0xc7290e00 da0 0xc72e8800 da0a 0xc72a2900 da0h 0xc72a2a00 da1 0xc72a2b00 ufsid/4856d98a00081994 0xc72a2c00 da1a 0xc72a2d00 da1h 0xc72e6700 usb/0.2.0 0xc72e7100 ugen0.2 0xc72e6e00 usb/0.2.1 0xc72e6c00 usb/0.3.0 0xc7375300 ugen0.3 0xc72a3400 usb/0.3.1 0xc7376d00 ukbd0 0xc7377200 kbd1 0xc72a3500 usb/0.4.0 0xc743a400 ugen0.4 0xc743a300 usb/0.4.1 0xc743a000 ums0 0xc7439500 usb/0.5.0 0xc7438c00 ugen0.5 0xc7438b00 usb/0.5.1 0xc7438a00 usb/0.6.0 0xc7501800 ugen0.6 0xc7501700 usb/0.6.2 0xc7501400 pf 0xc75d7500 nfslock 0xc7501a00 tap0 0xc7501100 apm0 0xc75d9600 dsp2.0 0xc82a3500 dsp1.0 0xc7f9dc00 dsp0.0 0xc7f9db00 pts/0 0xc8902d00 pts/1 0xc82a1600 pts/2 0xc89e0a00 pts/3 0xc8901a00 ptyp0 0xc8902c00 ttyp0 0xc82a3a00 pts/4 0xc819f100 pts/5 0xc89de200 pts/6 0xc8902600 tun0 0xc9f99300 pts/7 0xcc35a700 ptyp1 0xcc210a00 ttyp1 0xcc1b9600 pass3 0xce096c00 ch0 0xce113400 nsa0.0 0xcc814200 esa0.0 0xcdc50600 nsa0 0xcc81c800 esa0 0xcc871a00 sa0.1 0xce083c00 nsa0.1 0xccec1d00 esa0.1 0xccd63400 sa0.2 0xcc840e00 nsa0.2 0xcc7dc800 esa0.2 0xcc841500 sa0.3 0xce083400 nsa0.3 0xcdc50400 esa0.3 0xce084600 ptyp2 0xcf8b1000 ttyp2 0xcf929100 pass4 0xce989900 sa0.ctl 0xced5f400 sa0.0 0xce991100 nsa0.0 0xcea91c00 esa0.0 0xced17900 sa0 0xce71d500 nsa0 0xced60400 esa0 0xce956800 sa0.1 0xce68ab00 nsa0.1 0xceb10a00 esa0.1 0xced1f300 sa0.2 0xce6dd400 nsa0.2 0xcec9c800 esa0.2 0xce960100 sa0.3 0xcea91d00 nsa0.3 0xce9bb700 esa0.3 0xceb99d00 db> panic panic: from debugger cpuid = 0 Uptime: 1d5h4m38s Physical memory: 3575 MB Dumping 365 MB: 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Rebooting... As you can see, I've got a coredump this time, so I can run kgdb on that. Currently, I'm compiling an INVARIANTS kernel, and will boot that one soon - though I wonder whether it really makes sense here, as the picture is different from last time (due to Kostik's suggested patch?). One observation that comes to mind: with devices appearing and disappearing, the CAM subsystem sometimes suffers from some confusion if a device is still held open by the time it disappears on the bus. The device then appears in "camcontrol devlist" as just "sa0", without a pass device associated. When powering it on again, and reprobing it, it becomes "sa0, pass4, sa0" or such. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Wed May 18 08:27:47 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 616BC106566B; Wed, 18 May 2011 08:27:47 +0000 (UTC) Date: Wed, 18 May 2011 08:27:47 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20110518082747.GA75790@freebsd.org> References: <20110518082459.GA71662@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110518082459.GA71662@freebsd.org> Cc: freebsd-scsi@freebsd.org Subject: Re: issues with new sata dvd-drive X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 08:27:47 -0000 sorry. i wanted to cc freebsd-scsi and accidently wrote freebsd-cam. On Wed May 18 11, Alexander Best wrote: > hi there, > > i recently switched my old pata dvd-drive with a new sata one: > > cd0: Removable CD-ROM SCSI-0 device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: cd present [355062 x 2048 byte records] > > however now i experience the following issues: > > 1) > otaku% recoverdisk /dev/cd0 ~/test.iso > Bigsize = 1048576, medsize = 65536, minsize = 2048 > start size block-len state done remaining % done > 617611264 514048 514048 0 617611264 514048 99.91684 > 617611264 514048 failed (Device not configured) > > 2) > otaku% dd if=/dev/cd0 of=/home/arundel/test.iso bs=1048576 > dd: /dev/cd0: Device not configured > 589+0 records in > 589+0 records out > 617611264 bytes transferred in 120.144189 secs (5140584 bytes/sec) > > 3) > otaku% dd if=/dev/cd0 of=/home/arundel/test.iso bs=65536 > dd: /dev/cd0: Device not configured > 9431+0 records in > 9431+0 records out > 618070016 bytes transferred in 120.345870 secs (5135781 bytes/sec) > > 4) > otaku% dd if=/dev/cd0 of=/home/arundel/test.iso bs=2048 > load: 0.20 cmd: dd 50488 [physrd] 219.96r 0.17u 8.41s 1% 1016k > 203127+0 records in > 203127+0 records out > 416004096 bytes transferred in 219.746150 secs (1893112 bytes/sec) > dd: /dev/cd0: Device not configured > 301817+0 records in > 301817+0 records out > 618121216 bytes transferred in 371.835266 secs (1662352 bytes/sec) > > ...also when issuing this command (4)), at some point the drive starts spinning > down and then up again several times. this doesn't happen with a larger > blocksize (see 1-3)). i hit ctrl+t at the exact moment the drive started > spinning down the first time. > > i'm seeing the following warnings via dmesg: > > (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 4 9a c0 0 0 3b 0 > (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich2:0:0:0): SCSI status: Check Condition > (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) > (cd0:ahcich2:0:0:0): cddone: got error 0x6 back > (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 4 9a c0 0 0 3b 0 > (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich2:0:0:0): SCSI status: Check Condition > (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) > (cd0:ahcich2:0:0:0): cddone: got error 0x6 back > (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 4 9a c0 0 0 3b 0 > (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich2:0:0:0): SCSI status: Check Condition > (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) > (cd0:ahcich2:0:0:0): cddone: got error 0x6 back > > i'm running a recent HEAD (r221878) on amd64. my kernel contains > > device ahci > device scbus > device cd > device pass > > this my sata controller: > > ahci0: port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xfa206000-0xfa2067ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported > > two other issues i'm experiencing (if their really are issues and not me doing > something wrong are: > > 1) > when running cdrecord(1) to burn a DVD (DVD+R) i get the following warning: > > cdrecord: DMA speed too slow (OK for 10x). Cannot write at speed 18x. > > 2) > otaku% sudo cdrecord blank=fast > Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling > Using libscg version 'schily-0.9'. > No target specified, trying to find one... > Using dev=2,0,0. > Device type : Removable CD-ROM > Version : 0 > Response Format: 2 > Capabilities : > Vendor_info : 'HL-DT-ST' > Identifikation : 'DVDRAM GH24NS50 ' > Revision : 'XP02' > Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > Driver flags : MMC-3 SWABAUDIO BURNFREE > Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP > Starting to write CD/DVD/BD at speed 4 in real BLANK mode for single session. > Last chance to quit, starting real write 0 seconds. Operation starts. > > taku% dd if=/dev/random of=./test.file bs=1m count=10 > 10+0 records in > 10+0 records out > 10485760 bytes transferred in 0.635699 secs (16494850 bytes/sec) > > otaku% sudo cdrecord test.file > cdrecord: No write mode specified. > cdrecord: Assuming -sao mode. > cdrecord: If your drive does not accept -sao, try -tao. > cdrecord: Future versions of cdrecord may have different drive dependent defaults. > Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling > Using libscg version 'schily-0.9'. > No target specified, trying to find one... > Using dev=2,0,0. > Device type : Removable CD-ROM > Version : 0 > Response Format: 2 > Capabilities : > Vendor_info : 'HL-DT-ST' > Identifikation : 'DVDRAM GH24NS50 ' > Revision : 'XP02' > Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > Driver flags : MMC-3 SWABAUDIO BURNFREE > Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP > Starting to write CD/DVD/BD at speed 4 in real SAO mode for single session. > Last chance to quit, starting real write 0 seconds. Operation starts. > Turning BURN-Free off > cdrecord: WARNING: Drive returns wrong startsec (0) using -150 > Track 01: Total bytes read/written: 10485760/10485760 (5120 sectors). > > otaku% dd if=/dev/cd0 of=./test.dao bs=1m count=10 > 10+0 records in > 10+0 records out > 10485760 bytes transferred in 9.587938 secs (1093641 bytes/sec) > > otaku% sudo cdrecord blank=fast > Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling > Using libscg version 'schily-0.9'. > No target specified, trying to find one... > Using dev=2,0,0. > Device type : Removable CD-ROM > Version : 0 > Response Format: 2 > Capabilities : > Vendor_info : 'HL-DT-ST' > Identifikation : 'DVDRAM GH24NS50 ' > Revision : 'XP02' > Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > Driver flags : MMC-3 SWABAUDIO BURNFREE > Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP > Starting to write CD/DVD/BD at speed 4 in real BLANK mode for single session. > Last chance to quit, starting real write 0 seconds. Operation starts. > > otaku% sudo cdrecord -tao test.file > Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling > Using libscg version 'schily-0.9'. > No target specified, trying to find one... > Using dev=2,0,0. > Device type : Removable CD-ROM > Version : 0 > Response Format: 2 > Capabilities : > Vendor_info : 'HL-DT-ST' > Identifikation : 'DVDRAM GH24NS50 ' > Revision : 'XP02' > Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > Driver flags : MMC-3 SWABAUDIO BURNFREE > Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP > Starting to write CD/DVD/BD at speed 4 in real TAO mode for single session. > Last chance to quit, starting real write 0 seconds. Operation starts. > Track 01: Total bytes read/written: 10485760/10485760 (5120 sectors). > otaku% dd if=/dev/cd0 of=./test.tao bs=1m count=10 > 10+0 records in > 10+0 records out > 10485760 bytes transferred in 6.694222 secs (1566390 bytes/sec) > > otaku% diff test.file test.dao > > otaku% diff test.file test.tao > > ...so eventually nothing gets broken by the warning about the wrong startsec. > > cheers. > alex > > -- > a13x > -- a13x From owner-freebsd-scsi@FreeBSD.ORG Wed May 18 09:34:17 2011 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EA69106566B; Wed, 18 May 2011 09:34:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 75ADF8FC0A; Wed, 18 May 2011 09:34:16 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA15794; Wed, 18 May 2011 12:34:15 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QMd8w-000ARr-Mj; Wed, 18 May 2011 12:34:14 +0300 Message-ID: <4DD39296.2090805@FreeBSD.org> Date: Wed, 18 May 2011 12:34:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alexander Best References: <20110518082459.GA71662@freebsd.org> <20110518082747.GA75790@freebsd.org> In-Reply-To: <20110518082747.GA75790@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: issues with new sata dvd-drive X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 09:34:17 -0000 on 18/05/2011 11:27 Alexander Best said the following: > sorry. i wanted to cc freebsd-scsi and accidently wrote freebsd-cam. > > On Wed May 18 11, Alexander Best wrote: >> hi there, >> >> i recently switched my old pata dvd-drive with a new sata one: >> >> cd0: Removable CD-ROM SCSI-0 device >> cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) >> cd0: cd present [355062 x 2048 byte records] >> >> however now i experience the following issues: Just some sanity checks: 1. does the same happen with any media you try? 2. does the same not happen with the media you tried with any other drive? -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Wed May 18 09:38:19 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E67A1065700 for ; Wed, 18 May 2011 09:38:19 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6B88FC13 for ; Wed, 18 May 2011 09:38:18 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs.huji.ac.il with esmtp id 1QMcqb-000DON-2N; Wed, 18 May 2011 12:15:17 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Toomas Aas In-reply-to: <20110517223221.42331bryjddv87y8@webmail.raad.tartu.ee> References: <20110517223221.42331bryjddv87y8@webmail.raad.tartu.ee> Comments: In-reply-to Toomas Aas message dated "Tue, 17 May 2011 22:32:21 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 May 2011 12:15:17 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-scsi@freebsd.org Subject: Re: iscsi-2.3.1 on FreeBSD 7.3 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 09:38:19 -0000 > Hello! > > Should the iSCSI initiator > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.3.1.tar.gz work on > FreeBSD 7.3? I tried to install it, but iscsi_initiator.ko refuses to > load: > > link_elf_obj: symbol calculate_crc32c undefined > KLD file iscsi_initiator.ko - could not finalize loading > > Or maybe my installation procedure is wrong. I just copied the files > in the distribution into corresponding directories under /usr/src > where I have the full source tree and re-built and re-installed the > kernel. Should I be doing something else? > > -- > Toomas Aas I haven't tested on 7.x for a long time, but the patch included should solve the missing routine problem: diff -r 3f2c1e5002dd sys/dev/iscsi/initiator/isc_subr.c --- a/sys/dev/iscsi/initiator/isc_subr.c Thu Feb 03 12:05:48 2011 +0200 +++ b/sys/dev/iscsi/initiator/isc_subr.c Wed May 18 12:11:00 2011 +0300 @@ -77,6 +77,102 @@ return q; } +#if __FreeBSD_version < 800000 +/*****************************************************************/ +/* */ +/* CRC LOOKUP TABLE */ +/* ================ */ +/* The following CRC lookup table was generated automagically */ +/* by the Rocksoft^tm Model CRC Algorithm Table Generation */ +/* Program V1.0 using the following model parameters: */ +/* */ +/* Width : 4 bytes. */ +/* Poly : 0x1EDC6F41L */ +/* Reverse : TRUE. */ +/* */ +/* For more information on the Rocksoft^tm Model CRC Algorithm, */ +/* see the document titled "A Painless Guide to CRC Error */ +/* Detection Algorithms" by Ross Williams */ +/* (ross@guest.adelaide.edu.au.). This document is likely to be */ +/* in the FTP archive "ftp.adelaide.edu.au/pub/rocksoft". */ +/* */ +/*****************************************************************/ + +static uint32_t crc32Table[256] = { + 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, + 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, + 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, + 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, + 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, + 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, + 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, + 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, + 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, + 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, + 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, + 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, + 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, + 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, + 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, + 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, + 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, + 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, + 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, + 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, + 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, + 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, + 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, + 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, + 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, + 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, + 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, + 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, + 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, + 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, + 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, + 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, + 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, + 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, + 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, + 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, + 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, + 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, + 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, + 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, + 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, + 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, + 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, + 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, + 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, + 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, + 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, + 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, + 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, + 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, + 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, + 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, + 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, + 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, + 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, + 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, + 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, + 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, + 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, + 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, + 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, + 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, + 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, + 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L +}; + +static __inline int +calculate_crc32c(uint32_t crc, const void *buf, size_t size) +{ + while (size--) + crc = crc32Table[(crc ^ *p++) & 0xff] ^ (crc >> 8); + return crc; +} +#endif static uint32_t i_crc32c(const void *buf, size_t size, uint32_t crc) From owner-freebsd-scsi@FreeBSD.ORG Wed May 18 10:24:49 2011 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0D5FA1065670; Wed, 18 May 2011 10:24:49 +0000 (UTC) Date: Wed, 18 May 2011 10:24:49 +0000 From: Alexander Best To: Andriy Gapon Message-ID: <20110518102448.GA88446@freebsd.org> References: <20110518082459.GA71662@freebsd.org> <20110518082747.GA75790@freebsd.org> <4DD39296.2090805@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD39296.2090805@FreeBSD.org> Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: issues with new sata dvd-drive X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 10:24:49 -0000 On Wed May 18 11, Andriy Gapon wrote: > on 18/05/2011 11:27 Alexander Best said the following: > > sorry. i wanted to cc freebsd-scsi and accidently wrote freebsd-cam. > > > > On Wed May 18 11, Alexander Best wrote: > >> hi there, > >> > >> i recently switched my old pata dvd-drive with a new sata one: > >> > >> cd0: Removable CD-ROM SCSI-0 device > >> cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > >> cd0: cd present [355062 x 2048 byte records] > >> > >> however now i experience the following issues: > > Just some sanity checks: > 1. does the same happen with any media you try? > 2. does the same not happen with the media you tried with any other drive? i dug into this a little further and it appears that this only happens with CD-Rs. using CD-ROMs, DVDs or DVD+Rs this doesn't happen. i tested this with CD-Rs recorded under windows and freebsd (created with burncd(1), growisofs(1) and cdrecord(1)) and they all suffer the same issue. i also tried this with audio cds and here recoverdisk(1) fails no matter, if it's a CD-R or a CD-ROM: otaku% recoverdisk /dev/cd0 ./test10.iso Bigsize = 1048576, medsize = 65536, minsize = 2048 start size block-len state done remaining % done 0 1048576 243052544 0 0 243052544 0.00000 0 1048576 failed (Device not configured) cheers. alex > > -- > Andriy Gapon -- a13x From owner-freebsd-scsi@FreeBSD.ORG Wed May 18 11:23:11 2011 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AB55106566B; Wed, 18 May 2011 11:23:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E4DB78FC12; Wed, 18 May 2011 11:23:09 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA18829; Wed, 18 May 2011 14:23:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DD3AC1B.9080208@FreeBSD.org> Date: Wed, 18 May 2011 14:23:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alexander Best References: <20110518082459.GA71662@freebsd.org> <20110518082747.GA75790@freebsd.org> <4DD39296.2090805@FreeBSD.org> <20110518102448.GA88446@freebsd.org> In-Reply-To: <20110518102448.GA88446@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: issues with new sata dvd-drive X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 11:23:11 -0000 on 18/05/2011 13:24 Alexander Best said the following: > i dug into this a little further and it appears that this only happens with > CD-Rs. using CD-ROMs, DVDs or DVD+Rs this doesn't happen. i tested this with > CD-Rs recorded under windows and freebsd (created with burncd(1), growisofs(1) > and cdrecord(1)) and they all suffer the same issue. Are the CD-Rs from the same vendor/batch? Could it possibly be that there is some problem with firmware recognizing those disks? > i also tried this with audio cds and here recoverdisk(1) fails no matter, if > it's a CD-R or a CD-ROM: I think that it's not supposed to work for Audio-CDs with cd(4) [unlike acd(4) and then with bs of 2352]. To digitally extract audio data you have to go via pass(4) and appropriate SCSI/MMC commands. > otaku% recoverdisk /dev/cd0 ./test10.iso > Bigsize = 1048576, medsize = 65536, minsize = 2048 > start size block-len state done remaining % done > 0 1048576 243052544 0 0 243052544 0.00000 > 0 1048576 failed (Device not configured) -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Wed May 18 12:07:50 2011 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 76DA71065670; Wed, 18 May 2011 12:07:50 +0000 (UTC) Date: Wed, 18 May 2011 12:07:50 +0000 From: Alexander Best To: Andriy Gapon Message-ID: <20110518120750.GA2642@freebsd.org> References: <20110518082459.GA71662@freebsd.org> <20110518082747.GA75790@freebsd.org> <4DD39296.2090805@FreeBSD.org> <20110518102448.GA88446@freebsd.org> <4DD3AC1B.9080208@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD3AC1B.9080208@FreeBSD.org> Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: issues with new sata dvd-drive X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 12:07:50 -0000 On Wed May 18 11, Andriy Gapon wrote: > on 18/05/2011 13:24 Alexander Best said the following: > > i dug into this a little further and it appears that this only happens with > > CD-Rs. using CD-ROMs, DVDs or DVD+Rs this doesn't happen. i tested this with > > CD-Rs recorded under windows and freebsd (created with burncd(1), growisofs(1) > > and cdrecord(1)) and they all suffer the same issue. > > Are the CD-Rs from the same vendor/batch? > Could it possibly be that there is some problem with firmware recognizing those disks? > > > i also tried this with audio cds and here recoverdisk(1) fails no matter, if > > it's a CD-R or a CD-ROM: > > I think that it's not supposed to work for Audio-CDs with cd(4) [unlike acd(4) and > then with bs of 2352]. > To digitally extract audio data you have to go via pass(4) and appropriate > SCSI/MMC commands. i ran cdda2wav(1) and also got an error with a CD-R audio cd: No target specified, trying to find one... Using dev=2,0,0. Type: ROM, Vendor 'HL-DT-ST' Model 'DVDRAM GH24NS50 ' Revision 'XP02' MMC+CDDA 307200 bytes buffer memory requested, transfer size 65536 bytes, 4 buffers, 27 sectors #Cdda2wav version 3.01a04_freebsd_9.0-current_amd64_amd64, real time sched., soundcard, libparanoia support AUDIOtrack pre-emphasis copy-permitted tracktype channels 1-14 no no audio 2 Table of Contents: total tracks:14, (total time 60:03.00) 1.( 4:31.10), 2.( 3:07.55), 3.( 3:31.07), 4.( 3:46.15), 5.( 4:37.00), 6.( 3:36.63), 7.( 6:40.32), 8.( 3:24.18), 9.( 4:34.67), 10.( 4:25.38), 11.( 4:16.70), 12.( 4:11.12), 13.( 3:48.15), 14.( 5:31.48) Table of Contents: starting sectors 1.( 0), 2.( 20335), 3.( 34415), 4.( 50247), 5.( 67212), 6.( 87987), 7.( 104250), 8.( 134282), 9.( 149600), 10.( 170217), 11.( 190130), 12.( 209400), 13.( 228237), 14.( 245352), lead-out( 270225) CDINDEX discid: qYTN3dI8JolIM00IDYXcVYWwNYw- CDDB discid: 0xd60e130e CD-Text: not detected CD-Extra: not detected No media catalog number present. scanning for ISRCs: 14 ... index scan: 14...cdda2wav: Could not find index transition for pre-gap. samplefile size will be 635569244 bytes. recording 3603.0000 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'... percent_done: 100% track 1 recorded successfully 100% track 2 recorded successfully 100% track 3 recorded successfully 100% track 4 recorded successfully 100% track 5 recorded successfully 100% track 6 recorded successfully 100% track 7 recorded successfully 100% track 8 recorded successfully 100% track 9 recorded successfully 100% track 10 recorded successfully 100% track 11 recorded successfully 100% track 12 recorded successfully 100% track 13 recorded successfully 99%cdda2wav: Input/output error. ReadCD MMC 12: scsi sendcmd: retryable error CDB: BE 04 00 04 1F 88 00 00 09 10 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 03 00 00 00 00 0A 00 00 00 80 10 90 00 00 00 00 Sense Key: 0x3 Medium Error, Segment 0 Sense Code: 0x10 Qual 0x90 (id crc or ecc error) [No matching qualifier] Fru 0x0 Sense flags: Blk 0 (not valid) resid: 11760 cmd finished after 8.904s timeout 60s 100% track 14 recorded successfully with a retail audio CD i don't get any error. so this is the same as with data cds. i tried with three different manufacturers: Disk type: Long strategy type (Cyanine, AZO or similar) Manuf. index: 26 Manufacturer: TDK Corporation Disk type: Long strategy type (Cyanine, AZO or similar) Manuf. index: 11 Manufacturer: Mitsubishi Chemical Corporation Disk type: Short strategy type (Phthalocyanine or similar) Manuf. index: 27 Manufacturer: Prodisc Technology Inc. ...all suffer from the same issue. my drive's firmware is XP02 and i believe it's the latest one. cheers. alex > > > otaku% recoverdisk /dev/cd0 ./test10.iso > > Bigsize = 1048576, medsize = 65536, minsize = 2048 > > start size block-len state done remaining % done > > 0 1048576 243052544 0 0 243052544 0.00000 > > 0 1048576 failed (Device not configured) > > > -- > Andriy Gapon -- a13x From owner-freebsd-scsi@FreeBSD.ORG Wed May 18 12:47:55 2011 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D97381065670; Wed, 18 May 2011 12:47:55 +0000 (UTC) Date: Wed, 18 May 2011 12:47:55 +0000 From: Alexander Best To: Andriy Gapon Message-ID: <20110518124755.GA8500@freebsd.org> References: <20110518082459.GA71662@freebsd.org> <20110518082747.GA75790@freebsd.org> <4DD39296.2090805@FreeBSD.org> <20110518102448.GA88446@freebsd.org> <4DD3AC1B.9080208@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD3AC1B.9080208@FreeBSD.org> Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: issues with new sata dvd-drive X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 12:47:55 -0000 On Wed May 18 11, Andriy Gapon wrote: > on 18/05/2011 13:24 Alexander Best said the following: > > i dug into this a little further and it appears that this only happens with > > CD-Rs. using CD-ROMs, DVDs or DVD+Rs this doesn't happen. i tested this with > > CD-Rs recorded under windows and freebsd (created with burncd(1), growisofs(1) > > and cdrecord(1)) and they all suffer the same issue. > > Are the CD-Rs from the same vendor/batch? > Could it possibly be that there is some problem with firmware recognizing those disks? > > > i also tried this with audio cds and here recoverdisk(1) fails no matter, if > > it's a CD-R or a CD-ROM: > > I think that it's not supposed to work for Audio-CDs with cd(4) [unlike acd(4) and > then with bs of 2352]. > To digitally extract audio data you have to go via pass(4) and appropriate > SCSI/MMC commands. btw i also got an error when trying to blank an entire CD-RW: otaku% clear ; sudo cdrecord -v blank=all Cdrecord-ProDVD-ProBD-Clone 3.01a04 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Joerg Schilling TOC Type: 1 = CD-ROM Using libscg version 'schily-0.9'. SCSI buffer size: 65536 No target specified, trying to find one... Using dev=2,0,0. atapi: 0 Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'HL-DT-ST' Identifikation : 'DVDRAM GH24NS50 ' Revision : 'XP02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Current: CD-RW Profile: DVD-RAM Profile: DVD-R sequential recording Profile: DVD-R/DL sequential recording Profile: DVD-R/DL layer jump recording Profile: DVD-RW sequential recording Profile: DVD-RW restricted overwrite Profile: DVD+RW Profile: DVD+R Profile: DVD+R/DL Profile: DVD-ROM Profile: CD-R Profile: CD-RW (current) Profile: CD-ROM (current) Profile: Removable Disk Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP Drive buf size : 1053696 = 1029 KB Drive pbuf size: 1966080 = 1920 KB Drive DMA Speed: 16803 kB/s 95x CD 12x DVD 3x BD Current Secsize: 2048 ATIP info from disk: Indicated writing power: 6 Reference speed: 2 Disk Is not unrestricted Disk Is erasable ATIP start of lead in: -11078 (97:34/22) ATIP start of lead out: 359849 (79:59/74) 1T speed low: 0 (reserved val 0) 1T speed high: 4 2T speed low: 0 (reserved val 5) 2T speed high: 0 (reserved val 12) power mult factor: 3 5 recommended erase/write power: 3 A1 values: 02 3A B0 A2 values: 5C C6 26 Disk type: Phase change Manuf. index: 11 Manufacturer: Mitsubishi Chemical Corporation Capacity Blklen/Sparesz. Format-type Type 5122 2048 0x00 Formatted Media Starting to write CD/DVD/BD at speed 4 in real BLANK mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Performing OPC... Blanking entire disk cdrecord: Input/output error. blank unit: scsi sendcmd: cmd timeout after 1010.067 (9600) s CDB: A1 00 00 00 00 00 00 00 00 00 00 00 cmd finished after 1010.067s timeout 9600s cdrecord: Cannot blank disk, aborting. dmesg says: (cd0:ahcich2:0:0:0): READ(10). CDB: 28 0 0 5 70 80 0 0 3c 0 (cd0:ahcich2:0:0:0): CAM status: SCSI Status Error (cd0:ahcich2:0:0:0): SCSI status: Check Condition (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:28,a,0,80 asc:64,0 (Illegal mode for this track) (cd0:ahcich2:0:0:0): cddone: got error 0x6 back ahcich2: Timeout on slot 4 ahcich2: is 00000000 cs 00000010 ss 00000000 rs 00000010 tfd c0 serr 00000000 cheers. alex > > > otaku% recoverdisk /dev/cd0 ./test10.iso > > Bigsize = 1048576, medsize = 65536, minsize = 2048 > > start size block-len state done remaining % done > > 0 1048576 243052544 0 0 243052544 0.00000 > > 0 1048576 failed (Device not configured) > > > -- > Andriy Gapon -- a13x From owner-freebsd-scsi@FreeBSD.ORG Wed May 18 15:11:35 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 596DB106564A for ; Wed, 18 May 2011 15:11:35 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [213.184.43.8]) by mx1.freebsd.org (Postfix) with ESMTP id A8DAE8FC0C for ; Wed, 18 May 2011 15:11:12 +0000 (UTC) Received: from kuller.raad.tartu.ee (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 159D53987D; Wed, 18 May 2011 18:11:11 +0300 (EEST) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by kuller.raad.tartu.ee (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CDhf6w-762xe; Wed, 18 May 2011 18:11:09 +0300 (EEST) Received: by kuller.raad.tartu.ee (Postfix, from userid 80) id 2200739873; Wed, 18 May 2011 18:11:09 +0300 (EEST) Received: from lv.raad.tartu.ee (lv.raad.tartu.ee [213.184.43.2]) by webmail.raad.tartu.ee (Horde Framework) with HTTP; Wed, 18 May 2011 18:11:09 +0300 Message-ID: <20110518181109.40330buw2cn4gya0@webmail.raad.tartu.ee> Date: Wed, 18 May 2011 18:11:09 +0300 From: Toomas Aas To: Daniel Braniss References: <20110517223221.42331bryjddv87y8@webmail.raad.tartu.ee> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) X-Originating-IP: 213.184.43.2 Cc: freebsd-scsi@freebsd.org Subject: Re: iscsi-2.3.1 on FreeBSD 7.3 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 15:11:35 -0000 Hello Danny! > I haven't tested on 7.x for a long time, but the patch included should solve > the missing routine problem: Thanks for the patch, however the patched isc_subr.c does not compile: cc -O2 -fno-strict-aliasing -pipe -march=nocona -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/iscsi/initiator/../../.. -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/HEEROLD/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/HEEROLD -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/isc_subr.c /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/isc_subr.c: In function 'calculate_crc32c': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/isc_subr.c:172: error: 'p' undeclared (first use in this function) /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/isc_subr.c:172: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/isc_subr.c:172: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/sys/modules/iscsi/initiator. *** Error code 1 Stop in /usr/src/sys/modules/iscsi. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/HEEROLD. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Toomas Aas From owner-freebsd-scsi@FreeBSD.ORG Wed May 18 16:51:25 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 918C41065678 for ; Wed, 18 May 2011 16:51:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2C3768FC08 for ; Wed, 18 May 2011 16:51:24 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p4IGpLAi020348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 May 2011 19:51:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p4IGpLVd001338; Wed, 18 May 2011 19:51:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p4IGpK3J001337; Wed, 18 May 2011 19:51:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 May 2011 19:51:20 +0300 From: Kostik Belousov To: Joerg Wunsch Message-ID: <20110518165120.GT48734@deviant.kiev.zoral.com.ua> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua> <20110508104543.GB5364@uriah.heep.sax.de> <20110518060429.GA4146@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VDo88IHMZzDSr6Ba" Content-Disposition: inline In-Reply-To: <20110518060429.GA4146@uriah.heep.sax.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-scsi@freebsd.org Subject: Re: Panic when removing a SCSI device entry X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 16:51:25 -0000 --VDo88IHMZzDSr6Ba Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 18, 2011 at 08:04:29AM +0200, Joerg Wunsch wrote: > As Joerg Wunsch wrote: >=20 > > > Please provide the full printout from the panic. Also, it would > > > be useful to get the dump and do "p *dev" from the frame of > > > destroy_devl(). I might need further information after the requested > > > data is provided. > >=20 > > Unfortunately, I somehow cannot get the system to provide a coredump. >=20 > OK, it happened again last night, and I've got a DDB trace now. The > panic is at a slightly different location (in notify_destroy()), but > still a null pointer (apparently, dev->si_name is NULL now). >=20 > [thread pid 33502 tid 100246 ] > Stopped at strlen+0x8: cmpb $0,0(%edx) > db> bt > Tracing pid 33502 tid 100246 td 0xc8be92e0 > strlen(0,c6dfc804,cc0b0e80,cc6e6800,e98804b8,...) at strlen+0x8 > notify(ce0dc900,0,0,cc6e6800,c05ac3fb,...) at notify+0x3f > destroy_devl(e98804f4,c0470a2b,ce0dc900,c07e9284,1,...) at destroy_devl+0= x17b > destroy_dev(ce0dc900,c07e9284,1,0,e988051c,...) at destroy_dev+0x10 The ddb arguments printed might be wrong, or might point to the issue causing the panic. Please do "p *(struct cdev_priv *)0xe98804f4" and "p *(struct cdev_priv *)0xce0dc900" from kgdb. > sacleanup(cc0b0e80,c07f161b,12,0,e9880570,...) at sacleanup+0x8b > camperiphfree(50,e9880994,c044b4de,e98809ac,c6e83c80,...) at camperiphfre= e+0x8f > cam_periph_release_locked(cc0b0e80,0,cc0b0e80,e98809bc,c044b762,...) at c= am_periph_release_locked+0x55 > cam_periph_release(cc0b0e80,14c,cc814200,e98809fc,e98809e8,...) at cam_pe= riph_release+0x60 > saopen(cc814200,1,2000,c8be92e0,c07cc465,...) at saopen+0x263 > giant_open(cc814200,1,2000,c8be92e0,e9880b08,...) at giant_open+0x93 > devfs_open(e9880b08,e9880b30,c061c4fa,c0840e60,e9880b08,...) at devfs_ope= n+0x102 > VOP_OPEN_APV(c0840e60,e9880b08,c075ad1a,cacbe788,0,...) at VOP_OPEN_APV+0= x42 > vn_open_cred(e9880b78,e9880c2c,0,0,c7fba280,...) at vn_open_cred+0x4ba > vn_open(e9880b78,e9880c2c,0,c7f49150,3,...) at vn_open+0x3b > kern_openat(c8be92e0,ffffff9c,804a0bb,0,1,...) at kern_openat+0x12c > kern_open(c8be92e0,804a0bb,0,0,6,...) at kern_open+0x35 > open(c8be92e0,e9880cec,0,c,28176088,...) at open+0x30 > syscallenter(c8be92e0,e9880ce4,e9880d1c,c07ad276,c8be92e0,...) at syscall= enter+0x329 > syscall(e9880d28) at syscall+0x34 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > syscall (5, FreeBSD ELF32, open), eip =3D 0x2817608f, esp =3D 0xbfbfec7c,= ebp =3D 0xbfbfee18 --- > db> show reg > cs 0x20 > ds 0x28 > es 0x28 > fs 0x8 > ss 0x28 > eax 0 > ecx 0x8 > edx 0 > ebx 0x2 > esp 0xe9880468 > ebp 0xe9880468 > esi 0xce0dc900 > edi 0xcc6e6800 > eip 0xc0620568 strlen+0x8 > efl 0x10202 > strlen+0x8: cmpb $0,0(%edx) =2E.. > As you can see, I've got a coredump this time, so I can run kgdb > on that. >=20 > Currently, I'm compiling an INVARIANTS kernel, and will boot that one > soon - though I wonder whether it really makes sense here, as the > picture is different from last time (due to Kostik's suggested > patch?). I am pretty much sure that INVARIANTS kernel would hit the assert about SI_NAMED flag being clear on destroy_devl() invocation. We would have catched the issue earlier, with less interesting data destroyed. Anyway, please show the data I requested from the dump, and do install INVARIANTS kernel. --VDo88IHMZzDSr6Ba Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3T+QgACgkQC3+MBN1Mb4hkQQCfe2RIG5OOZoUWoSzrSCbOJBfg 12MAoMEDO0N9WCM+9nJAaBMS1LDrR7o+ =MZHr -----END PGP SIGNATURE----- --VDo88IHMZzDSr6Ba-- From owner-freebsd-scsi@FreeBSD.ORG Thu May 19 08:09:37 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09A171065673 for ; Thu, 19 May 2011 08:09:37 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.freebsd.org (Postfix) with ESMTP id B9E508FC13 for ; Thu, 19 May 2011 08:09:36 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs.huji.ac.il with esmtp id 1QMxZn-000CLA-7H; Thu, 19 May 2011 10:23:19 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Toomas Aas In-reply-to: <20110518181109.40330buw2cn4gya0@webmail.raad.tartu.ee> References: <20110517223221.42331bryjddv87y8@webmail.raad.tartu.ee> <20110518181109.40330buw2cn4gya0@webmail.raad.tartu.ee> Comments: In-reply-to Toomas Aas message dated "Wed, 18 May 2011 18:11:09 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 May 2011 10:23:19 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-scsi@freebsd.org Subject: Re: iscsi-2.3.1 on FreeBSD 7.3 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 08:09:37 -0000 > Hello Danny! > > > > I haven't tested on 7.x for a long time, but the patch included should solve > > the missing routine problem: > > Thanks for the patch, however the patched isc_subr.c does not compile: > > cc -O2 -fno-strict-aliasing -pipe -march=nocona > -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -D_KERNEL -DKLD_MODULE > -std=c99 -nostdinc -I/usr/src/sys/modules/iscsi/initiator/../../.. > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/HEEROLD/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer > -I/usr/obj/usr/src/sys/HEEROLD -mcmodel=kernel -mno-red-zone > -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -c > /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/isc_subr.c > /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/isc_subr.c: > In function 'calculate_crc32c': > /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/isc_subr.c:172: error: 'p' undeclared (first use in this > function) > /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/isc_subr.c:172: error: (Each undeclared identifier is reported only > once > /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/isc_subr.c:172: error: for each function it appears > in.) > *** Error code 1 > > Stop in /usr/src/sys/modules/iscsi/initiator. > *** Error code 1 > > Stop in /usr/src/sys/modules/iscsi. > *** Error code 1 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/HEEROLD. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > -- > Toomas Aas > wups, sorry, here is a patch to apply after the previous patch. --- a/sys/dev/iscsi/initiator/isc_subr.c Wed May 18 12:18:40 2011 +0300 +++ b/sys/dev/iscsi/initiator/isc_subr.c Thu May 19 10:22:20 2011 +0300 @@ -168,6 +168,8 @@ static __inline int calculate_crc32c(uint32_t crc, const void *buf, size_t size) { + const uint8_t *p = buf; + while (size--) crc = crc32Table[(crc ^ *p++) & 0xff] ^ (crc >> 8); return crc; From owner-freebsd-scsi@FreeBSD.ORG Thu May 19 17:27:50 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4478A106564A for ; Thu, 19 May 2011 17:27:50 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [213.184.43.8]) by mx1.freebsd.org (Postfix) with ESMTP id E24128FC14 for ; Thu, 19 May 2011 17:27:49 +0000 (UTC) Received: from kuller.raad.tartu.ee (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 2FAEA398AB; Thu, 19 May 2011 20:27:48 +0300 (EEST) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by kuller.raad.tartu.ee (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with LMTP id myjX1r+RrsfC; Thu, 19 May 2011 20:27:45 +0300 (EEST) Received: by kuller.raad.tartu.ee (Postfix, from userid 80) id 6F21E398AA; Thu, 19 May 2011 20:27:45 +0300 (EEST) Received: from lv.raad.tartu.ee (lv.raad.tartu.ee [213.184.43.2]) by webmail.raad.tartu.ee (Horde Framework) with HTTP; Thu, 19 May 2011 20:27:45 +0300 Message-ID: <20110519202745.97922qmhf9k10d2c@webmail.raad.tartu.ee> Date: Thu, 19 May 2011 20:27:45 +0300 From: Toomas Aas To: Daniel Braniss References: <20110517223221.42331bryjddv87y8@webmail.raad.tartu.ee> <20110518181109.40330buw2cn4gya0@webmail.raad.tartu.ee> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) X-Originating-IP: 213.184.43.2 Cc: freebsd-scsi@freebsd.org Subject: Re: iscsi-2.3.1 on FreeBSD 7.3 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 17:27:50 -0000 N, 19 mai 2011 kirjutas Daniel Braniss : > wups, sorry, here is a patch to apply after the previous patch. After applying this additional patch, I have some success. The module loaded ok and I could create a session with my EMC Celerra NX4 iSCSI server (which I couldn't do using the version of iSCSI initiator included with FreeBSD 7.3). /dev/da0 was created and I could successfully fdisk, label, newfs and mount it. Then, for testing purposes, i untar'ed the FreeBSD source tree to this filesystem. Halfway through the process stalled and this message appeared in /var/log/messages: kernel: so_input: out of pdus, wait After it had waited for approximately 8 minutes, I noticed that Apache running on the same server had become unresponsive. Other processes seemed to still be running OK, but as Apache couldn't be stopped even with kill -9, I rebooted the server. During reboot, there was a panic which looked like this: ----------------------------------------------------------------------- 0] ism_stop: terminating 0] ism_stop: n=4 0] ism_stop: final n=3 0] ic_destroy: name=iscsi unit=0 g_vfs_done():da0s1d[WRITE(offset=17168261120, length=4096)]error = 6 /mnt/iscsi: got error 6 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error cpuid = 0 Uptime: 35m18s (da0:iscsi0:0:0:2): lost device ----------------------------------------------------------------------- my iscsi.conf is pretty simple at the moment: ----------------------------------------------------------------------- celerra_path1 { TargetName = iqn.1992-05.com.emc:sl7e90837000600000-2; TargetAddress = 192.168.11.1; } ----------------------------------------------------------------------- So, what are pdus and how do I get more of them? ;) -- Toomas Aas From owner-freebsd-scsi@FreeBSD.ORG Fri May 20 08:39:50 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA0AE1065670 for ; Fri, 20 May 2011 08:39:50 +0000 (UTC) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.freebsd.org (Postfix) with ESMTP id 0ABEB8FC0C for ; Fri, 20 May 2011 08:39:49 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 7559427; Fri, 20 May 2011 10:39:48 +0200 (MET DST) Date: Fri, 20 May 2011 10:39:48 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org Message-ID: <20110520083948.GA2277@uriah.heep.sax.de> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua> <20110508104543.GB5364@uriah.heep.sax.de> <20110518060429.GA4146@uriah.heep.sax.de> <20110518165120.GT48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110518165120.GT48734@deviant.kiev.zoral.com.ua> X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: Panic when removing a SCSI device entry X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 08:39:50 -0000 As Kostik Belousov wrote: > Please do "p *(struct cdev_priv *)0xe98804f4" and > "p *(struct cdev_priv *)0xce0dc900" from kgdb. Well, that kernel unfortunately lacked debugging symbols, and while I've still been thinking about the best way to recompile an exact same kernel with them ... > I am pretty much sure that INVARIANTS kernel would hit the assert > about SI_NAMED flag being clear on destroy_devl() invocation. > We would have catched the issue earlier, with less interesting data > destroyed. ... the now INVARIANTS kernel panicked again last night. This time, I've got debugging symbols. So, as you expected, the corruption had been caught earliere now. The panic message is: (kgdb) p panicstr $1 = 0xc088dca0 "Bad link elm 0xc81cc200 prev->next != elm" Here is the stack trace: (kgdb) bt #0 doadump () at pcpu.h:231 #1 0xc057943e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc0579710 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0xc044b707 in camperiphfree (periph=0xc81cc200) at /usr/src/sys/cam/cam_periph.c:550 #4 0xc044b8e5 in cam_periph_release_locked (periph=0xc81cc200) at /usr/src/sys/cam/cam_periph.c:336 #5 0xc044ba74 in cam_periph_release (periph=0xc81cc200) at /usr/src/sys/cam/cam_periph.c:352 #6 0xc046eea2 in saopen (dev=0xc8d9ba00, flags=1, fmt=8192, td=0xc93d15c0) at /usr/src/sys/cam/scsi/scsi_sa.c:499 #7 0xc053833e in giant_open (dev=0xc8d9ba00, oflags=1, devtype=8192, td=0xc93d15c0) at /usr/src/sys/kern/kern_conf.c:361 #8 0xc05177b2 in devfs_open (ap=0xe98b3b00) at /usr/src/sys/fs/devfs/devfs_vnops.c:992 #9 0xc07b9a95 in VOP_OPEN_APV (vop=0xc08403c0, a=0xe98b3b00) at vnode_if.c:445 #10 0xc06143d6 in vn_open_cred (ndp=0xe98b3b78, flagp=0xe98b3c2c, cmode=0, vn_open_flags=0, cred=0xc807a780, fp=0xc90f6d58) at vnode_if.h:196 #11 0xc06144db in vn_open (ndp=0xe98b3b78, flagp=0xe98b3c2c, cmode=0, fp=0xc90f6d58) at /usr/src/sys/kern/vfs_vnops.c:94 #12 0xc06133fc in kern_openat (td=0xc93d15c0, fd=-100, path=0x804a0bb
, pathseg=UIO_USERSPACE, flags=1, mode=6) at /usr/src/sys/kern/vfs_syscalls.c:1083 #13 0xc0613845 in kern_open (td=0xc93d15c0, path=0x804a0bb
, pathseg=UIO_USERSPACE, flags=0, mode=6) at /usr/src/sys/kern/vfs_syscalls.c:1039 #14 0xc06138c0 in open (td=0xc93d15c0, uap=0xe98b3cec) at /usr/src/sys/kern/vfs_syscalls.c:1015 #15 0xc05b6276 in syscallenter (td=0xc93d15c0, sa=0xe98b3ce4) at /usr/src/sys/kern/subr_trap.c:326 #16 0xc0799b54 in syscall (frame=0xe98b3d28) at /usr/src/sys/i386/i386/trap.c:1086 #17 0xc077fd21 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) The dev node in question (I think, it's the "dev" argument in stack frame #6) is: (kgdb) p dev $5 = (struct cdev *) 0xc8d9ba00 (kgdb) p *dev $6 = {__si_reserved = 0x0, si_flags = 4, si_atime = {tv_sec = 1305772805, tv_nsec = 0}, si_ctime = { tv_sec = 1305773153, tv_nsec = 0}, si_mtime = {tv_sec = 1305773153, tv_nsec = 0}, si_uid = 0, si_gid = 5, si_mode = 432, si_cred = 0x0, si_drv0 = 1, si_refcount = 2, si_list = { le_next = 0xc7f9ed00, le_prev = 0xc8d43538}, si_clone = {le_next = 0x0, le_prev = 0x0}, si_children = {lh_first = 0xc8d9f100}, si_siblings = {le_next = 0x0, le_prev = 0x0}, si_parent = 0x0, si_name = 0xc8d9ba78 "nsa0.0", si_drv1 = 0xc81cc200, si_drv2 = 0x0, si_devsw = 0xc0833a40, si_iosize_max = 65536, si_usecount = 1, si_threadcount = 2, __si_u = {__sid_snapdata = 0x0}, __si_namebuf = "nsa0.0", '\0' } The contents of the "periph" object as seen in the various CAM layer functions is: (kgdb) p *periph $1 = {pinfo = {priority = 1, generation = 87063, index = -1}, periph_start = 0xc046ba80 , periph_oninval = 0xc046bcf0 , periph_dtor = 0xc046f2d0 , periph_name = 0xc07e07bc "sa", path = 0xc8dd31b0, softc = 0xc8387800, sim = 0xc6e83c80, unit_number = 0, type = CAM_PERIPH_BIO, flags = 8, immediate_priority = 4294967295, refcount = 0, ccb_list = {slh_first = 0x0}, periph_links = {sle_next = 0x0}, unit_links = {tqe_next = 0x0, tqe_prev = 0xc0833b30}, deferred_callback = 0, deferred_ac = 0} Finally, here's the "show cdev" command from DDB: db> show cdev geom.ctl 0xc6d1a100 devctl 0xc6ccc700 console 0xc6ccc600 sndstat 0xc6ccc500 ptmx 0xc6ccc400 ctty 0xc6ccc300 mem 0xc6ccc200 kmem 0xc6db3800 audit 0xc6db3700 bpf 0xc6db3600 bpf0 0xc6db3500 null 0xc6db3400 zero 0xc6db3300 fd/0 0xc6db3200 stdin 0xc6db3100 fd/1 0xc6db3000 stdout 0xc6db2e00 fd/2 0xc6db2d00 stderr 0xc6db2c00 klog 0xc6db2b00 pci 0xc6db2a00 midistat 0xc6db2900 kbdmux0 0xc6db2700 kbd0 0xc6db2600 random 0xc6db2400 urandom 0xc6db2300 sysmouse 0xc6db2200 io 0xc6db2100 speaker 0xc6db2000 fido 0xc6d1be00 ata 0xc6d1bd00 acpi 0xc6d1b800 ttyu2 0xc6e7dd00 ttyu2.init 0xc6e7d800 ttyu2.lock 0xc6e7d700 cuau2 0xc6e7d600 cuau2.init 0xc6e7d500 cuau2.lock 0xc6e7d400 ttyu3 0xc6e7d000 ttyu3.init 0xc6e7ce00 ttyu3.lock 0xc6e7cd00 cuau3 0xc6e7cc00 cuau3.init 0xc6e7cb00 cuau3.lock 0xc6e7ca00 ttyu4 0xc6e7c600 ttyu4.init 0xc6e7c500 ttyu4.lock 0xc6e7c800 cuau4 0xc6e7c900 cuau4.init 0xc6e7d200 cuau4.lock 0xc6e7d300 ttyu5 0xc6e7e400 ttyu5.init 0xc6e7e500 ttyu5.lock 0xc6e7e600 cuau5 0xc6e7e700 cuau5.init 0xc6e7e800 cuau5.lock 0xc6e7e900 ttyu6 0xc6e7e000 ttyu6.init 0xc6f01e00 ttyu6.lock 0xc6f01d00 cuau6 0xc6f01c00 cuau6.init 0xc6f01b00 cuau6.lock 0xc6f01a00 ttyu7 0xc6f01600 ttyu7.init 0xc6f01500 ttyu7.lock 0xc6f01400 cuau7 0xc6f01300 cuau7.init 0xc6f01200 cuau7.lock 0xc6f01100 ttyu8 0xc6f00c00 ttyu8.init 0xc6f00b00 ttyu8.lock 0xc6f00a00 cuau8 0xc6f00900 cuau8.init 0xc6f00800 cuau8.lock 0xc6f00700 ttyu9 0xc6f00300 ttyu9.init 0xc6f00200 ttyu9.lock 0xc6f00100 cuau9 0xc6f00000 cuau9.init 0xc6e7fe00 cuau9.lock 0xc6e7fd00 ttyv0 0xc6f01000 ttyv1 0xc6f01800 ttyv2 0xc6fa5d00 ttyv3 0xc6fa5c00 ttyv4 0xc6fa5b00 ttyv5 0xc6fa5a00 ttyv6 0xc6fa5900 ttyv7 0xc6fa5800 ttyv8 0xc6fa5700 ttyv9 0xc6fa5600 ttyva 0xc6fa5500 ttyvb 0xc6fa5400 ttyvc 0xc6fa5300 ttyvd 0xc6fa5200 ttyve 0xc6fa5100 ttyvf 0xc6fa5000 consolectl 0xc6fa4e00 lpt0 0xc6fa4b00 lpt0.ctl 0xc6fa4a00 ppi0 0xc6fa4900 ttyu0 0xc6fa4600 ttyu0.init 0xc6fa4500 ttyu0.lock 0xc6fa4400 cuau0 0xc6fa4300 cuau0.init 0xc6fa4200 cuau0.lock 0xc6fa4100 usbctl 0xc71d6d00 mdctl 0xc71d6b00 devstat 0xc71d6a00 fd0 0xc71d6900 usb/0.1.0 0xc71d6700 ugen0.1 0xc71d6600 usb/1.1.0 0xc71d6500 ugen1.1 0xc71d6400 usb/0.1.1 0xc71d6300 usb/1.1.1 0xc71d5d00 xpt0 0xc71d5800 mixer0 0xc71d4a00 mixer1 0xc71d4000 mixer2 0xc7216a00 acd0 0xc7216100 ad4 0xc7216000 ad4s1 0xc7215e00 ad4s1b 0xc7215d00 ad4s1h 0xc7215c00 gvinum/ports 0xc728e100 gvinum/src 0xc728e000 gvinum/news 0xc728de00 gvinum/distfiles 0xc728dd00 gvinum/pdf 0xc728dc00 gvinum/mysql 0xc728db00 gvinum/upload 0xc728da00 gvinum/obj 0xc728d900 gvinum/root 0xc728d800 gvinum/local 0xc728d700 gvinum/usr 0xc728d600 gvinum/var 0xc728d500 gvinum/home_cvs 0xc728d400 gvinum/home 0xc728d300 gvinum/junk 0xc728d200 gvinum/bacula_db 0xc728d100 gvinum/dump 0xc728d000 gvinum/tmp 0xc72a4400 gvinum/camel 0xc72a4300 gvinum/squid 0xc72a4200 gvinum/sound 0xc72a4100 usb/1.2.0 0xc72a2b00 ugen1.2 0xc72a2a00 cd0 0xc7290c00 usb/1.2.1 0xc7290b00 pass0 0xc7290400 pass1 0xc7290300 pass2 0xc7290200 da0 0xc72e8800 da0a 0xc72a2700 da0h 0xc72a2800 da1 0xc72a2e00 ufsid/4856d98a00081994 0xc72a3000 da1a 0xc72a3100 da1h 0xc72a3200 usb/0.2.0 0xc72e6900 ugen0.2 0xc72e6a00 usb/0.2.1 0xc72e6b00 usb/0.3.0 0xc72e7400 ugen0.3 0xc72e7500 usb/0.3.1 0xc72e7600 ukbd0 0xc72e7e00 kbd1 0xc72e8000 usb/0.4.0 0xc72e8100 ugen0.4 0xc72e8200 usb/0.4.1 0xc72e8300 ums0 0xc72e7300 usb/0.5.0 0xc72e6e00 ugen0.5 0xc72e6c00 usb/0.5.1 0xc72e6100 usb/0.6.0 0xc72a4900 ugen0.6 0xc72a4800 usb/0.6.2 0xc72a4700 pf 0xc7449700 nfslock 0xc7e39100 tap0 0xc7e95b00 apm0 0xc7fa0100 dsp2.0 0xc7446100 dsp1.0 0xc7e37300 dsp0.0 0xc7e37100 pts/1 0xc8230600 pts/2 0xc8230900 ptyp0 0xc7e36d00 ttyp0 0xc8230700 ptyp1 0xc8230b00 ttyp1 0xc82eb800 pts/3 0xc8d9ae00 pts/0 0xc8047800 pts/4 0xc82c9400 pts/5 0xc8da1400 pts/6 0xc8e02700 usb/0.6.0 0xc8497a00 ugen0.6 0xc7e97500 usb/0.6.2 0xc82ed400 pass3 0xc8d9d700 ch0 0xc8046200 nsa0.0 0xc8d9ba00 esa0.0 0xc8d43500 nsa0 0xc8d9f100 esa0 0xc8d43c00 sa0.1 0xc8497e00 nsa0.1 0xc8048800 esa0.1 0xc8e00100 sa0.2 0xc8e01b00 nsa0.2 0xc8da0c00 esa0.2 0xc8d9d900 sa0.3 0xc8d9de00 nsa0.3 0xc8d9f900 esa0.3 0xc8d42600 usb/0.7.0 0xcecdad00 ugen0.7 0xcecd4a00 usb/0.7.2 0xcecd7800 pts/7 0xc8046100 ptyp2 0xc822da00 ttyp2 0xc8230300 pass4 0xce291100 sa0.ctl 0xcecfca00 sa0.0 0xcecfcd00 nsa0.0 0xc7f9e900 esa0.0 0xcecf3000 sa0 0xc8d42b00 nsa0 0xcecd7b00 esa0 0xc90a7000 sa0.1 0xcbda4c00 nsa0.1 0xcecfcc00 esa0.1 0xce21a400 sa0.2 0xceccb600 nsa0.2 0xcece3b00 esa0.2 0xc8e01d00 sa0.3 0xcecd4600 nsa0.3 0xceccb300 esa0.3 0xcecfc500 I think that's all I could tell by now ... -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Fri May 20 20:18:03 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34CBC1065672 for ; Fri, 20 May 2011 20:18:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 48D328FC1A for ; Fri, 20 May 2011 20:18:01 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p4KKHvei075952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2011 23:17:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p4KKHvWt016801; Fri, 20 May 2011 23:17:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p4KKHvK8016800; Fri, 20 May 2011 23:17:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 20 May 2011 23:17:57 +0300 From: Kostik Belousov To: Joerg Wunsch Message-ID: <20110520201757.GE48734@deviant.kiev.zoral.com.ua> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua> <20110508104543.GB5364@uriah.heep.sax.de> <20110518060429.GA4146@uriah.heep.sax.de> <20110518165120.GT48734@deviant.kiev.zoral.com.ua> <20110520083948.GA2277@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K5FRBbPSksISZ1JK" Content-Disposition: inline In-Reply-To: <20110520083948.GA2277@uriah.heep.sax.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-scsi@freebsd.org Subject: Re: Panic when removing a SCSI device entry X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 20:18:03 -0000 --K5FRBbPSksISZ1JK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 20, 2011 at 10:39:48AM +0200, Joerg Wunsch wrote: > As Kostik Belousov wrote: >=20 > > Please do "p *(struct cdev_priv *)0xe98804f4" and > > "p *(struct cdev_priv *)0xce0dc900" from kgdb. >=20 > Well, that kernel unfortunately lacked debugging symbols, and while > I've still been thinking about the best way to recompile an exact > same kernel with them ... Yes, it would be quite interesting to see the data I asked for. I spent significant time trying to imagine a scenario where the reported panic could be possible, and did not end with anything. >=20 > > I am pretty much sure that INVARIANTS kernel would hit the assert > > about SI_NAMED flag being clear on destroy_devl() invocation. > > We would have catched the issue earlier, with less interesting data > > destroyed. >=20 > ... the now INVARIANTS kernel panicked again last night. This time, > I've got debugging symbols. So, as you expected, the corruption had > been caught earliere now. The panic message is: >=20 > (kgdb) p panicstr > $1 =3D 0xc088dca0 "Bad link elm 0xc81cc200 prev->next !=3D elm" >=20 > Here is the stack trace: >=20 > (kgdb) bt > #0 doadump () at pcpu.h:231 > #1 0xc057943e in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :419 > #2 0xc0579710 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:592 > #3 0xc044b707 in camperiphfree (periph=3D0xc81cc200) at /usr/src/sys/cam= /cam_periph.c:550 What is the exact revision of your sources ? I do not see ay list manipulation macros at the line 550 in cam_periph.c, both in HEAD and stable/8. There is one three lines earlier, and it could cause the panic shown. This looks like a CAM issue, which is out of my scope. Hope other subscribers will offer the help. I committed the devfs fix you tested, it should land into stable/8 in a wee= k. > #4 0xc044b8e5 in cam_periph_release_locked (periph=3D0xc81cc200) at /usr= /src/sys/cam/cam_periph.c:336 > #5 0xc044ba74 in cam_periph_release (periph=3D0xc81cc200) at /usr/src/sy= s/cam/cam_periph.c:352 > #6 0xc046eea2 in saopen (dev=3D0xc8d9ba00, flags=3D1, fmt=3D8192, td=3D0= xc93d15c0) > at /usr/src/sys/cam/scsi/scsi_sa.c:499 > #7 0xc053833e in giant_open (dev=3D0xc8d9ba00, oflags=3D1, devtype=3D819= 2, td=3D0xc93d15c0) > at /usr/src/sys/kern/kern_conf.c:361 > #8 0xc05177b2 in devfs_open (ap=3D0xe98b3b00) at /usr/src/sys/fs/devfs/d= evfs_vnops.c:992 > #9 0xc07b9a95 in VOP_OPEN_APV (vop=3D0xc08403c0, a=3D0xe98b3b00) at vnod= e_if.c:445 > #10 0xc06143d6 in vn_open_cred (ndp=3D0xe98b3b78, flagp=3D0xe98b3c2c, cmo= de=3D0, vn_open_flags=3D0,=20 > cred=3D0xc807a780, fp=3D0xc90f6d58) at vnode_if.h:196 > #11 0xc06144db in vn_open (ndp=3D0xe98b3b78, flagp=3D0xe98b3c2c, cmode=3D= 0, fp=3D0xc90f6d58) > at /usr/src/sys/kern/vfs_vnops.c:94 > #12 0xc06133fc in kern_openat (td=3D0xc93d15c0, fd=3D-100, path=3D0x804a0= bb
,=20 > pathseg=3DUIO_USERSPACE, flags=3D1, mode=3D6) at /usr/src/sys/kern/vf= s_syscalls.c:1083 > #13 0xc0613845 in kern_open (td=3D0xc93d15c0, path=3D0x804a0bb
,=20 > pathseg=3DUIO_USERSPACE, flags=3D0, mode=3D6) at /usr/src/sys/kern/vf= s_syscalls.c:1039 > #14 0xc06138c0 in open (td=3D0xc93d15c0, uap=3D0xe98b3cec) at /usr/src/sy= s/kern/vfs_syscalls.c:1015 > #15 0xc05b6276 in syscallenter (td=3D0xc93d15c0, sa=3D0xe98b3ce4) at /usr= /src/sys/kern/subr_trap.c:326 > #16 0xc0799b54 in syscall (frame=3D0xe98b3d28) at /usr/src/sys/i386/i386/= trap.c:1086 > #17 0xc077fd21 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception= .s:266 > #18 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) >=20 > The dev node in question (I think, it's the "dev" argument in stack As I said, devfs looks innocent in this backtrace. > frame #6) is: > (kgdb) p dev > $5 =3D (struct cdev *) 0xc8d9ba00 > (kgdb) p *dev > $6 =3D {__si_reserved =3D 0x0, si_flags =3D 4, si_atime =3D {tv_sec =3D 1= 305772805, tv_nsec =3D 0}, si_ctime =3D { > tv_sec =3D 1305773153, tv_nsec =3D 0}, si_mtime =3D {tv_sec =3D 13057= 73153, tv_nsec =3D 0}, si_uid =3D 0,=20 > si_gid =3D 5, si_mode =3D 432, si_cred =3D 0x0, si_drv0 =3D 1, si_refco= unt =3D 2, si_list =3D { > le_next =3D 0xc7f9ed00, le_prev =3D 0xc8d43538}, si_clone =3D {le_nex= t =3D 0x0, le_prev =3D 0x0},=20 > si_children =3D {lh_first =3D 0xc8d9f100}, si_siblings =3D {le_next =3D= 0x0, le_prev =3D 0x0}, si_parent =3D 0x0,=20 > si_name =3D 0xc8d9ba78 "nsa0.0", si_drv1 =3D 0xc81cc200, si_drv2 =3D 0x= 0, si_devsw =3D 0xc0833a40,=20 > si_iosize_max =3D 65536, si_usecount =3D 1, si_threadcount =3D 2, __si_= u =3D {__sid_snapdata =3D 0x0},=20 > __si_namebuf =3D "nsa0.0", '\0' } >=20 > The contents of the "periph" object as seen in the various CAM layer > functions is: >=20 > (kgdb) p *periph > $1 =3D {pinfo =3D {priority =3D 1, generation =3D 87063, index =3D -1}, p= eriph_start =3D 0xc046ba80 ,=20 > periph_oninval =3D 0xc046bcf0 , periph_dtor =3D 0xc046f= 2d0 ,=20 > periph_name =3D 0xc07e07bc "sa", path =3D 0xc8dd31b0, softc =3D 0xc8387= 800, sim =3D 0xc6e83c80,=20 > unit_number =3D 0, type =3D CAM_PERIPH_BIO, flags =3D 8, immediate_prio= rity =3D 4294967295, refcount =3D 0,=20 > ccb_list =3D {slh_first =3D 0x0}, periph_links =3D {sle_next =3D 0x0}, = unit_links =3D {tqe_next =3D 0x0,=20 > tqe_prev =3D 0xc0833b30}, deferred_callback =3D 0, deferred_ac =3D 0} >=20 > Finally, here's the "show cdev" command from DDB: >=20 > db> show cdev > geom.ctl 0xc6d1a100 > devctl 0xc6ccc700 > console 0xc6ccc600 > sndstat 0xc6ccc500 > ptmx 0xc6ccc400 > ctty 0xc6ccc300 > mem 0xc6ccc200 > kmem 0xc6db3800 > audit 0xc6db3700 > bpf 0xc6db3600 > bpf0 0xc6db3500 > null 0xc6db3400 > zero 0xc6db3300 > fd/0 0xc6db3200 > stdin 0xc6db3100 > fd/1 0xc6db3000 > stdout 0xc6db2e00 > fd/2 0xc6db2d00 > stderr 0xc6db2c00 > klog 0xc6db2b00 > pci 0xc6db2a00 > midistat 0xc6db2900 > kbdmux0 0xc6db2700 > kbd0 0xc6db2600 > random 0xc6db2400 > urandom 0xc6db2300 > sysmouse 0xc6db2200 > io 0xc6db2100 > speaker 0xc6db2000 > fido 0xc6d1be00 > ata 0xc6d1bd00 > acpi 0xc6d1b800 > ttyu2 0xc6e7dd00 > ttyu2.init 0xc6e7d800 > ttyu2.lock 0xc6e7d700 > cuau2 0xc6e7d600 > cuau2.init 0xc6e7d500 > cuau2.lock 0xc6e7d400 > ttyu3 0xc6e7d000 > ttyu3.init 0xc6e7ce00 > ttyu3.lock 0xc6e7cd00 > cuau3 0xc6e7cc00 > cuau3.init 0xc6e7cb00 > cuau3.lock 0xc6e7ca00 > ttyu4 0xc6e7c600 > ttyu4.init 0xc6e7c500 > ttyu4.lock 0xc6e7c800 > cuau4 0xc6e7c900 > cuau4.init 0xc6e7d200 > cuau4.lock 0xc6e7d300 > ttyu5 0xc6e7e400 > ttyu5.init 0xc6e7e500 > ttyu5.lock 0xc6e7e600 > cuau5 0xc6e7e700 > cuau5.init 0xc6e7e800 > cuau5.lock 0xc6e7e900 > ttyu6 0xc6e7e000 > ttyu6.init 0xc6f01e00 > ttyu6.lock 0xc6f01d00 > cuau6 0xc6f01c00 > cuau6.init 0xc6f01b00 > cuau6.lock 0xc6f01a00 > ttyu7 0xc6f01600 > ttyu7.init 0xc6f01500 > ttyu7.lock 0xc6f01400 > cuau7 0xc6f01300 > cuau7.init 0xc6f01200 > cuau7.lock 0xc6f01100 > ttyu8 0xc6f00c00 > ttyu8.init 0xc6f00b00 > ttyu8.lock 0xc6f00a00 > cuau8 0xc6f00900 > cuau8.init 0xc6f00800 > cuau8.lock 0xc6f00700 > ttyu9 0xc6f00300 > ttyu9.init 0xc6f00200 > ttyu9.lock 0xc6f00100 > cuau9 0xc6f00000 > cuau9.init 0xc6e7fe00 > cuau9.lock 0xc6e7fd00 > ttyv0 0xc6f01000 > ttyv1 0xc6f01800 > ttyv2 0xc6fa5d00 > ttyv3 0xc6fa5c00 > ttyv4 0xc6fa5b00 > ttyv5 0xc6fa5a00 > ttyv6 0xc6fa5900 > ttyv7 0xc6fa5800 > ttyv8 0xc6fa5700 > ttyv9 0xc6fa5600 > ttyva 0xc6fa5500 > ttyvb 0xc6fa5400 > ttyvc 0xc6fa5300 > ttyvd 0xc6fa5200 > ttyve 0xc6fa5100 > ttyvf 0xc6fa5000 > consolectl 0xc6fa4e00 > lpt0 0xc6fa4b00 > lpt0.ctl 0xc6fa4a00 > ppi0 0xc6fa4900 > ttyu0 0xc6fa4600 > ttyu0.init 0xc6fa4500 > ttyu0.lock 0xc6fa4400 > cuau0 0xc6fa4300 > cuau0.init 0xc6fa4200 > cuau0.lock 0xc6fa4100 > usbctl 0xc71d6d00 > mdctl 0xc71d6b00 > devstat 0xc71d6a00 > fd0 0xc71d6900 > usb/0.1.0 0xc71d6700 > ugen0.1 0xc71d6600 > usb/1.1.0 0xc71d6500 > ugen1.1 0xc71d6400 > usb/0.1.1 0xc71d6300 > usb/1.1.1 0xc71d5d00 > xpt0 0xc71d5800 > mixer0 0xc71d4a00 > mixer1 0xc71d4000 > mixer2 0xc7216a00 > acd0 0xc7216100 > ad4 0xc7216000 > ad4s1 0xc7215e00 > ad4s1b 0xc7215d00 > ad4s1h 0xc7215c00 > gvinum/ports 0xc728e100 > gvinum/src 0xc728e000 > gvinum/news 0xc728de00 > gvinum/distfiles 0xc728dd00 > gvinum/pdf 0xc728dc00 > gvinum/mysql 0xc728db00 > gvinum/upload 0xc728da00 > gvinum/obj 0xc728d900 > gvinum/root 0xc728d800 > gvinum/local 0xc728d700 > gvinum/usr 0xc728d600 > gvinum/var 0xc728d500 > gvinum/home_cvs 0xc728d400 > gvinum/home 0xc728d300 > gvinum/junk 0xc728d200 > gvinum/bacula_db 0xc728d100 > gvinum/dump 0xc728d000 > gvinum/tmp 0xc72a4400 > gvinum/camel 0xc72a4300 > gvinum/squid 0xc72a4200 > gvinum/sound 0xc72a4100 > usb/1.2.0 0xc72a2b00 > ugen1.2 0xc72a2a00 > cd0 0xc7290c00 > usb/1.2.1 0xc7290b00 > pass0 0xc7290400 > pass1 0xc7290300 > pass2 0xc7290200 > da0 0xc72e8800 > da0a 0xc72a2700 > da0h 0xc72a2800 > da1 0xc72a2e00 > ufsid/4856d98a00081994 0xc72a3000 > da1a 0xc72a3100 > da1h 0xc72a3200 > usb/0.2.0 0xc72e6900 > ugen0.2 0xc72e6a00 > usb/0.2.1 0xc72e6b00 > usb/0.3.0 0xc72e7400 > ugen0.3 0xc72e7500 > usb/0.3.1 0xc72e7600 > ukbd0 0xc72e7e00 > kbd1 0xc72e8000 > usb/0.4.0 0xc72e8100 > ugen0.4 0xc72e8200 > usb/0.4.1 0xc72e8300 > ums0 0xc72e7300 > usb/0.5.0 0xc72e6e00 > ugen0.5 0xc72e6c00 > usb/0.5.1 0xc72e6100 > usb/0.6.0 0xc72a4900 > ugen0.6 0xc72a4800 > usb/0.6.2 0xc72a4700 > pf 0xc7449700 > nfslock 0xc7e39100 > tap0 0xc7e95b00 > apm0 0xc7fa0100 > dsp2.0 0xc7446100 > dsp1.0 0xc7e37300 > dsp0.0 0xc7e37100 > pts/1 0xc8230600 > pts/2 0xc8230900 > ptyp0 0xc7e36d00 > ttyp0 0xc8230700 > ptyp1 0xc8230b00 > ttyp1 0xc82eb800 > pts/3 0xc8d9ae00 > pts/0 0xc8047800 > pts/4 0xc82c9400 > pts/5 0xc8da1400 > pts/6 0xc8e02700 > usb/0.6.0 0xc8497a00 > ugen0.6 0xc7e97500 > usb/0.6.2 0xc82ed400 > pass3 0xc8d9d700 > ch0 0xc8046200 > nsa0.0 0xc8d9ba00 > esa0.0 0xc8d43500 > nsa0 0xc8d9f100 > esa0 0xc8d43c00 > sa0.1 0xc8497e00 > nsa0.1 0xc8048800 > esa0.1 0xc8e00100 > sa0.2 0xc8e01b00 > nsa0.2 0xc8da0c00 > esa0.2 0xc8d9d900 > sa0.3 0xc8d9de00 > nsa0.3 0xc8d9f900 > esa0.3 0xc8d42600 > usb/0.7.0 0xcecdad00 > ugen0.7 0xcecd4a00 > usb/0.7.2 0xcecd7800 > pts/7 0xc8046100 > ptyp2 0xc822da00 > ttyp2 0xc8230300 > pass4 0xce291100 > sa0.ctl 0xcecfca00 > sa0.0 0xcecfcd00 > nsa0.0 0xc7f9e900 > esa0.0 0xcecf3000 > sa0 0xc8d42b00 > nsa0 0xcecd7b00 > esa0 0xc90a7000 > sa0.1 0xcbda4c00 > nsa0.1 0xcecfcc00 > esa0.1 0xce21a400 > sa0.2 0xceccb600 > nsa0.2 0xcece3b00 > esa0.2 0xc8e01d00 > sa0.3 0xcecd4600 > nsa0.3 0xceccb300 > esa0.3 0xcecfc500 >=20 > I think that's all I could tell by now ... > --=20 > cheers, J"org .-.-. --... ...-- -.. . DL8DTL >=20 > http://www.sax.de/~joerg/ NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) --K5FRBbPSksISZ1JK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3WzHQACgkQC3+MBN1Mb4gA2gCdH1IBuR7JGlSJP6CQA1r+WwDI uuQAoMTQvvRLUF0XHoxkJMa8qMaAxvqv =Hxmp -----END PGP SIGNATURE----- --K5FRBbPSksISZ1JK-- From owner-freebsd-scsi@FreeBSD.ORG Fri May 20 20:37:33 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2432C1065672 for ; Fri, 20 May 2011 20:37:33 +0000 (UTC) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.freebsd.org (Postfix) with ESMTP id C01A08FC14 for ; Fri, 20 May 2011 20:37:32 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 40A8D1E; Fri, 20 May 2011 22:37:31 +0200 (MET DST) Date: Fri, 20 May 2011 22:37:31 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org Message-ID: <20110520203731.GG2277@uriah.heep.sax.de> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua> <20110508104543.GB5364@uriah.heep.sax.de> <20110518060429.GA4146@uriah.heep.sax.de> <20110518165120.GT48734@deviant.kiev.zoral.com.ua> <20110520083948.GA2277@uriah.heep.sax.de> <20110520201757.GE48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110520201757.GE48734@deviant.kiev.zoral.com.ua> X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: Panic when removing a SCSI device entry X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 20:37:33 -0000 As Kostik Belousov wrote: > > > Please do "p *(struct cdev_priv *)0xe98804f4" and > > > "p *(struct cdev_priv *)0xce0dc900" from kgdb. > > > > Well, that kernel unfortunately lacked debugging symbols, and while > > I've still been thinking about the best way to recompile an exact > > same kernel with them ... > Yes, it would be quite interesting to see the data I asked for. OK, I found a way to cheat around the missing -g symbols ... and: all the data at 0xce0dc900 are zeroed out. The other address does not make any sense at all: (kgdb) p *(struct cdev_priv *)0xe98804f4 $1 = {cdp_c = {__si_reserved = 0xe988097c, si_flags = 3225728383, si_atime = {tv_sec = -871690624, tv_nsec = -1065413093}, si_ctime = {tv_sec = 18, tv_nsec = 0}, si_mtime = {tv_sec = -376961680, tv_nsec = -927034656}, si_uid = 3239626616, si_gid = 0, si_mode = 1316, si_cred = 0xdad13340, si_drv0 = -376961728, si_refcount = -1068057405, si_list = {le_next = 0x0, le_prev = 0xe9880538}, si_clone = {le_next = 0xe9880538, le_prev = 0x202}, si_children = {lh_first = 0x2}, si_siblings = { le_next = 0xdad13340, le_prev = 0x0}, si_parent = 0xe9880564, si_name = 0xc056bcc3 "\213]�213u�213}�211��\211�213U\f\205�\r�����\213E\b����]�215�&", si_drv1 = 0x0, si_drv2 = 0x1, si_devsw = 0x0, si_iosize_max = -1055340680, si_usecount = 3918005652, si_threadcount = 3671143232, __si_u = {__sid_snapdata = 0x0}, __si_namebuf = "\000�030�000\000\000\000@3�|\005\210�000\000\000\000\000@�\224\005\210��V�001\000\000\000\020\000\000\000�\005\210��V�\234\204�020\000\000\000\001\000\000\000\006\000\000"}, cdp_list = {tqe_next = 0xe988061a, tqe_prev = 0x4}, cdp_inode = 2147289763, cdp_flags = 3918005812, cdp_inuse = 3671349200, cdp_maxdirent = 3671143232, cdp_dirents = 0x6400, cdp_dirent0 = 0xe0badfa7, cdp_dtr_list = {tqe_next = 0x257, tqe_prev = 0xc056bc4a}, cdp_dtr_cb = 0x404a9c20, cdp_dtr_cb_arg = 0xc084b894, cdp_fdpriv = {lh_first = 0xe9880674}} > What is the exact revision of your sources ? It's a checkout from a CVS tree, so I cannot give you an exact SVN revision number. The checkout has been done on April 13. > This looks like a CAM issue, which is out of my scope. This was my fear, and that's why I wrote to the freebsd-scsi list. > > si_name = 0xc8d9ba78 "nsa0.0", Could that be an issue with the multiple SCSI tape drive device nodes? I see, /dev/nsa0.0 is somehow involved into the panic, yet other processes might access just /dev/nsa0 (which is a different cdev). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi@FreeBSD.ORG Fri May 20 21:40:13 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62E36106566C for ; Fri, 20 May 2011 21:40:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 009048FC15 for ; Fri, 20 May 2011 21:40:12 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p4KKjAKQ077599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2011 23:45:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p4KKjAfX016951; Fri, 20 May 2011 23:45:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p4KKjA2w016950; Fri, 20 May 2011 23:45:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 20 May 2011 23:45:10 +0300 From: Kostik Belousov To: Joerg Wunsch Message-ID: <20110520204510.GF48734@deviant.kiev.zoral.com.ua> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua> <20110508104543.GB5364@uriah.heep.sax.de> <20110518060429.GA4146@uriah.heep.sax.de> <20110518165120.GT48734@deviant.kiev.zoral.com.ua> <20110520083948.GA2277@uriah.heep.sax.de> <20110520201757.GE48734@deviant.kiev.zoral.com.ua> <20110520203731.GG2277@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gYXIgL6/MA84ylAn" Content-Disposition: inline In-Reply-To: <20110520203731.GG2277@uriah.heep.sax.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-scsi@freebsd.org Subject: Re: Panic when removing a SCSI device entry X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 21:40:13 -0000 --gYXIgL6/MA84ylAn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 20, 2011 at 10:37:31PM +0200, Joerg Wunsch wrote: > As Kostik Belousov wrote: >=20 > > > > Please do "p *(struct cdev_priv *)0xe98804f4" and > > > > "p *(struct cdev_priv *)0xce0dc900" from kgdb. > > >=20 > > > Well, that kernel unfortunately lacked debugging symbols, and while > > > I've still been thinking about the best way to recompile an exact > > > same kernel with them ... >=20 > > Yes, it would be quite interesting to see the data I asked for. >=20 > OK, I found a way to cheat around the missing -g symbols ... and: all > the data at 0xce0dc900 are zeroed out. The other address does not > make any sense at all: Yes, this is a garbage, and it is consistent with the panic you reported with INVARIANTS turned on. It seems quite possible that CAM did destroy_dev() on the freed and reused memory. >=20 > (kgdb) p *(struct cdev_priv *)0xe98804f4 > $1 =3D {cdp_c =3D {__si_reserved =3D 0xe988097c, si_flags =3D 3225728383,= si_atime =3D {tv_sec =3D -871690624,=20 > tv_nsec =3D -1065413093}, si_ctime =3D {tv_sec =3D 18, tv_nsec =3D = 0}, si_mtime =3D {tv_sec =3D -376961680,=20 > tv_nsec =3D -927034656}, si_uid =3D 3239626616, si_gid =3D 0, si_mo= de =3D 1316, si_cred =3D 0xdad13340,=20 > si_drv0 =3D -376961728, si_refcount =3D -1068057405, si_list =3D {le_= next =3D 0x0, le_prev =3D 0xe9880538},=20 > si_clone =3D {le_next =3D 0xe9880538, le_prev =3D 0x202}, si_children= =3D {lh_first =3D 0x2}, si_siblings =3D { > le_next =3D 0xdad13340, le_prev =3D 0x0}, si_parent =3D 0xe9880564,= =20 > si_name =3D 0xc056bcc3 "\213]???213u???213}???211??????\211???213U\f\= 205???\r???????????????\213E\b????????????]???215???&",=20 > si_drv1 =3D 0x0, si_drv2 =3D 0x1, si_devsw =3D 0x0, si_iosize_max =3D= -1055340680,=20 > si_usecount =3D 3918005652, si_threadcount =3D 3671143232, __si_u =3D= {__sid_snapdata =3D 0x0},=20 > __si_namebuf =3D "\000???030???000\000\000\000@3???|\005\210???000\00= 0\000\000\000@???\224\005\210??????V???001\000\000\000\020\000\000\000???\0= 05\210??????V???\234\204???020\000\000\000\001\000\000\000\006\000\000"},= =20 > cdp_list =3D {tqe_next =3D 0xe988061a, tqe_prev =3D 0x4}, cdp_inode =3D= 2147289763, cdp_flags =3D 3918005812,=20 > cdp_inuse =3D 3671349200, cdp_maxdirent =3D 3671143232, cdp_dirents =3D= 0x6400, cdp_dirent0 =3D 0xe0badfa7,=20 > cdp_dtr_list =3D {tqe_next =3D 0x257, tqe_prev =3D 0xc056bc4a}, cdp_dtr= _cb =3D 0x404a9c20,=20 > cdp_dtr_cb_arg =3D 0xc084b894, cdp_fdpriv =3D {lh_first =3D 0xe9880674}} >=20 > > What is the exact revision of your sources ? >=20 > It's a checkout from a CVS tree, so I cannot give you an exact SVN > revision number. The checkout has been done on April 13. >=20 > > This looks like a CAM issue, which is out of my scope. >=20 > This was my fear, and that's why I wrote to the freebsd-scsi list. Well, it helped to identify and correct a devfs bug anyway, thank you. >=20 > > > si_name =3D 0xc8d9ba78 "nsa0.0", >=20 > Could that be an issue with the multiple SCSI tape drive device nodes? > I see, /dev/nsa0.0 is somehow involved into the panic, yet other > processes might access just /dev/nsa0 (which is a different cdev). >=20 > --=20 > cheers, J"org .-.-. --... ...-- -.. . DL8DTL >=20 > http://www.sax.de/~joerg/ NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) --gYXIgL6/MA84ylAn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3W0tYACgkQC3+MBN1Mb4iVdgCffLuIH1vRtEN0ypWfMwdaII5V ErgAoK155nt0LJg1/9xxxUlULfx5wjKF =qtuZ -----END PGP SIGNATURE----- --gYXIgL6/MA84ylAn--