Re: SMART threshold exceeded

[Mike Tancsa]

00%  9309
-
# 8  Short offline   Completed without error   00%  9286
-
# 9  Short offline   Completed without error   00%  9262
-
#10  Short offline   Completed without error   00%  9239
-
#11  Short offline   Completed without error   00%  9215
-
#12  Short offline   Completed without error   00%  9192
-
#13  Short offline   Completed without error   00%  9168
-
#14  Short offline   Completed without error   00%  9144
-
#15  Short offline   Completed without error   00%  9121
-
#16  Short offline   Completed without error   00%  9097
-
#17  Short offline   Completed without error   00%  9074
-
#18  Short offline   Completed without error   00%  9050
-
#19  Short offline   Completed without error   00%  9027
-
#20  Short offline   Completed without error   00%  9003
-
#21  Short offline   Completed without error   00%  8980
-

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
100  Not_testing
200  Not_testing
300  Not_testing
400  Not_testing
500  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute
delay.

backup2# 
--------
Mike Tancsa, Sentex communications http://www.sentex.net
Providing Internet Access since 1994
[EMAIL PROTECTED], (http://www.tancsa.com)
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SMART threshold exceeded

[Mike Tancsa]

At 08:55 PM 27/03/2005, Randy Bush wrote:
> The disk on Port 0 in this case.   The smartmontools can speak to
> disks behind a 3ware both on RELENG_4 and RELENG_5 to get more info.
but maybe not on 6-current?
The driver is the same.   Perhaps try version 5.33 from the cvs on 
sourceforge?
---Mike 

___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: RAID Cards

[Mike Tancsa]

On Sun, 26 Jun 2005 11:38:42 -0500, in sentex.lists.freebsd.hardware
you wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>I am looking to build a new file server.  I have used
>Promise cards exclusivly in the past, but I am looking
>at Highpoint cards for this machine.  Anybody have any
>opinions on RAID cards?


For RAID1, the 3ware cards are great.  I have been using them many
years.  For RAID5, I have started using the Areca SATA cards. VERY
fast.  Both are supported out of the box on FreeBSD 5.4 install CD

---Mike
----
Mike Tancsa, Sentex communications http://www.sentex.net
Providing Internet Access since 1994
[EMAIL PROTECTED], (http://www.tancsa.com)
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Usb to serial problems

[Mike Tancsa]

On 06 Jul 2005 09:11:19 +1000, in sentex.lists.freebsd.hardware you
wrote:

>
>I had an Aten USB to Serial device attached to an old laptop running
>FreeBSD 4.7. I am now upgrading to much newer IBM thinkpad (A21m) :-)
>I have installed FreeBSD 4.10 onto this machine and am now trying to
>get the Aten to work. I have rebuilt the kernel with the extra devices:

If possible, go to 5.4 instead. There are a lot of USB bug fixes and
enhancements over the RELENG_4 branch.  I have a similar USB device
(same chipset) that works just fine using that driver.  On the
RELENG_4 branch, it would panic for me too often.

---Mike
--------
Mike Tancsa, Sentex communications http://www.sentex.net
Providing Internet Access since 1994
[EMAIL PROTECTED], (http://www.tancsa.com)
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 3com V.90 mini-pci modem

[Mike Tancsa]

On Thu, 07 Jul 2005 03:42:38 +0100, in sentex.lists.freebsd.hardware
you wrote:

>Hi,
>
>I have a Dell Latitude c810 laptop which is using a 3com mini-pci combo 
>(modem/ethernet). 
>
>I am using properly the ethernet card but cannot use the modem. 
>The output from pciconf -lv shows me the device. 
>The output is:
>
>[EMAIL PROTECTED]:6:1: .
>vendor: 3com Corp. Networking Division
>device: 3c556 V.90 mini-pci modem.
>class: Simple comms
>
>The only thing I found is some people's drivers in the internet but they all 
>seem to be made for Linux. Did anyone use any of these drivers? Any suggestion 
>or recommendation that may help would be appreciated. I am using Freebsd 5.4.
>

It *might* work with the PUC driver.  What does the output of
pciconf -vl
show ?

---Mike
--------
Mike Tancsa, Sentex communications http://www.sentex.net
Providing Internet Access since 1994
[EMAIL PROTECTED], (http://www.tancsa.com)
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATA problem with FreeBSD 6.1-PRERELEASE #10

[Mike Tancsa]

On Fri, 7 Apr 2006 17:08:11 +0200, in sentex.lists.freebsd.hardware
you wrote:

>Hi all,
>I meet a problem with some ATA tools (ataidle and smartmontool) and FreeBSD
>6.1-PRERELEASE #10.
>
>
>$ smartctl -i /dev/ad0
>smartctl version 5.33 [i386-portbld-freebsd6.0] Copyright (C) 2002-4 Bruce
>Allen
>Home page is http://smartmontools.sourceforge.net/
>
>Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)


There were changed to the ata driver that breaks binary compatibility
of the smartmontools.  You will need to recompile the smartmontools
port and all will work again.


[tyan-1u]# smartctl -a /dev/ad0 | head
smartctl version 5.33 [i386-portbld-freebsd6.1] Copyright (C) 2002-4
Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model: ST340014A
Serial Number:5JX5L5H4
Firmware Version: 3.06
User Capacity:40,020,664,320 bytes
Device is:In smartctl database [for details use: -P show]
ATA Version is:   6
[tyan-1u]# uname -a
FreeBSD tyan-1u.sentex.ca 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0:
Wed Apr  5 07:46:21 EDT 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP  i386
[tyan-1u]# 



---Mike

----
Mike Tancsa, Sentex communications http://www.sentex.net
Providing Internet Access since 1994
[EMAIL PROTECTED], (http://www.tancsa.com)
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SATA-RAID Cards

[Mike Tancsa]

On Thu, 18 May 2006 08:21:25 +0300, in sentex.lists.freebsd.hardware
you wrote:

>Same question I asked earlier on -questions list, but I'll make it here
>again with new subject. :)
>

I would go with the 3ware or the ARECA.

---Mike
--------
Mike Tancsa, Sentex communications http://www.sentex.net
Providing Internet Access since 1994
[EMAIL PROTECTED], (http://www.tancsa.com)
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Intel 1000 PT PCI Express single port ethernet adaptor diffs

[Mike Tancsa]

In case anyone comes across this PCI-e NIC from Intel, the following 
diffs get it to work for me.  I had a quick look at Intels source 
code from the website and they seem to define it just as #define 
E1000_DEV_ID_82572EI 0x10B9



# diff -u if_em.c.orig if_em.c
--- if_em.c.origThu May 18 20:19:57 2006
+++ if_em.c Fri Jun  2 13:59:45 2006
@@ -111,6 +111,7 @@
{ 0x8086, E1000_DEV_ID_82571EB_FIBER,   PCI_ANY_ID, 
PCI_ANY_ID, 0},
{ 0x8086, E1000_DEV_ID_82571EB_SERDES,  PCI_ANY_ID, 
PCI_ANY_ID, 0},


+   { 0x8086, E1000_DEV_ID_82572EI, PCI_ANY_ID, PCI_ANY_ID, 0},
{ 0x8086, E1000_DEV_ID_82572EI_COPPER,  PCI_ANY_ID, 
PCI_ANY_ID, 0},
{ 0x8086, E1000_DEV_ID_82572EI_FIBER,   PCI_ANY_ID, 
PCI_ANY_ID, 0},
{ 0x8086, E1000_DEV_ID_82572EI_SERDES,  PCI_ANY_ID, 
PCI_ANY_ID, 0},

# diff -u if_em_hw.c.orig if_em_hw.c
--- if_em_hw.c.orig Fri Nov 25 09:11:59 2005
+++ if_em_hw.c  Fri Jun  2 14:00:00 2006
@@ -319,6 +319,7 @@
 case E1000_DEV_ID_82571EB_SERDES:
hw->mac_type = em_82571;
break;
+case E1000_DEV_ID_82572EI:
 case E1000_DEV_ID_82572EI_COPPER:
 case E1000_DEV_ID_82572EI_FIBER:
 case E1000_DEV_ID_82572EI_SERDES:
# diff -u if_em_hw.h.orig if_em_hw.h
--- if_em_hw.h.orig Fri Nov 25 09:11:59 2005
+++ if_em_hw.h  Fri Jun  2 13:59:19 2006
@@ -500,6 +500,7 @@
 #define E1000_DEV_ID_82571EB_COPPER  0x105E
 #define E1000_DEV_ID_82571EB_FIBER   0x105F
 #define E1000_DEV_ID_82571EB_SERDES  0x1060
+#define E1000_DEV_ID_82572EI 0x10B9
 #define E1000_DEV_ID_82572EI_COPPER  0x107D
 #define E1000_DEV_ID_82572EI_FIBER   0x107E
 #define E1000_DEV_ID_82572EI_SERDES  0x107F





pciconf -lv shows it as

[EMAIL PROTECTED]:0:0:   class=0x02 card=0x10838086 chip=0x10b98086 
rev=0x06 hdr=0x00

vendor   = 'Intel Corporation'
class= network
subclass = ethernet


I guess for completeness,


# diff -u /usr/src/share/misc/pci_vendors.orig pci_vendors
--- /usr/src/share/misc/pci_vendors.origMon Jul 18 03:45:17 2005
+++ pci_vendors Fri Jun  2 14:11:56 2006
@@ -6970,7 +6970,8 @@
105482801EB/ER PRO/100 VE Network Connection (mobile)
105582801EB/ER PRO/100 VM Network Connection (mobile)
105982551QM Fast Ethernet PCI/CardBus Controller
-   105EPRO/1000 PT
+   10B9PRO/1000 PT Single Port
+   105EPRO/1000 PT Dual Port
105FPRO/1000 PF
1060PRO/1000 PB
106482562EZ PRO/100 Ethernet Controller


As the 105E refers to the dual port (at least my NIC does)


[EMAIL PROTECTED]:0:0:   class=0x02 card=0x115e8086 chip=0x105e8086 
rev=0x06 hdr=0x00

vendor   = 'Intel Corporation'
device   = 'PRO/1000 PT'
class= network
subclass = ethernet
[EMAIL PROTECTED]:0:1:   class=0x02 card=0x115e8086 chip=0x105e8086 
rev=0x06 hdr=0x00

vendor   = 'Intel Corporation'
device   = 'PRO/1000 PT'
class= network
subclass = ethernet



dmesg for the dual (on i386)

em0:  port 
0x9000-0x901f mem 0xd702-0xd703,0xd700-0xd701 irq

17 at device 0.0 on pci6
em0: Ethernet address: 00:15:17:0b:70:98
em1:  port 
0x9400-0x941f mem 0xd704-0xd705,0xd706-0xd707 irq

18 at device 0.1 on pci6
em1: Ethernet address: 00:15:17:0b:70:99

dmesg for the single (on AMD64)

em0:  port 
0xd800-0xd81f mem 0xfe9e-0xfe9f,0xfe9c-0xfe9d irq 18 
at device 0.0 on pci2

em0: Ethernet address: 00:15:17:0b:6a:83



----
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

nVidia MCP51 NIC

[Mike Tancsa]

 port 0xd400-0xd407 mem 
0xfe02b000-0xfe02bfff irq 21 at device 20.0 on pci0

nve0: Ethernet address 00:16:ec:9b:c3:97
miibus1:  on nve0
ukphy0:  on miibus1
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
nve0: Ethernet address: 00:16:ec:9b:c3:97
acpi_tz0:  on acpi0
fdc0:  port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FAST]
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
pmtimer0 on isa0
orm0:  at iomem 0xd-0xd3fff,0xd4000-0xd57ff on isa0
ppc0: parallel port not found.
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounters tick every 1.000 msec
ad0: 76319MB  at ata0-master UDMA100
SMP: AP CPU #1 Launched!
Trying to mount root from ufs:/dev/ad0s1a




Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Multiport cards

[Mike Tancsa]

On Fri, 2 Mar 2007 15:44:41 +0600, in sentex.lists.freebsd.hardware
you wrote:

>Intel DQ965F motherboard has only one COM-port and it miss on backplane. I'd 
>like to setup multiport card with 2-4 COM's. Are these cards supported in 
>FreeBSD:
>

I use Lava cards and they work fairly well.  Take a look at 
/usr/src/sys/dev/puc/pucdata.c
and you can get a sense of what works.

---Mike

>ST-lab I-142, I-152, I-160, I-180
>Match Tech CP4S

----
Mike Tancsa, Sentex communications http://www.sentex.net
Providing Internet Access since 1994
[EMAIL PROTECTED], (http://www.tancsa.com)
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Multiport cards

[Mike Tancsa]

On Mon, 5 Mar 2007 10:44:08 +0600, in sentex.lists.freebsd.hardware
you wrote:

>On Saturday 03 March 2007 06:52, Mike Tancsa wrote:
>> 
>> I use Lava cards and they work fairly well.  Take a look at 
>> /usr/src/sys/dev/puc/pucdata.c
>> and you can get a sense of what works.
>> 
>>  ---Mike
>> 
>> >ST-lab I-142, I-152, I-160, I-180
>> >Match Tech CP4S
>
>That was first, what I have done, but I cannot search any notifications about 
>ST-lab nor Match Tech in pucdata.c. There are cheapest devices, I think, our 
>company does not ravage itself with 300-600 russian rubles :->>> But I need 
>working solution - I need to install new server, but I need at least 2 COM's 
>on it...

I have no idea on pricing where you are, but here in Canada they are
about $50 USD new Perhaps cheaper on ebay.  If you are really
strapped for cash, consider a couple of cheap USB-serial adaptors. I
find the ones based on the UFTDI work best and they can be had for
fairly low prices if you shop around.

---Mike.


Mike Tancsa, Sentex communications http://www.sentex.net
Providing Internet Access since 1994
[EMAIL PROTECTED], (http://www.tancsa.com)
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

MPT SAS1064

[Mike Tancsa]

Hi,

One of our suppliers sent us an MPT adaptor (SAS1064? screen capture 
below) to evaluate.  Seems like a fairly decent adaptor speed / 
feature wise, but I cant seem to figure out a way to monitor the 
status of the array ?  Is there a way to do so from RELENG_6 ?


---Mike


| LSI Logic MPT Setup Utility  v6.04.00.00 
(2005.08.29)|
| Adapter List  Global 
Properties  |
| AdapterPCI  PCI  PCI  PCI   FW 
Revision  StatusBoot  |
|Bus  Dev  Fnc  Slot 
Order |
| 
SAS106403   01   00   021.06.00.00-IREnabled   0|


[tyan-1u]% dmesg | grep mpt
mpt0:  port 0xd800-0xd8ff mem 
0xdfefc000-0xdfef,0xdfee-0xdfee irq 48 at device 1.0 on pci3

mpt0: [GIANT-LOCKED]
mpt0: MPI Version=1.5.10.0
mpt0: mpt_cam_event: 0xb
mpt0: Unhandled Event Notify Frame. Event 0xb (ACK not required).
da0 at mpt0 bus 0 target 8 lun 0
[tyan-1u]% dmesg | grep da0
da0 at mpt0 bus 0 target 8 lun 0
da0:  Fixed Direct Access SCSI-2 device
da0: 300.000MB/s transfers, Tagged Queueing Enabled
da0: 75340MB (154296320 512 byte sectors: 255H 63S/T 9604C)
[tyan-1u]%

[EMAIL PROTECTED]:1:0:  class=0x01 card=0x30201000 chip=0x00501000 
rev=0x02 hdr=0x00

vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
class  = mass storage
subclass   = SCSI
cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
cap 05[98] = MSI supports 1 message, 64 bit
cap 07[68] = PCI-X 64-bit supports 133MHz, 2048 burst read, 16 
split transactions

cap 11[b0] = MSI-X supports 1 message in map 0x14


----
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MPT SAS1064

[Mike Tancsa]

At 01:21 AM 3/10/2007, [EMAIL PROTECTED] wrote:


Haven't a clue- this doesn't appear to be the embedded mirroring 
adapter- which is good because you're lucky if it works at all for 
you. What's the actual underlying device?


Hi,
Not sure how to find that out ? I dont see anything in dmesg 
or pciconf other than what I included in the original email.


---Mike



| LSI Logic MPT Setup Utility  v6.04.00.00 (2005.08.29) |
| Adapter List  Global Properties |
| AdapterPCI  PCI  PCI  PCI   FW Revision  StatusBoot |
|Bus  Dev  Fnc  Slot Order |
| SAS106403   01   00   021.06.00.00-IREnabled   0 |

[tyan-1u]% dmesg | grep mpt
mpt0:  port 0xd800-0xd8ff mem 
0xdfefc000-0xdfef,0xdfee-0xdfee irq 48 at device 1.0 on pci3

mpt0: [GIANT-LOCKED]
mpt0: MPI Version=1.5.10.0
mpt0: mpt_cam_event: 0xb
mpt0: Unhandled Event Notify Frame. Event 0xb (ACK not required).
da0 at mpt0 bus 0 target 8 lun 0
[tyan-1u]% dmesg | grep da0
da0 at mpt0 bus 0 target 8 lun 0
da0:  Fixed Direct Access SCSI-2 device
da0: 300.000MB/s transfers, Tagged Queueing Enabled
da0: 75340MB (154296320 512 byte sectors: 255H 63S/T 9604C)
[tyan-1u]%

[EMAIL PROTECTED]:1:0:  class=0x01 card=0x30201000 chip=0x00501000 
rev=0x02 hdr=0x00

   vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
   class  = mass storage
   subclass   = SCSI
   cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
   cap 05[98] = MSI supports 1 message, 64 bit
   cap 07[68] = PCI-X 64-bit supports 133MHz, 2048 burst read, 16 
split transactions

   cap 11[b0] = MSI-X supports 1 message in map 0x14


--------
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike



___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MPT SAS1064

[Mike Tancsa]

At 11:51 AM 3/10/2007, [EMAIL PROTECTED] wrote:

Do you know what the actual attached disk(s) are? Can you get into 
the MPT BIOS and look at the RAID Properties tab if it exists?


Hi,
Yes, I just attached a couple of Segate SATA drives and configured 
the card to be a RAID1 mirror.


---Mike



At 01:21 AM 3/10/2007, [EMAIL PROTECTED] wrote:


Haven't a clue- this doesn't appear to be the embedded mirroring 
adapter- which is good because you're lucky if it works at all for 
you. What's the actual underlying device?


Hi,
   Not sure how to find that out ? I dont see anything in 
dmesg or pciconf other than what I included in the original email.


   ---Mike



| LSI Logic MPT Setup Utility  v6.04.00.00 (2005.08.29) |
| Adapter List  Global Properties |
| AdapterPCI  PCI  PCI  PCI   FW Revision  StatusBoot |
|Bus  Dev  Fnc  Slot Order |
| SAS106403   01   00   021.06.00.00-IREnabled   0 |
[tyan-1u]% dmesg | grep mpt
mpt0:  port 0xd800-0xd8ff mem 
0xdfefc000-0xdfef,0xdfee-0xdfee irq 48 at device 1.0 on pci3

mpt0: [GIANT-LOCKED]
mpt0: MPI Version=1.5.10.0
mpt0: mpt_cam_event: 0xb
mpt0: Unhandled Event Notify Frame. Event 0xb (ACK not required).
da0 at mpt0 bus 0 target 8 lun 0
[tyan-1u]% dmesg | grep da0
da0 at mpt0 bus 0 target 8 lun 0
da0:  Fixed Direct Access SCSI-2 device
da0: 300.000MB/s transfers, Tagged Queueing Enabled
da0: 75340MB (154296320 512 byte sectors: 255H 63S/T 9604C)
[tyan-1u]%
[EMAIL PROTECTED]:1:0:  class=0x01 card=0x30201000 chip=0x00501000 
rev=0x02 hdr=0x00

   vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
   class  = mass storage
   subclass   = SCSI
   cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
   cap 05[98] = MSI supports 1 message, 64 bit
   cap 07[68] = PCI-X 64-bit supports 133MHz, 2048 burst read, 
16 split transactions

   cap 11[b0] = MSI-X supports 1 message in map 0x14

--------
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike




___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Areca ARC-1120 on FreeBSD 7.0

[Mike Tancsa]

At 11:11 AM 8/12/2008, Andrew Hotlab wrote:

You can confirm me that you are successfully using FreeBSD 7.0R with 
the 1.43 firmware? If it's so, we might compare our hardware 
components to find out if and what are differences...



Hi,
The dmesg below is on a supermicro board.  Actually, if you 
take the Areca out, does 7.0R boot up ?  As mentioned by another 
poster, try the RELENG_7 snapshot to see if it boots with that. If 
you are starting fresh, I would suggest it as there are a number of 
bug fixes and enhancements in the snapshot and its quite stable.



Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.0-PRERELEASE #3: Wed Feb 13 11:51:23 EST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/db
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU3060  @ 2.40GHz (2400.10-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
  
Features=0xbfebfbff
  Features2=0xe3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  Cores per package: 2
usable memory = 8577662976 (8180 MB)
avail memory  = 8298295296 (7913 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 5
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0:  on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
cpu0:  on acpi0
est0:  on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 92a092a0600092a
device_attach: est0 attach returned 6
p4tcc0:  on cpu0
cpu1:  on acpi0
est1:  on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 92a092a0600092a
device_attach: est1 attach returned 6
p4tcc1:  on cpu1
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 28.0 on pci0
pci1:  on pcib1
pcib2:  at device 0.0 on pci1
pci2:  on pcib2
arcmsr0: > mem 0xe860-0xe8600fff,0xe800-0xe83f irq 18 at device 
14.0 on pci2

ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07
ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17
arcmsr0: [ITHREAD]
pcib3:  at device 0.2 on pci1
pci3:  on pcib3
pcib4:  at device 28.4 on pci0
pci4:  on pcib4
pcib5:  at device 28.5 on pci0
pci5:  on pcib5
em0:  port 
0x2000-0x201f mem 0xe858-0xe859,0xe850-0xe857 irq 17 
at device 0.0 on pci5

em0: Using MSI interrupt
em0: Ethernet address: 00:15:17:50:40:28
em0: [FILTER]
pci5:  at device 0.3 (no driver attached)
pci5:  at device 0.4 (no driver attached)
pcib6:  at device 30.0 on pci0
pci6:  on pcib6
vgapci0:  port 0x1000-0x10ff mem 
0xe000-0xe7ff,0xe844-0xe844 irq 18 at device 4.0 on pci6
em1:  port 
0x1100-0x113f mem 0xe842-0xe843,0xe840-0xe841 irq 17 
at device 5.0 on pci6

em1: Ethernet address: 00:15:17:50:40:29
em1: [FILTER]
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3030-0x303f irq 18 at device 31.1 on pci0

ata0:  on atapci0
ata0: [ITHREAD]
ata1:  on atapci0
ata1: [ITHREAD]
atapci1:  port 
0x3048-0x304f,0x3064-0x3067,0x3040-0x3047,0x3060-0x3063,0x3020-0x302f 
mem 0xe870-0xe87003ff irq 19 at device 31.2 on pci0

atapci1: [ITHREAD]
ata2:  on atapci1
ata2: [ITHREAD]
ata3:  on atapci1
ata3: [ITHREAD]
pci0:  at device 31.3 (no driver attached)
fdc0:  port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0
fdc0: [FILTER]
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A, console
sio0: [FILTER]
orm0:  at iomem 
0xc-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff on isa0

ppc0: cannot reserve I/O port range
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounters tick every 1.000 msec
Waiting 5 seconds for SCSI devices to settle
(probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step
da0 at arcmsr0 bus 0 target 0 lun 0
da0:  Fixed Direct Access SCSI-5 device
da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit)
da0: 305175MB (624999424 512 byte sectors: 255H 63S/T 38904C)
SMP: AP CPU #1 Launched!
Trying to mount root from ufs:/dev/da0s1a



Thanks a lot for your help.


> From: 

RE: Areca ARC-1120 on FreeBSD 7.0

[Mike Tancsa]

At 12:13 PM 8/12/2008, Andrew Hotlab wrote:
last e-mail! :)  I can confirm that all works like a charm without 
the Areca card. So, where the problem might lie?!  I tested the card 
with both 7.0-STABLE and 8.0-CURRENT (it hangs even before) without

success... :(


Perhaps a disk option set on the Areca ? Looking at my config, I have 
it set to

SATA300+NCQ
HDD Read Ahead Cache  enabled
Stagger Power On Control 0..4
Spin Down Idle HDD  disabled
HDD SMART status polling enabled
Disk Write Cache Mode enabled

Can you try booting without the drives, or with just a couple of 
drives with a fresh raidset created ?  I wonder if the box is booting 
up and is confused by the existing raidset ?


---Mike


P.S.: during all these tests I was always verifying that the card 
itself was always functioning well, by

booting the Windows Server 2003 x64 installed on the RAID set.

>
>
>>Thanks a lot for your help.
>>
>>
>>> From: [EMAIL PROTECTED]
>>> To: [EMAIL PROTECTED]
>>> Subject: Re: Areca ARC-1120 on FreeBSD 7.0
>>> Date: Tue, 12 Aug 2008 08:13:56 -0400
>>>
>>> On Mon, 11 Aug 2008 22:54:41 +, in sentex.lists.freebsd.hardware
>>> you wrote:
arcmsr0:  mem 0xfc7ff000-0xfc7f,0xfc00-0xfc3f irq 31
>> at device 14.0 on pci2
arcmsr0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfc7ff000
ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07
ARECA RAID ADAPTER0: FIRMWARE VERSION V1.39 2006-2-9
>>>
>>>
>>> Not sure it will help you or not, but I run the same card with version
>>> 1.43 of the firmware.  I would try to upgrade the Areca card's
>>> firmware and then give 7.0R another try.
>>>
>>>   ---Mike
>>

_
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx


___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Areca ARC-1120 on FreeBSD 7.0

[Mike Tancsa]

At 01:54 PM 8/12/2008, Andrew Hotlab wrote:
I tried to boot without disks using the new firmware, but nothing 
changed! Then I created a new RAID0
set/volume using only a single SATA drive (it was used as online 
spare), but still not success... I'm afraid

to have ended any ideas about what it might be the cause of this trouble!! :(

I'll go on changing PCI-X slot of the Areca card, but I'm going to 
became pessimistic about a successful

end of this story... sigh!



MB BIOS update ?  On some more exotic boards I find I sometimes have 
to disable some features, typically USB related, if there are 
problems.  Not sure in your case.  I think MSI is enabled by default 
on 7 and not on 6, so perhaps something on the board does not like 
that ?  Try disabling it in the loader.conf


hw.pci.enable_msi=0

---Mike 


___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel

[Mike Tancsa]

At 04:44 PM 10/9/2008, Nick Hibma wrote:

Just now I have committed a driver for Option and Huawei cards previously
supported by the ubsa driver. More information is in the commit message.

I am looking for people who would be able to provide more information after
testing with the 3G cards branded by:


Hi,
I gave it a try on the Sierra USB card and it seems to work 
really well on RELENG_7! There is however also a mini-pci express 
version of the Sierra card, the MC8775.  Do you have plans to add 
support for it ?  I am not sure how the unit is even supposed to show 
up as I dont see it in the dmesg, but I do see that it shows some 
sort of umass device


# usbdevs
addr 1: OHCI root hub, AMD
 addr 2: USB MMC Storage, Sierra Wireless
addr 1: EHCI root hub, AMD

dmesg snippet
...
isa_probe_children: probing PnP devices
umass0: addr 2> on uhub0

umass0:0:0:-1: Attached to scbus0
Device configuration finished.
procfs registered
Timecounter "TSC" frequency 498053687 Hz quality 800
Timecounters tick every 1.000 msec
crypto: 
vlan: initialized, using hash tables with chaining
IPsec: Initialized Security Association Processing.
pflog0: bpf attached
lo0: bpf attached
ata0-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire
ad0: setting PIO4 on CS5536 chip
ad0: 1953MB  at ata0-master PIO4
ad0: 4001760 sectors [3970C/16H/63S] 4 sectors/interrupt 1 depth queue
GEOM: new disk ad0
pass0 at umass-sim0 bus 0 target 0 lun 0
pass0:  Removable CD-ROM SCSI-0 device
pass0: 1.000MB/s transfers
Trying to mount root from ufs:/dev/ad0s1a
start_init: trying /sbin/init
bridge0: bpf attached
bridge0: Ethernet address: 3a:72:35:a3:25:ce
tun0: bpf attached

Not sure why it shows up as a passthrough device ?

---Mike




OEM:
Merlin
Huawei
Option
Sierra
Novatel
Qualcomm

Rebranded:
Dell
Vodafone

Note: The driver can be copied across to FreeBSD 7-STABLE if you copy the
sys/modules/u3g directory and sys/dev/usb/u3g.c and sys/dev/usb/usbdevs
files from HEAD and _move_ the ID from ubsa to u3g.

More information can be found on

http://people.freebsd.org/~n_hibma/u3g.html

Thanks,

Nick
--  Forwarded Message  --
Subject: svn commit: r183735 - in head: share/man/man4 sys/conf sys/dev/usb
sys/i386/conf sys/modules sys/modules/u3g
Date: Thu October 9 2008
From: Nick Hibma <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]

Author: n_hibma
Date: Thu Oct  9 21:25:01 2008
New Revision: 183735
URL: http://svn.freebsd.org/changeset/base/183735

Log:
  Say hello to the u3g driver, implementing support for 3G modems.

  This was located in the ubsa driver, but should be moved into a separate
  driver:

  - 3G modems provide multiple serial ports to allow AT commands while the
PPP
connection is up.
  - 3G modems do not provide baud rate or other serial port settings.
  - Huawei cards need specific initialisation.
  - ubsa is for Belkin adapters, an Linuxy choice for another device like
3G.

  Speeds achieved here with a weak signal at best is ~40kb/s (UMTS). No
spooky
  STALLED messages as well.

  Next: Move over all entries for Sierra and Novatel cards once I have found
  testers, and implemented serial port enumeration for Sierra (or rather
have
  Andrea Guzzo do it). They list all endpoints in 1 iface instead of 4
ifaces.

  Submitted by: [EMAIL PROTECTED]
  MFC after:3 weeks

Added:
  head/share/man/man4/u3g.4   (contents, props changed)
  head/sys/dev/usb/u3g.c   (contents, props changed)
  head/sys/modules/u3g/
  head/sys/modules/u3g/Makefile   (contents, props changed)
Modified:
  head/share/man/man4/Makefile
  head/sys/conf/NOTES
  head/sys/conf/files
  head/sys/dev/usb/ubsa.c
  head/sys/dev/usb/usbdevs
  head/sys/i386/conf/GENERIC
  head/sys/modules/Makefile

Modified: head/share/man/man4/Makefile
==
--- head/share/man/man4/MakefileThu Oct  9 20:51:25 
2008(r183734)
+++ head/share/man/man4/MakefileThu Oct  9 21:25:01 
2008(r183735)

@@ -384,6 +384,7 @@ MAN=aac.4 \
twe.4 \
tx.4 \
txp.4 \
+   u3g.4 \
uark.4 \
uart.4 \
ubsa.4 \

Added: head/share/man/man4/u3g.4
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/man/man4/u3g.4   Thu Oct  9 21:25:01 2008(r183735)
@@ -0,0 +1,100 @@
+.\"
+.\" Copyright (c) 2008 AnyWi Technologies
+.\" All rights reserved.
+.\"
+.\" This code is derived from uark.c
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
WARRANTIES
+.\" WITH REGARD

Re: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel

[Mike Tancsa]

At 11:06 AM 11/5/2008, Nick Hibma wrote:


> At 04:44 PM 10/9/2008, Nick Hibma wrote:
> >Just now I have committed a driver for Option and Huawei cards
> > previously supported by the ubsa driver. More information is in the
> > commit message.
> >
> >I am looking for people who would be able to provide more information
> > after testing with the 3G cards branded by:
>
> Hi,
>  I gave it a try on the Sierra USB card and it seems to work
> really well on RELENG_7! There is however also a mini-pci express
> version of the Sierra card, the MC8775.  Do you have plans to add
> support for it ?  I am not sure how the unit is even supposed to show
> up as I dont see it in the dmesg, but I do see that it shows some
> sort of umass device
>
> # usbdevs
> addr 1: OHCI root hub, AMD
>   addr 2: USB MMC Storage, Sierra Wireless
> addr 1: EHCI root hub, AMD

If you could run usbdevs -v and then jot down the IDs you can add those to
the top of u3g.c. You'll have to add a quirk like for other sierra devices
that show up as mass storage and need to be kicked into modem mode.

It pretends to be a mass storage device (with drivers on it) and after
installation switches to modem mode.

Or that's my guess.



# usbdevs -v
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x), 
AMD(0x), rev 1.00

 port 1 powered
 port 2 addr 2: full speed, power 100 mA, config 1, USB MMC 
Storage(0x0fff), Sierra Wireless(0x1199), rev 0.00

 port 3 powered
 port 4 powered
Controller /dev/usb1:
addr 1: high speed, self powered, config 1, EHCI root hub(0x), 
AMD(0x), rev 1.00

 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered

It looks like its already there in the drivers. Is it possible the 
mini-pci express card is conflicting with the USB of the Alix board ?


---Mike


Nick

> dmesg snippet
> ...
> isa_probe_children: probing PnP devices
> umass0:  addr 2> on uhub0
> umass0:0:0:-1: Attached to scbus0
> Device configuration finished.
> procfs registered
> Timecounter "TSC" frequency 498053687 Hz quality 800
> Timecounters tick every 1.000 msec
> crypto: 
> vlan: initialized, using hash tables with chaining
> IPsec: Initialized Security Association Processing.
> pflog0: bpf attached
> lo0: bpf attached
> ata0-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire
> ad0: setting PIO4 on CS5536 chip
> ad0: 1953MB  at ata0-master PIO4
> ad0: 4001760 sectors [3970C/16H/63S] 4 sectors/interrupt 1 depth queue
> GEOM: new disk ad0
> pass0 at umass-sim0 bus 0 target 0 lun 0
> pass0:  Removable CD-ROM SCSI-0 device
> pass0: 1.000MB/s transfers
> Trying to mount root from ufs:/dev/ad0s1a
> start_init: trying /sbin/init
> bridge0: bpf attached
> bridge0: Ethernet address: 3a:72:35:a3:25:ce
> tun0: bpf attached
>
> Not sure why it shows up as a passthrough device ?
>
>  ---Mike


___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel

[Mike Tancsa]

At 10:48 AM 11/5/2008, Mike Tancsa wrote:

At 04:44 PM 10/9/2008, Nick Hibma wrote:

Just now I have committed a driver for Option and Huawei cards previously
supported by the ubsa driver. More information is in the commit message.

I am looking for people who would be able to provide more information after
testing with the 3G cards branded by:


Hi,
I gave it a try on the Sierra USB card and it seems to work 
really well on RELENG_7! There is however also a mini-pci express 
version of the Sierra card, the MC8775.



For the archives, I was able to get the card working with the latest 
version of the driver from the SVN tree! 
(http://people.freebsd.org/~n_hibma/u3g.html)


For the hardware, I used
http://www.pcengines.ch/alix6b2.htm
with RELENG_7 and nanobsd.  The board has dual SIM slots, but there 
are no drivers to switch between the two, so just the top one works.


When I bought the mini-pciexpress card (or PCI Express Mini Card), it 
was listed as a MC8775, where as ati3 shows a Sierra MC8781.  I 
bought it on ebay from the US and it works fine using my Roger's 
blackbery SIM here in Ontario, Canada.



# cat /var/run/dmesg.boot
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-PRERELEASE #0: Thu Nov  6 12:05:41 EST 2008
[EMAIL PROTECTED]:/usr/obj/nanobsd.alix/usr/src/sys/nano5501
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Geode(TM) Integrated Processor by AMD PCS (498.05-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x5a2  Stepping = 2
  Features=0x88a93d
  AMD Features=0xc040
real memory  = 268435456 (256 MB)
avail memory = 253202432 (241 MB)
pnpbios: Bad PnP BIOS data checksum
K6-family MTRR support enabled (2 registers)
cryptosoft0:  on motherboard
pcib0:  pcibus 0 on motherboard
pci0:  on pcib0
...
u3gstub0: at uhub0 port 2 (addr 2) disconnected
u3gstub0: detached

ucom0: 1.10/0.02, addr 2> on uhub0

ucom0: configured 3 serial ports (U0.%d)



# cu -l /dev/cuaU0.2
Connected
ati
Manufacturer: Sierra Wireless, Inc.
Model: MC8781
Revision: F1_0_0_4CAP C:/WS/FW/F1_0_0_4CAP/MSM7200R3/SRC/AMSS 
2007/09/25 18:39:23

IMEI: 356685011922513
IMEI SV: 4
FSN: D350568535811
3GPP Release 6
+GCAP: +CGSM,+DS,+ES

at!GSTATUS?
!GSTATUS:
Current Time:  3455 Temperature: 30
Bootup Time:   3201 Mode:ONLINE
System mode:   WCDMAPS state:Not attached
WCDMA band:WCDMA800 GSM band:Unknown
WCDMA channel: 1037 GSM channel: 65535
GMM (PS) state:DEREGISTERED NO IMSI
MM (CS) state: IDLE NO IMSI

WCDMA L1 State:L1M_PCH_SLEEPRRC State:   DISCONNECTED
RX level (dBm):-87


OK
at^SYSINFO
^SYSINFO: 1,0,1,5,255 


___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ichwd device ID for Intel H55 Express Watchdog

[Mike Tancsa]

9/
ichwd0:  on isa0
WARNING: /usr/src was not properly dismounted
0(i3)%


--------
Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 11/23/2010 7:47 AM, Ivan Voras wrote:
> It looks like I'm unfortunate enough to have to deploy on a machine
> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
> apparently has hardware issues, according to this thread:
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449
> 
> 

Interesting, this is the same nic that has been giving me grief! Mine is
on an Intel server board (S3420GPX). The symptoms are VERY similar to
what the LINUX user sees as well with RX errors and the traffic patterns.

---Mike


> One of the proposed workarounds is disabling "Active State Power
> Management" in the BIOS and in the OS.
> 
> I have disabled it in BIOS but I don't know how to disable it in FreeBSD
> (apparently only disabling it in BIOS isn't enough).
> 
> Any ideas on how to achieve the effect in FreeBSD?
> 
> ___
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 
> 

___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 11/23/2010 8:16 AM, Ivan Voras wrote:
> On 11/23/10 14:03, Mike Tancsa wrote:
>> On 11/23/2010 7:47 AM, Ivan Voras wrote:
>>> It looks like I'm unfortunate enough to have to deploy on a machine
>>> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which
>>> apparently has hardware issues, according to this thread:
>>>
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449
>>>
>>>
>>>
>>
>> Interesting, this is the same nic that has been giving me grief! Mine is
>> on an Intel server board (S3420GPX). The symptoms are VERY similar to
>> what the LINUX user sees as well with RX errors and the traffic patterns.
> 
> I've posted detailed info on this NIC in the thread "em card wedging" -
> can you compare it with yours?
> 
> The whole thing looks very sensitive to BIOS settings. I've just toggled
> something that looked unrelated (don't remember what, I've been toggling
> BIOS settings all day) and the machine has been doing a flood-ping for
> 20 minutes without wedging (which doesn't mean it won't wedge as soon as
> I send this message, it did such things before).


I posted whats in the BIOS at

http://www.tancsa.com/82574.html

Unfortunately, if I disable the BIOS option highlighted I can no longer
netboot the box :(  For my production box having the issues, this is not
a problem.  But it makes it difficult for testing on my lab box.  I am
not sure if that even really disables IPMI ?  Also on this box whats
NIC1 and NIC2 is the opposite of what FreeBSD sees as em0 and em1.

So far I have tried

Driver from HEAD -- This seems to help a bit in that wedges are less
disable MSIX - no difference, still hangs

It seems the nic will get one error and never recover. There will just
be a steady stream of them.  On the other onboard nic (a different type
of em), the card will see the odd "no_buff" error, but it recovers like
all the other em nics. Where as this problem nic, gets errors and they
just keep on going up and up. Using the driver from HEAD, I can do an
ifconfig em1 down;sleep 1;ifconfig em1 up and that fixes the problem

dev.em.1.mac_stats.missed_packets: 1292
dev.em.1.mac_stats.recv_no_buff: 31

where as previous versions of the driver would panic the box doing that.

Looking at the driver from HEAD, there does seem to be some mention of
ASPM. Is this what the LINUX driver is doing too ?



   /* PCI-Ex Control Registers */
switch (hw->mac.type) {
case e1000_82574:
case e1000_82583:
reg = E1000_READ_REG(hw, E1000_GCR);
reg |= (1 << 22);
E1000_WRITE_REG(hw, E1000_GCR, reg);

/*
 * Workaround for hardware errata.
 * apply workaround for hardware errata documented in errata
 * docs Fixes issue where some error prone or unreliable
PCIe
 * completions are occurring, particularly with ASPM
enabled.
 * Without fix, issue can cause tx timeouts.
 */
reg = E1000_READ_REG(hw, E1000_GCR2);
reg |= 1;
E1000_WRITE_REG(hw, E1000_GCR2, reg);
break;
default:
break;
}

return;




---Mike
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 11/23/2010 12:39 PM, Sean Bruno wrote:
> On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote:
>> It looks like I'm unfortunate enough to have to deploy on a machine 
>> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which 
> i...@pci0:5:0:0:class=0x02 card=0x8975152d chip=0x10c98086

Strange, the 82574 attaches as em for me, not igb

e...@pci0:10:0:0:class=0x02 card=0x34ec8086 chip=0x10d38086
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
class  = network
subclass   = ethernet
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
cap 11[a0] = MSI-X supports 5 messages in map 0x1c
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 001517ed68a4

Normally, its msix, but I had disabled that hoping it would fix the problem

em1:  port 0x2000-0x201f mem
0xb410-0xb411,0xb412-0xb4123fff irq 16 at dev
ice 0.0 on pci10
em1: Using an MSI interrupt
em1: [FILTER]
em1: Ethernet address: 00:15:17:ed:68:a4


---Mike
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 12/24/2010 5:44 PM, Jan Koum wrote:
> hi Ivan and Mike,
> 
> wanted to follow up and see if you found a solid long-term solution to this
> bug. we are still seeing this problem in our 8.2 environment with ASPM
> already disabled.  here is what we have:

Hmmm,
With the latest version of the driver in RELENG_8 (its the same as in
HEAD) I havent seen the problem.  However, I would only see it once per
week prior to that.  The odd thing is that it would happen during a
slightly lower than normal backup load, but almost always at the same
time (early sunday AM).  Not sure what would trigger it exactly.  If it
happened again, I was going to enable port mirroring on the switchport
and capture the traffic, hoping some "special" pattern would enable the
issue.

Do you have IPMI enabled on the NIC ? I tried to turn it off on my MB,
but there is no clear way to do this. It 'seems' to be off, but not sure
if it really is.  One thing I noticed was that when the NIC was hung, it
still was able to receive and process IPMI commands from an external host.

---Mike

> 
> 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon:
> 
> e...@pci0:3:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00
> hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
> class  = network
> subclass   = ethernet
> e...@pci0:4:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00
> hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
> class  = network
> subclass   = ethernet
> e...@pci0:5:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00
> hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
> class  = network
> subclass   = ethernet
> e...@pci0:6:0:0: class=0x02 card=0x040d15d9 chip=0x10d38086 rev=0x00
> hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
> class  = network
> subclass   = ethernet
> 
> 2. ASPM is already disabled in the BIOS
> 
> 3. when em1 interface locks up, sysctl debug says:
> 
> Interface is NOT RUNNING
> and INACTIVE
> em1: hw tdh = 0, hw tdt = 0
> em1: hw rdh = 0, hw rdt = 0
> em1: Tx Queue Status = 0
> em1: TX descriptors avail = 110
> em1: Tx Descriptors avail failure = 319
> em1: RX discarded packets = 0
> em1: RX Next to Check = 80
> em1: RX Next to Refresh = 80
> 
> 4. doing "ifconfig em1 down; sleep1; ifconfig em1 up" resolves the issue and
> removes OACTIVE flag from em1.
> 
> 5. we are running 8.2-PRERELEASE from December 19th:
> % grep '$FreeBSD' /usr/src/sys/dev/e1000/if_em.c
> /*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.18 2010/12/14 19:59:39 jfv
> Exp $*/
> 
> dmesg output is:
> 
> em1:  port 0xcc00-0xcc1f mem
> 0xfb4e-0xfb4f,0xfb4dc000-0xfb4d irq 17 at device 0.0 on pci4
> em1: Reserved 0x2 bytes for rid 0x10 type 3 at 0xfb4e
> em1: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfb4dc000
> em1: attempting to allocate 3 MSI-X vectors (5 supported)
> msi: routing MSI-X IRQ 259 to local APIC 0 vector 53
> msi: routing MSI-X IRQ 260 to local APIC 0 vector 54
> msi: routing MSI-X IRQ 261 to local APIC 0 vector 55
> em1: using IRQs 259-261 for MSI-X
> em1: Using MSIX interrupts with 3 vectors
> em1: [MPSAFE]
> em1: [ITHREAD]
> em1: [MPSAFE]
> em1: [ITHREAD]
> em1: [MPSAFE]
> em1: [ITHREAD]
> em1: bpf attached
> em1: Ethernet address: 00:25:90:0e:25:e9
> 
> aside from running cronjob every minute to check for dead interface and
> reset it, is there anything else we can try?
> 
> thanks.
> 
> 
> On Tue, Nov 23, 2010 at 10:36 AM, Jack Vogel  wrote:
> 
>> 82574 is supposed to be em, not igb :)  Its always had this kind of
>> 'in-between'
>> status, it was targeted as a 'client' or consumer part, but it has MSIX
>> which
>> make it almost like 8257[56].
>>
>> Mike, there are some further 82574 changes to shared code that I'm looking
>> into today.
>>
>> Jack
>>
>>
>> On Tue, Nov 23, 2010 at 10:17 AM, Mike Tancsa  wrote:
>>
>>> On 11/23/2010 12:39 PM, Sean Bruno wrote:
>>>> On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote:
>>>>> It looks like I'm unfortunate enough to have to deploy on a machine
>>>>> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board,
>> which
>>>> i...@pci0

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 12/24/2010 5:44 PM, Jan Koum wrote:
> hi Ivan and Mike,
> 
> wanted to follow up and see if you found a solid long-term solution to this
> bug. we are still seeing this problem in our 8.2 environment with ASPM
> already disabled.  here is what we have:
> 
> 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon:
> 

Hi Jack,
Looks like this problem is not completely gone :(  I have seen it now 
on 2 different machines. On the RELENG_7, ASPM was enabled in the BIOS (INTEL  
DH55TC MB), so I have disabled that for now to see what happens. On the 
RELENG_8 machine, its been a LOT better since 7.1.8, but again it happened last 
night during a backup


dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.8
dev.em.1.%driver: em
dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART
dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 
subdevice=0x34ec class=0x02
dev.em.1.%parent: pci10
dev.em.1.nvm: -1
dev.em.1.debug: -1
dev.em.1.rx_int_delay: 0
dev.em.1.tx_int_delay: 66
dev.em.1.rx_abs_int_delay: 66
dev.em.1.tx_abs_int_delay: 66
dev.em.1.rx_processing_limit: 100
dev.em.1.flow_control: 3
dev.em.1.link_irq: 346
dev.em.1.mbuf_alloc_fail: 0
dev.em.1.cluster_alloc_fail: 0
dev.em.1.dropped: 0
dev.em.1.tx_dma_fail: 0
dev.em.1.rx_overruns: 0
dev.em.1.watchdog_timeouts: 0
dev.em.1.device_control: 1209008712
dev.em.1.rx_control: 67141634
dev.em.1.fc_high_water: 18432
dev.em.1.fc_low_water: 16932
dev.em.1.queue0.txd_head: 231
dev.em.1.queue0.txd_tail: 231
dev.em.1.queue0.tx_irq: 828804317
dev.em.1.queue0.no_desc_avail: 0
dev.em.1.queue0.rxd_head: 692
dev.em.1.queue0.rxd_tail: 691
dev.em.1.queue0.rx_irq: 1035962009
dev.em.1.mac_stats.excess_coll: 0
dev.em.1.mac_stats.single_coll: 0
dev.em.1.mac_stats.multiple_coll: 0
dev.em.1.mac_stats.late_coll: 0
dev.em.1.mac_stats.collision_count: 0
dev.em.1.mac_stats.symbol_errors: 0
dev.em.1.mac_stats.sequence_errors: 0
dev.em.1.mac_stats.defer_count: 0
dev.em.1.mac_stats.missed_packets: 395
dev.em.1.mac_stats.recv_no_buff: 22
dev.em.1.mac_stats.recv_undersize: 0
dev.em.1.mac_stats.recv_fragmented: 0
dev.em.1.mac_stats.recv_oversize: 0
dev.em.1.mac_stats.recv_jabber: 0
dev.em.1.mac_stats.recv_errs: 0
dev.em.1.mac_stats.crc_errs: 0
dev.em.1.mac_stats.alignment_errs: 0
dev.em.1.mac_stats.coll_ext_errs: 0
dev.em.1.mac_stats.xon_recvd: 0
dev.em.1.mac_stats.xon_txd: 0
dev.em.1.mac_stats.xoff_recvd: 0
dev.em.1.mac_stats.xoff_txd: 0
dev.em.1.mac_stats.total_pkts_recvd: 2374779279
dev.em.1.mac_stats.good_pkts_recvd: 2374778884
dev.em.1.mac_stats.bcast_pkts_recvd: 91866
dev.em.1.mac_stats.mcast_pkts_recvd: 14709
dev.em.1.mac_stats.rx_frames_64: 3694217
dev.em.1.mac_stats.rx_frames_65_127: 42644392
dev.em.1.mac_stats.rx_frames_128_255: 52724116
dev.em.1.mac_stats.rx_frames_256_511: 768263
dev.em.1.mac_stats.rx_frames_512_1023: 28549934
dev.em.1.mac_stats.rx_frames_1024_1522: 2246397962
dev.em.1.mac_stats.good_octets_recvd: 3420561094673
dev.em.1.mac_stats.good_octets_txd: 130129757787
dev.em.1.mac_stats.total_pkts_txd: 1553568635
dev.em.1.mac_stats.good_pkts_txd: 1553568635
dev.em.1.mac_stats.bcast_pkts_txd: 13131
dev.em.1.mac_stats.mcast_pkts_txd: 9
dev.em.1.mac_stats.tx_frames_64: 564243380
dev.em.1.mac_stats.tx_frames_65_127: 864123029
dev.em.1.mac_stats.tx_frames_128_255: 119250324
dev.em.1.mac_stats.tx_frames_256_511: 240369
dev.em.1.mac_stats.tx_frames_512_1023: 554247
dev.em.1.mac_stats.tx_frames_1024_1522: 5157286
dev.em.1.mac_stats.tso_txd: 1216433
dev.em.1.mac_stats.tso_ctx_fail: 0
dev.em.1.interrupts.asserts: 51
dev.em.1.interrupts.rx_pkt_timer: 0
dev.em.1.interrupts.rx_abs_timer: 0
dev.em.1.interrupts.tx_pkt_timer: 0
dev.em.1.interrupts.tx_abs_timer: 0
dev.em.1.interrupts.tx_queue_empty: 0
dev.em.1.interrupts.tx_queue_min_thresh: 0
dev.em.1.interrupts.rx_desc_min_thresh: 0
dev.em.1.interrupts.rx_overrun: 0


em1: flags=8843 metric 0 mtu 1500

options=219b
ether 00:15:17:ed:68:a4
inet xx.yy.13.254 netmask 0xff00 broadcast zz.yy.13.255
inet6 fe80::215:17ff:feed:68a4%em1 prefixlen 64 scopeid 0x3 
inet xx.zz.1.1 netmask 0xff00 broadcast xx.zz.1.255
inet6 2607:f3e0:xx prefixlen 64 
nd6 options=3
media: Ethernet autoselect (1000baseT )
status: active

e...@pci0:10:0:0:class=0x02 card=0x34ec8086 chip=0x10d38086 
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
class  = network
subclass   = ethernet
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit 
cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 001517ed68a4

The MB is an INTEL  S3420GPX

---Mike



___
freebsd-hardware@freebsd.org mailing list
htt

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 1/21/2011 4:21 AM, Jan Koum wrote:
> 
> 
> Dear Mike and Jack,
> 
> sadly the problem is not gone for us either.  here is what we know so far:

Same here. There was a new BIOS from Intel for our motherboard (INTEL
S3420GPX), but had another hang last night. Debug below.  I will try the
newer driver Monday.

One other thing I noticed is that when the nic is in its hung state, the
WOL option is gone ?

e.g

em1: flags=8843 metric 0 mtu 1500
options=19b
ether 00:15:17:ed:68:a4

vs


em1: flags=8843 metric 0 mtu 1500

options=219b
ether 00:15:17:ed:68:a4



Interface is RUNNING and INACTIVE
em1: hw tdh = 75, hw tdt = 75
em1: hw rdh = 771, hw rdt = 771
em1: Tx Queue Status = 0
em1: TX descriptors avail = 1024
em1: Tx Descriptors avail failure = 0
em1: RX discarded packets = 0
em1: RX Next to Check = 771
em1: RX Next to Refresh = 772
em1: link state changed to DOWN
em1: link state changed to UP

dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.8
dev.em.1.%driver: em
dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART
dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086
subdevice=0x34ec class=0x02
dev.em.1.%parent: pci10
dev.em.1.nvm: -1
dev.em.1.debug: -1
dev.em.1.rx_int_delay: 0
dev.em.1.tx_int_delay: 66
dev.em.1.rx_abs_int_delay: 66
dev.em.1.tx_abs_int_delay: 66
dev.em.1.rx_processing_limit: 100
dev.em.1.flow_control: 3
dev.em.1.link_irq: 563
dev.em.1.mbuf_alloc_fail: 0
dev.em.1.cluster_alloc_fail: 0
dev.em.1.dropped: 0
dev.em.1.tx_dma_fail: 0
dev.em.1.rx_overruns: 0
dev.em.1.watchdog_timeouts: 0
dev.em.1.device_control: 1209008712
dev.em.1.rx_control: 67141634
dev.em.1.fc_high_water: 18432
dev.em.1.fc_low_water: 16932
dev.em.1.queue0.txd_head: 68
dev.em.1.queue0.txd_tail: 68
dev.em.1.queue0.tx_irq: 6378625
dev.em.1.queue0.no_desc_avail: 0
dev.em.1.queue0.rxd_head: 771
dev.em.1.queue0.rxd_tail: 771
dev.em.1.queue0.rx_irq: 6987244
dev.em.1.mac_stats.excess_coll: 0
dev.em.1.mac_stats.single_coll: 0
dev.em.1.mac_stats.multiple_coll: 0
dev.em.1.mac_stats.late_coll: 0
dev.em.1.mac_stats.collision_count: 0
dev.em.1.mac_stats.symbol_errors: 0
dev.em.1.mac_stats.sequence_errors: 0
dev.em.1.mac_stats.defer_count: 0
dev.em.1.mac_stats.missed_packets: 625
dev.em.1.mac_stats.recv_no_buff: 16
dev.em.1.mac_stats.recv_undersize: 0
dev.em.1.mac_stats.recv_fragmented: 0
dev.em.1.mac_stats.recv_oversize: 0
dev.em.1.mac_stats.recv_jabber: 0
dev.em.1.mac_stats.recv_errs: 0
dev.em.1.mac_stats.crc_errs: 0
dev.em.1.mac_stats.alignment_errs: 0
dev.em.1.mac_stats.coll_ext_errs: 0
dev.em.1.mac_stats.xon_recvd: 0
dev.em.1.mac_stats.xon_txd: 0
dev.em.1.mac_stats.xoff_recvd: 0
dev.em.1.mac_stats.xoff_txd: 0
dev.em.1.mac_stats.total_pkts_recvd: 28035460
dev.em.1.mac_stats.good_pkts_recvd: 28034835
dev.em.1.mac_stats.bcast_pkts_recvd: 2649
dev.em.1.mac_stats.mcast_pkts_recvd: 892
dev.em.1.mac_stats.rx_frames_64: 1443
dev.em.1.mac_stats.rx_frames_65_127: 398677
dev.em.1.mac_stats.rx_frames_128_255: 154336
dev.em.1.mac_stats.rx_frames_256_511: 473952
dev.em.1.mac_stats.rx_frames_512_1023: 199839
dev.em.1.mac_stats.rx_frames_1024_1522: 26806588
dev.em.1.mac_stats.good_octets_recvd: 40546236160
dev.em.1.mac_stats.good_octets_txd: 1625971127
dev.em.1.mac_stats.total_pkts_txd: 18447279
dev.em.1.mac_stats.good_pkts_txd: 18447279
dev.em.1.mac_stats.bcast_pkts_txd: 194
dev.em.1.mac_stats.mcast_pkts_txd: 6
dev.em.1.mac_stats.tx_frames_64: 352
dev.em.1.mac_stats.tx_frames_65_127: 16626040
dev.em.1.mac_stats.tx_frames_128_255: 1790624
dev.em.1.mac_stats.tx_frames_256_511: 876
dev.em.1.mac_stats.tx_frames_512_1023: 902
dev.em.1.mac_stats.tx_frames_1024_1522: 28485
dev.em.1.mac_stats.tso_txd: 2542
dev.em.1.mac_stats.tso_ctx_fail: 0
dev.em.1.interrupts.asserts: 222
dev.em.1.interrupts.rx_pkt_timer: 0
dev.em.1.interrupts.rx_abs_timer: 0
dev.em.1.interrupts.tx_pkt_timer: 0
dev.em.1.interrupts.tx_abs_timer: 0
dev.em.1.interrupts.tx_queue_empty: 0
dev.em.1.interrupts.tx_queue_min_thresh: 0
dev.em.1.interrupts.rx_desc_min_thresh: 0
dev.em.1.interrupts.rx_overrun: 0

___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 1/23/2011 10:21 AM, Mike Tancsa wrote:
> On 1/21/2011 4:21 AM, Jan Koum wrote:
> One other thing I noticed is that when the nic is in its hung state, the
> WOL option is gone ?
> 
> e.g
> 
> em1: flags=8843 metric 0 mtu 1500
> options=19b
> ether 00:15:17:ed:68:a4
> 
> vs
> 
> 
> em1: flags=8843 metric 0 mtu 1500
> 
> options=219b
> ether 00:15:17:ed:68:a4


Another hang last night :(

Whats really strange is that the WOL_MAGIC and TSO4 got turned back on
somehow ? I had explicitly turned it off, but when the NIC was in its
bad state

em1: flags=8843 metric 0 mtu 1500
options=2198

... its back on along with TSO?  Not sure if its coincidence or a side
effect or what.  For now, I have had to re-purpose this nic to something
else.

debug info shows

Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and INACTIVE
Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = 625
Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = 903
Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0
Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = 1024
Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail failure = 0
Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = 0
Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903
Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = 904
Jan 28 00:25:27 backup3 kernel: em1: link state changed to DOWN
Jan 28 00:25:30 backup3 kernel: em1: link state changed to UP


---Mike
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 2/1/2011 3:05 PM, Jack Vogel wrote:
> At this point I'm open to any ideas, this sounds like a good one Sean,
> thanks.
> Mike, you want to test this ?

Sure, I am feeling lucky ;-)  If someone generates the appropriate em
diffs for me, I will apply on the box that sees this issue the most.

---Mike

> 
> Jack
> 
> 
> On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno  wrote:
> 
>> On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote:
>>> On 1/23/2011 10:21 AM, Mike Tancsa wrote:
>>>> On 1/21/2011 4:21 AM, Jan Koum wrote:
>>>> One other thing I noticed is that when the nic is in its hung state,
>> the
>>>> WOL option is gone ?
>>>>
>>>> e.g
>>>>
>>>> em1: flags=8843 metric 0 mtu
>> 1500
>>>>
>> options=19b
>>>> ether 00:15:17:ed:68:a4
>>>>
>>>> vs
>>>>
>>>>
>>>> em1: flags=8843 metric 0 mtu
>> 1500
>>>>
>>>>
>> options=219b
>>>> ether 00:15:17:ed:68:a4
>>>
>>>
>>> Another hang last night :(
>>>
>>> Whats really strange is that the WOL_MAGIC and TSO4 got turned back on
>>> somehow ? I had explicitly turned it off, but when the NIC was in its
>>> bad state
>>>
>>> em1: flags=8843 metric 0 mtu 1500
>>> options=2198
>>>
>>> ... its back on along with TSO?  Not sure if its coincidence or a side
>>> effect or what.  For now, I have had to re-purpose this nic to something
>>> else.
>>>
>>> debug info shows
>>>
>>> Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and INACTIVE
>>> Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = 625
>>> Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = 903
>>> Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0
>>> Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = 1024
>>> Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail failure = 0
>>> Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = 0
>>> Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903
>>> Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = 904
>>> Jan 28 00:25:27 backup3 kernel: em1: link state changed to DOWN
>>> Jan 28 00:25:30 backup3 kernel: em1: link state changed to UP
>>>
>>>
>>>   ---Mike
>>
>>
>> I'm trying to get some more testing done regarding my suggestions around
>> the OACTIVE assertions in the driver.  More or less, it looks like
>> intense periods of activity can push the driver into the OACTIVE hold
>> off state and the logic isn't quite right in igb(4) or em(4) to handle
>> it.
>>
>> I suspect that something like this modification to igb(4) may be
>> required for em(4).
>>
>> Comments?
>>
>> Sean
>>
> 


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 2/1/2011 3:55 PM, Jack Vogel wrote:
> Mike, just to remind me, are you running these 82574 adapters with MSIX ?

Yes. Board is an Intel MB (S3420GPX). 8G RAM, AMD64. Kernel from a few
days ago


0(backup3)# vmstat -i | grep em1
irq257: em1:rx 0   113712958159
irq258: em1:tx 096623551135
irq259: em1:link 488  0
0(backup3)# grep ^em1 /var/run/dmesg.boot
em1:  port 0x2000-0x201f mem
0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci10
em1: Using MSIX interrupts with 3 vectors
em1: [ITHREAD]
em1: [ITHREAD]
em1: [ITHREAD]
em1: Ethernet address: 00:15:17:ed:68:a4
em1: link state changed to UP
0(backup3)#
em1@pci0:10:0:0:class=0x02 card=0x34ec8086 chip=0x10d38086
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
class  = network
subclass   = ethernet
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit
cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 001517ed68a4

---Mike
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 2/1/2011 4:17 PM, Jack Vogel wrote:
> But you aren't defining EM_MULTIQUEUE are you? (its not on by default)

Nope. Everything is the default wrt to the em driver. Nothing odd in
loader.conf

0(backup3)% grep -v ^# /boot/loader.conf
ahci_load="YES"
siis_load="YES"
if_em_load="YES"
coretemp_load="YES"
comconsole_speed="115200"# Set the current serial console speed
console="comconsole,vidconsole"   # A comma separated list of
console(s)
aesni_load="YES"
cryptodev_load="YES"


---Mike
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 2/1/2011 4:43 PM, Jack Vogel wrote:
> To those who are going to test, here is the if_em.c, based on head, with my
> changes, I have to leave for the afternoon, and have not had a chance to
> build
> this, but it should work. I will check back in the later evening.
> 
> Any blatant problems Sean, feel free to fix them :)

My boxes are RELENG_7 and RELENG_8. Apart from manually hand editing
those pesky sysctl changes out, is there a better way to generate
RELENG_8 and 7 diffs ?

---Mike
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 2/1/2011 7:56 PM, Chris Peiffer wrote:
> 
> Did this get sent to the list? I didn't get this quoted message and I
> can't find it in the archives. 
> 
> If someone could post the current revision of if_em.c that would be
> great; we are also very eager to test. 
> 

Strange, it seems to be eaten/held by mailman ?  I posted the file to
http://www.tancsa.com/if_em.c


% md5 if_em.c
MD5 (if_em.c) = 0f2d48c7734496c2262f468cd1ab9117

% ident if_em.c
if_em.c:
 $FreeBSD: src/sys/dev/e1000/if_em.c,v 1.68 2011/01/19 18:20:11 jfv
Exp $

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 2/1/2011 8:44 PM, Mike Tancsa wrote:
> 
> % md5 if_em.c
> MD5 (if_em.c) = 0f2d48c7734496c2262f468cd1ab9117

Sorry, thats

MD5 (if_em.c) = 9cede4ab0d833e0f97172ed715e2b4e3

---Mike

-- 
-------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

,
+   SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq",
+   CTLFLAG_RD, &adapter->link_irq,0,
"Link MSIX IRQ Handled");
SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "mbuf_alloc_fail",
 CTLFLAG_RD, &adapter->mbuf_alloc_failed,
@@ -5108,11 +5102,13 @@
queue_list = SYSCTL_CHILDREN(queue_node);

SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_head",
-   CTLFLAG_RD, adapter, E1000_TDH(txr->me),
+   CTLFLAG_RD, adapter,
+   E1000_TDH(txr->me),
em_sysctl_reg_handler, "IU",
"Transmit Descriptor Head");
SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_tail",
-   CTLFLAG_RD, adapter, E1000_TDT(txr->me),
+   CTLFLAG_RD, adapter,
+   E1000_TDT(txr->me),
em_sysctl_reg_handler, "IU",
"Transmit Descriptor Tail");
SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "tx_irq",
@@ -5123,11 +5119,13 @@
"Queue No Descriptor Available");

SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_head",
-   CTLFLAG_RD, adapter, E1000_RDH(rxr->me),
+   CTLFLAG_RD, adapter,
+   E1000_RDH(rxr->me),
em_sysctl_reg_handler, "IU",
"Receive Descriptor Head");
SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_tail",
-   CTLFLAG_RD, adapter, E1000_RDT(rxr->me),
+   CTLFLAG_RD, adapter,
+   E1000_RDT(rxr->me),
em_sysctl_reg_handler, "IU",
"Receive Descriptor Tail");
SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "rx_irq",
@@ -5141,19 +5139,19 @@
CTLFLAG_RD, NULL, "Statistics");
stat_list = SYSCTL_CHILDREN(stat_node);

-   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll",
+   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll",
CTLFLAG_RD, &stats->ecol,
"Excessive collisions");
-   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll",
+   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll",
CTLFLAG_RD, &stats->scc,
"Single collisions");
-   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll",
+   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll",
CTLFLAG_RD, &stats->mcc,
"Multiple collisions");
-   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll",
+   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll",
CTLFLAG_RD, &stats->latecol,
"Late collisions");
-   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count",
+   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count",
CTLFLAG_RD, &stats->colc,
"Collision Count");
SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "symbol_errors",
@@ -5240,12 +5238,12 @@
SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "rx_frames_1024_1522",
CTLFLAG_RD, &adapter->stats.prc1522,
"1023-1522 byte frames received");
-   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd",
+   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd",
CTLFLAG_RD, &adapter->stats.gorc,
"Good Octets Received");

