unRAID Server Release 6.1-rc5-x86_64 Available

[digitalfixer]

Since updating to 6.1rc5 I'm seeing lots of errors like this in the log file.

 

Aug 24 09:34:01 Tower kernel: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
Aug 24 09:34:01 Tower kernel: xhci_hcd 0000:00:14.0: Looking for event-dma 00000000fffd4000 trb-start 00000000fffd5fe0 trb-end 00000000fffd6000 seg-start 00000000fffd5000 seg-end 00000000fffd5ff0
Aug 24 09:34:04 Tower kernel: usb 1-3.2: reset high-speed USB device number 5 using xhci_hcd

 

I've included the diagnostic file.

 

Kevin.

 

I too am seeing this once in a while:

Aug 24 05:39:57 MediaServer kernel: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
Aug 24 05:39:57 MediaServer kernel: xhci_hcd 0000:00:14.0: Looking for event-dma 00000000fffb0000 trb-start 00000000fffb1fd0 trb-end 00000000fffb2000 seg-start 00000000fffb1000 seg-end 00000000fffb1ff0

 

You have the unassigned devices plugin installed and so do I.  I wonder if this is a udev/unassigned devices issue.  You are getting this a lot more than I am.  Can you uninstall the unassigned devices plugin and see if the messages stop?

 

No change. Still occurring about every 8 or 9 minutes.

 

Kevin.

[dlandon]

Since updating to 6.1rc5 I'm seeing lots of errors like this in the log file.

 

Aug 24 09:34:01 Tower kernel: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
Aug 24 09:34:01 Tower kernel: xhci_hcd 0000:00:14.0: Looking for event-dma 00000000fffd4000 trb-start 00000000fffd5fe0 trb-end 00000000fffd6000 seg-start 00000000fffd5000 seg-end 00000000fffd5ff0
Aug 24 09:34:04 Tower kernel: usb 1-3.2: reset high-speed USB device number 5 using xhci_hcd

 

I've included the diagnostic file.

 

Kevin.

 

I too am seeing this once in a while:

Aug 24 05:39:57 MediaServer kernel: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
Aug 24 05:39:57 MediaServer kernel: xhci_hcd 0000:00:14.0: Looking for event-dma 00000000fffb0000 trb-start 00000000fffb1fd0 trb-end 00000000fffb2000 seg-start 00000000fffb1000 seg-end 00000000fffb1ff0

 

You have the unassigned devices plugin installed and so do I.  I wonder if this is a udev/unassigned devices issue.  You are getting this a lot more than I am.  Can you uninstall the unassigned devices plugin and see if the messages stop?

 

No change. Still occurring about every 8 or 9 minutes.

 

Kevin.

 

I just looked and unassigned devices adds some udev rules, but does not seem to remove them when the plugin is removed.  Can you reboot with unassigned devices plugin removed and see if it makes any difference?

[digitalfixer]

Since updating to 6.1rc5 I'm seeing lots of errors like this in the log file.

 

Aug 24 09:34:01 Tower kernel: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
Aug 24 09:34:01 Tower kernel: xhci_hcd 0000:00:14.0: Looking for event-dma 00000000fffd4000 trb-start 00000000fffd5fe0 trb-end 00000000fffd6000 seg-start 00000000fffd5000 seg-end 00000000fffd5ff0
Aug 24 09:34:04 Tower kernel: usb 1-3.2: reset high-speed USB device number 5 using xhci_hcd

 

I've included the diagnostic file.

 

Kevin.

 

I too am seeing this once in a while:

Aug 24 05:39:57 MediaServer kernel: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
Aug 24 05:39:57 MediaServer kernel: xhci_hcd 0000:00:14.0: Looking for event-dma 00000000fffb0000 trb-start 00000000fffb1fd0 trb-end 00000000fffb2000 seg-start 00000000fffb1000 seg-end 00000000fffb1ff0

 

You have the unassigned devices plugin installed and so do I.  I wonder if this is a udev/unassigned devices issue.  You are getting this a lot more than I am.  Can you uninstall the unassigned devices plugin and see if the messages stop?

 

No change. Still occurring about every 8 or 9 minutes.

 

Kevin.

 

I just looked and unassigned devices adds some udev rules, but does not seem to remove them when the plugin is removed.  Can you reboot with unassigned devices plugin removed and see if it makes any difference?

 

I did reboot.

 

Kevin.

 

[Edit]

 

Not sure if this has anything to with it.

 

