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

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

[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

[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=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=bf11fee6a5cf97102f87695185cadb63d5a2a7de
and
https://cgit.freebsd.org/src/commit/?h=stable/14=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/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/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/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=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
(da3:mpr0:0:13:0)

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=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 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

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: 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"

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: 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: 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: 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=revisionrevision=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

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  WDC WD40EFRX-68W 0A80 
serial=WD-WCC4E0911515 SATA E1:S1
 9 ( 3726G) JBOD  WDC WD40EFRX-68W 0A82 
serial=WD-WCC4E9Y80F79 SATA E1:S0
10 ( 3726G) JBOD  WDC WD40EFRX-68W 0A80 
serial=WD-WCC4E0916074 SATA E1:S3
11 ( 3726G) JBOD  WDC WD40EFRX-68W 0A80 
serial=WD-WCC4E0893433 SATA E1:S2
13 ( 3726G) JBOD  WDC WD40EFRX-68W 0A82 
serial=WD-WCC4E9Y80J8A SATA E1:S5


mfi0: Drake Skinny 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: SCSI Passthrough Bus 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: 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

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: 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: 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: 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: ACPI PCI bus on pcib5
siis0: SiI3124 SATA controller port 0x3000-0x300f mem
0xb4408000-0xb440807f,0xb440-0xb4407fff irq 19 at device 0.0 on pci5
siisch0: SIIS channel at channel 0 on siis0
siisch1: SIIS channel at channel 1 on siis0
siisch2: SIIS channel at channel 2 on siis0
siisch3: SIIS channel 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: 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: 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: Port Multiplier 38261095 1706 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
WDC WD1002FAEX-00Z3A0 05.01D05   at scbus0 target 0 lun 0 (ada0,pass1)
WDC WD1002FAEX-00Z3A0 05.01D05   at scbus0 target 1 lun 0 (ada1,pass2)
WDC WD1502FAEX-007BA0 05.01D05   at scbus0 target 2 lun 0 (ada3,pass4)
WDC WD2002FAEX-007BA0 05.01D05   at scbus0 target 3 lun 0 (ada4,pass5)
WDC WD2002FAEX-007BA0 05.01D05   at scbus0 target 4 lun 0 (ada2,pass3)
Port Multiplier 37261095 1706at scbus0 target 15 lun 0 (pmp0,pass0)
WDC WD5002AALX-00J37A0 15.01H15  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

Rocket Raid 622 in AHCI mode

[Mike Tancsa]

, 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 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

Re: Supermicro X7SBE with Chenbro 16 bay 4U case

[Mike Tancsa]

  | 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: 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: 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: 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/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: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet 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: MII bus on re0
rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface 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 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: ACPI PCI bus 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: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet 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: ACPI PCI bus 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: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet 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: MII bus on re0
ukphy0: Generic IEEE 802.3u media interface 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

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: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet 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: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet 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: MII bus on re0
rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface 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

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: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet 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: 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: Intel(R) PRO/1000 Network Connection 7.2.3 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

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/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.43r2=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: 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 sean...@yahoo-inc.com 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 m...@sentex.net 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_snd))
em_start_locked(ifp, txr);
  #endif
 -   em_txeof(txr);
E1000_WRITE_REG(adapter-hw, E1000_IMS, txr-ims);
EM_TX_UNLOCK(txr);
  }
 @@ -3730,17 +3724,17 @@
txr-queue_status = EM_QUEUE_HUNG;

 /*
 - * If we have enough room, clear IFF_DRV_OACTIVE

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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC

em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC

em0: Intel(R) PRO/1000 Network Connection 7.1.9-test 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: Intel(R) PRO/1000 Network Connection 7.1.9-test 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]

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 m...@sentex.net 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_snd))
em_start_locked(ifp, txr);
  #endif
 -   em_txeof(txr);
E1000_WRITE_REG(adapter-hw, E1000_IMS, txr-ims);
EM_TX_UNLOCK(txr);
  }
 @@ -3730,17 +3724,17 @@
txr-queue_status = EM_QUEUE_HUNG;

 /*
 - * If we have enough room, clear IFF_DRV_OACTIVE
 + * If we have a minimum free, clear IFF_DRV_OACTIVE
  * to tell the stack that it is OK to send packets.
  */
 -if (txr-tx_avail  EM_TX_CLEANUP_THRESHOLD) {
 +if (txr-tx_avail  EM_MAX_SCATTER)
 ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
 -   /* Disable watchdog if all clean */
 -if (txr-tx_avail == adapter-num_tx_desc) {
 -   txr-queue_status = EM_QUEUE_IDLE;
 -   return (FALSE);
 -   }
 -}
 +
 +   /* Disable watchdog if all clean */
 +   if (txr-tx_avail == adapter-num_tx_desc) {
 +   txr-queue_status = EM_QUEUE_IDLE;
 +   return (FALSE);
 +   }

