I just added two new 1TB drives, and after clearing and adding them to the array I noticed that my user share allocation, split level, etc. were all erased. I tried to re-apply my settings, but nothing would stick in the Shares page. So I restarted the server hoping that it would correct it.

 

After the restart, the main page shows that the two drives are still new and need to be cleared. I did not know what to do so I have started the clearing process again.

 

I am using the P5B VM-DO motherboard and one of the drives is connect to the 7th internal port near the rear I/O panel, and the other is connected to the eSATA port using a eSATA to SATA cable. I believe these ports are assigned as ACHI in the bios. Could this be causing it.

 

Any ideas on what I should do? Will I be stuck in a loop?

After clearing and adding the drives again to the array, I still cannot apply user shares splitting and allocation properly. Also when I try to access the flash share, nothing is shown even after I have enabled to see all hidden and system files.

 

What should my next step be?

 

Edit: The flash share is exported with read/write permissions. Also, I am able to read and write to the new drives.

 

Edit2: I shutdown the server and restarted it, and once again the same drives appear as new drives.

The configuration file, showing the user-shares you defined, is stored on the flash drive.

 

If your flash drive is not writable, then your configuration will not be stored.

 

I would look at BIOS options for the USB Flash config.  (Legacy, 1.0, or something like that)

 

Until you can telnet into the unRaid server and then do an

ls  -lR  /boot

 

and see all your config files, then you will not be able to store a configuration. 

 

Joe L.

After I shutdown and did a restart the flash share began working again.

 

It appears that something during the clearing or adding process is screwing things up. I am going to run memtest on the system, since I had a problem with the memory a few weeks back.

 

Everything was working fine until I tried to add these two new drives.

I ran memtest and after 4 passes it did not report any problems.

 

Attached is my syslog after I first boot up.

 

Does anyone know what the BIOS setting for the Jmicron SATA controller should be for the Asus P5B VM-DO motherboard. I originally had it set to AHCI, but have now changed it to Basic. I will try to add the drives with this setting.

I have also applied the read performance tweak posted in this thread. Attached is my go script. Could this be causing it?

 

I am not going to add the drives again for the moment. Maybe someone will be able to tell me exactly what the cause is. Also, would I face a problem if I continue to clear and add the drives over and over?

I have the same MB.  Mine is set to "Basic".  That is the default and I have not changed it.  I am using the SATA port with a 750G drive withouth an problem.  I am not using the eSATA port.

 

I did not add drives as you are doing.  This drive was formatted when there was no parity drive assigned.  unRAID did a quick format.  I then built parity after I got all the drives added / assigned.

 

It does sound like you are having a problem with the USB stick.  There seem to be more problems with USB sticks than any other problem reported here.  Not sure why.  I wonder if USB sticks somehow "wear out" when they are kept in a powered state for a long time, even with little or no reading / writing going on.

 

Another user reported having a problem with certain of the SATA ports with higher capacity drives.  He needed to upgrade his BIOS.

 

(Unrelated) Where did you get the eSATA to SATA cable?  I was thinking of trying to use the eSATA port for an internal drive as well.

 

I have the same MB.  Mine is set to "Basic".  That is the default and I have not changed it.  I am using the SATA port with a 750G drive withouth an problem.  I am not using the eSATA port.

 

I did not add drives as you are doing.  This drive was formatted when there was no parity drive assigned.  unRAID did a quick format.  I then built parity after I got all the drives added / assigned.

 

It does sound like you are having a problem with the USB stick.  There seem to be more problems with USB sticks than any other problem reported here.  Not sure why.  I wonder if USB sticks somehow "wear out" when they are kept in a powered state for a long time, even with little or no reading / writing going on.

 

Another user reported having a problem with certain of the SATA ports with higher capacity drives.  He needed to upgrade his BIOS.

 

(Unrelated) Where did you get the eSATA to SATA cable?  I was thinking of trying to use the eSATA port for an internal drive as well.

 

 

I don't know if the USB is the cause, because after a reboot I am able to access it.

 

Here is the cable I bought.  PPA 3.28 ft. SATA to eSATA Cable Model 3848

I am using the CM Stacker, and I route the cable into the case through one of the PCI slot openings. It then connects to my backplane.

Hi all,

 

Yesterday I went ahead and added the drives again to the array. Attached is the tailed syslog, starting from when the clearing was almost complete. I then formatted and added the drives to the array.

 