/* Packet Transmission Stats */
-   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd",
+   SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd",
CTLFLAG_RD, &adapter->stats.gotc,
"Good Octets Transmitted");
SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "total_pkts_txd",

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 2/2/2011 12:37 PM, Jack Vogel wrote:
> So has everyone that wanted to get something  testing been able to do so?

I have been testing in the back and will deploy to my production box
this afternoon.  As I am not able to reproduce it easily, it will be a
bit before I can say the issue is gone.  Jan however, was able to
trigger it with greater ease ?

---Mike

> 
> Jack
> 
> 
> On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa  wrote:
> 
>> On 2/1/2011 5:03 PM, Sean Bruno wrote:
>>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
>>>> To those who are going to test, here is the if_em.c, based on head,
>>>> with my
>>>> changes, I have to leave for the afternoon, and have not had a chance
>>>> to build
>>>> this, but it should work. I will check back in the later evening.
>>>>
>>>> Any blatant problems Sean, feel free to fix them :)
>>>>
>>>> Jack
>>>>
>>>
>>>
>>> I suspect that line 1490 should be:
>>>   if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
>>>
>>
>>
>> I have hacked up a RELENG_8 version which I think is correct including
>> the above change
>>
>> http://www.tancsa.com/if_em-8.c
>>
>>
>>
>> --- if_em.c.orig2011-02-01 21:47:14.0 -0500
>> +++ if_em.c 2011-02-01 21:47:19.0 -0500
>> @@ -30,7 +30,7 @@
>>   POSSIBILITY OF SUCH DAMAGE.
>>
>>
>>  
>> **/
>> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
>> jfv Exp $*/
>> +/*$FreeBSD$*/
>>
>>  #ifdef HAVE_KERNEL_OPTION_HEADERS
>>  #include "opt_device_polling.h"
>> @@ -93,7 +93,7 @@
>>  /*
>>  *  Driver version:
>>  */
>> -char em_driver_version[] = "7.1.9";
>> +char em_driver_version[] = "7.1.9-test";
>>
>>  /*
>>  *  PCI Device ID Table
>> @@ -927,11 +927,10 @@
>>if (!adapter->link_active)
>>return;
>>
>> -/* Call cleanup if number of TX descriptors low */
>> -   if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
>> -   em_txeof(txr);
>> -
>>while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
>> +   /* First cleanup if TX descriptors low */
>> +   if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
>> +   em_txeof(txr);
>>if (txr->tx_avail < EM_MAX_SCATTER) {
>>ifp->if_drv_flags |= IFF_DRV_OACTIVE;
>>break;
>> @@ -1411,8 +1410,7 @@
>>if (!drbr_empty(ifp, txr->br))
>>em_mq_start_locked(ifp, txr, NULL);
>>  #else
>> -   if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
>> -   em_start_locked(ifp, txr);
>> +   em_start_locked(ifp, txr);
>>  #endif
>>EM_TX_UNLOCK(txr);
>>
>> @@ -1475,11 +1473,10 @@
>>struct ifnet*ifp = adapter->ifp;
>>struct tx_ring  *txr = adapter->tx_rings;
>>struct rx_ring  *rxr = adapter->rx_rings;
>> -   boolmore;
>> -
>>
>>if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
>> -   more = em_rxeof(rxr, adapter->rx_process_limit, NULL);
>> +   boolmore_rx;
>> +   more_rx = em_rxeof(rxr, adapter->rx_process_limit, NULL);
>>
>>EM_TX_LOCK(txr);
>>em_txeof(txr);
>> @@ -1487,12 +1484,10 @@
>>if (!drbr_empty(ifp, txr->br))
>>em_mq_start_locked(ifp, txr, NULL);
>>  #else
>> -   if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
>> -   em_start_locked(ifp, txr);
>> +   em_start_locked(ifp, txr);
>>  #endif
>> -   em_txeof(txr);
>>EM_TX_UNLOCK(txr);
>> -   if (more) {
>> +   if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
>>taskqueue_enqueue(adapter->tq, &adapter->que_task);
>>return;
>>}
>> @@ -1604,7 +1599,6 @@
>>if (!IFQ_DRV_IS_EMPTY(&ifp->if_sn

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 2/4/2011 1:09 PM, Sean Bruno wrote:
> Any more data on this problem or do we have to wait a while?


On my RELENG_8 production box, so far so good.  It usually would hang on
weekend runs, so tomorrow would be a good sign, but not a proof that its
fixed as it has on occasion survived a few weeks in a row.  I am running
the version Jack posted with the one change Sean suggested and is at

http://www.tancsa.com/if_em-8.c

I am also using all default options for the two onboard nics

em0: flags=8843 metric 0 mtu 1500

options=219b

em1: flags=8843 metric 0 mtu 1500

options=219b

em0:  port
0x4040-0x405f mem 0xb450-0xb451,0xb4525000-0xb4525fff irq 16 at
device 25.0 on pci0
em0: Using an MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:15:17:ed:68:a5
em1:  port
0x2000-0x201f mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at
device 0.0 on pci10
em1: Using MSIX interrupts with 3 vectors
em1: [ITHREAD]
em1: [ITHREAD]
em1: [ITHREAD]
em1: Ethernet address: 00:15:17:ed:68:a4
em0: link state changed to UP
em1: link state changed to UP



---Mike
-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

So far so good.  I would often get a hang on the level zero dumps to my
backup server Sunday AM, and it made it through!  So a good sign, but
not a definitive sign.

I have a PCIe em card that has this chipset as well and was showing the
same sort of problem in a customer's RELENG_7 box.  I will see if I can
get the customer to try the card in their box with the patch for
RELENG_7 as it would show this issue at least once a day until I pulled
the card for an older version

---Mike


On 2/4/2011 1:12 PM, Jack Vogel wrote:
> Was curious too, but being more patient than you :)
> 
> Jack
> 
> 
> On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno  wrote:
> 
>> Any more data on this problem or do we have to wait a while?
>>
>> Sean
>>
>>
>> On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote:
>>> On 2/2/2011 12:37 PM, Jack Vogel wrote:
>>>> So has everyone that wanted to get something  testing been able to do
>> so?
>>>
>>> I have been testing in the back and will deploy to my production box
>>> this afternoon.  As I am not able to reproduce it easily, it will be a
>>> bit before I can say the issue is gone.  Jan however, was able to
>>> trigger it with greater ease ?
>>>
>>> ---Mike
>>>
>>>>
>>>> Jack
>>>>
>>>>
>>>> On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa  wrote:
>>>>
>>>>> On 2/1/2011 5:03 PM, Sean Bruno wrote:
>>>>>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
>>>>>>> To those who are going to test, here is the if_em.c, based on head,
>>>>>>> with my
>>>>>>> changes, I have to leave for the afternoon, and have not had a
>> chance
>>>>>>> to build
>>>>>>> this, but it should work. I will check back in the later evening.
>>>>>>>
>>>>>>> Any blatant problems Sean, feel free to fix them :)
>>>>>>>
>>>>>>> Jack
>>>>>>>
>>>>>>
>>>>>>
>>>>>> I suspect that line 1490 should be:
>>>>>>   if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
>>>>>>
>>>>>
>>>>>
>>>>> I have hacked up a RELENG_8 version which I think is correct including
>>>>> the above change
>>>>>
>>>>> http://www.tancsa.com/if_em-8.c
>>>>>
>>>>>
>>>>>
>>>>> --- if_em.c.orig2011-02-01 21:47:14.0 -0500
>>>>> +++ if_em.c 2011-02-01 21:47:19.0 -0500
>>>>> @@ -30,7 +30,7 @@
>>>>>   POSSIBILITY OF SUCH DAMAGE.
>>>>>
>>>>>
>>>>>
>>  
>> **/
>>>>> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
>>>>> jfv Exp $*/
>>>>> +/*$FreeBSD$*/
>>>>>
>>>>>  #ifdef HAVE_KERNEL_OPTION_HEADERS
>>>>>  #include "opt_device_polling.h"
>>>>> @@ -93,7 +93,7 @@
>>>>>
>>  /*
>>>>>  *  Driver version:
>>>>>
>>  */
>>>>> -char em_driver_version[] = "7.1.9";
>>>>> +char em_driver_version[] = "7.1.9-test";
>>>>>
>>>>>
>>  /*
>>>>>  *  PCI Device ID Table
>>>>> @@ -927,11 +927,10 @@
>>>>>if (!adapter->link_active)
>>>>>return;
>>>>>
>>>>> -/* Call cleanup if number of TX descriptors low */
>>>>> -   if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
>>>>> -   em_txeof(txr);
>>>>> -
>>>>>while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) {
>>>>> +   /* First cleanup if TX descriptors low */
>>>>> +   if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
>>>>> +   em_txeof(txr);
>>>>>if (txr->tx_avail < EM_MAX_SCATTER) {
>>>>>ifp->if_drv_flags |= IFF_DRV_OACTIVE;
>>>&g

Re: modem support MT9234ZPX-PCIE-NV

[Mike Tancsa]

On 5/26/2011 4:12 PM, John Baldwin wrote:
> 
> Hmm, can you get 'pciconf -lb' output?
> 
> Hmm, wow, I wonder how uart(4) works at all.  It tries to reuse it's softc
> structure in uart_bus_attach() that was setup in uart_bus_probe().  Since it
> doesn't return 0 from its probe routine, that is forbidden.   I guess it
> accidentally works because of the hack where we call DEVICE_PROBE() again
> to make sure the device description is correct.


I think this is a similar card.  Had it laying about for a while and
popped it in.  cu -l to it, attaches, but I am not able to interact with it.

none3@pci0:5:0:0:   class=0x070002 card=0x20282205 chip=0x015213a8
rev=0x02 hdr=0x00
vendor = 'Exar Corp.'
device = 'XR17C/D152 Dual PCI UART'
class  = simple comms
subclass   = UART
bar   [10] = type Memory, range 32, base 0xe895, size 1024, enabled


NetBSD supposedly has support for this card

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/pucdata.c.diff?r1=1.43&r2=1.44


---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: modem support MT9234ZPX-PCIE-NV

[Mike Tancsa]

On 5/27/2011 8:05 AM, John Baldwin wrote:
> 
> Oh, hmm, looks like the clock has an unusual multiplier.  Does it work if you
> use 'cu -l -s 1200' to talk at 9600 for example?  (In general use speed / 8
> as the speed to '-s'.)
> 
> Also, is your card a modem or a dual-port card?

Its a 3G modem.

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: modem support MT9234ZPX-PCIE-NV

[Mike Tancsa]

On 5/27/2011 8:05 AM, John Baldwin wrote:

> 
> Oh, hmm, looks like the clock has an unusual multiplier.  Does it work if you
> use 'cu -l -s 1200' to talk at 9600 for example?  (In general use speed / 8
> as the speed to '-s'.)
> 
> Also, is your card a modem or a dual-port card?

If I add in the device IDs, I am not able to talk to it at any speed.
However, the port that is exposed, might just not be echoing back chars
and the second port which is not showing up, might be the "control port" ?

uart2@pci0:5:0:0:   class=0x070002 card=0x20282205 chip=0x015213a8
rev=0x02 hdr=0x00
vendor = 'Exar Corp.'
device = 'XR17C/D152 Dual PCI UART'
class      = simple comms
subclass   = UART




-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: modem support MT9234ZPX-PCIE-NV

[Mike Tancsa]

On 5/27/2011 12:00 PM, John Baldwin wrote:
>>
>> uart2@pci0:5:0:0:   class=0x070002 card=0x20282205 chip=0x015213a8
>> rev=0x02 hdr=0x00
>> vendor = 'Exar Corp.'
>> device = 'XR17C/D152 Dual PCI UART'
>> class  = simple comms
>> subclass   = UART
> 
> Possibly.  Did you try adding it via puc instead?

Yes, same result. But I am not sure what values to plugin for some of
the options.

I tried this is uart

1(ich10)# diff -u uart_bus_pci.c.orig uart_bus_pci.c
--- uart_bus_pci.c.orig 2011-05-24 17:10:21.0 -0400
+++ uart_bus_pci.c  2011-05-27 10:49:05.0 -0400
@@ -110,6 +110,8 @@
 { 0x1415, 0x950b, 0x, 0, "Oxford Semiconductor OXCB950 Cardbus
16950 UART",
0x10, 16384000 },
 { 0x151f, 0x, 0x, 0, "TOPIC Semiconductor TP560 56k modem", 0x10 },
+{ 0x13a8, 0x0152, 0x2205, 0x2028, "MultiTech MultiModem ZPX", 0x10,
+   8 * DEFAULT_RCLK },
 { 0x9710, 0x9835, 0x1000, 1, "NetMos NM9835 Serial Port", 0x10 },
 { 0x9710, 0x9865, 0xa000, 0x1000, "NetMos NM9865 Serial Port", 0x10 },
 { 0x9710, 0x9901, 0xa000, 0x1000,
1(ich10)#

Then I removed the entry from uart and added the following for pucdata.c


{   0x13a8, 0x0152, 0x, 0,
"Exar Multitech",
DEFAULT_RCLK * 8,
    PUC_PORT_2S, 0x10, 0, -1,
},

But it does not seem to want to attach ?

---Mike
-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: modem support MT9234ZPX-PCIE-NV

[Mike Tancsa]

On 5/27/2011 3:33 PM, John Baldwin wrote:
> 
> Actually, can you just try this:
> 
> Index: pucdata.c

Hi,
Patch applies, but it doesnt compile on RELENG_8

 patch < p
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|Index: pucdata.c
|===
|--- pucdata.c  (revision 222364)
|+++ pucdata.c  (working copy)
--
Patching file pucdata.c using Plan A...
Hunk #1 succeeded at 48.
Hunk #2 succeeded at 546 (offset -1 lines).
Hunk #3 succeeded at 949 (offset -75 lines).
done


===> puc (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/ipsec/opt_global.h -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/ipsec
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -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/puc/../../dev/puc/pucdata.c
cc1: warnings being treated as errors
/usr/src/sys/modules/puc/../../dev/puc/pucdata.c:552: warning: overflow
in implicit constant conversion
/usr/src/sys/modules/puc/../../dev/puc/pucdata.c:558: warning: overflow
in implicit constant conversion
/usr/src/sys/modules/puc/../../dev/puc/pucdata.c:564: warning: overflow
in implicit constant conversion
*** Error code 1

Stop in /usr/src/sys/modules/puc.
*** Error code 1

Stop in /usr/src/sys/modules.
*** Error code 1

Stop in /usr/obj/usr/src/sys/ipsec.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.



-- 
-------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: modem support MT9234ZPX-PCIE-NV

[Mike Tancsa]

On 5/27/2011 4:22 PM, John Baldwin wrote:
> On Friday, May 27, 2011 3:38:04 pm Mike Tancsa wrote:
>> On 5/27/2011 3:33 PM, John Baldwin wrote:
>>>
>>> Actually, can you just try this:
>>>
>>> Index: pucdata.c
>>
>> Hi,
>>  Patch applies, but it doesnt compile on RELENG_8
> 
> Ugh, looks like the offset can't handle 0x200, try this instead:
> 
> Index: pucdata.c
> ===


Thanks! that applies cleanly and I see both ports now.  However, I still
cannot interact with the modem.  Let me fire up LINUX

0(ich10)# patch < p
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|Index: pucdata.c
|===
|--- pucdata.c  (revision 222364)
|+++ pucdata.c  (working copy)
--
Patching file pucdata.c using Plan A...
Hunk #1 succeeded at 48.
Hunk #2 succeeded at 547 (offset -1 lines).
Hunk #3 succeeded at 953 (offset -75 lines).
done
0(ich10)#


puc0:  mem 0xe895-0xe89503ff irq 21 at device 0.0
on pci5
puc0: [FILTER]
uart2: <16750 or compatible> on puc0
uart2: [FILTER]
uart3: <16750 or compatible> on puc0
uart3: [FILTER]




-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: em driver, 82574L chip, and possibly ASPM

[Mike Tancsa]

On 7/12/2011 3:03 PM, Hooman Fazaeli wrote:
> 
> I have similar problems on a couple of 7.3 boxes with latest driver form
> -CURRENT.
> I just wanted to know if your 7 boxes work fine so I look for cause else
> where.

Yes, all has been working quite well for me to date.


em1@pci0:11:0:0:class=0x02 card=0x34ec8086 chip=0x10d38086
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
class  = network
subclass   = ethernet
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit
cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 001517ed68a4


em1:  port 0x2000-0x201f mem
0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci11
em1: Using MSIX interrupts with 3 vectors
em1: [ITHREAD]
em1: [ITHREAD]
em1: [ITHREAD]


    ---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

pcie realtek issue (re driver)

[Mike Tancsa]

My recent batch of realtek nics seems to have a version that does not
work with RELENG_8 or RELENG_9. Anyone know what the issue might be ?


re0:  at device
0.0 on pci4
re0: Using 1 MSI-X message
re0: turning off MSI enable bit.
re0: ASPM disabled
re0: Chip rev. 0x7c80
re0: MAC rev. 0x0040
re0: reset never completed!
re0: PHY write failed
re0: PHY write failed
re0: attaching PHYs failed
device_attach: re0 attach returned 6


none2@pci0:4:0:0:   class=0x02 card=0x816810ec chip=0x816810ec
rev=0x03 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class  = network
subclass   = ethernet
bar   [18] = type I/O Port, range 32, base 0xfffc, size  4, disabled
bar   [20] = type I/O Port, range 32, base 0xfffc, size 16384,
disabled
cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 15 type 15 IRQ 62 max data 16384(16384)
link x63(x63)




-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: pcie realtek issue (re driver)

[Mike Tancsa]

On 5/29/2012 9:01 PM, YongHyeon PYUN wrote:
> On Fri, May 25, 2012 at 10:14:27PM -0400, Mike Tancsa wrote:
>> My recent batch of realtek nics seems to have a version that does not
>> work with RELENG_8 or RELENG_9. Anyone know what the issue might be ?
>>
>>
>> re0:  at device
>> 0.0 on pci4
>> re0: Using 1 MSI-X message
>> re0: turning off MSI enable bit.
>> re0: ASPM disabled
>> re0: Chip rev. 0x7c80
>  ^^
> 
> If memory serves me right there would be no known controller for
> revision 0x7c80.  Actually I wonder how re(4) can attach to
> this unknown device.
> Did you apply local patch?

Hi,
No, its a stock kernel.  If I add

hw.re.msix_disable=1
hw.re.msi_disable=1

it sort of comes up


  re0 pnpinfo vendor=0x10ec device=0x8168 subvendor=0x10ec
subdevice=0x8168 class=0x02 at slot=0 function=0
  miibus0
rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x2 at phyno=1

re0:  port
0xd000-0xd0ff mem 0xfe20-0xfe200fff,0xf000-0xf0003fff irq 18 at
device 0.0 on pci4
re0: Chip rev. 0x2800
re0: MAC rev. 0x
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master,
1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow,
1000baseT-FDX-flow-master, auto, auto-flow
re0: Ethernet address: 00:0a:cd:1c:ba:89

but doing ifconfig re0 up, does not work as dmesg shows

re0: reset never completed!
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed


re0@pci0:4:0:0: class=0x02 card=0x816810ec chip=0x816810ec rev=0x03
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class  = network
subclass   = ethernet
bar   [10] = type I/O Port, range 32, base 0xd000, size 256, disabled
bar   [18] = type Memory, range 64, base 0xfe20, size 4096, disabled
bar   [20] = type Prefetchable Memory, range 64, base 0xf000,
size 16384, disabled

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: pcie realtek issue (re driver)

[Mike Tancsa]

On 5/31/2012 10:57 AM, John Baldwin wrote:
>>
>> Right, but what if it is not(from the pciconf output)?
>> I'm pretty sure re(4) used RF_ACTIVE with bus_alloc_resource_any(9).
> 
> Hmm, is this pciconf output when the driver is attached?

Hi,
Here are some of the variations attached in a txt file.  Could this
just be a broken card ?  I will try and boot up another OS on the box
and see if it works.

---Mike







-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

GENERIC kernel, no loader tuneables with if_re loaded from /boot/loader.conf

none2@pci0:4:0:0:   class=0x02 card=0x10ec chip=0x816810ec rev=0x03 
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class  = network
subclass   = ethernet
bar   [10] = type I/O Port, range 32, base 0, size 256, disabled
bar   [18] = type Memory, range 64, base 0xdfa0, size 4096, disabled
bar   [20] = type Prefetchable Memory, range 64, base 0, size 16384, 
disabled
cap 01[40] = powerspec 7  supports D0 D1 D2 D3  current D3


pci4:  on pcib4
pci4: domain=0, physical bus=4
found-> vendor=0x10ec, dev=0x8168, revid=0x03
domain=0, bus=4, slot=0, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=255
map[10]: type I/O Port, range 32, base 0, size  8, port disabled
map[18]: type Memory, range 64, base 0, size 12, memory disabled
map[20]: type Prefetchable Memory, range 64, base 0, size 14, memory 
disabled
re0:  at device 0.0 on 
pci4
pcib0: allocated type 3 (0xdfa0-0xdfaf) for rid 20 of pcib4
pcib4: allocated initial memory window of 0xdfa0-0xdfaf
pcib4: allocated memory range (0xdfa0-0xdfa00fff) for rid 18 of re0
re0: Lazy allocation of 0x1000 bytes rid 0x18 type 3 at 0xdfa0
re0: MSI count : 0
re0: MSI-X count : 0
pcib4: matched entry for 4.0.INTA
pcib4: slot 0 INTA hardwired to IRQ 18
re0: turning off MSI enable bit.
re0: ASPM disabled
re0: Chip rev. 0x7c80
re0: MAC rev. 0x0040
re0: reset never completed!
re0: PHY write failed
re0: PHY write failed
re0: attaching PHYs failed
device_attach: re0 attach returned 6



with 
if_re_load="YES"
hw.re.msi_disable=1

pci4:  on pcib4
pci4: domain=0, physical bus=4
found-> vendor=0x10ec, dev=0x8168, revid=0x03
domain=0, bus=4, slot=0, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=255
powerspec 3  supports D0 D1 D2 D3  current D0
MSI supports 1 message, 64 bit
MSI-X supports 4 messages in map 0x20
map[10]: type I/O Port, range 32, base 0, size  8, enabled
map[18]: type Memory, range 64, base 0, size 12, enabled
map[20]: type Prefetchable Memory, range 64, base 0, size 14, enabled
re0:  at device 0.0 on 
pci4
pcib4: allocated memory range (0xfe20-0xfe200fff) for rid 18 of re0
re0: Lazy allocation of 0x1000 bytes rid 0x18 type 3 at 0xfe20
re0: MSI count : 1
re0: MSI-X count : 4
pcib4: allocated memory range (0xfe204000-0xfe207fff) for rid 20 of re0
re0: Lazy allocation of 0x4000 bytes rid 0x20 type 3 at 0xfe204000
re0: attempting to allocate 1 MSI-X vectors (4 supported)
msi: routing MSI-X IRQ 266 to local APIC 0 vector 62
re0: using IRQ 266 for MSI-X
re0: Using 1 MSI-X message
re0: Chip rev. 0x2800
re0: MAC rev. 0x
miibus0:  on re0
ukphy0:  PHY 1 on miibus0
ukphy0: OUI 0x00e0fc, model 0x003f, rev. 15
re0: PHY write failed
re0: PHY write failed
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 100baseT4, 
1000baseSX, 1000baseSX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 
1000baseT-FDX-master, auto, auto-flow
re0: PHY write failed
re0: PHY write failed
re0: bpf attached
re0: Ethernet address: 00:0a:cd:1c:ba:89

re0@pci0:4:0:0: class=0x02 card=0x816810ec chip=0x816810ec rev=0x03 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class  = network
subclass   = ethernet
bar   [10] = type I/O Port, range 32, base 0, size 256, disabled
bar   [18] = type Memory, range 64, base 0xfe20, size 4096, disabled
bar   [20] = type Prefetchable Memory, range 64, base 0xfe204000, size 
16384, disabled
cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
cap 05[50] = MSI supports 1 message, 64 bit 
cap 10[70] = PCI-Express 2 endpoint IRQ 2 max data 128(128) link x1

Re: pcie realtek issue (re driver)

[Mike Tancsa]

On 5/31/2012 1:42 PM, Mike Tancsa wrote:
> On 5/31/2012 10:57 AM, John Baldwin wrote:
>>>
>>> Right, but what if it is not(from the pciconf output)?
>>> I'm pretty sure re(4) used RF_ACTIVE with bus_alloc_resource_any(9).
>>
>> Hmm, is this pciconf output when the driver is attached?
> 
> Hi,
>   Here are some of the variations attached in a txt file.  Could this
> just be a broken card ?  I will try and boot up another OS on the box
> and see if it works.

Oh, and doing a load post reboot,

0{intel-i3}# kldload if_re
pci0: driver added
found-> vendor=0x8086, dev=0x1c3a, revid=0x04
domain=0, bus=0, slot=22, func=0
class=07-80-00, hdrtype=0x00, mfdev=1
cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=16
powerspec 3  supports D0 D3  current D0
MSI supports 1 message, 64 bit
pci0:0:22:0: reprobing on driver added
found-> vendor=0x8086, dev=0x1c22, revid=0x05
domain=0, bus=0, slot=31, func=3
class=0c-05-00, hdrtype=0x00, mfdev=0
cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=c, irq=18
pci0:0:31:3: reprobing on driver added
pci1: driver added
pci2: driver added
pci3: driver added
pci4: driver added
found-> vendor=0x10ec, dev=0x8168, revid=0x03
domain=0, bus=4, slot=0, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=255
powerspec 3  supports D0 D1 D2 D3  current D0
MSI supports 1 message, 64 bit
MSI-X supports 4 messages in map 0x20
pci0:4:0:0: reprobing on driver added
re0:  at device
0.0 on pci4
pci4: child re0 requested type 3 for rid 0x18, but the BAR says it is an
ioport
pcib4: allocated I/O port range (0xd000-0xd0ff) for rid 10 of re0
re0: Lazy allocation of 0x100 bytes rid 0x10 type 4 at 0xd000
re0: MSI count : 1
re0: MSI-X count : 4
pcib4: allocated prefetch range (0xf000-0xf0003fff) for rid 20 of re0
re0: Lazy allocation of 0x4000 bytes rid 0x20 type 3 at 0xf000
re0: attempting to allocate 1 MSI-X vectors (4 supported)
msi: routing MSI-X IRQ 270 to local APIC 1 vector 52
re0: using IRQ 270 for MSI-X
re0: Using 1 MSI-X message
re0: Chip rev. 0x2800
re0: MAC rev. 0x
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0: OUI 0x00e04c, model 0x0011, rev. 2
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 100baseT4, 1000baseSX,
1000baseSX-FDX, 1000baseSX-FDX-flow, 1000baseT, 1000baseT-master,
1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow,
1000baseT-FDX-flow-master, auto, auto-flow
re0: PHY write failed
re0: PHY write failed
re0: bpf attached
re0: Ethernet address: 00:0a:cd:1c:ba:89
pci5: driver added
pci6: driver added
0{intel-i3}#
0{intel-i3}# ifconfig re0 up
re0: reset never completed!
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
0{intel-i3}#


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: pcie realtek issue (re driver)

[Mike Tancsa]

On 6/1/2012 4:09 PM, YongHyeon PYUN wrote:
> 
> This is the first time I saw BAR2 is I/O space on RealTek PCI
> express device. re(4) switched to use BAR0 with I/O space after
> failing to use BAR2. Could you try attached patch?

0(ich10)# patch < re.map.diff
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/dev/re/if_re.c
|===
|--- sys/dev/re/if_re.c (revision 236345)
|+++ sys/dev/re/if_re.c (working copy)
--
Patching file sys/dev/re/if_re.c using Plan A...
Hunk #1 succeeded at 1191.
Hunk #2 succeeded at 1220.
Hunk #3 succeeded at 3320 (offset -1 lines).
done
0(ich10)#

 pci0: driver added
found-> vendor=0x8086, dev=0x1c3a, revid=0x04
domain=0, bus=0, slot=22, func=0
class=07-80-00, hdrtype=0x00, mfdev=1
cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=16
powerspec 3  supports D0 D3  current D0
MSI supports 1 message, 64 bit
pci0:0:22:0: reprobing on driver added
found-> vendor=0x8086, dev=0x1c22, revid=0x05
domain=0, bus=0, slot=31, func=3
class=0c-05-00, hdrtype=0x00, mfdev=0
cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=c, irq=18
pci0:0:31:3: reprobing on driver added
pci1: driver added
pci2: driver added
pci3: driver added
pci4: driver added
found-> vendor=0x10ec, dev=0x8168, revid=0x03
domain=0, bus=4, slot=0, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=255
powerspec 3  supports D0 D1 D2 D3  current D0
MSI supports 1 message, 64 bit
MSI-X supports 4 messages in map 0x20
pci0:4:0:0: reprobing on driver added
re0:  at device
0.0 on pci4
pcib4: allocated memory range (0xfe20-0xfe200fff) for rid 18 of re0
re0: Lazy allocation of 0x1000 bytes rid 0x18 type 3 at 0xfe20
re0: MSI count : 1
re0: MSI-X count : 4
pcib4: allocated prefetch range (0xf000-0xf0003fff) for rid 20 of re0
re0: Lazy allocation of 0x4000 bytes rid 0x20 type 3 at 0xf000
re0: attempting to allocate 1 MSI-X vectors (4 supported)
msi: routing MSI-X IRQ 270 to local APIC 1 vector 52
re0: using IRQ 270 for MSI-X
re0: Using 1 MSI-X message
re0: Chip rev. 0x2800
re0: MAC rev. 0x
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0: OUI 0x00e04c, model 0x0011, rev. 2
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 100baseT4, 1000baseSX,
1000baseSX-FDX, 1000baseSX-FDX-flow, 1000baseT, 1000baseT-master,
1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow,
1000baseT-FDX-flow-master, auto, auto-flow
re0: PHY write failed
re0: PHY write failed
re0: bpf attached
re0: Ethernet address: 00:0a:cd:1c:ba:89
pci5: driver added
pci6: driver added

re0@pci0:4:0:0: class=0x02 card=0x816810ec chip=0x816810ec rev=0x03
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class  = network
subclass   = ethernet
bar   [10] = type I/O Port, range 32, base 0, size 256, disabled
bar   [18] = type Memory, range 64, base 0xfe20, size 4096, disabled
bar   [20] = type Prefetchable Memory, range 64, base 0xf000,
size 16384, disabled
cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 2 endpoint IRQ 2 max data 128(128) link x1(x1)
cap 11[ac] = MSI-X supports 4 messages in map 0x20
cap 03[cc] = VPD
ecap 0001[100] = AER 1 1 fatal 1 non-fatal 3 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 8305684ce000


but ifconfig re0 up
 re0: reset never completed!
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed
re0: PHY write failed



-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: pcie realtek issue (re driver)

[Mike Tancsa]

On 6/1/2012 10:30 AM, John Baldwin wrote:
> 
> BTW, it would be interesting to see what the AER errors are.  Can you apply 
> www.freebsd.org/~jhb/patches/pciconf_e.patch to pciconf and paste the output 
> of 'pciconf -lcbe' for re0?
> 

Hi,
Using the pciconf from HEAD,

re0@pci0:4:0:0: class=0x02 card=0x816810ec chip=0x816810ec rev=0x03
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class  = network
subclass   = ethernet
bar   [10] = type I/O Port, range 32, base 0, size 256, disabled
bar   [18] = type Memory, range 64, base 0xfe20, size 4096, disabled
bar   [20] = type Prefetchable Memory, range 64, base 0xf000,
size 16384, disabled
cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
cap ff[50] = unknown
PCI errors = Master Data Parity Error
 Sent Target-Abort
 Received Target-Abort
 Received Master-Abort
 Signalled System Error
 Detected Parity Error


    ---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: pcie realtek issue (re driver)

[Mike Tancsa]

On 6/4/2012 8:47 PM, YongHyeon PYUN wrote:
> Hmm, Target abort/parity error looks serious to me. Could you
> remove re(4) driver in kernel and perform cold boot and check the
> AER errors again?
> (I assume your controller is not a stand-alone PCIe controller so
> I excluded resitting the controller).


Hi,
This is a stand alone card actually.  Here it is after a power cycle.
Perhaps just a bad card ?

none2@pci0:4:0:0:   class=0x02 card=0x chip=0x816810ec
rev=0x03 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class  = network
subclass   = ethernet
bar   [10] = type I/O Port, range 32, base 0, size 256, disabled
bar   [18] = type Memory, range 64, base 0, size 4096, disabled
bar   [20] = type Prefetchable Memory, range 64, base 0, size 16384,
disabled
cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 2 endpoint IRQ 2 max data 128(128) link x1(x1)
cap 11[ac] = MSI-X supports 4 messages in maps 0x20 and 0x2c
PCI errors = Master Data Parity Error
 Sent Target-Abort
 Received Target-Abort
 Received Master-Abort
 Signalled System Error
 Detected Parity Error





-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Supermicro X7SBE with Chenbro 16 bay 4U case

[Mike Tancsa]

On 9/18/2012 10:21 AM, Dan Carroll wrote:
> Hiya All,
> 
> I have the above gear with an Areca 12 channel card in it.It's
> getting on and I'm getting a periodic loud beeping from it.   When it
> starts it beeps for about half a second and repeats every 15 seconds or so.

Hi,
Is it the card, or the MB that is beeping ? Did you try and look at the
RAID card to see if its complaining about a disk ?

---Mike



-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Supermicro X7SBE with Chenbro 16 bay 4U case

[Mike Tancsa]

13.250| 13.303| 13.356
+3.3V| 3.240  | Volts  | ok| 2.880 | 2.904
   | 2.928 | 3.648 | 3.672 | 3.696
+3.3VSB  | 3.312  | Volts  | ok| 2.880 | 2.904
   | 2.928 | 3.648 | 3.672 | 3.696
VBAT | 3.168  | Volts  | ok| 2.880 | 2.904
   | 2.928 | 3.648 | 3.672 | 3.696
Fan1 | 9315.000   | RPM| ok| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Fan2 | 9315.000   | RPM| ok| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Fan3 | 9315.000   | RPM| ok| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Fan4 | 9315.000   | RPM| ok| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Fan5 | 9315.000   | RPM| ok| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Fan6 | 9315.000   | RPM| ok| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Fan7 | na | RPM| na| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Fan8 | na | RPM| na| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Fan9 | na | RPM| na| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Fan10| 6480.000   | RPM| ok| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Fan11| na | RPM| na| 405.000   | 540.000
  | 675.000   | 34155.000 | 34290.000 | 34425.000
Intrusion| 0.000  | unspecified | nc| na| na
| na| na| na| na
PS Status| 0.000  | unspecified | ok| na| na
| na| na| na| na
0(backup3)%




---Mike

> 
> -D
> ___
> freebsd-hardware@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
> To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
> 
> 


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Which one has better support for FreeBSD , LSI or Areca ? with multiport support

[Mike Tancsa]

On 9/21/2012 4:25 PM, Pepe (Jose) Amengual wrote:
> 
> So now I have decided to buy a real controller, Areca or LSI for the server
> but I need one that is port multiplier compatible and with external esata
> connectors.

Not sure about the eSata ports, but we are testing the newer 3ware
controllers (9750) that use the tws driver. Its a SAS controller, but
you can use SATA drives on them.

They seem to be quite fast!  In the past, we have used the twe and twa
based controllers from 3ware and have had very good results with them
over the years.  The monitoring facilities are great (CLI and web
based).  We have had drive failures over the years, and replacing them
has been painless

We also use a number of the older series Areca cards (ARC-1210) and they
too have been solid.  The monitoring daemon is a little quirky at first,
but it works well as does the CLI tool.  I havent tried any of their
newer SAS controllers, but they use the same arcmsr driver which is
actively maintained by Areca.

In short, I think you would do really well with either card.

---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Rocket Raid 622 in AHCI mode

[Mike Tancsa]

I picked up an external PMP/Cage/RR6622 combo that claims to be Sata
III. From the BIOS, the card implies it does indeed see the SATA III drives

Pic of the BIOS here
http://tancsa.com/rr.jpg

ahci0:  port
0x4090-0x4097,0x4080-0x4083,0x4070-0x4077,0x4060-0x4063,0x4050-0x405f
mem 0xc243-0xc24307ff irq 16 at device 0.0 on pci1
ahci0: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS
ahcich0:  at channel 0 on ahci0
ahcich1:  at channel 1 on ahci0



However, performance is abysmal and worse than using a regular sii based
SATA II card.

It sees the PMP and cage as

pmp0 at ahcich1 bus 0 scbus1 target 15 lun 0
pmp0:  ATA-0 device
pmp0: 300.000MB/s transfers (SATA 2.x, NONE, PIO 8192bytes)
pmp0: 5 fan-out ports
ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
ada1:  ATA-8 SATA 3.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada1: Previously was known as ad6
ada2 at ahcich1 bus 0 scbus1 target 1 lun 0
ada2:  ATA-8 SATA 3.x device
ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada2: Command Queueing enabled
ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada2: Previously was known as ad7
ada3 at ahcich1 bus 0 scbus1 target 2 lun 0
ada3:  ATA-8 SATA 3.x device
ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada3: Command Queueing enabled
ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
ada4 at ahcich1 bus 0 scbus1 target 3 lun 0
ada4:  ATA-8 SATA 3.x device
ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada4: Command Queueing enabled
ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
ada5 at ahcich1 bus 0 scbus1 target 4 lun 0
ada5:  ATA-8 SATA 3.x device
ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada5: Command Queueing enabled
ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)

# camcontrol devlist
   at scbus1 target 0 lun 0 (ada1,pass2)
   at scbus1 target 1 lun 0 (ada2,pass3)
   at scbus1 target 2 lun 0 (ada3,pass4)
   at scbus1 target 3 lun 0 (ada4,pass5)
   at scbus1 target 4 lun 0 (ada5,pass6)
at scbus1 target 15 lun 0 (pmp0,pass1)
  at scbus2 target 0 lun 0 (pass0,ada0)

Writing to the individual disks seems fine, but when all the disks are
engaged, its very slow

# zpool create -f tank raidz ada1 ada2 ada3 ada4 ada5

# dd if=/dev/zero of=/tank/test1 bs=2048k count=10
10+0 records in
10+0 records out
20971520 bytes transferred in 60.370025 secs (347383 bytes/sec)
# zpool export tank; zpool import tank
# dd if=/tank/test1 of=/dev/null bs=2048k
10+0 records in
10+0 records out
20971520 bytes transferred in 7.678915 secs (2731052 bytes/sec)


# for i in `jot 5 1`; do dd if=/dev/ada$i of=/dev/null count=200
bs=2048k;done
200+0 records in
200+0 records out
419430400 bytes transferred in 3.211699 secs (130594554 bytes/sec)
200+0 records in
200+0 records out
419430400 bytes transferred in 3.034111 secs (138238327 bytes/sec)
200+0 records in
200+0 records out
419430400 bytes transferred in 3.639701 secs (115237601 bytes/sec)
200+0 records in
200+0 records out
419430400 bytes transferred in 2.841386 secs (147614716 bytes/sec)
200+0 records in
200+0 records out
419430400 bytes transferred in 3.020611 secs (138856154 bytes/sec)
#

# for i in `jot 5 1`; do dd if=/dev/zero  of=/dev/ada$i  count=200
bs=2048k;done
200+0 records in
200+0 records out
419430400 bytes transferred in 3.285333 secs (127667539 bytes/sec)
200+0 records in
200+0 records out
419430400 bytes transferred in 3.043410 secs (137815945 bytes/sec)
200+0 records in
200+0 records out
419430400 bytes transferred in 3.611478 secs (116138154 bytes/sec)
200+0 records in
200+0 records out
419430400 bytes transferred in 2.830386 secs (148188414 bytes/sec)
200+0 records in
200+0 records out
419430400 bytes transferred in 2.987366 secs (140401412 bytes/sec)
#

Any ideas on how to fix this controller to make it work better with ZFS
and get better speeds ?


ahci0@pci0:1:0:0:   class=0x010400 card=0x00011103 chip=0x06221103
rev=0x01 hdr=0x00
vendor = 'HighPoint Technologies, Inc.'
class  = mass storage
subclass   = RAID
bar   [10] = type I/O Port, range 32, base 0x4090, size  8, enabled
bar   [14] = type I/O Port, range 32, base 0x4080, size  4, enabled
bar   [18] = type I/O Port, range 32, base 0x4070, size  8, enabled
bar   [1c] = type I/O Port, range 32, base 0x4060, size  4, enabled
bar   [20] = type I/O Port, range 32, base 0x4050, size 16, enabled
bar   [24] = type Memory, range 32, base 0xc243, size 2048, enabled
cap 01[40] = powerspec 3  supports D0 D3  current D0
cap 05[50] = MSI supports 1 message enabled with 1 message
cap 10[70] = PCI-Express 2 legacy endpoint max data 128(512) link x1(x1)
 speed 5.0(5.0)
ecap 0001[100] = AER 1 1 fatal 0 non-fatal 0 corrected


---Mike








-- 
---
Mike Tanc

Re: Rocket Raid 622 in AHCI mode

[Mike Tancsa]

On 5/28/2013 12:33 PM, Alexander Motin wrote:
>> #
>>
>> Any ideas on how to fix this controller to make it work better with ZFS
>> and get better speeds ?
> 
> Good question. One of several about these Marvell controllers, caused by
> lack of any public documentation. :(
> 

OK, thanks for responding. I figured if anyone knew definitively, it
would be you :) I will just use the 3124 for now.  It has been pretty
reliably for me to make these large storage appliances.

Other than the 3124, do you recommend anything else ? I want to put
together another 20TB storage appliance.  Faster is nicer, but cost is a
constraining factor.

    ---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Rocket Raid 622 in AHCI mode

[Mike Tancsa]

On 5/28/2013 12:33 PM, Alexander Motin wrote:
> On 28.05.2013 16:38, Mike Tancsa wrote:
> 
> SiI3124 still was not beaten.
> 
>> It sees the PMP and cage as
>>
>> pmp0 at ahcich1 bus 0 scbus1 target 15 lun 0
>> pmp0:  ATA-0 device
>> pmp0: 300.000MB/s transfers (SATA 2.x, NONE, PIO 8192bytes)
>> pmp0: 5 fan-out ports
>> Any ideas on how to fix this controller to make it work better with ZFS
>> and get better speeds ?
> 
> Good question. One of several about these Marvell controllers, caused by
> lack of any public documentation. :(


I tried to do a little more testing to see what might be up either with
the cage, the card or the drives.  It seems there is something odd about
the first slot in the cage-- I have tried 2 cages, and they both show
the same behaviour.  ie. two cages (same make/model) and two of the
rocket raid cards (same make and model).

If I read/write to just the disk in slot zero, it works as expected.
However, if I create some sort of multi-disk array with the disk in the
first slot, its so slow, its almost broken.

e.g.

0{mdttestbox}# gstripe stop data
0{mdttestbox}# gstripe label -v -s 131072 data ada0 ada1
Metadata value stored on ada0.
Metadata value stored on ada1.
Done.
0{mdttestbox}# newfs -U -O2 /dev/stripe/data > /dev/null
0{mdttestbox}# mount /dev/stripe/data /mnt
0{mdttestbox}# dd if=/dev/zero of=/mnt/test bs=4096k count=100
100+0 records in
100+0 records out
419430400 bytes transferred in 56.875768 secs (7374501 bytes/sec)
0{mdttestbox}# umount /mnt;mount /dev/stripe/data /mnt
0{mdttestbox}# dd if=/mnt/test of=/dev/null bs=4096k
^C17+0 records in
17+0 records out
71303168 bytes transferred in 237.424329 secs (300320 bytes/sec)
1{mdttestbox}# gstripe stop data
gstripe: Cannot destroy device data (error=16).
1{mdttestbox}# umount /mnt ; mount /dev/stripe/data /mnt
0{mdttestbox}# umount /mnt


Yet, if I use the other 4 disks, all works well

0{mdttestbox}# gstripe stop data
0{mdttestbox}# gstripe label -v -s 131072 data ada1 ada2 ada3 ada4
Metadata value stored on ada1.
warning: ada2: only 1000204885504 bytes from 2000398933504 bytes used.
Metadata value stored on ada2.
warning: ada3: only 1000204885504 bytes from 1500301909504 bytes used.
Metadata value stored on ada3.
warning: ada4: only 1000204885504 bytes from 2000398933504 bytes used.
Metadata value stored on ada4.
Done.
0{mdttestbox}# newfs -U -O2 /dev/stripe/data > /dev/null
0{mdttestbox}# mount /dev/stripe/data /mnt
0{mdttestbox}# dd if=/dev/zero of=/mnt/test bs=4096k count=100
100+0 records in
100+0 records out
419430400 bytes transferred in 2.131533 secs (196774067 bytes/sec)
0{mdttestbox}# umount /mnt ; mount /dev/stripe/data /mnt
0{mdttestbox}# dd if=/mnt/test of=/dev/null bs=4096k
100+0 records in
100+0 records out
419430400 bytes transferred in 2.574856 secs (162894699 bytes/sec)
0{mdttestbox}#


Although its a bit odd writes are faster than reads ?


ZFS works as expected as well if I exclude the first slot.

1{mdttestbox}# zpool create stripe ada1 ada2 ada3 ada4
0{mdttestbox}# dd if=/dev/zero of=/stripe/test bs=4096k count=100
100+0 records in
100+0 records out
419430400 bytes transferred in 1.283134 secs (326879599 bytes/sec)
0{mdttestbox}# dd if=/dev/zero of=/stripe/test bs=4096k count=1000
1000+0 records in
1000+0 records out
4194304000 bytes transferred in 22.798638 secs (183971691 bytes/sec)
0{mdttestbox}# dd if=/stripe/test of=/dev/null bs=4096k
1000+0 records in
1000+0 records out
4194304000 bytes transferred in 0.472554 secs (8875820076 bytes/sec)
0{mdttestbox}# zpool export stripe
0{mdttestbox}# zpool import stripe
0{mdttestbox}# dd if=/stripe/test of=/dev/null bs=4096k
1000+0 records in
1000+0 records out
4194304000 bytes transferred in 23.068320 secs (181820956 bytes/sec)
0{mdttestbox}#

Whats odd is that the SII card does not have this problem with 5 disks
in the drive cage.  Only the RR card does.

0{mdttestbox}# camcontrol devlist
   at scbus0 target 0 lun 0 (ada0,pass1)
   at scbus0 target 1 lun 0 (ada1,pass2)
   at scbus0 target 2 lun 0 (ada3,pass4)
   at scbus0 target 3 lun 0 (ada4,pass5)
   at scbus0 target 4 lun 0 (ada2,pass3)
at scbus0 target 15 lun 0 (pmp0,pass0)
  at scbus2 target 0 lun 0 (pass6,ada5)
0{mdttestbox}#

---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Rocket Raid 622 in AHCI mode

[Mike Tancsa]

On 5/30/2013 3:02 PM, Lawrence K. Chen, P.Eng. wrote:
> 
> I've been thinking of replacing the cards with ASM1061 based onesbut 
> things have been stable, so not sure I really want to go poking around inside 
> my computer just to try different cards.  Though I have plans to drop in 
> another SSD to use as L2ARC in the future (had picked up a Velocity Solo x1 
> card a while back )

Hi,
What does the ASM1061 attach as ?  A generic AHCI controller ?

---Mike


-- 
-------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Inexpensive PCI SATA, anyone?

[Mike Tancsa]

With a lot of trial and error, the one card that works well for us in a 
backup server with 16 drives is


http://www.addonics.com/products/adsa3gpx8-4e.php

it shows up as

pci5:  on pcib5
siis0:  port 0x3000-0x300f mem 
0xb4408000-0xb440807f,0xb440-0xb4407fff irq 19 at device 0.0 on pci5

siisch0:  at channel 0 on siis0
siisch1:  at channel 1 on siis0
siisch2:  at channel 2 on siis0
siisch3:  at channel 3 on siis0

# pciconf -lvcb siis0
siis0@pci0:5:0:0:   class=0x010400 card=0x71241095 chip=0x31241095 
rev=0x02 hdr=0x00

vendor = 'Silicon Image, Inc.'
device = 'SiI 3124 PCI-X Serial ATA Controller'
class  = mass storage
subclass   = RAID
bar   [10] = type Memory, range 64, base 0xb4408000, size 128, enabled
bar   [18] = type Memory, range 64, base 0xb440, size 32768, 
enabled

bar   [20] = type I/O Port, range 32, base 0x3000, size 16, enabled
cap 01[64] = powerspec 2  supports D0 D1 D2 D3  current D0
cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12 
split transactions

cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message

Its PCIX chip on a PCIe bus

---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Inexpensive PCI SATA, anyone?

[Mike Tancsa]

On 7/23/2014 1:22 PM, Alex Povolotsky wrote:

Seems to be too thick for 1U...


You could look at some of the 3ware cards on ebay. The 96xx series can 
be used as JBOD if you are looking for just a lot of disks.  Ebay has 
them, and the card works quite well using the twa driver.


---Mike



On 23.07.2014 21:11, Mike Tancsa wrote:


With a lot of trial and error, the one card that works well for us in
a backup server with 16 drives is

http://www.addonics.com/products/adsa3gpx8-4e.php

it shows up as

pci5:  on pcib5
siis0:  port 0x3000-0x300f mem
0xb4408000-0xb440807f,0xb440-0xb4407fff irq 19 at device 0.0 on pci5
siisch0:  at channel 0 on siis0
siisch1:  at channel 1 on siis0
siisch2:  at channel 2 on siis0
siisch3:  at channel 3 on siis0

# pciconf -lvcb siis0
siis0@pci0:5:0:0:   class=0x010400 card=0x71241095 chip=0x31241095
rev=0x02 hdr=0x00
vendor = 'Silicon Image, Inc.'
device = 'SiI 3124 PCI-X Serial ATA Controller'
class  = mass storage
subclass   = RAID
bar   [10] = type Memory, range 64, base 0xb4408000, size 128,
enabled
bar   [18] = type Memory, range 64, base 0xb440, size 32768,
enabled
bar   [20] = type I/O Port, range 32, base 0x3000, size 16, enabled
cap 01[64] = powerspec 2  supports D0 D1 D2 D3  current D0
cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12
split transactions
cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message

Its PCIX chip on a PCIe bus

---Mike




___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"





--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Anyone working on the Marvell 88se64xx sas/sata chip driver?

[Mike Tancsa]

On 11/21/2014 4:08 AM, John-Mark Gurney wrote:

Jia-Shiun Li wrote this message on Fri, Nov 21, 2014 at 13:11 +0800:

for 6G SAS there is hpt27xx blob driver for Highpoint cards using
88SE94xx. 12G SAS is 88SE1495, but there seems no products yet.


In my exerience w/ the hpt27xx driver on 9.1-R, the card is terrible...
Caused me no end of pain.. I replaced the card w/ an ahci native card
(since I was hooking up SATA drivers), and now I'm happy...

I couldn't get any support from Highpoint... Not really surprising
considering the binary driver...


I have had good results with the LSI cards, both based on the 3ware 
driver (tws) and the mfi driver.  The cost of the previous gen 6G SAS 
9240-8si is quite reasonable and I can get great speeds and good 
monitoring through the available native FreeBSD tools 
(3dm,tw_cli,MegaCli,mfiutil)


---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Real vs available memory

[Mike Tancsa]

On 12/9/2014 10:19 AM, Frank Seltzer wrote:

I have a Dell Studio XPS 7100 that came with 4 gigs of memory.  I have
added another 4 gigs but there is a problem using it.  The system BIOS
sees the additional 4 gigs and apparently so does FreeBSD but I get this
during boot.

real memory  = 8589934592 (8192 MB)
avail memory = 3400794112 (3243 MB)

How do I get use of the full 8 gigs?



What does
uname -a
show ? Are you by chance running i386 inadvertently ?

---Mike




--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Real vs available memory

[Mike Tancsa]

On 12/9/2014 11:00 AM, Frank Seltzer wrote:

real memory  = 8589934592 (8192 MB)
avail memory = 3400794112 (3243 MB)

How do I get use of the full 8 gigs?



What does
uname -a
show ? Are you by chance running i386 inadvertently ?

---Mike


FreeBSD xxx.xxx.xxx 10.1-STABLE FreeBSD 10.1-STABLE #0 r275606: Mon Dec
8 14:36:16 EST 2014 fran...@xxx.xxx.xxx:/usr/obj/usr/src/sys/GENERIC i386

Should I be running something else?


i386 is a 32 bit kernel and without PAE extensions, you cannot make use 
of the extra memory. Going to 64bit means you can use all of the RAM in 
your machine, but it means reinstalling.

see

https://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/hardware.html

as a start.

---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

zfs and 512/4096 sector sizes

[Mike Tancsa]

On a remote server, I replaced a dead 2TB disk with a new one that had 
4096K sectors.


2014-12-11.22:40:30 zpool replace -f tank1 16144392433229115618 /dev/ada0


My ZFS pool then warned me after

  pool: tank1
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
Expect reduced performance.
action: Replace affected devices with devices that support the
configured block size, or migrate data to a properly configured
pool.

Camcontrol and smartctl confirm the 2TB drive was indeed 4096. (All my 
previous ones were 512, so didnt think to check)


# camcontrol identify ada0 | grep secto
sectors/track 63
sector size   logical 512, physical 4096, offset 0
LBA supported 268435455 sectors
LBA48 supported   3907029168 sectors

# smartctl -a /dev/ada0 | grep -i 512
Sector Sizes: 512 bytes logical, 4096 bytes physical

So, with a new drive, I replaced the 4096 drive

2014-12-16.17:07:14 zpool replace tank1 ada0 ada11

# smartctl -a /dev/ada11 | grep -i 512
Sector Size:  512 bytes logical/physical
# camcontrol identify ada11 | grep -i sector
sectors/track 63
sector size   logical 512, physical 512, offset 0
LBA supported 268435455 sectors
LBA48 supported   3907029168 sectors

yet, zfs is still complaining

# zpool status
  pool: tank1
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
Expect reduced performance.
action: Replace affected devices with devices that support the
configured block size, or migrate data to a properly configured
pool.
  scan: resilvered 898G in 8h4m with 0 errors on Wed Dec 17 15:01:18 2014
config:

NAMESTATE READ WRITE CKSUM
tank1   ONLINE   0 0 0
  raidz1-0  ONLINE   0 0 0
ada12   ONLINE   0 0 0
ada10   ONLINE   0 0 0
ada6ONLINE   0 0 0
ada14   ONLINE   0 0 0
  raidz1-1  ONLINE   0 0 0
ada11   ONLINE   0 0 0  block size: 512B 
configured, 4096B native

ada1ONLINE   0 0 0
ada8ONLINE   0 0 0
ada9ONLINE   0 0 0
  raidz1-2  ONLINE   0 0 0
ada13   ONLINE   0 0 0
ada4ONLINE   0 0 0
ada5ONLINE   0 0 0
ada7ONLINE   0 0 0

errors: No known data errors


# zdb | grep -i shift
metaslab_shift: 35
ashift: 9
metaslab_shift: 35
ashift: 9
metaslab_shift: 35
ashift: 9

This is RELENG_9 r275680

Any ideas if the reporting is cosmetic ? Or there is an issue

Sorry for the xpost as this is sort of both a hardware and config issue.

---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: zfs and 512/4096 sector sizes

[Mike Tancsa]

On 12/17/2014 6:12 PM, Andriy Gapon wrote:


yet, zfs is still complaining


Does zpool clear help in this situation?




Looks like a reboot was needed to fix the issue.

# zpool status
  pool: tank1
 state: ONLINE
  scan: resilvered 898G in 8h4m with 0 errors on Wed Dec 17 15:01:18 2014
config:

NAMESTATE READ WRITE CKSUM
tank1   ONLINE   0 0 0
  raidz1-0  ONLINE   0 0 0
ada12   ONLINE   0 0 0
ada10   ONLINE   0 0 0
ada6ONLINE   0 0 0
ada14   ONLINE   0 0 0
  raidz1-1  ONLINE   0 0 0
ada11   ONLINE   0 0 0
ada1ONLINE   0 0 0
ada8ONLINE   0 0 0
ada9ONLINE   0 0 0
  raidz1-2  ONLINE   0 0 0
ada13   ONLINE   0 0 0
ada4ONLINE   0 0 0
ada5ONLINE   0 0 0
ada7ONLINE   0 0 0

errors: No known data errors




--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

mfi vs mps vs firmware images

[Mike Tancsa]

I have been using a pair of LSI branded 9420-8si cards in my backup 
server on RELENG_10 since November 2014 (firmware from Oct 2014 off the 
LSI site) and so far so good. However, a number of other users have 
warned me not to use the mfi driver, and stick with the MPS driver and 
some older versions of the firmware aimed at an IBM m1015.  I use the 
cards for zfs and to expose the disks individually through cam with the 
mfip module and so far so good.
However, folks over on the FreeNAS forum are convinced I am flirting 
with data loss using the supposed disastrous mfi driver/firmware combo. 
 Can anyone shed light  on the state of these cards and how best to use 
them ? I havent really seen anything on the FreeBSD lists in the past 
year indicating serious issues, but then again, I only started using 
these cards since Novmeber of last year.


I do zfs scrubs every month and they have yet to show errors on my 32TB 
pool. (a number of raidz2s)



# mfiutil show adapter
mfi0 Adapter:
Product Name: LSI MegaRAID SAS 9240-8i
   Serial Number: SP34906493
Firmware: 20.13.1-0208
 RAID Levels: JBOD, RAID0, RAID1, RAID10
  Battery Backup: not present
   NVRAM: 32K
  Onboard Memory: 0M
  Minimum Stripe: 8K
  Maximum Stripe: 64K
# mfiutil show firmware
mfi0 Firmware Package Version: 20.13.1-0208
mfi0 Firmware Images:
Name  Version  Date Time Status
BIOS  4.38.02.2_4.16.08.00_0x06060A05  07/23/2014
  07/23/2014
  active
PCLI  03.02-020:#%9May 07 2012  13:21:53 active
BCON  4.0-61-e_50-Rel  Sep 09 2014  11:45:57 active
NVDT  3.09.03-0064 Oct 06 2014  12:00:15 active
APP   2.130.404-3836   Oct 16 2014  06:50:12 active
BTBL  2.02.00.00-0001  Aug 18 2010  11:44:44 active
# mfiutil show drives
mfi0 Physical Drives:
 8 ( 3726G) JBOD  serial=WD-WCC4E0911515> SATA E1:S1
 9 ( 3726G) JBOD  serial=WD-WCC4E9Y80F79> SATA E1:S0
10 ( 3726G) JBOD  serial=WD-WCC4E0916074> SATA E1:S3
11 ( 3726G) JBOD  serial=WD-WCC4E0893433> SATA E1:S2
13 ( 3726G) JBOD  serial=WD-WCC4E9Y80J8A> SATA E1:S5


mfi0:  port 0x6000-0x60ff mem 
0xb146-0xb1463fff,0xb140-0xb143 irq 16 at device 0.0 on pci1

mfi0: Using MSI
mfi0: Megaraid SAS driver Ver 4.23
mfip0:  on mfi0

}# pciconf -lvcb mfi0
mfi0@pci0:1:0:0:class=0x010400 card=0x92401000 chip=0x00731000 
rev=0x03 hdr=0x00

vendor = 'LSI Logic / Symbios Logic'
device = 'MegaRAID SAS 2008 [Falcon]'
class  = mass storage
subclass   = RAID
bar   [10] = type I/O Port, range 32, base 0x6000, size 256, enabled
bar   [14] = type Memory, range 64, base 0xb146, size 16384, 
enabled
bar   [1c] = type Memory, range 64, base 0xb140, size 262144, 
enabled

cap 01[50] = powerspec 3  supports D0 D1 D2 D3  current D0
cap 10[68] = PCI-Express 2 endpoint max data 256(4096) FLR link x2(x8)
 speed 5.0(5.0) ASPM disabled(L0s)
cap 03[d0] = VPD
cap 05[a8] = MSI supports 1 message, 64 bit enabled with 1 message
cap 11[c0] = MSI-X supports 15 messages
 Table in map 0x14[0x2000], PBA in map 0x14[0x3800]
ecap 0001[100] = AER 1 1 fatal 0 non-fatal 0 corrected
ecap 0004[138] = Power Budgeting 1


Box is running 10.1-STABLE FreeBSD 10.1-STABLE #10 r275939 AMD64

    ---Mike

--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: L2 cache errors???

[Mike Tancsa]

On 7/28/2015 1:16 PM, Willem Jan Withagen wrote:
> Hi,
> 
> Are these what I think they are?
> Errors in the CPU L2 cache?
> 
> Are the ECC corrected?
> Or is error really "data kaput"?
> 


Could be. There is also an erratum issue that triggers these errors on
certain CPUs when running software like virtualbox.  It was fixed in
RELENG_10 some time ago. What are you running ?


https://svnweb.freebsd.org/base?view=revision&revision=269052

has some details.

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: no IPMI on identical box

[Mike Tancsa]

On 9/18/2018 6:26 AM, Axel Rau wrote:
> Hi all,
> 
> The attached text files show the dmesg of both boxes.
> How can I fix the broken one?

If you install sysutils/dmidecode
does it show the same BIOS version, board revision etc ?

Also, if you manually load the ipmi driver on the second one, does it
give an error ?

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
freebsd-hardware@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: no IPMI on identical box

[Mike Tancsa]

On 9/18/2018 11:40 AM, Axel Rau wrote:
>> Also, if you manually load the ipmi driver on the second one, does it
>> give an error ?
> It’s loaded now (after reboot), but there is no ipmi device:
> 
> [bh3:~] root# kldstat
> Id Refs AddressSize Name
>  1   27 0x8020 20647f8  kernel
>  21 0x82266000 25b38geom_mirror.ko
>  31 0x8228c000 381080   zfs.ko
>  42 0x8260e000 a380 opensolaris.ko
>  51 0x82619000 f988 ipmi.ko
>  62 0x82629000 2d10 smbus.ko
>  71 0x82d11000 2328 ums.ko
>  81 0x82d14000 237c nullfs.ko
>  91 0x82d17000 1820 fdescfs.ko


Take it out of /boot/loader.conf
and after the box boots up try

sysctl -w debug.bootverbose=1
kldload -v ipmi

and paste the output here.

If still nothing, I would have a look through the BIOS options to see if
its somehow disabled, or try reflashing the BIOS.  Is the IPMI
integrated onto the motherboard or is it an additional card that is added ?

---Mike
___
freebsd-hardware@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: LSI/AVGO/Broadcom 9280-16i4e support?

[mike tancsa]

On 9/3/2019 10:46 AM, Josh Paetzel wrote:
>> (however, not sure if mfip_load is really necessary :-).
>
>> The above works for me in a 11.2-RELEASE machine. However this is a 
>> playground machine, used mainly for smoke-testing disks, not for serious 
>> production tasks.
>
>
> Well, you are right about that.
>
> mfip gives you access to SMART. mrsas doesn't have an analogue to that.


mrsas seems to be better maintained than mfi and I have had cards that
didnt work on RELENG12 via the mfi driver but did via mrsas[1]. You dont
need mfip as drives show up as /dev/da* and smartctl works with the
corresponding /dev/pass# device files. You can also use storcli (also in
the ports) to put it in jbod mode if you dont like megacli

eg

storcli /c0 show all
storcli /c0 show help
storcli /c0 set jbod=on (enable jbod mode for drives)
storcli /c0/e252/s0 set jbod (sets a disk into jbod mode)

I am using the mrsas driver in jbod mode on the 9272 controller for ZFS
and its nice and zippy and (so far) quite reliable.

# storcli /c0 show all
Generating detailed summary of the adapter, it may take a while to complete.

CLI Version = 007.0709.. Aug 14, 2018
Operating system = FreeBSD 12.0-STABLE
Controller = 0
Status = Success
Description = None


Basics :
==
Controller = 0
Model = LSI MegaRAID SAS 9272-8i



PD LIST :
===


EID:Slt DID State DG Size Intf Med SED PI SeSz Model   
Sp Type

252:0    15 JBOD  -  7.276 TB SATA HDD N   N  512B WDC WD80EFAX-68KNBN0
U  -   
252:4    16 JBOD  -  7.276 TB SATA HDD N   N  512B WDC WD80EFAX-68KNBN0
U  -   
252:5    18 JBOD  -  7.276 TB SATA HDD N   N  512B WDC WD80EFAX-68KNBN0
U  -   
252:6    19 JBOD  -  7.276 TB SATA HDD N   N  512B WDC WD80EFAX-68KNBN0
U  -   
252:7    17 JBOD  -  7.276 TB SATA HDD N   N  512B WDC WD80EFAX-68KNBN0
U  -   


# camcontrol devlist
    at scbus1 target 15 lun 0 (pass0,da0)
    at scbus1 target 16 lun 0 (pass1,da1)
    at scbus1 target 17 lun 0 (pass2,da2)
    at scbus1 target 18 lun 0 (pass3,da3)
    at scbus1 target 19 lun 0 (pass4,da4)

# smartctl -a /dev/pass0 | head
smartctl 7.0 2018-12-30 r4883 [FreeBSD 12.0-STABLE amd64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Red
Device Model: WDC WD80EFAX-68KNBN0
Serial Number:    VAHZRMSL
LU WWN Device Id: 5 000cca 099dc0f9d
Firmware Version: 81.00A81
User Capacity:    8,001,563,222,016 bytes [8.00 TB]

 

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231432

---Mike

___
freebsd-hardware@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

Re: Request for Recommendations: media / transcode server

[mike tancsa]

On 11/14/2019 12:17 PM, Axel Rau wrote:
> I just built an AMD server box from desktop parts (plus a 3U rack
> case), which has all you are asking for:
> - motherboard Asrock Rack X470D4U
>   
> https://www.asrockrack.com/general/productdetail.asp?Model=X470D4U#Specifications
>  
> 
> - CPU Ryzen, like Ryzen 7 3700X or smaller
>
> The idle power consumption is about 50 Watts.
> Matisse Ridge CPU should support ECC RAM.
> As compared to supermicro’s, the IPMI works flawless and shows a clear design.

Just got one of these boards too. Are you able to get ipmi sol working
fully ? For some reason, it decided to redirect the BIOS to serial, and
then the post boot up to sol ?!?  Other than that, it does seem like a
decent board so far, especially with the cost and availability of the CPUs

    ---Mike

___
freebsd-hardware@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"

WD Blue 510 SSD and strange write performance

[mike tancsa]

This might be more of a hardware question than anything, but I noticed 
the drive is fairly fast on initial writes, but dramatically slows down 
over time with a consistent write.


At bootup time, I can blast out a file (UFS2 mount)

#  dd if=/dev/zero of=/mnt/tmp/junk.bin.`date "+%s"` bs=1m 
status=progress count=4000

  3735027712 bytes (3735 MB, 3562 MiB) transferred 7.014s, 533 MB/s
#

nice and fast.  But subsequent writes really start to tank.

#  dd if=/dev/zero of=/mnt/tmp/junk.bin.`date "+%s"` bs=1m 
status=progress count=4000

  4128243712 bytes (4128 MB, 3937 MiB) transferred 46.048s, 90 MB/s

# dd if=/dev/zero of=/mnt/tmp/junk.bin.`date "+%s"` bs=1m 
status=progress count=4000

  3992977408 bytes (3993 MB, 3808 MiB) transferred 31.016s, 129 MB/s

If I wait for 2min, it seems to be back to normal

 # sleep 120 ; dd if=/dev/zero of=/mnt/tmp/junk.bin.`date "+%s"` bs=1m 
status=progress count=4000

  4137680896 bytes (4138 MB, 3946 MiB) transferred 9.025s, 458 MB/s

Is there something going on behind the scenes limiting the amount of 
sustained writes these drives can handle ? Is it just a limitation of 
the SSD ?  I didnt notice such issues on some consumer Samsungs. The 
problem initially showed up for me when I was doing a series of zfs send 
| zfs recv on the same pool (so a lot of reads and writes at the same 
time) and I would get a bunch of errors on the WD disks.  Replacing them 
with Samsungs avoids the errors.



=== START OF INFORMATION SECTION ===
Device Model: WD Blue SA510 2.5 1000GB
Serial Number:    24040681
LU WWN Device Id: 5 001b44 8b334e00b
Firmware Version: 52046100
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Size:  512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:  2.5 inches
TRIM Command: Available, deterministic
Device is:    Not in smartctl database 7.3/5528
ATA Version is:   ACS-4, ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Thu Mar 14 14:41:58 2024 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

# camcontrol iden ada1
pass1:  ACS-4 ATA SATA 3.x device
pass1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)

protocol  ACS-4 ATA SATA 3.x
device model  WD Blue SA510 2.5 1000GB
firmware revision 52046100
serial number 24040681
WWN   5001b448b334e00b
additional product id
cylinders 16383
heads 16
sectors/track 63
sector size   logical 512, physical 512, offset 0
LBA supported 268435455 sectors
LBA48 supported   1953525168 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA6
media RPM non-rotating
Zoned-Device Commands no

Feature  Support  Enabled   Value Vendor
read ahead yes  yes
write cache    yes  yes
flush cache    yes  yes
Native Command Queuing (NCQ)   yes  32 tags
NCQ Priority Information   no
NCQ Non-Data Command   no
NCQ Streaming  no
Receive & Send FPDMA Queued    no
NCQ Autosense  no
SMART  yes  yes
security   yes  no
power management   yes  yes
microcode download yes  yes
advanced power management  yes  no  0/0x00
automatic acoustic management  no   no
media status notification  no   no
power-up in Standby    no   no
write-read-verify  no   no
unload no   no
general purpose logging    yes  yes
free-fall  no   no
sense data reporting   no   no
extended power conditions  no   no
device statistics notification no   no
Data Set Management (DSM/TRIM) yes
DSM - max 512byte blocks   yes  8
DSM - deterministic read   yes  any value
Trusted Computing  no
encrypts all user data no
Sanitize   yes  block,
Sanitize - commands allowed    yes
Sanitize - antifreeze lock yes
Host Protected Area (HPA)  no
Accessible Max Address Config  yes  no 1953525168/1953525168


RELENG_14 from today

Re: WD Blue 510 SSD and strange write performance

[mike tancsa]

On 3/14/2024 2:56 PM, Bob Bishop wrote:
Probably (I don’t know for sure) these drives have a RAM write cache 
and really suck at committing from there to NVM.



ZFS doesnt seem to like it, or, possibly something else in addition 
going on.   I will start to get errors like this


(da4:mrsas0:0:23:0): READ(10). CDB: 28 00 3c 39 f2 60 00 00 08 00
(da4:mrsas0:0:23:0): CAM status: SCSI Status Error
(da4:mrsas0:0:23:0): SCSI status: OK
(da5:mrsas0:0:24:0): READ(10). CDB: 28 00 28 0b b5 38 00 00 f0 00
(da5:mrsas0:0:24:0): CAM status: SCSI Status Error
(da5:mrsas0:0:24:0): SCSI status: OK

when I have a heavy stream of zfs send | zfs recv going on.  Not sure if 
its possible to work around this or its some other bad interaction, or 
just a plain old bug in the firmware of these SSDs


    ---Mike

Re: WD Blue 510 SSD and strange write performance

[mike tancsa]

On 3/14/2024 3:48 PM, Frank Leonhardt wrote:

"CAM status: SCSI Status Error" suggests to me that the drive was just too busy 
when asked. I'm not saying it's nothing to worry about, but neither am I saying it is.


Given enough of them it does cause checksum errors on the test pool 
unfortunately.  Could a buggy TRIM play a role here too ? I noticed a 
commit the other day for a Segate SSD that had a broken NCQ TRIM. Could 
these units suffer from that ?

https://cgit.freebsd.org/src/commit/?h=stable/14&id=47fff7407c22c2c4b36b4f9f27ddfa70bb8f3fee

Is there a way to turn that off via camcontrol ? Or perhaps instrument 
some other settings ?  I am not wedded to this hardware, but it would be 
good to know if they can be made workable without too much effort.


kern.cam.da.2.delete_max: 17179607040
kern.cam.da.2.delete_method: ATA_TRIM
kern.cam.da.6.delete_max: 17179607040
kern.cam.da.6.delete_method: ATA_TRIM
kern.cam.da.0.delete_max: 17179607040
kern.cam.da.0.delete_method: ATA_TRIM
kern.cam.da.8.delete_max: 17179607040
kern.cam.da.8.delete_method: ATA_TRIM
kern.cam.da.3.delete_max: 17179607040
kern.cam.da.3.delete_method: ATA_TRIM
kern.cam.da.7.delete_max: 17179607040
kern.cam.da.7.delete_method: ATA_TRIM
kern.cam.da.5.delete_max: 17179607040
kern.cam.da.5.delete_method: ATA_TRIM
kern.cam.da.4.delete_max: 17179607040
kern.cam.da.4.delete_method: ATA_TRIM
kern.cam.da.1.delete_max: 17179607040
kern.cam.da.1.delete_method: ATA_TRIM
kern.cam.ada.0.delete_method: DSM_TRIM


 # camcontrol iden da3
pass3:  ACS-4 ATA SATA 3.x device
pass3: 600.000MB/s transfers, Command Queueing Enabled

protocol  ACS-4 ATA SATA 3.x
device model  WD Blue SA510 2.5 1000GB
firmware revision 52046100
serial number 23261Y800771
WWN   5001b448bf6521a5
additional product id
cylinders 16383
heads 16
sectors/track 63
sector size   logical 512, physical 512, offset 0
LBA supported 268435455 sectors
LBA48 supported   1953525168 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA6
media RPM non-rotating
Zoned-Device Commands no

Feature  Support  Enabled   Value Vendor
read ahead yes  yes
write cache    yes  yes
flush cache    yes  yes
Native Command Queuing (NCQ)   yes  32 tags
NCQ Priority Information   no
NCQ Non-Data Command   no
NCQ Streaming  no
Receive & Send FPDMA Queued    no
NCQ Autosense  no
SMART  yes  yes
security   yes  no
power management   yes  yes
microcode download yes  yes
advanced power management  yes  no  0/0x00
automatic acoustic management  no   no
media status notification  no   no
power-up in Standby    no   no
write-read-verify  no   no
unload no   no
general purpose logging    yes  yes
free-fall  no   no
sense data reporting   no   no
extended power conditions  no   no
device statistics notification no   no
Data Set Management (DSM/TRIM) yes
DSM - max 512byte blocks   yes  8
DSM - deterministic read   yes  any value
Trusted Computing  no
encrypts all user data no
Sanitize   yes  block,
Sanitize - commands allowed    yes
Sanitize - antifreeze lock yes
Host Protected Area (HPA)  no
Accessible Max Address Config  yes  no 1953525168/1953525168

Re: WD Blue 510 SSD and strange write performance

[mike tancsa]

On 3/14/2024 3:56 PM, mike tancsa wrote:

On 3/14/2024 3:48 PM, Frank Leonhardt wrote:
"CAM status: SCSI Status Error" suggests to me that the drive was 
just too busy when asked. I'm not saying it's nothing to worry about, 
but neither am I saying it is.


Given enough of them it does cause checksum errors on the test pool 
unfortunately.  Could a buggy TRIM play a role here too ? I noticed a 
commit the other day for a Segate SSD that had a broken NCQ TRIM. 
Could these units suffer from that ?
https://cgit.freebsd.org/src/commit/?h=stable/14&id=47fff7407c22c2c4b36b4f9f27ddfa70bb8f3fee 



Is there a way to turn that off via camcontrol ? Or perhaps instrument 
some other settings ?  I am not wedded to this hardware, but it would 
be good to know if they can be made workable without too much effort.


On another test box with an MPR controller and same WD drives, a few 
more messages after the zfs send is about 50% done on a dataset thats 
about 1TB but compressed to about 260G. Some 29 million files. But with 
Samsungs, reliably no issue :(



(da6:mpr0:0:16:0): WRITE(10). CDB: 2a 00 48 1e 9b 90 00 00 80 00
mpr0: Controller reported scsi ioc terminated tgt 16 SMID 897 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 16 SMID 1358 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 16 SMID 1742 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 16 SMID 1187 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 16 SMID 1006 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 16 SMID 758 loginfo 
31110f00

(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): WRITE(10). CDB: 2a 00 48 1e 9c 10 00 00 b8 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): WRITE(10). CDB: 2a 00 46 93 47 18 00 00 08 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): READ(10). CDB: 28 00 1c c7 dc 40 00 01 00 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): READ(10). CDB: 28 00 1c c7 d9 30 00 00 f8 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): WRITE(10). CDB: 2a 00 46 93 47 10 00 00 08 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): READ(10). CDB: 28 00 1c c7 d8 30 00 01 00 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): WRITE(10). CDB: 2a 00 49 55 29 20 00 00 08 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): WRITE(10). CDB: 2a 00 48 1e 9b 90 00 00 80 00
(da6:mpr0:0:16:0): CAM status: SCSI Status Error
(da6:mpr0:0:16:0): SCSI status: Check Condition
(da6:mpr0:0:16:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, 
or bus device reset occurred)