return (TRUE);
  }
 @@ -5064,8 +5058,8 @@
char namebuf[QUEUE_NAME_LEN

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 sean...@yahoo-inc.com 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
 1500

 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4
 ether 00:15:17:ed:68:a4

 vs


 em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
 1500


 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC
 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 options=2198VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC

 ... 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 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 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_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 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4
 ether 00:15:17:ed:68:a4
 
 vs
 
 
 em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 
 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC
 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=2198VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC

... 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 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC
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=3PERFORMNUD,ACCEPT_RTADV
media: Ethernet autoselect (1000baseT full-duplex)
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 

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: Intel(R) PRO/1000 Network Connection 7.1.8 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 jfvo...@gmail.com 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 m...@sentex.net 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: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

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=detailaid=2908463group_id=42302atid=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=detailaid=2908463group_id=42302atid=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: Intel(R) PRO/1000 Network Connection 7.1.7 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

ichwd device ID for Intel H55 Express Watchdog

[Mike Tancsa]

-0xb on isa0
ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
ata0: [ITHREAD]
ata1 at port 0x170-0x177,0x376 irq 15 on isa0
ata1: [ITHREAD]
Timecounters tick every 1.000 msec
IPsec: Initialized Security Association Processing.
Waiting 5 seconds for SCSI devices to settle
usbus0: 480Mbps High Speed USB v2.0
usbus1: 480Mbps High Speed USB v2.0
ugen0.1: Intel at usbus0
uhub0: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0
ugen1.1: Intel at usbus1
uhub1: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus1
uhub0: 3 ports with 3 removable, self powered
uhub1: 3 ports with 3 removable, self powered
ugen0.2: vendor 0x8087 at usbus0
uhub2: vendor 0x8087 product 0x0020, class 9/0, rev 2.00/0.00, addr 
2 on usbus0

ugen1.2: vendor 0x8087 at usbus1
uhub3: vendor 0x8087 product 0x0020, class 9/0, rev 2.00/0.00, addr 
2 on usbus1

uhub2: 6 ports with 6 removable, self powered
uhub3: 8 ports with 8 removable, self powered
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: ST380811AS 3.AAE ATA-7 SATA 1.x device
ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO size 8192bytes)
ada0: Command Queueing enabled
ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C)
SMP: AP CPU #1 Launched!
Trying to mount root from nfs:
NFS ROOT: 10.255.255.1:/usr/home/pxe9/
ichwd0: Intel H55 Express watchdog timer 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: 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=0x88a93dFPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX
  AMD Features=0xc040MMX+,3DNow!+,3DNow!
real memory  = 268435456 (256 MB)
avail memory = 253202432 (241 MB)
pnpbios: Bad PnP BIOS data checksum
K6-family MTRR support enabled (2 registers)
cryptosoft0: software crypto on motherboard
pcib0: Host to PCI bridge pcibus 0 on motherboard
pci0: PCI bus on pcib0
...
u3gstub0: at uhub0 port 2 (addr 2) disconnected
u3gstub0: detached

ucom0: Sierra Wireless, Incorporated AirCard, class 0/0, rev 
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]

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: Sierra Wireless USB MMC Storage, class 0/0, rev 1.10/0.00, 
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: crypto device
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 SanDisk SDCFH2-002G HDX 4.32 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: AirCard TRU-Install 2.31 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 

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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
  AMD Features=0x20100800SYSCALL,NX,LM
  AMD Features2=0x1LAHF
  Cores per package: 2