It appears that there is indeed something wrong with the flash drive. Although I am not too sure since I have no idea if what is reported is normal.

 

Any feedback would be appreciated.

The series of messages describing errors when writing to the USB device are not normal. 

 

It appears as if your USB Flash drive is being "offlined" after a series of errors when attempting to access it fail.

 

You might see if your BIOS has a USB 1.0 mode, or Legacy mode and see if that helps.  It will boot slower, but maybe the errors will stop.

If not, try a different USB flash drive, or a different USB port on the motherboard.

 

Joe L.

These messages in your syslog are NOT normal:

Mar 23 20:13:06 MediaServer1 kernel: [26887.069066] usb 2-4: device not accepting address 2, error -110

Mar 23 20:13:06 MediaServer1 kernel: [26887.069086] usb 2-4: USB disconnect, address 2

Mar 23 20:13:06 MediaServer1 kernel: [26887.069238] sd 0:0:0:0: scsi: Device offlined - not ready after error recovery

Mar 23 20:13:06 MediaServer1 kernel: [26887.070086] sd 0:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00

Mar 23 20:13:06 MediaServer1 kernel: [26887.070090] end_request: I/O error, dev sdg, sector 67

Mar 23 20:13:06 MediaServer1 kernel: [26887.070115] sd 0:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00

Mar 23 20:13:06 MediaServer1 kernel: [26887.070118] end_request: I/O error, dev sdg, sector 51207

Mar 23 20:13:06 MediaServer1 kernel: [26887.070125] FAT: FAT read failed (blocknr 4)

Mar 23 20:13:06 MediaServer1 kernel: [26887.070144] FAT: FAT read failed (blocknr 4)

Mar 23 20:13:06 MediaServer1 kernel: [26887.070150] write_file: write error 5

Mar 23 20:13:06 MediaServer1 kernel: [26887.070153] md: could not write superblock from /boot/config/super.dat

Mar 23 20:13:06 MediaServer1 kernel: [26887.070155] md: recovery thread has nothing to resync

Mar 23 20:13:06 MediaServer1 kernel: [26887.071161] FAT: Directory bread(block 648) failed

Mar 23 20:13:06 MediaServer1 kernel: [26887.071203] FAT: Directory bread(block 649) failed

Mar 23 20:13:06 MediaServer1 kernel: [26887.071232] FAT: Directory bread(block 650) failed

Mar 23 20:13:06 MediaServer1 kernel: [26887.071261] FAT: Directory bread(block 651) failed

Mar 23 20:13:06 MediaServer1 kernel: [26887.071289] FAT: Directory bread(block 652) failed

Mar 23 20:13:06 MediaServer1 kernel: [26887.071317] FAT: Directory bread(block 653) failed

Mar 23 20:13:06 MediaServer1 kernel: [26887.071345] FAT: Directory bread(block 654) failed

Mar 23 20:13:06 MediaServer1 kernel: [26887.071373] FAT: Directory bread(block 655) failed

Mar 23 20:13:06 MediaServer1 kernel: [26887.071401] FAT: Directory bread(block 656) failed

...

 

Joe's right, it looks like the problem has been the flash drive all along.  The 2 drives cleared and formatted properly, and are ready to use, but since the flash drive could not be updated, you will be re-starting with the previous 6 disk setup every time you reboot.

 

Although clearing and formatting the 2 drives should not be measurably harming them, I would not assign the 2 new drives until you fix the flash situation.

 

Perhaps a long shot, but I believe some USB keys have a write-protect switch on them.  If that is the case here, make sure it is not set to "locked".

 

 

Bill

Once I add the drives and reboot, the USB flash works fine but the drives are reported as new. I am able to access it, and I was even able to apply an update to the time (which was saved even after multiple reboots).

 

I am not at home right now, but I think my bios settings are the same as the ones listed here.

 

The USB drive I am using is the Lexar JumpDrive FireFly, and I am not sure if it has a write protection lock on it.

Perhaps a long shot, but I believe some USB keys have a write-protect switch on them.  If that is the case here, make sure it is not set to "locked".

