Re: FreeBSD 9.1 RC1 and CAM issues with old SCSI drive
On Sat, Sep 8, 2012 at 12:29 PM, Alexander Motin wrote: > Hi. > > It seems like both of your problems have the same cause: device report wrong > size of INQUIRY data, that causes failure on attempt to fetch it. With > FreeBSD 9.0 it caused domain validation failures and so reduced transfer > rate, on 9.1 it also causes detection failure. I am not sure why detection > worked on 9.0, it needs some deeper code comparison, but I think it is > mostly device problem. > > Could you send me output of such commands from FreeBSD 9.0: > camcontrol cmd da0 -vEc "12 00 00 00 24 00" -i 36 - | hd > camcontrol cmd da0 -vEc "12 00 00 00 fe 00" -i 254 - | hd > camcontrol cmd da0 -vEc "12 00 00 01 00 00" -i 256 - | hd > > -- > Alexander Motin This is running 9.0-RELEASE. # camcontrol cmd da0 -vEc "12 00 00 00 24 00" -i 36 - | hd 00 00 02 02 fa 00 00 3e 43 4f 4d 50 41 51 50 43 |...>COMPAQPC| 0010 57 44 45 39 31 30 30 57 20 20 20 20 20 20 20 20 |WDE9100W| 0020 31 2e 30 31 |1.01| 0024 # camcontrol cmd da0 -vEc "12 00 00 00 fe 00" -i 254 - | hd 00 00 02 02 fa 00 00 3e 43 4f 4d 50 41 51 50 43 |...>COMPAQPC| 0010 57 44 45 39 31 30 30 57 20 20 20 20 20 20 20 20 |WDE9100W| 0020 31 2e 30 31 32 33 30 31 57 53 37 30 32 30 33 37 |1.012301WS702037| 0030 32 34 39 33 00 00 00 00 20 20 20 20 20 20 20 20 |2493| 0040 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 || * 0060 57 44 45 39 31 30 30 2d 36 30 30 35 44 30 20 20 |WDE9100-6005D0 | 0070 34 30 36 31 30 30 31 31 39 31 30 30 32 43 30 20 |4061001191002C0 | 0080 32 34 30 38 00 00 00 00 00 00 00 00 00 00 00 00 |2408| 0090 00 00 00 00 4e 32 30 35 30 30 39 39 30 32 35 35 |N20500990255| 00a0 33 20 20 20 50 20 30 30 00 00 00 00 00 00 42 41 |3 P 00..BA| 00b0 43 43 42 45 4b 43 31 39 39 38 30 38 32 38 57 53 |CCBEKC19980828WS| 00c0 36 30 44 20 04 03 00 04 02 01 00 00 00 00 00 00 |60D | 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00f0 # camcontrol cmd da0 -vEc "12 00 00 01 00 00" -i 256 - | hd (pass1:ahc0:0:0:0): INQUIRY. CDB: 12 0 0 1 0 0 (pass1:ahc0:0:0:0): CAM status: SCSI Status Error (pass1:ahc0:0:0:0): SCSI status: Check Condition (pass1:ahc0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (pass1:ahc0:0:0:0): Command Specific Info: 0x (pass1:ahc0:0:0:0): Command byte 3 is invalid camcontrol: error sending command (pass1:ahc0:0:0:0): INQUIRY. CDB: 12 0 0 1 0 0 (pass1:ahc0:0:0:0): CAM status: SCSI Status Error (pass1:ahc0:0:0:0): SCSI status: Check Condition (pass1:ahc0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (pass1:ahc0:0:0:0): Command Specific Info: 0x (pass1:ahc0:0:0:0): Command byte 3 is invalid -- Kirk Russell http://www.ba23.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1 RC1 and CAM issues with old SCSI drive
On 09.09.2012 16:25, kirk russell wrote: On Sat, Sep 8, 2012 at 12:29 PM, Alexander Motin wrote: Hi. It seems like both of your problems have the same cause: device report wrong size of INQUIRY data, that causes failure on attempt to fetch it. With FreeBSD 9.0 it caused domain validation failures and so reduced transfer rate, on 9.1 it also causes detection failure. I am not sure why detection worked on 9.0, it needs some deeper code comparison, but I think it is mostly device problem. Could you send me output of such commands from FreeBSD 9.0: camcontrol cmd da0 -vEc "12 00 00 00 24 00" -i 36 - | hd camcontrol cmd da0 -vEc "12 00 00 00 fe 00" -i 254 - | hd camcontrol cmd da0 -vEc "12 00 00 01 00 00" -i 256 - | hd -- Alexander Motin This is running 9.0-RELEASE. # camcontrol cmd da0 -vEc "12 00 00 00 24 00" -i 36 - | hd 00 00 02 02 fa 00 00 3e 43 4f 4d 50 41 51 50 43 |...>COMPAQPC| 0010 57 44 45 39 31 30 30 57 20 20 20 20 20 20 20 20 |WDE9100W| 0020 31 2e 30 31 |1.01| 0024 # camcontrol cmd da0 -vEc "12 00 00 00 fe 00" -i 254 - | hd 00 00 02 02 fa 00 00 3e 43 4f 4d 50 41 51 50 43 |...>COMPAQPC| 0010 57 44 45 39 31 30 30 57 20 20 20 20 20 20 20 20 |WDE9100W| 0020 31 2e 30 31 32 33 30 31 57 53 37 30 32 30 33 37 |1.012301WS702037| 0030 32 34 39 33 00 00 00 00 20 20 20 20 20 20 20 20 |2493| 0040 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 || * 0060 57 44 45 39 31 30 30 2d 36 30 30 35 44 30 20 20 |WDE9100-6005D0 | 0070 34 30 36 31 30 30 31 31 39 31 30 30 32 43 30 20 |4061001191002C0 | 0080 32 34 30 38 00 00 00 00 00 00 00 00 00 00 00 00 |2408| 0090 00 00 00 00 4e 32 30 35 30 30 39 39 30 32 35 35 |N20500990255| 00a0 33 20 20 20 50 20 30 30 00 00 00 00 00 00 42 41 |3 P 00..BA| 00b0 43 43 42 45 4b 43 31 39 39 38 30 38 32 38 57 53 |CCBEKC19980828WS| 00c0 36 30 44 20 04 03 00 04 02 01 00 00 00 00 00 00 |60D | 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00f0 # camcontrol cmd da0 -vEc "12 00 00 01 00 00" -i 256 - | hd (pass1:ahc0:0:0:0): INQUIRY. CDB: 12 0 0 1 0 0 (pass1:ahc0:0:0:0): CAM status: SCSI Status Error (pass1:ahc0:0:0:0): SCSI status: Check Condition (pass1:ahc0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (pass1:ahc0:0:0:0): Command Specific Info: 0x (pass1:ahc0:0:0:0): Command byte 3 is invalid camcontrol: error sending command (pass1:ahc0:0:0:0): INQUIRY. CDB: 12 0 0 1 0 0 (pass1:ahc0:0:0:0): CAM status: SCSI Status Error (pass1:ahc0:0:0:0): SCSI status: Check Condition (pass1:ahc0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (pass1:ahc0:0:0:0): Command Specific Info: 0x (pass1:ahc0:0:0:0): Command byte 3 is invalid It seems that problem can be in our SCSI code that rounds inquiry data size up to even. Please try to comment out line inquiry_len = roundup2(inquiry_len, 2); in sys/cam/scsi/scsi_xpt.c and rebuild the kernel. It should probably fix both device detection and transfer speed. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1 RC1 and CAM issues with old SCSI drive
On Sun, Sep 9, 2012 at 4:54 PM, Alexander Motin wrote: > On 09.09.2012 16:25, kirk russell wrote: >> >> On Sat, Sep 8, 2012 at 12:29 PM, Alexander Motin wrote: >>> >>> Hi. >>> >>> It seems like both of your problems have the same cause: device report >>> wrong >>> size of INQUIRY data, that causes failure on attempt to fetch it. With >>> FreeBSD 9.0 it caused domain validation failures and so reduced transfer >>> rate, on 9.1 it also causes detection failure. I am not sure why >>> detection >>> worked on 9.0, it needs some deeper code comparison, but I think it is >>> mostly device problem. >>> >>> Could you send me output of such commands from FreeBSD 9.0: >>> camcontrol cmd da0 -vEc "12 00 00 00 24 00" -i 36 - | hd >>> camcontrol cmd da0 -vEc "12 00 00 00 fe 00" -i 254 - | hd >>> camcontrol cmd da0 -vEc "12 00 00 01 00 00" -i 256 - | hd >>> >>> -- >>> Alexander Motin >> >> [.] > > It seems that problem can be in our SCSI code that rounds inquiry data size > up to even. Please try to comment out line > inquiry_len = roundup2(inquiry_len, 2); > in sys/cam/scsi/scsi_xpt.c and rebuild the kernel. It should probably fix > both device detection and transfer speed. > This is running 9.0-RELEASE, with your patch to scsi_xpt.c: da0 at ahc0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: Command Queueing enabled da0: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) This is running FreeBSD 9.1-RC1, with your patch to scsi_xpt.c: da0 at ahc0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: Command Queueing enabled da0: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) -- Kirk Russell http://www.ba23.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IPv4 vs. IPv6 Ethernet Performance
On Thu, 30 Aug 2012, Norbert Aschendorff wrote: Hi, I tested it using tcpdump: http://nopaste.info/9394068f54_nl.html The length field says for each packet 1408 bytes, so that should be OK. The Wireshark instance on the iperf server says something like "16732 bytes on wire" for the most packets (not always with 16732 bytes, but most packets over 10,000) - could that be reassembled somehow? only slowly catching up on email so... chiming in now. I'd assume in this case the iperf "server" is linux or did Jack add IPv6 LRO support to e1000? Sorry, I am not up-to-date. However, any modern peice of hardware should be able to fill the 1G link even with software doing csums or offloading really and all our routing table lookups. What's the well known FreeBSD machine of a machine? I can only imaging what's going on for you and some of the latest work was not yet merged to head or 9; I have 1 or 2 patches posted to net@ for review and testing though. Sorry not immediately helpful. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
bsnmpd always died on HDD detach
I am running bsnmpd with basic snmpd.config (only community and location changed). When there is a problem with HDD and disk disapeared from ATA channel (eg.: disc physically removed) the bsnmpd always dumps core: kernel: pid 1188 (bsnmpd), uid 0: exited on signal 11 (core dumped) I see this for a long rime on all releases of 7.x and 8.x branches (i386 and amd64). I did not tested 9.x. Is it a known bug, or should I file PR? Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bsnmpd always died on HDD detach
On Sun, Sep 09, 2012 at 11:56:55PM +0200, Miroslav Lachman wrote: > I am running bsnmpd with basic snmpd.config (only community and location > changed). > > When there is a problem with HDD and disk disapeared from ATA channel > (eg.: disc physically removed) the bsnmpd always dumps core: > > kernel: pid 1188 (bsnmpd), uid 0: exited on signal 11 (core dumped) > > I see this for a long rime on all releases of 7.x and 8.x branches (i386 > and amd64). I did not tested 9.x. > > Is it a known bug, or should I file PR? Do you happen to run bsnmp-ucd too? If you do then what version is it? In bsnmp-ucd-0.3.5 I introduced a bug that lead to bsnmpd crash on a disk detach. It has been fixed (thanks to Brian Somers) in 0.3.6. -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