usable memory = 8577662976 (8180 MB)
avail memory  = 8298295296 (7913 MB)
ACPI APIC Table: INTEL  S3000AH
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 5
ioapic0 Version 2.0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: INTEL S3000AH 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: ACPI CPU on acpi0
est0: Enhanced SpeedStep Frequency Control on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 92a092a0600092a
device_attach: est0 attach returned 6
p4tcc0: CPU Frequency Thermal Control on cpu0
cpu1: ACPI CPU on acpi0
est1: Enhanced SpeedStep Frequency Control on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 92a092a0600092a
device_attach: est1 attach returned 6
p4tcc1: CPU Frequency Thermal Control on cpu1
acpi_button0: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: ACPI PCI-PCI bridge at device 28.0 on pci0
pci1: ACPI PCI bus on pcib1
pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
pci2: ACPI PCI bus on pcib2
arcmsr0: Areca SATA Host Adapter RAID Controller
 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: PCI-PCI bridge at device 0.2 on pci1
pci3: PCI bus on pcib3
pcib4: ACPI PCI-PCI bridge at device 28.4 on pci0
pci4: ACPI PCI bus on pcib4
pcib5: ACPI PCI-PCI bridge at device 28.5 on pci0
pci5: ACPI PCI bus on pcib5
em0: Intel(R) PRO/1000 Network Connection Version - 6.7.3 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: simple comms, UART at device 0.3 (no driver attached)
pci5: serial bus at device 0.4 (no driver attached)
pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0
pci6: ACPI PCI bus on pcib6
vgapci0: VGA-compatible display port 0x1000-0x10ff mem 
0xe000-0xe7ff,0xe844-0xe844 irq 18 at device 4.0 on pci6
em1: Intel(R) PRO/1000 Network Connection Version - 6.7.3 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: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH7 UDMA100 controller port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3030-0x303f irq 18 at device 31.1 on pci0

ata0: ATA channel 0 on atapci0
ata0: [ITHREAD]
ata1: ATA channel 1 on atapci0
ata1: [ITHREAD]
atapci1: Intel ICH7 SATA300 controller 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: ATA channel 0 on atapci1
ata2: [ITHREAD]
ata3: ATA channel 1 on atapci1
ata3: [ITHREAD]
pci0: serial bus, SMBus at device 31.3 (no driver attached)
fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0
fdc0: [FILTER]
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard 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 

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: 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: LSILogic SAS/SATA Adapter 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: LSILOGIC Logical Volume 3000 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: LSILogic SAS/SATA Adapter 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: LSILOGIC Logical Volume 3000 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]

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: LSILogic SAS/SATA Adapter 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: LSILOGIC Logical Volume 3000 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: 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]

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]

nVidia MCP51 NIC

[Mike Tancsa]

-0x177,0x376,0xf400-0xf40f at device 13.0 on pci0

ata0: ATA channel 0 on atapci0
ata1: ATA channel 1 on atapci0
atapci1: nVidia nForce MCP51 SATA300 controller port 
0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xe000-0xe00f mem 
0xfe02d000-0xfe02dfff irq 23 at device 14.0 on pci0

ata2: ATA channel 0 on atapci1
ata3: ATA channel 1 on atapci1
pcib3: ACPI PCI-PCI bridge at device 16.0 on pci0
pci3: ACPI PCI bus on pcib3
rl0: RealTek 8139 10/100BaseTX port 0xac00-0xacff mem 
0xfddff000-0xfddff0ff irq 17 at device 7.0 on pci3

miibus0: MII bus on rl0
rlphy0: RealTek internal media interface on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: Ethernet address: 00:50:fc:32:52:a4
pci0: simple comms, generic modem at device 16.3 (no driver attached)
nve0: NVIDIA nForce MCP51 Networking Adapter port 0xd400-0xd407 mem 
0xfe02b000-0xfe02bfff irq 21 at device 20.0 on pci0

nve0: Ethernet address 00:16:ec:9b:c3:97
miibus1: MII bus on nve0
ukphy0: Generic IEEE 802.3u media interface on miibus1
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
nve0: Ethernet address: 00:16:ec:9b:c3:97
acpi_tz0: Thermal Zone on acpi0
fdc0: floppy drive controller 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: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
pmtimer0 on isa0
orm0: ISA Option ROMs at iomem 0xd-0xd3fff,0xd4000-0xd57ff on isa0
ppc0: parallel port not found.
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounters tick every 1.000 msec
ad0: 76319MB Seagate ST3802110A 3.AAJ 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: 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]

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: 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: SMART threshold exceeded

[Mike Tancsa]

 error   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]