(da6:mpr0:0:16:0): Retrying command (per sense data)
mpr0: Controller reported scsi ioc terminated tgt 13 SMID 1023 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 13 SMID 297 loginfo 
31110f00

(da3:mpr0:0:13:0): WRITE(10). CDB: 2a 00 4c 49 50 18 00 00 a0 00
mpr0: Controller reported scsi ioc terminated tgt 13 SMID 1999 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 13 SMID 280 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 13 SMID 1970 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 13 SMID 859 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 13 SMID 1652 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 13 SMID 613 loginfo 
31110f00

(da3:mpr0:0:13:0): CAM status: CCB request completed with an error
(da3:mpr0:0:13:0): Retrying command, 3 more tries remain
(da3:mpr0:0:13:0): WRITE(10). CDB: 2a 00 4c 49 4e a8 00 01 00 00
(da3:mpr0:0:13:0): CAM status: CCB request completed with an error
(da3:mpr0:0:13:0): Retrying command, 3 more tries remain
(da3:mpr0:0:13:0): WRITE(10). CDB: 2a 00 4c 49 4f a8 00 00 70 00
(da3:mpr0:0:13:0): CAM status: CCB request completed with an error
(da3:mpr0:0:13:0): Retrying command, 3 more tries remain
(da3:mpr0:0:13:0): WRITE(10). CDB: 2a 00 4c bc 65 30 00 01 08 00
(da3:mpr0:0:13:0): CAM status: CCB request completed with an error
(da3:mpr0:0:13:0): Retrying command, 3 more tries remain
(da3:mpr0:0:13:0): READ(10). CDB: 28 00 2c 99 68 80 00 01 00 00
(da3:mpr0:0:13:0): CAM status: CCB request completed with an error
(da3:mpr0:0:13:0): Retrying command, 3 more tries remain
(da

Re: WD Blue 510 SSD and strange write performance

[mike tancsa]

On 3/14/2024 4:58 PM, Frank Leonhardt wrote:

Sorry - not that deeply into modern SSD (never written a driver for one), but 
based on my understanding your TRIM theory makes sense to me. I'd try turning 
it off. It does seem to be an ongoing source of snafus.

I did use WD Blue SSDs but I suspect they vary quite a bit. I've had rather too 
many early failures. I wouldn't use them in production but okay for Windoze. We 
all know deep down there's a reason the enterprise SSDs cost what they do :-)

I'll keep thinking


Thanks for the input. I think these drives are just kinda broken :( I 
noticed we had the 2TB versions of this line, but they seem rather 
different and I am not able to trigger the errors with them 
thankfully.   Even stranger, I have a 1TB version of this drive I bought 
from a while back that has the same firmware, but does NOT have this 
issue. However, the output of the identifier is slightly different.  Who 
knows, it could be some component WD uses that *should be* the same but 
is not and is causing some subtle pathology.



I tried turning off NCQ on the controller and it didnt seem to make a 
difference. Then I turned off autotrim and did a manual trim of the 
pool, then did the tests and same sorts of errors.  I think I am just 
gonna cut my losses with these disks :(   Even if I figured out some 
work around at this point, I would not deploy them into production.  I 
doubt I will be able to get anywhere with WD. Farewell my 400 bucks :(


(da6:mpr0:0:16:0): READ(10). CDB: 28 00 6d e0 ae 28 00 00 08 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): WRITE(10). CDB: 2a 00 0c cb 3f 00 00 00 e8 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): READ(10). CDB: 28 00 6d e0 ad 28 00 01 00 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): READ(10). CDB: 28 00 6d e0 ac 28 00 00 f8 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): WRITE(10). CDB: 2a 00 40 07 df 88 00 01 00 00
(da6:mpr0:0:16:0): CAM status: CCB request completed with an error
(da6:mpr0:0:16:0): Retrying command, 3 more tries remain
(da6:mpr0:0:16:0): WRITE(10). CDB: 2a 00 3f 48 72 08 00 01 00 00
(da6:mpr0:0:16:0): CAM status: SCSI Status Error
(da6:mpr0:0:16:0): SCSI status: Check Condition
(da6:mpr0:0:16:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, 
or bus device reset occurred)

