August 24, 201510 yr 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.
August 24, 201510 yr 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?
August 24, 201510 yr 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
August 24, 201510 yr 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.
August 24, 201510 yr You are absolutely right, this setting needs to be re-applied too. I thought it was mentioned somewhere, but I could be wrong
August 24, 201510 yr 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
August 24, 201510 yr 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
August 24, 201510 yr 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.
August 24, 201510 yr 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 ...
Archived
This topic is now archived and is closed to further replies.