Good idea.  I thought of that, as well as the possibility that the config folder or config/super.dat or config/disk.cfg might be flagged Read Only.  But from the extract of the syslog (visible above in Joe's post), it is clear that contact with the flash drive is being completely lost.

 

As to BIOS settings, the fact that it boots fine, means that they should be OK, normally, but Legacy mode *might* be better, if it keeps your flash working.  The fact that the drives are reported as New is because super.dat and/or disk.cfg could not be updated during the previous session, so you are starting from the same 6 disk setup each boot.  Because the flash drive appears to work fine probably means it IS fine, and that the real issue is: why does your machine lose contact with your flash drive during operation.  I would suggest a different USB port first, then a USB port that is located far away (front of machine?), then older USB modes such as Legacy mode in the BIOS.

 

By the way, your change of time was not a good test of updating the flash drive, since that only changes the time saved in CMOS, not on the flash.  Changing a share setting or spin down setting would test whether you can update a file in the config folder, especially the spin down setting, since that is stored in config/disk.cfg.

 

cool_runner - your Flash is trash   Get another one - if you need a key for it, send me an email: [email protected]

Seeing everyones responses and the syslog, I agree something is wrong with the flash drive or USB port.

 

One thing I should mention is that over the weekend when I was testing out a few things, I was able to make changes to my go script and copy it to the server without any problems. Also the syslog I posted after a fresh boot, was obtained by dumping it onto the flash drive. It is only when adding the new drives that the flash just disappears.

 

 

Tom,

I am going to try a few more things, and if they don't work then I will email you.  I have a feeling things got really screwed up when I lost power a few weeks back. I am fairly certain that it was the cause of my memory problems, and possibly the cause of this problem.

 

If I restart the server, it will report the drives as new, and I will not be able to make changes to the shares to test if indeed the flash cannot be written to. Is there anything else I can do in the web interface at that state to check if files on the flash can be updated/modified correctly. 

cool_runner,

 

Is it possible that you are just at the edge of what your power supply can handle and that adding two new drives takes it to where it can no longer power up the flash drive reliably?  It sure seems as if the flash drive is initially readable as you can boot from it, but then it goes away, and you cannot read or write it.

 

I know we are all saying "replace the flash drive," and it might fix the problem... but it might just mask the symptoms until you add another drive...  Is your power supply sized to handle all your drives?

 

And take Tom up on his offer.... send him an e-mail....  Odds are your flash drive is not reliable.

 

Joe L.

If I restart the server, it will report the drives as new, and I will not be able to make changes to the shares to test if indeed the flash cannot be written to. Is there anything else I can do in the web interface at that state to check if files on the flash can be updated/modified correctly.

 

Change the spin down setting on the Settings tab, that changes config/disk.cfg.

 

cool_runner,

 

Is it possible that you are just at the edge of what your power supply can handle and that adding two new drives takes it to where it can no longer power up the flash drive reliably?   It sure seems as if the flash drive is initially readable as you can boot from it, but then it goes away, and you cannot read or write it.

 

I know we are all saying "replace the flash drive," and it might fix the problem... but it might just mask the symptoms until you add another drive...   Is your power supply sized to handle all your drives?

 

I am running only 7 drives in my system (including the new ones) and I have a CORSAIR CMPSU-550VX ATX12V V2.2 550W Power Supply, which has a single 41A 12V rail. I don't believe the PSU is the culprit, but who knows.

 

And take Tom up on his offer.... send him an e-mail....  Odds are your flash drive is not reliable.

 

I will send him an email.

I got a chance to try to add the drives again. This time I moved the flash drive to a USB bracket that I placed inside the server (so that it won't stick out).

 

After a restart, the flash drive became visible, and I began to tail the syslog. I was able to copy a file to the flash share, a small 76kB pdf file, and open it successfully. I even changed the spin down time without any problems.

 

I then began the clearing process again, while tailing the syslog from the beginning of the process. As shown below, something is happening to IRQ#7 that might be causing the USB ports to drop.

 

Mar 26 07:21:00 MediaServer1 emhttp[1442]: clearing disk6 disk7 ...

Mar 26 07:23:16 MediaServer1 emhttp[1442]: ... clearing 1% complete

Mar 26 07:25:30 MediaServer1 emhttp[1442]: ... clearing 2% complete

Mar 26 07:27:44 MediaServer1 emhttp[1442]: ... clearing 3% complete

Mar 26 07:29:57 MediaServer1 emhttp[1442]: ... clearing 4% complete

Mar 26 07:32:11 MediaServer1 emhttp[1442]: ... clearing 5% complete

Mar 26 07:33:04 MediaServer1 kernel: [ 1277.773982] spurious 8259A interrupt: IRQ7.

Mar 26 07:34:24 MediaServer1 emhttp[1442]: ... clearing 6% complete

Mar 26 07:36:37 MediaServer1 emhttp[1442]: ... clearing 7% complete

Mar 26 07:38:53 MediaServer1 emhttp[1442]: ... clearing 8% complete

 

Message from syslogd@MediaServer1 at Wed Mar 26 07:40:28 2008 ...

MediaServer1 kernel: [ 1721.088670] Disabling IRQ #7

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088429] irq 7: nobody cared (try booting with the "irqpoll" option)

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088437]  [<c012d568>] __report_bad_irq+0x36/0x75

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088445]  [<c012d637>] note_interrupt+0x74/0xa7

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088449]  [<c012dada>] handle_level_irq+0x70/0x91

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088453]  [<c01051cb>] do_IRQ+0x4e/0x65

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088458]  [<c0103c0b>] common_interrupt+0x23/0x28

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088463]  [<c0144e42>] kmem_cache_free+0x73/0x78

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088467]  [<c016193d>] end_bio_bh_io_sync+0x0/0x37

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088472]  [<c0131b74>] mempool_free+0x48/0x4c

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088477]  [<c0161ead>] bio_free+0x21/0x2c

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088480]  [<c01620cb>] bio_put+0x22/0x23

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088484]  [<c0161970>] end_bio_bh_io_sync+0x33/0x37

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088487]  [<c0162bd2>] bio_endio+0x5a/0x62

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088491]  [<c0131aaf>] mempool_alloc+0x1e/0x9b

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088495]  [<c01b42f3>] __end_that_request_first+0x1bc/0x299

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088501]  [<c02368c9>] scsi_end_request+0x1b/0x92

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088507]  [<c0236af3>] scsi_io_completion+0x109/0x347

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088512]  [<c023b8b4>] sd_rw_intr+0x1fb/0x203

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088517]  [<f882fe7e>] ahci_host_intr+0x6b/0x1ce [ahci]

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088525]  [<c0236882>] scsi_next_command+0x25/0x2f

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088529]  [<c02332dd>] scsi_finish_command+0x3c/0x40

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088533]  [<c02371af>] scsi_softirq_done+0xbc/0xc3

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088537]  [<f8830036>] ahci_interrupt+0x54/0xbc [ahci]

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088544]  [<c01b442e>] blk_done_softirq+0x51/0x58

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088548]  [<c01174d0>] __do_softirq+0x35/0x73

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088552]  [<c0117530>] do_softirq+0x22/0x26

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088556]  [<c01051d0>] do_IRQ+0x53/0x65

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088560]  [<c0103c0b>] common_interrupt+0x23/0x28

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088565]  [<c0144c0c>] kmem_cache_zalloc+0x2d/0x5c

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088569]  [<c0161df6>] alloc_buffer_head+0xd/0x2b

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088573]  [<c015f9d4>] alloc_page_buffers+0x21/0x9c

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088577]  [<c01600f3>] create_empty_buffers+0x10/0x6b

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088580]  [<c01604bf>] __block_prepare_write+0x84/0x42c

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088584]  [<c0132e2f>] get_page_from_freelist+0x8a/0xa6

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088589]  [<c0160fda>] block_prepare_write+0x21/0x2e

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088593]  [<c0163065>] blkdev_get_block+0x0/0x45

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088597]  [<c0130dc2>] generic_file_buffered_write+0x228/0x57b

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088601]  [<c0163065>] blkdev_get_block+0x0/0x45

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088608]  [<c01561c6>] file_update_time+0x26/0x8b

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088612]  [<c013155f>] __generic_file_aio_write_nolock+0x44a/0x474

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088618]  [<c02373e8>] scsi_request_fn+0x232/0x23b

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088623]  [<c0236882>] scsi_next_command+0x25/0x2f

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088628]  [<c01315d4>] generic_file_aio_write_nolock+0x4b/0x9e

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088633]  [<c0146fed>] do_sync_write+0xbe/0xfb

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088638]  [<c01215b2>] autoremove_wake_function+0x0/0x33

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088643]  [<c02332dd>] scsi_finish_command+0x3c/0x40

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088648]  [<c01470b5>] vfs_write+0x8b/0x106

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088652]  [<c01471d8>] sys_write+0x41/0x67

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088656]  [<c0103a62>] syscall_call+0x7/0xb

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088660]  =======================

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088662] handlers:

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088663] [<c02419ed>] (usb_hcd_irq+0x0/0x4c)

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088667] [<c02419ed>] (usb_hcd_irq+0x0/0x4c)