(da6:mpr0:0:16:0): Retrying command (per sense data)
mpr0: Controller reported scsi ioc terminated tgt 15 SMID 2036 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 15 SMID 637 loginfo 
31110f00

(da5:mpr0:0:15:0): WRITE(10). CDB: 2a 00 41 98 42 00 00 01 00 00
mpr0: Controller reported scsi ioc terminated tgt 15 SMID 1242 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 15 SMID 979 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 15 SMID 1243 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 15 SMID 2091 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 15 SMID 1612 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 15 SMID 2093 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 15 SMID 152 loginfo 
31110f00
mpr0: Controller reported scsi ioc terminated tgt 15 SMID 2132 loginfo 
31110f00

(da5:mpr0:0:15:0): CAM status: CCB request completed with an error
(da5:mpr0:0:15:0): Retrying command, 3 more tries remain
(da5:mpr0:0:15:0): WRITE(10). CDB: 2a 00 43 17 dc 88 00 01 00 00
(da5:mpr0:0:15:0): CAM status: CCB request completed with an error
(da5:mpr0:0:15:0): Retrying command, 3 more tries remain
(da5:mpr0:0:15:0): WRITE(10). CDB: 2a 00 41 98 43 00 00 00 50 00
(da5:mpr0:0:15:0): CAM status: CCB request completed with an error
(da5:mpr0:0:15:0): Retrying command, 3 more tries remain
(da5:mpr0:0:15:0): WRITE(10). CDB: 2a 00 0c d4 f6 80 00 00 68 00
(da5:mpr0:0:15:0): CAM status: CCB request completed with an error
(da5:mpr0:0:15:0): Retrying command, 3 more tries remain
(da5:mpr0:0:15:0): WRITE(10). CDB: 2a 00 0c d4 f5 80 00 01 00 00
(da5:mpr0:0:15:0): CAM status: CCB request completed with an error
(da5:mpr0:0:15:0): Retrying command, 3 more tries remain
(da5:mpr0:0:15:0): READ(10). CDB: 28 00 05 dc 12 28 00 00 f8 00
(da5:mpr0:0:15:0): CAM status: CCB request completed with an error
(da5:mpr0:0:15:0): Retrying command, 3 more tries remain
(da5:mpr0:0:15:0): READ(10). CDB: 28 00 05 dc 0f b0 00 00 88 00
(da5:mpr0:0:15:0): CAM status: CCB request completed with an error
(da5:mpr0:0:15:0): Retrying command, 3 more tries remain
(da5:mpr0:0:15:0): WRITE(10). CDB: 2a 00 02 96 7e 80 00 00 10 00
(da5:mpr0:0:15:0): CAM status: CCB request completed 