Bus 004 Device 002: ID 8087:8000 Intel Corp.

Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 003 Device 002: ID 8087:8008 Intel Corp.

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 003: ID 0781:5571 SanDisk Corp. Cruzer Fit

Bus 001 Device 007: ID 046b:ff31 American Megatrends, Inc.

Bus 001 Device 006: ID 046b:ff40 American Megatrends, Inc.

Bus 001 Device 005: ID 046b:ff20 American Megatrends, Inc.

Bus 001 Device 004: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard and Mouse

Bus 001 Device 002: ID 046b:ff01 American Megatrends, Inc.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

tower-diagnostics-20150824-1339.zip

[RobJ]

I noticed the following in my log this morning -

Aug 24 00:30:16 JacoBack crond[1537]: exit status 1 from user root [ $(date +%d) -le 7 ] && /root/mdcmd check &> /dev/null

 

Since I was sure I had done the re-apply procedure to get the Notifications system to working correctly with the new security rules, and it's all working fine, I went looking and found this (in /boot/config/plugins/dynamix/parity-check.cron) -

# Generated parity check schedule:

30 0 * 2,4,6,8,10,12 1 [ $(date +%d) -le 7 ] && /root/mdcmd check  &> /dev/null

 

Thought about it, and decided it's probably independent of the rest of the Notifications system, and needs its own re-apply to bring it up to date, did it and it worked!  Cron file now contains -

# Generated parity check schedule:

30 0 * 2,4,6,8,10,12 1 [ $(date +%d) -le 7 ] && /usr/local/sbin/mdcmd check  &> /dev/null

 

I suspect a number of users (running recent v6.1-rc's) are going to be complaining about non-working parity checks in the first week of September, if they don't go to Settings -> Scheduler and re-apply in the Parity Check section.

[bonienl]

You are absolutely right, this setting needs to be re-applied too. I thought it was mentioned somewhere, but I could be wrong

[jbrodriguez]

Hello, I used to have my disks available as smb shares.

 

After upgrading to 6.1-rc5, the disk shares are gone.

 

I don't remember how I did that in the first place (it was some years ago)

 

Do I have to 'Add Share', call it disk1 and specify disk1 as the only included disk (repeat for each disk) ?

 

But I wasn't doing that for each new disk I've been adding and yet, they showed up as smb shares.

 

Attached is a pic of my current shares

 

 

 

[bonienl]

Hello, I used to have my disks available as smb shares.

 

After upgrading to 6.1-rc5, the disk shares are gone.

 

I don't remember how I did that in the first place (it was some years ago)

 

Do I have to 'Add Share', call it disk1 and specify disk1 as the only included disk (repeat for each disk) ?

 

But I wasn't doing that for each new disk I've been adding and yet, they showed up as smb shares.

 

Attached is a pic of my current shares

 

Please read the announcement of v6.1rc1 here

[jbrodriguez]

...

Please read the announcement of v6.1rc1 here

 

Thank you bonienl !

[trurl]

I noticed the following in my log this morning -

Aug 24 00:30:16 JacoBack crond[1537]: exit status 1 from user root [ $(date +%d) -le 7 ] && /root/mdcmd check &> /dev/null

 

Since I was sure I had done the re-apply procedure to get the Notifications system to working correctly with the new security rules, and it's all working fine, I went looking and found this (in /boot/config/plugins/dynamix/parity-check.cron) -

# Generated parity check schedule:

30 0 * 2,4,6,8,10,12 1 [ $(date +%d) -le 7 ] && /root/mdcmd check  &> /dev/null

 

Thought about it, and decided it's probably independent of the rest of the Notifications system, and needs its own re-apply to bring it up to date, did it and it worked!  Cron file now contains -

# Generated parity check schedule:

30 0 * 2,4,6,8,10,12 1 [ $(date +%d) -le 7 ] && /usr/local/sbin/mdcmd check  &> /dev/null

 

I suspect a number of users (running recent v6.1-rc's) are going to be complaining about non-working parity checks in the first week of September, if they don't go to Settings -> Scheduler and re-apply in the Parity Check section.

Thanks, I had missed that one too.

[bonienl]

I suspect a number of users (running recent v6.1-rc's) are going to be complaining about non-working parity checks in the first week of September, if they don't go to Settings -> Scheduler and re-apply in the Parity Check section.

Thanks, I had missed that one too.

 

Guess, it should be added to the OT to have full visibility ...