Mar 26 07:40:28 MediaServer1 kernel: [ 1721.088670] Disabling IRQ #7

Mar 26 07:41:09 MediaServer1 emhttp[1442]: ... clearing 9% complete

Mar 26 07:43:23 MediaServer1 emhttp[1442]: ... clearing 10% complete

Mar 26 07:45:37 MediaServer1 emhttp[1442]: ... clearing 11% complete

Mar 26 07:47:50 MediaServer1 emhttp[1442]: ... clearing 12% complete

 

I don't know if replacing the flash drive will solve the problem, since there seems to be a problem with the motherboard. Any suggestions? 

This looks to me to be a bug somewhere, rather than a bad flash drive.  It could possibly be a faulty motherboard, particularly a USB component, or the bug could be in the Linux kernel, or in a driver (possibly USB related), or in the motherboard firmware (you might check for an updated BIOS), or in unRAID itself, although that seems very unlikely as the unRAID driver is compiled code, which is unlikely to be messing directly with interrupts, or misbehaving with them.  This does not look like a bad flash drive, as no matter how defective, it can't affect the interrupts.

 

I looked up your previous syslog, and IRQ 7 is assigned to a group of 6 USB ports, including the one connected to your flash drive.  I suspect that some or all of the 6 ports are on the rear of your machine.  IRQ 3 is assigned to a group of 4 USB ports, of which 2 or all are probably on the front of the machine.  I suggest switching your flash from back to front of the machine (or vice-versa if I guessed wrong), to use the other USB controller and IRQ 3.  This will test whether the rear USB ports and their controller and/or the assigned interrupt IRQ 7 may be bad.

 