Re: WD Blue 510 SSD and strange write performance

[mike tancsa]

On 3/15/2024 3:09 PM, Karl Denninger wrote:
I've got both the Kingston and Micron versions of these in production 
use and have seen nothing like this at all; they get hit pretty hard 
too, including release building (both direct and cross-builds) and 
similar stuff.


What firmware are your devices running ? There are 2 out there I know 
of.  One one server I have running in prod from last November, it seems 
fine, but the firmware is older.



=== START OF INFORMATION SECTION ===
Device Model: WD Blue SA510 2.5 1000GB
Serial Number:    23020L807259
LU WWN Device Id: 5 001b44 8b2463dcb
Firmware Version: 52020100

Device Model: WD Blue SA510 2.5 1000GB
Serial Number:    23261Y804499
LU WWN Device Id: 5 001b44 8bf6bb6c1
Firmware Version: 52046100

Re: WD Blue 510 SSD and strange write performance

[mike tancsa]

On 3/17/2024 4:32 AM, Andrea Venturoli wrote:

On 3/15/24 19:17, mike tancsa wrote:

(da5:mpr0:0:15:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, 
reset, or bus device reset occurred)


Hello.
I know I'm probably blaming the wrong component, but is your PSU up to 
the task?
How many drives do you have? Are they power-hungrier than the others 
you tried (Samsung ???)?

