Thread: Re: Harddrive(s) not properly recognized
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-user
|
From: Stefan R. <st...@s5...> - 2015-01-24 21:18:32
|
On Jan 23 Magnus La wrote: > The system itself is a ARM board running the Dizzy release of Yocto linux. I suppose you discovered a bug of the 1394 + scsi stack of drivers in conjunction with that ARM platform. > The PCI-e firewire controller seems to be this card (PCI-E, firewire 800, TI chipset): http://www.syba.com/index.php?controller=Product&action=Info&Id=995 > > Linux nitrogen6x 3.10.17-1.0.2_ga+yocto+g0d7db21 #1 SMP Tue Dec 9 15:15:03 CET 2014 armv7l GNU/Linux > > # lspci > 00:00.0 PCI bridge: Device 16c3:abcd (rev 01) > 01:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] (rev 01) > 02:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] (rev 01) XIO2213A/B are generally rather good for SBP-2 I/O. > # lspci -vv | grep firewire > Kernel driver in use: firewire_ohci > > When a firewire drive (I've tried several with the same results) is connected the following information is logged: > firewire_core 0000:02:00.0: rediscovered device fw0 > firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 > firewire_core 0000:02:00.0: phy config: new root=ffc1, gap_count=5 > scsi1 : SBP-2 IEEE-1394 > firewire_core 0000:02:00.0: created device fw1: GUID 0030e0f5e0100a94, S400 > firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > > (I tried the same but when enabling debug output via "echo -1 > /sys/module/firewire_ohci/parameters/debug", the log is a bit verbose so I posted it here: http://pastebin.com/skm6ZBYw) [...] The stock kernel log shows that Self-ID reception DMA, request transmit DMA, response reception DMA (which are needed to get the disk probed by firewire-core), physical response DMA, and request reception DMA (which together with the former DMAs are need for firewire-sbp2 to perform SBP-2 transactions work as they are intended to work. The verbose kernel log additionally shows a few more SBP-2 transactions happening after the log in management transaction succeeded. Those subsequent transactions should be ones issued by scsi core, notably SCSI Inquiry, and then read requests to discover the medium size and the contents of the partition table (if present). However, I wonder why there is no message from the SCSI subsystem, not even anything about failed SCSI requests. Did you filter the log through grep or something like that? If so, please provide a full log with messages from any and all kernel subsystems, even if they seem totally unrelated. Best would be a kernel log beginning from actual boot. Don't remove anything, except lines which you can't expose for privacy reasons. -- Stefan Richter -=====-===== ---= ==--- http://arcgraph.de/sr/ |
|
From: Magnus La <mag...@in...> - 2015-01-26 19:24:12
|
Thanks! > However, I wonder why there is no message from the SCSI subsystem, not > even anything about failed SCSI requests. Did you filter the log through > grep or something like that? If so, please provide a full log with > messages from any and all kernel subsystems, even if they seem totally > unrelated. Best would be a kernel log beginning from actual boot. Don't > remove anything, except lines which you can't expose for privacy reasons. They were unfiltered but I hadn't explicitly enabled SCSI logging which might explain the lack of SCSI messages... This time I enabled it with "echo -1 > /proc/sys/dev/scsi/logging_level". As for other logs: # ls /var/log/ Xorg.0.log messages Xsession.log wtmp boot xinput_calibrator.pointercal.log dmesg The only logs in /var/log that seems of interest is messages and dmesg, but the dmesg file contains only about the first half of what executing dmesg actually returns so I'm not sure what its use is. Hope I haven't missed anything. I've collected three logs: * The actual serial output of the serial console (the verbose firewire+scsi logs are printed to stdout so they there are present here as well). http://pastebin.com/E91YHVww * The output of dmesg (very similar to the log above, but included if I've missed something). http://pastebin.com/2UVufJnu * The contents of /var/log/messages (not much different from dmesg, but with timestamps and what not) http://pastebin.com/1L69V9yJ What the logs describe: A system boot followed by theese commands to enable verbose logging: # echo -1 > /proc/sys/dev/scsi/logging_level # echo -1 > /sys/module/firewire_ohci/parameters/debug Then I attach a firewire hard-drive. One of the very last lines (present in all logs above) seems to be of interest: "scsi scan: INQUIRY failed with code 0x20000" though I can't find that error code (but I'm not sure where to look either). Regards, Magnus ____________________________________________________________ FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more! |
|
From: Stefan R. <st...@s5...> - 2015-02-03 22:13:33
|
On Jan 26 Magnus La wrote: [...] > I've collected three logs: > > * The actual serial output of the serial console (the verbose firewire+scsi logs are printed to stdout so they there are present here as well). > http://pastebin.com/E91YHVww > > * The output of dmesg (very similar to the log above, but included if I've missed something). > http://pastebin.com/2UVufJnu > > * The contents of /var/log/messages (not much different from dmesg, but with timestamps and what not) > http://pastebin.com/1L69V9yJ > > > What the logs describe: > A system boot followed by theese commands to enable verbose logging: > # echo -1 > /proc/sys/dev/scsi/logging_level > # echo -1 > /sys/module/firewire_ohci/parameters/debug > Then I attach a firewire hard-drive. > > One of the very last lines (present in all logs above) seems to be of interest: > "scsi scan: INQUIRY failed with code 0x20000" > though I can't find that error code (but I'm not sure where to look either). Thanks. I have yet to examine these logs in detail. For now, I am noting the following to bits of info: - It's a 32bits ARM host, hence PAGE_SIZE is 4k. (We had an open issue with hosts with larger page size, https://bugzilla.kernel.org/show_bug.cgi?id=12725, but this is from the looks of it unrelated to your issue.) - From your pastebin 1L69V9yJ, I gathered the following contents of the FireWire HDD's Configuration ROM register. There is nothing suspicious sticking out. It seems to be an OXFW900 based device, although one cannot be totally sure just from looking at what the firmware puts into Configuration ROM. ROM header and bus information block ----------------------------------------------------------------- 400 043a33e8 bus_info_length 4, crc_length 58, crc 13288 (should be 53453) 404 31333934 bus_name "1394" 408 00ff5000 irmc 0, cmc 0, isc 0, bmc 0, cyc_clk_acc 255, max_rec 5 (64) 40c 0030e0f5 company_id 0030e0 | OXFORD SEMICONDUCTOR LTD. 410 e0100a94 device_id f5e0100a94 | EUI-64 0030e0f5e0100a94 root directory ----------------------------------------------------------------- 414 0006496e directory_length 6, crc 18798 418 0c0083c0 node capabilities per IEEE 1394 41c 030030e0 vendor: OXFORD SEMICONDUCTOR LTD. 420 81000014 --> descriptor leaf at 470 424 0400f900 hardware version 428 8100001d --> descriptor leaf at 49c 42c d1000001 --> unit directory at 430 unit directory at 430 ----------------------------------------------------------------- 430 000cf19a directory_length 12, crc 61850 434 1200609e specifier id: INCITS 438 13010483 version: SBP-2 43c 3c000137 SBP-2 firmware revision 000137 440 5400c000 --> SBP-2 management agent CSR at fffff0030000 444 3a003c08 SBP-2 unit char.: mgt_ORB_timeout 30s, ORB_size 8 quadlets 448 3800609e SBP-2 command set spec id: INCITS 44c 390104d8 SBP-2 command set: SCSI Primary Commands 2 and related standards 450 3b000000 SBP-2 command set revision 454 3d000003 SBP-2 reconnect timeout: max_reconnect_hold 4s 458 144e0000 SBP-2 logical unit number: ordered 1, type RBC, lun 0000 45c 17000001 model 460 81000015 --> descriptor leaf at 4b4 descriptor leaf at 470 ----------------------------------------------------------------- 470 000aadc5 leaf_length 10, crc 44485 474 00000000 textual descriptor 478 00000000 minimal ASCII 47c 4f78666f "Oxfo" 480 72642053 "rd S" 484 656d6963 "emic" 488 6f6e6475 "ondu" 48c 63746f72 "ctor" 490 204c7464 " Ltd" 494 2e202020 ". " 498 00000000 descriptor leaf at 49c ----------------------------------------------------------------- 49c 0005a08c leaf_length 5, crc 41100 4a0 00000000 textual descriptor 4a4 00000000 minimal ASCII 4a8 4f584657 "OXFW" 4ac 39303020 "900 " 4b0 00000000 descriptor leaf at 4b4 ----------------------------------------------------------------- 4b4 00090d79 leaf_length 9, crc 3449 4b8 00000000 textual descriptor 4bc 00000000 minimal ASCII 4c0 4f58464f "OXFO" 4c4 52442049 "RD I" 4c8 44452044 "DE D" 4cc 65766963 "evic" 4d0 65204c55 "e LU" 4d4 4e203020 "N 0 " 4d8 00000000 -- Stefan Richter -=====-===== --=- ---== http://arcgraph.de/sr/ |
|
From: Eric L. <ela...@te...> - 2015-06-26 01:10:48
|
Sorry about the repeated message... I believe that I posted to the incorrect list... I am working with Magnus La on the issue that he reported a while back: We are still trying to get this to work... http://sourceforge.net/p/linux1394/mailman/message/33270726/ I am using the same hardware (nitrogen6x, with a Freescale iMX6q processor) and the same PCI card (which works flawlessly on my desktop running Fedora 19) for the nitrogen6x board, we are using the following kernel sources: git://github.com/boundarydevices/linux-imx6.git branch: boundary-imx_3.10.17_1.0.2_ga revision/commit: fdf3d06333f2c4ae8aa8bac9bca2e5c15041f22e As far as I can tell, the firewire driver appears to be unmodified from the mainline 3.10.17 sources. From there, I added a few printk statements to help see what was going on... the patch is here: http://pastebin.com/Ney1WfiQ on bootup (or if I remove and reinstall the firewire_ohci module) I get the following: root@nitrogen6x<mailto:root@nitrogen6x>:~# dmesg | grep -e firewire -e sbp2 -e scsi -e pcie imx6q-pcie 1ffc000.pcie: Link up, Gen=1 imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00 scsi0 : ahci_platform firewire_ohci 0000:02:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x2 firewire_core 0000:02:00.0: created device fw0: GUID 0001b713000039db, S800 firewire_core 0000:02:00.0: created device fw1: GUID 0014520300501763, S800 firewire_core 0000:02:00.0: phy config: new root=ffc0, gap_count=5 scsi1 : SBP-2 IEEE-1394 firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) sbp2_login: command_block_agent_address is 281470681743360, generation is 2 sbp2_set_busy_timeout returned rcode 0x0 (no error) sbp2_agent_reset: command_block_agent_address is 281470681743360, generation is 2 sbp2_agent_reset returned rcode 0x7 (address error) scsi_probe_and_add_lun: scsi_device_lookup_by_target(0xD268AC00, 0x0) returned sdev of 0x0 sbp2-complete_transaction: complete_transaction() sending NULL status due to rcode != RCODE_COMPLETE sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL sbp2-complete_transaction: complete_transaction() sending NULL status due to rcode != RCODE_COMPLETE sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL sbp2-complete_transaction: complete_transaction() sending NULL status due to rcode != RCODE_COMPLETE sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL sbp2-complete_transaction: complete_transaction() sending NULL status due to rcode != RCODE_COMPLETE sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL scsi_probe_and_add_lun: scsi_probe_lun returned non 0! __scsi_add_device: scsi_probe_add_lun returned 0(0x0): sdev = -19 (0xFFFFFFED) sbp2_login: scsi sdev = -19(0xFFFFFFED) sbp2_login: IS_ERR(sdev) is true... attempt logout_login sbp2_login: out_logout_login: sending SBP2_LOGOUT_REQUEST. sbp2_login: out_logout_login: rescheduling login. after this there are no more messages... If I remove the firewire_sbp2 and firewire_ohci modules and re-install the firewire_ohci using "modprobe firewire_ohci debug=8", I get the following: root@nitrogen6x<mailto:root@tads_nitrogen6x>:~# modprobe firewire_ohci debug=8 firewire_ohci 0000:02:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x2 firewire_ohci 0000:02:00.0: IRQ 00030010 selfID AR_req busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset root@tads_nitrogen6x<mailto:root@tads_nitrogen6x>:~# firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset firewire_ohci 0000:02:00.0: IRQ 00020000 busReset ... the last line repeats very rapidly until the kernel eventually crashes (using a serial port, my guess is that this message is overflowing the output). Either way, once I start with debug=8 I cannot do anything else. it looks to me like the bus resets are not allowing the sbp2_login function to complete (in fact the rescheduled login never happens). I have also tried this using a Lacie portable firewire hard drive with the exact same results. I am stuck at this point... any help or pointers would be greatly appreciated. Eric |
|
From: Eric L. <ela...@te...> - 2015-07-22 19:16:46
|
On Thu, 2015-06-25 at 20:10 -0500, Eric Lamphear wrote: > > Sorry about the repeated message... I believe that I posted to the > incorrect list... > > I am working with Magnus La on the issue that he reported a while > back: > We are still trying to get this to work... > http://sourceforge.net/p/linux1394/mailman/message/33270726/ > > I am using the same hardware (nitrogen6x, with a Freescale iMX6q > processor) and the same PCI card (which works flawlessly on my desktop > running Fedora 19) > for the nitrogen6x board, we are using the following kernel sources: > git://github.com/boundarydevices/linux-imx6.git > branch: boundary-imx_3.10.17_1.0.2_ga > revision/commit: fdf3d06333f2c4ae8aa8bac9bca2e5c15041f22e > > As far as I can tell, the firewire driver appears to be unmodified > from the mainline 3.10.17 sources. > > From there, I added a few printk statements to help see what was going > on... the patch is here: > http://pastebin.com/Ney1WfiQ > > on bootup (or if I remove and reinstall the firewire_ohci module) I > get the following: > > root@nitrogen6x:~# dmesg | grep -e firewire -e sbp2 -e scsi -e > pcie > imx6q-pcie 1ffc000.pcie: Link up, Gen=1 > imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00 > scsi0 : ahci_platform > firewire_ohci 0000:02:00.0: added OHCI v1.10 device as card 0, 8 IR + > 8 IT contexts, quirks 0x2 > firewire_core 0000:02:00.0: created device fw0: GUID 0001b713000039db, > S800 > firewire_core 0000:02:00.0: created device fw1: GUID 0014520300501763, > S800 > firewire_core 0000:02:00.0: phy config: new root=ffc0, gap_count=5 > scsi1 : SBP-2 IEEE-1394 > firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > sbp2_login: command_block_agent_address is 281470681743360, generation > is 2 > sbp2_set_busy_timeout returned rcode 0x0 (no error) > sbp2_agent_reset: command_block_agent_address is 281470681743360, > generation is 2 > sbp2_agent_reset returned rcode 0x7 (address error) > scsi_probe_and_add_lun: scsi_device_lookup_by_target(0xD268AC00, 0x0) > returned sdev of 0x0 > sbp2-complete_transaction: complete_transaction() sending NULL status > due to rcode != RCODE_COMPLETE > sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL > sbp2-complete_transaction: complete_transaction() sending NULL status > due to rcode != RCODE_COMPLETE > sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL > sbp2-complete_transaction: complete_transaction() sending NULL status > due to rcode != RCODE_COMPLETE > sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL > sbp2-complete_transaction: complete_transaction() sending NULL status > due to rcode != RCODE_COMPLETE > sbp2-complete_command_orb: Setting DID_BUS_BUSY due to status == NULL > scsi_probe_and_add_lun: scsi_probe_lun returned non 0! > __scsi_add_device: scsi_probe_add_lun returned 0(0x0): sdev = -19 > (0xFFFFFFED) > sbp2_login: scsi sdev = -19(0xFFFFFFED) > sbp2_login: IS_ERR(sdev) is true... attempt logout_login > sbp2_login: out_logout_login: sending SBP2_LOGOUT_REQUEST. > sbp2_login: out_logout_login: rescheduling login. > > after this there are no more messages... > > If I remove the firewire_sbp2 and firewire_ohci modules and re-install > the firewire_ohci using "modprobe firewire_ohci debug=8", I get the > following: > root@nitrogen6x:~# modprobe firewire_ohci > debug=8 > firewire_ohci 0000:02:00.0: added OHCI v1.10 device as card 0, 8 IR + > 8 IT contexts, quirks 0x2 > > firewire_ohci 0000:02:00.0: IRQ 00030010 selfID AR_req busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > root@tads_nitrogen6x:~# firewire_ohci 0000:02:00.0: IRQ 00020000 > busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > ... > the last line repeats very rapidly until the kernel eventually crashes > (using a serial port, my guess is that this message is overflowing the > output). > Either way, once I start with debug=8 I cannot do anything else. > > it looks to me like the bus resets are not allowing the sbp2_login > function to complete (in fact the rescheduled login never happens). > I have also tried this using a Lacie portable firewire hard drive with > the exact same results. > > I am stuck at this point... any help or pointers would be greatly > appreciated. > > Eric OK, not sure why this is being ignored, but I really do need help to get this resolved? I am not familiar with Linux drivers or kernel development, so I am afraid that I will make things worse if I start hacking around looking for a fix (which I already have by adding the printk statements in the patch mentioned above)... if anyone is willing to help, I can, at the very least, provide the hardware. |
|
From: Stefan R. <st...@s5...> - 2015-07-23 18:22:58
|
On Jul 22 Eric Lamphear wrote: > On Thu, 2015-06-25 at 20:10 -0500, Eric Lamphear wrote: [...] > > firewire_ohci 0000:02:00.0: IRQ 00030010 selfID AR_req busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > root@tads_nitrogen6x:~# firewire_ohci 0000:02:00.0: IRQ 00020000 > > busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset [...] > OK, not sure why this is being ignored, but I really do need help to get > this resolved? I am not familiar with Linux drivers or kernel > development, so I am afraid that I will make things worse if I start > hacking around looking for a fix (which I already have by adding the > printk statements in the patch mentioned above)... > if anyone is willing to help, I can, at the very least, provide the > hardware. Long series of bus reset events, more so ones without following selfIDcomplete events, mean that the bus is electrically unstable (i.e. too much noise on the bus). I.e. the hardware is defect. Another possible cause of many bus resets which prevent normal access to the bus would be the presence of several Texas Instruments TSB81BA3 phys which have a long list of errata (up to chip revision C inclusive). However, in my experience the TSB81BA3 errata cause bus resets with many selfIDcomplete events, unlike your log. Several of the TSB81BA3 errata can be worked around by adding a 1394a-only phy to the bus. -- Stefan Richter -=====-===== -=== =-=== http://arcgraph.de/sr/ |
|
From: Eric L. <ela...@te...> - 2015-07-23 19:24:37
|
On Thu, 2015-07-23 at 20:22 +0200, Stefan Richter wrote: > On Jul 22 Eric Lamphear wrote: > > On Thu, 2015-06-25 at 20:10 -0500, Eric Lamphear wrote: > [...] > > > firewire_ohci 0000:02:00.0: IRQ 00030010 selfID AR_req busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > root@tads_nitrogen6x:~# firewire_ohci 0000:02:00.0: IRQ 00020000 > > > busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > > > firewire_ohci 0000:02:00.0: IRQ 00020000 busReset > [...] > > OK, not sure why this is being ignored, but I really do need help to get > > this resolved? I am not familiar with Linux drivers or kernel > > development, so I am afraid that I will make things worse if I start > > hacking around looking for a fix (which I already have by adding the > > printk statements in the patch mentioned above)... > > if anyone is willing to help, I can, at the very least, provide the > > hardware. > > Long series of bus reset events, more so ones without following > selfIDcomplete events, mean that the bus is electrically unstable (i.e. > too much noise on the bus). I.e. the hardware is defect. > > Another possible cause of many bus resets which prevent normal access to > the bus would be the presence of several Texas Instruments TSB81BA3 phys > which have a long list of errata (up to chip revision C inclusive). > However, in my experience the TSB81BA3 errata cause bus resets with many > selfIDcomplete events, unlike your log. Several of the TSB81BA3 errata > can be worked around by adding a 1394a-only phy to the bus. Stefan, Thank you for the reply... I am not entirely sure that the hardware is faulty... If I place the same PCI card into my host machine (i686 running Fedora 19), and use the same hard drive and cable, I am able to connect without any issues. So unless the problem is in the PCI link to the 1394 controller it may have something to do with the ARM Cortex-A9 processor (Freescale i.MX6) on my target hardware. Or, possibly any changes made between the 3.10.17 kernel on my target and the 3.14.17 kernel on my host machine. I don't know if I have a TSB81BA3 phy... Unless this is contained within the XIO2213B (3 port phy) controller that is on the PCI card. Also, Is it possible to force the controller to connect as 1394a on the 1394b port? I guess I will try to upgrade my kernel to 3.14.28 first to see if the problem goes away... If that doesn't work, I will look into the ARM Errata selections in the Kernel Config. |
|
From: Stefan R. <st...@s5...> - 2015-07-23 21:39:20
|
On Jul 23 Eric Lamphear wrote: > On Thu, 2015-07-23 at 20:22 +0200, Stefan Richter wrote: > > Long series of bus reset events, more so ones without following > > selfIDcomplete events, mean that the bus is electrically unstable (i.e. > > too much noise on the bus). I.e. the hardware is defect. > > > > Another possible cause of many bus resets which prevent normal access to > > the bus would be the presence of several Texas Instruments TSB81BA3 phys > > which have a long list of errata (up to chip revision C inclusive). > > However, in my experience the TSB81BA3 errata cause bus resets with many > > selfIDcomplete events, unlike your log. Several of the TSB81BA3 errata > > can be worked around by adding a 1394a-only phy to the bus. > > Stefan, Thank you for the reply... > I am not entirely sure that the hardware is faulty... If I place the > same PCI card into my host machine (i686 running Fedora 19), and use the > same hard drive and cable, I am able to connect without any issues. So > unless the problem is in the PCI link to the 1394 controller it may have > something to do with the ARM Cortex-A9 processor (Freescale i.MX6) on my > target hardware. Insufficient power supply of the card could be another cause for such symptoms. Or EMI from the host board, or EMI from elsewhere combined with lacking shielding. Or some sort of issue with the grounding. (Note, I am not an electrical engineer.) > Or, possibly any changes made between the 3.10.17 > kernel on my target and the 3.14.17 kernel on my host machine. The issue is at the physical layer. Driver software does not cause such behavior, except with some exotic controllers which currently do not work alright with Linux (notably some ALi based cards and with the Fujitsu-derived controller of Pinnacle MovieBoard). But your card contains a good link & phy chip which works very well under Linux. > I don't know if I have a TSB81BA3 phy... Unless this is contained within > the XIO2213B (3 port phy) controller that is on the PCI card. The integrated phy of XIO2213B possibly inherits some genes from the older TSB81BA3. The TSB81BA3 errata which I alluded to had been fixed in TSB81BA3D and are not present in XIO2213B. (My own experience with several chips from all three generations backs this up.) BTW, I am having an errata sheet for XIO2213B here (SCPZ007A, issued May 2010, revised June 2010). It lists two issues which concern the PCIe bridge part of the chip: "Errata #1: UR Bit Incorrectly Set in the Uncorrectable Error Status Register When the ANFES Bit Is Set" (no proposed workaround documented in this sheet) "Errata #2: File Transfer Fails When L1 is Enabled" (proposed workaround: do not enable L1) XIO2213B is three chips in one: A PCIe to PCI bridge (with the two mentioned errata), an OHCI1394 link, and a 1394b phy. I am not sure whether there is any connection between L1 low power state of the PCIe bridge and possible low power states of the phy. At least the XIO2213B data manual (SCPS210D, issued October 2008, revised July 2009) section 3.10 does not indicate any such connection. > Also, Is it possible to force the controller to connect as 1394a on the > 1394b port? Yes; see descriptions of the terminals DS0, DS1, and LKON/DS2_P in table 2-9 and section 10 of SCPS210D. > I guess I will try to upgrade my kernel to 3.14.28 first to see if the > problem goes away... If that doesn't work, I will look into the ARM > Errata selections in the Kernel Config. Yes, please try the newest kernel that you possibly can; maybe there is an unexpected interaction between ARM specific platform code and the 1394 physical layer. (Unexpected to me at least...) -- Stefan Richter -=====-===== -=== =-=== http://arcgraph.de/sr/ |
|
From: Eric L. <ela...@te...> - 2015-09-02 02:13:06
|
On Thu, 2015-07-23 at 23:39 +0200, Stefan Richter wrote: > On Jul 23 Eric Lamphear wrote: > > On Thu, 2015-07-23 at 20:22 +0200, Stefan Richter wrote: > > > Long series of bus reset events, more so ones without following > > > selfIDcomplete events, mean that the bus is electrically unstable (i.e. > > > too much noise on the bus). I.e. the hardware is defect. > > > > > > Another possible cause of many bus resets which prevent normal access to > > > the bus would be the presence of several Texas Instruments TSB81BA3 phys > > > which have a long list of errata (up to chip revision C inclusive). > > > However, in my experience the TSB81BA3 errata cause bus resets with many > > > selfIDcomplete events, unlike your log. Several of the TSB81BA3 errata > > > can be worked around by adding a 1394a-only phy to the bus. > > > > Stefan, Thank you for the reply... > > I am not entirely sure that the hardware is faulty... If I place the > > same PCI card into my host machine (i686 running Fedora 19), and use the > > same hard drive and cable, I am able to connect without any issues. So > > unless the problem is in the PCI link to the 1394 controller it may have > > something to do with the ARM Cortex-A9 processor (Freescale i.MX6) on my > > target hardware. > > Insufficient power supply of the card could be another cause for such > symptoms. Or EMI from the host board, or EMI from elsewhere combined with > lacking shielding. Or some sort of issue with the grounding. (Note, I am > not an electrical engineer.) > > > Or, possibly any changes made between the 3.10.17 > > kernel on my target and the 3.14.17 kernel on my host machine. > > The issue is at the physical layer. Driver software does not cause such > behavior, except with some exotic controllers which currently do not work > alright with Linux (notably some ALi based cards and with the > Fujitsu-derived controller of Pinnacle MovieBoard). But your card > contains a good link & phy chip which works very well under Linux. > > > I don't know if I have a TSB81BA3 phy... Unless this is contained within > > the XIO2213B (3 port phy) controller that is on the PCI card. > > The integrated phy of XIO2213B possibly inherits some genes from the older > TSB81BA3. The TSB81BA3 errata which I alluded to had been fixed in > TSB81BA3D and are not present in XIO2213B. (My own experience with > several chips from all three generations backs this up.) > > BTW, I am having an errata sheet for XIO2213B here (SCPZ007A, issued May > 2010, revised June 2010). It lists two issues which concern the PCIe > bridge part of the chip: > "Errata #1: UR Bit Incorrectly Set in the Uncorrectable Error Status > Register When the ANFES Bit Is Set" > (no proposed workaround documented in this sheet) > "Errata #2: File Transfer Fails When L1 is Enabled" > (proposed workaround: do not enable L1) > > XIO2213B is three chips in one: A PCIe to PCI bridge (with the two > mentioned errata), an OHCI1394 link, and a 1394b phy. I am not sure > whether there is any connection between L1 low power state of the PCIe > bridge and possible low power states of the phy. At least the XIO2213B > data manual (SCPS210D, issued October 2008, revised July 2009) section 3.10 > does not indicate any such connection. > > > Also, Is it possible to force the controller to connect as 1394a on the > > 1394b port? > > Yes; see descriptions of the terminals DS0, DS1, and LKON/DS2_P in table > 2-9 and section 10 of SCPS210D. > > > I guess I will try to upgrade my kernel to 3.14.28 first to see if the > > problem goes away... If that doesn't work, I will look into the ARM > > Errata selections in the Kernel Config. > > Yes, please try the newest kernel that you possibly can; maybe there is an > unexpected interaction between ARM specific platform code and the 1394 > physical layer. (Unexpected to me at least...) One more clue... I decided to try to limit my processor to 1 cpu by adding maxcpus=1 to my kernel command line in u-boot. After doing this I am able to reliably connect to my drive as long as it is connected prior to booting. If I connec, or disconnect/reconnect the drive after the system is up, the behavior is the same as before. Is it possible that there is a data race or some kind of synchronization problem when running on the ARM Cortex A9 processor? |
|
From: Eric L. <ela...@te...> - 2015-09-10 00:16:21
|
On Thu, 2015-07-23 at 23:39 +0200, Stefan Richter wrote: > On Jul 23 Eric Lamphear wrote: > > On Thu, 2015-07-23 at 20:22 +0200, Stefan Richter wrote: > > > Long series of bus reset events, more so ones without following > > > selfIDcomplete events, mean that the bus is electrically unstable (i.e. > > > too much noise on the bus). I.e. the hardware is defect. > > > > > > Another possible cause of many bus resets which prevent normal access to > > > the bus would be the presence of several Texas Instruments TSB81BA3 phys > > > which have a long list of errata (up to chip revision C inclusive). > > > However, in my experience the TSB81BA3 errata cause bus resets with many > > > selfIDcomplete events, unlike your log. Several of the TSB81BA3 errata > > > can be worked around by adding a 1394a-only phy to the bus. > > > > Stefan, Thank you for the reply... > > I am not entirely sure that the hardware is faulty... If I place the > > same PCI card into my host machine (i686 running Fedora 19), and use the > > same hard drive and cable, I am able to connect without any issues. So > > unless the problem is in the PCI link to the 1394 controller it may have > > something to do with the ARM Cortex-A9 processor (Freescale i.MX6) on my > > target hardware. > > Insufficient power supply of the card could be another cause for such > symptoms. Or EMI from the host board, or EMI from elsewhere combined with > lacking shielding. Or some sort of issue with the grounding. (Note, I am > not an electrical engineer.) > > > Or, possibly any changes made between the 3.10.17 > > kernel on my target and the 3.14.17 kernel on my host machine. > > The issue is at the physical layer. Driver software does not cause such > behavior, except with some exotic controllers which currently do not work > alright with Linux (notably some ALi based cards and with the > Fujitsu-derived controller of Pinnacle MovieBoard). But your card > contains a good link & phy chip which works very well under Linux. > > > I don't know if I have a TSB81BA3 phy... Unless this is contained within > > the XIO2213B (3 port phy) controller that is on the PCI card. > > The integrated phy of XIO2213B possibly inherits some genes from the older > TSB81BA3. The TSB81BA3 errata which I alluded to had been fixed in > TSB81BA3D and are not present in XIO2213B. (My own experience with > several chips from all three generations backs this up.) > > BTW, I am having an errata sheet for XIO2213B here (SCPZ007A, issued May > 2010, revised June 2010). It lists two issues which concern the PCIe > bridge part of the chip: > "Errata #1: UR Bit Incorrectly Set in the Uncorrectable Error Status > Register When the ANFES Bit Is Set" > (no proposed workaround documented in this sheet) > "Errata #2: File Transfer Fails When L1 is Enabled" > (proposed workaround: do not enable L1) > > XIO2213B is three chips in one: A PCIe to PCI bridge (with the two > mentioned errata), an OHCI1394 link, and a 1394b phy. I am not sure > whether there is any connection between L1 low power state of the PCIe > bridge and possible low power states of the phy. At least the XIO2213B > data manual (SCPS210D, issued October 2008, revised July 2009) section 3.10 > does not indicate any such connection. > > > Also, Is it possible to force the controller to connect as 1394a on the > > 1394b port? > > Yes; see descriptions of the terminals DS0, DS1, and LKON/DS2_P in table > 2-9 and section 10 of SCPS210D. > > > I guess I will try to upgrade my kernel to 3.14.28 first to see if the > > problem goes away... If that doesn't work, I will look into the ARM > > Errata selections in the Kernel Config. > > Yes, please try the newest kernel that you possibly can; maybe there is an > unexpected interaction between ARM specific platform code and the 1394 > physical layer. (Unexpected to me at least...) In an effort to start debugging my issues connecting to the drive, I turned on CONFIG_LOCK_STAT in my kernel configuration. After doing this I have not been able replicate the issue. The drive is now discovered and able to be mounted on boot as well as when it is hot-plugged. Enabling CONFIG_LOCK_STAT also changed some other items in my .config file... the following is a diff from my old .config to my new .config (I removed the irrelevant extra lines)... This caused the issue "go away", although I am sure that this only masked the problem. -# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_ALL=y -CONFIG_INLINE_SPIN_UNLOCK_IRQ=y -CONFIG_INLINE_READ_UNLOCK=y -CONFIG_INLINE_READ_UNLOCK_IRQ=y -CONFIG_INLINE_WRITE_UNLOCK=y -CONFIG_INLINE_WRITE_UNLOCK_IRQ=y -CONFIG_MUTEX_SPIN_ON_OWNER=y +CONFIG_UNINLINE_SPIN_UNLOCK=y -CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_SPLIT_PTLOCK_CPUS=999999 -# CONFIG_DEBUG_SPINLOCK is not set -# CONFIG_DEBUG_MUTEXES is not set -# CONFIG_DEBUG_LOCK_ALLOC is not set +CONFIG_DEBUG_SPINLOCK=y +CONFIG_DEBUG_MUTEXES=y +CONFIG_DEBUG_LOCK_ALLOC=y -# CONFIG_LOCK_STAT is not set +CONFIG_LOCKDEP=y +CONFIG_LOCK_STAT=y +# CONFIG_DEBUG_LOCKDEP is not set +CONFIG_STACKTRACE=y |
Thanks for helping keep SourceForge clean.
X