Another test I would suggest, is to try a very different unRAID version, older or newer.  This should test whether the problem is in the kernel, a driver, or unRAID itself, by using a different version of each.  If you are using 4.2, try a 4.0 or 4.3 version, you only need to substitute the bzroot and bzimage files.

 

When IRQ 7 'malfunctioned', that meant that support for the entire block of 6 USB ports also malfunctioned, which is why the flash drive could no longer be read or updated.

 

The piece of the syslog you made available is certainly the most relevant to this problem, but I would like to recommend always attaching the entire syslog.  There is often a need to trace something back to its first assignment.

 

Thanks Rob.

 

The flash drive was initially connected to a rear USB port, and this last time I moved it to a bracket that I attached to the pins for the front ports.

 

I am going to try flashing the bios with the latest one from the Asus website to see if it fixes the problem.

Well this is scary!  I have the same motherboard and also added 2 new 1TB drives yesterday.  These were added to the one remaining Intel port on the board (SATA-6) as well as the internal JMicron connector.  After booting, I went through the process of clearing and formatting.  Once that was done, I added some more content to the array not really paying much attention to which drive it was copied to.  I shut down the server last night and then booted it this afternoon.  Attaching from either Macs or PCs showed only the flash drive share available.  Looking at the web page revealed that there were 2 new drives added but not cleared.  It appears that the changes I made yesterday disappeared!

 

I shut down the system and unplugged the 2 new drives and rebooted.  Now the array starts properly and shows all the shares as normal with good parity.  I checked the last transferred content and it seems to be fine (luckily it was not added to the new drives).  I am now starting a parity check to see if things are okay.  After that i will try adding the drives again.

 

Here are the vital stats:

unRaid Server Pro 4.2.4

Asus P5B VM-DO

Lexar Flash from Lime-Tech

PC Power Cooling 610watt

7 WDC 1TB Greenpower drives (only 5 running now)

 

Regards,  Peter

I have a few more hours of parity check still.  So far it has reported zero drive errors but 15 sync errors.  Does anyone know what the impact is of these sync errors?

 

Regards,  Peter

Please report back if were able to add the drives. I am not sure what the sync errors mean, and if they will effect the parity rebuild.

 

I have not been able to work on my server since my last post, but once I get a chance I will report back. I am thinking the problem may be with the jmicron ports. You might want to try adding the drives one by one, starting with the drive on the intel port. After a restart, you should then check if you configuration is maintained. Then you can repeat the process with the drive on the internal jmicron port. Unfortunately, all my internal intel ports are taken so I can't test this.