Do you have a spare PSU to test/add?

Probably this is not the cause... still, before you bit farewell to 
400 bucks...




hehe, thanks Andrea :)  I too dont want to be out the money. Power 
supply for sure is a good thing to check. In this case, the main server 
chassis is sized with a couple of redundant 1000W power supplies that 
should handle 12 full HDDs. Pretty sure in this case 6 SSDs should not 
stress it beyond the point. But I had 2 other test boxes on the bench 
and the one common variable seems to be the WDs.


I feel like this is a sunk cost I am pushing myself into, but I did do 
some more testing.  My co-worker came across this post which was 
interesting.


https://forum.hddguru.com/viewtopic.php?f=10&t=43284

The very last entry says

"For WD BLUE SA 510 there are some problems with this type of SSD. This 
YODA model

To fix the SSD if it is still recognized, use the firmware update tools.
And then do a secure erase or full wipe of the SSD. After this it will 
work well. I can give you a link to this utility if it necessary. Also 
ossible download it from manufacture FTP.
If it is not recognized by the computer or is identified as a SSD 
device, there only one way, use production tools with new firmware to 
begin the production process by testing the controller and NAND chip and 
forming a translator. The SSD will be like brand new.

"

After I did the erase, the tests worked for a good 5 cycles and 
performance was MUCH smoother and consistent. But then the drives 
started to fail again.  So I really wonder if TRIM has something to do 
with it as my test is essentially writing a 250G data set with about 28 
million txt files, destroying the dataset and then copying it again.


I noticed these 2 commits for other drives. I wonder if the WD is having 
similar issues.


https://cgit.freebsd.org/src/commit/?h=stable/14&id=bf11fee6a5cf97102f87695185cadb63d5a2a7de
and
https://cgit.freebsd.org/src/commit/?h=stable/14&id=50aa22323424ccea00ef5d8f24e729a480cc77eb

I hope you dont mind bcc'ing you Andriy.  I noticed you only added the 
NCQ quirks for CAM ata and not for CAM scsi. I am running into odd 
issues with some WD drives and wondering if there is the same root 
limitation of these WD SA 510 drives like the Samsungs ? However, in my 
use of the Samsungs I have not been able to trigger these bugs so far.


    ---Mike

Re: WD Blue 510 SSD and strange write performance

[mike tancsa]

On 3/18/2024 4:59 AM, Christian Weisgerber wrote:

mike tancsa:


This might be more of a hardware question than anything, but I noticed the
drive is fairly fast on initial writes, but dramatically slows down over
time with a consistent write.
If I wait for 2min, it seems to be back to normal

Sounds like normal behavior for a drive that runs part of its flash
as a fast cache in SLC mode, the rest as much slower TLC/QLC memory.


I guess the question is, how do I work with such a drive so it doesnt 
get to the point where it causes errors.  Is there a quirk that can be 
set somehow ?


    ---Mike

Re: WD Blue 510 SSD and strange write performance (update)

[mike tancsa]

summary: WD Blue 510 SSDs when attached to the mpr controller seem to 
start throwing errors on random disks in the pools (see 
https://lists.freebsd.org/archives/freebsd-hardware/2024-March/000100.html 
for examples) after copying and destroying a zfs 200G dataset with many 
small files 3 or 4 times on a set of 4 disks in raidz1. Doing a hard 
trim -f da on the disks and recreating the pool allows me to do the 
tests 3 or 4 more times before hitting the errors again.  The same tests 
with the same disks attached to a sata controller doesnt show the 
errors. I also ran into the same problem with a similar LSI controller 
but using the mrsas controller/driver ().  
It seems to be trim related?  Using samsung SSDs on the mpr controller 
does not seem to show the issue.



OK, some updates.  I took the same 4 disks off the mpr controller and 
put them off the motherboard and the problem seems to disappear.  If it 
is still related to trim, I notice that on the mpr controller the trim 
method is ATA_TRIM and when attached to the motherboard SATA its 
DSM_TRIM.  Not sure if there is any difference there ? Or its some other 
problem.  PR time for the mpr driver ?


kern.cam.ada.1.trim_ticks: 0
kern.cam.ada.1.trim_goal: 0
kern.cam.ada.1.flags: 
0x1be3bde

kern.cam.ada.1.trim_lbas: 6356918872
kern.cam.ada.1.trim_ranges: 171552
kern.cam.ada.1.trim_count: 84205
kern.cam.ada.1.delete_method: DSM_TRIM

kern.cam.da.6.trim_ticks: 0
kern.cam.da.6.trim_goal: 0
kern.cam.da.6.sort_io_queue: 0
kern.cam.da.6.unmapped_io: 1
kern.cam.da.6.rotating: 0
kern.cam.da.6.flags: 
0x10ef40

kern.cam.da.6.p_type: 0
kern.cam.da.6.error_inject: 0
kern.cam.da.6.max_seq_zones: 0
kern.cam.da.6.optimal_nonseq_zones: 0
kern.cam.da.6.optimal_seq_zones: 0
kern.cam.da.6.zone_support: None
kern.cam.da.6.zone_mode: Not Zoned
kern.cam.da.6.trim_lbas: 0
kern.cam.da.6.trim_ranges: 0
kern.cam.da.6.trim_count: 0
kern.cam.da.6.minimum_cmd_size: 6
kern.cam.da.6.delete_max: 17179607040
kern.cam.da.6.delete_method: ATA_TRIM

camcontrol iden doesnt show much difference really

 diff -bu wd.mpr wd.ata
--- wd.mpr  2024-03-21 08:27:02.995734000 -0400
+++ wd.ata  2024-03-21 08:21:42.310055000 -0400
@@ -1,5 +1,6 @@
+# camcontrol ide ada1
 pass6:  ACS-4 ATA SATA 3.x device
-pass6: 600.000MB/s transfers, Command Queueing Enabled
+pass6: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)

 protocol  ACS-4 ATA SATA 3.x
 device model  WD Blue SA510 2.5 1000GB


Controller is

 mprutil show adapter
mpr0 Adapter:
   Board Name: INSPUR 3008IT
   Board Assembly: INSPUR
    Chip Name: LSISAS3008
    Chip Revision: ALL
    BIOS Revision: 18.00.00.00
Firmware Revision: 16.00.12.00
  Integrated RAID: no
 SATA NCQ: ENABLED
 PCIe Width/Speed: x8 (8.0 GB/sec)
    IOC Speed: Full
  Temperature: 51 C

PhyNum  CtlrHandle  DevHandle  Disabled  Speed   Min    Max Device
0   0001    0009   N 6.0 3.0    12 SAS 
Initiator
1   0001    0009   N 6.0 3.0    12 SAS 
Initiator
2   0001    0009   N 6.0 3.0    12 SAS 
Initiator
3   0001    0009   N 6.0 3.0    12 SAS 
Initiator
4  N 3.0    12 SAS 
Initiator
5  N 3.0    12 SAS 
Initiator
6  N 3.0    12 SAS 
Initiator
7  N 3.0    12 SAS 
Initiator

Re: WD Blue 510 SSD and strange write performance (update II)

[mike tancsa]

On 3/21/2024 8:46 AM, mike tancsa wrote:


summary: WD Blue 510 SSDs when attached to the mpr controller seem to 
start throwing errors on random disks in the pools (see 
https://lists.freebsd.org/archives/freebsd-hardware/2024-March/000100.html 
for examples) after copying and destroying a zfs 200G dataset with 
many small files 3 or 4 times on a set of 4 disks in raidz1. Doing a 
hard trim -f da on the disks and recreating the pool allows me to do 
the tests 3 or 4 more times before hitting the errors again.  The same 
tests with the same disks attached to a sata controller doesnt show 
the errors. I also ran into the same problem with a similar LSI 
controller but using the mrsas controller/driver (Controller>).  It seems to be trim related?  Using samsung SSDs on the 
mpr controller does not seem to show the issue.


I decided to try the same tests on the exact same hardware but booting 
truenas scale (the linux variant) to see if the problem persists.  If I 
do a manual trim between zfs send | zfs recv, zfs destroy, the 
performance seems fairly consistent and there are no crashes/resets of 
the drives in the pool on linux (6.6.20-production+truenas).


Not a linux person so hard to say if there are some quirks for these 
disks on linux.


root@truenas[/var/log]# hdparm -I /dev/sda | grep -i tri
   *    Data Set Management TRIM supported (limit 8 blocks)
   *    Deterministic read data after TRIM
root@truenas[/var/log]#

If I dont do the manual TRIM between send|recv (ie zpool trim -w pool), 
I get the same pattern as when I do a manual trim -f /dev/da[x] on each 
disk one by one on FreeBSD.  I get 3 full speed loops and after that, 
super slow until a proper trim is done. On FreeBSD I do this to the 
raidz1 pool by doing a trim -f /dev/da[1-4] one by one and resilver.


So it does seem to point to TRIM via zfs (be that manual or autotrim) 
somehow broken with this drive on FreeBSD via the mpr driver and via the 
ATA driver.


given the output of hdparm on linux and trim being limited to 8 blocks, 
anyone know if there is a quirk I can try on FreeBSD to maybe get TRIM 
working for these SSDs ?


details captured in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277992

the attachment in the PR, 
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250268 has a PNG 
showing the performance when the TRIM is not done.


    ---Mike





OK, some updates.  I took the same 4 disks off the mpr controller and 
put them off the motherboard and the problem seems to disappear.  If 
it is still related to trim, I notice that on the mpr controller the 
trim method is ATA_TRIM and when attached to the motherboard SATA its 
DSM_TRIM.  Not sure if there is any difference there ? Or its some 
other problem.  PR time for the mpr driver ?


kern.cam.ada.1.trim_ticks: 0
kern.cam.ada.1.trim_goal: 0
kern.cam.ada.1.flags: 
0x1be3bde

kern.cam.ada.1.trim_lbas: 6356918872
kern.cam.ada.1.trim_ranges: 171552
kern.cam.ada.1.trim_count: 84205
kern.cam.ada.1.delete_method: DSM_TRIM

kern.cam.da.6.trim_ticks: 0
kern.cam.da.6.trim_goal: 0
kern.cam.da.6.sort_io_queue: 0
kern.cam.da.6.unmapped_io: 1
kern.cam.da.6.rotating: 0
kern.cam.da.6.flags: 
0x10ef40

kern.cam.da.6.p_type: 0
kern.cam.da.6.error_inject: 0
kern.cam.da.6.max_seq_zones: 0
kern.cam.da.6.optimal_nonseq_zones: 0
kern.cam.da.6.optimal_seq_zones: 0
kern.cam.da.6.zone_support: None
kern.cam.da.6.zone_mode: Not Zoned
kern.cam.da.6.trim_lbas: 0
kern.cam.da.6.trim_ranges: 0
kern.cam.da.6.trim_count: 0
kern.cam.da.6.minimum_cmd_size: 6
kern.cam.da.6.delete_max: 17179607040
kern.cam.da.6.delete_method: ATA_TRIM

camcontrol iden doesnt show much difference really

 diff -bu wd.mpr wd.ata
--- wd.mpr  2024-03-21 08:27:02.995734000 -0400
+++ wd.ata  2024-03-21 08:21:42.310055000 -0400
@@ -1,5 +1,6 @@
+# camcontrol ide ada1
 pass6:  ACS-4 ATA SATA 3.x device
-pass6: 600.000MB/s transfers, Command Queueing Enabled
+pass6: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)

 protocol  ACS-4 ATA SATA 3.x
 device model  WD Blue SA510 2.5 1000GB


Controller is

 mprutil show adapter
mpr0 Adapter:
   Board Name: INSPUR 3008IT
   Board Assembly: INSPUR
    Chip Name: LSISAS3008
    Chip Revision: ALL
    BIOS Revision: 18.00.00.00
Firmware Revision: 16.00.12.00
  Integrated RAID: no
 SATA NCQ: ENABLED
 PCIe Width/Speed: x8 (8.0 GB/sec)
    IOC Speed: Full
  Temperature: 51 C

PhyNum  CtlrHandle  DevHandle  Disabled  Speed   Min    Max Device
0   0001    0009   N 6.0 3.0    12 SAS 
Initiator
1   0001    0009   N 6.0 3.0    12 SAS 
Initiator
2   0001    0009   N 6.0 3.0    12 SAS 
Initiator
3   0001    0009   N 6.0 3.0    12 SAS 
Initiator
4  N 3.0    12 SAS 
Initiator
5  N 3.0    12 SAS 
Initiato