Re: half a loop
Brought to you by:
aeb,
bencollins
From: Stefan R. <st...@s5...> - 2011-12-20 19:53:49
|
On Dec 20 Carl Karsten wrote: > On Tue, Dec 20, 2011 at 8:58 AM, Carl Karsten <ca...@pe...> wrote: > I am not sure how close to trunk this is, but here is what kernel > source I am using: > > juser@pc8:~/temp$ apt-get source linux-image-$(uname -r) > Reading package lists... Done > Building dependency tree > Reading state information... Done > Picking 'linux' as source package instead of 'linux-image-3.2.0-6-generic' > NOTICE: 'linux' packaging is maintained in the 'Git' version control system at: > http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-precise.git [...] > dpkg-source: info: unpacking linux_3.2.0-6.12.tar.gz Most of the time, the firewire kernel drivers in distributor kernels are identical with those in the kernel.org 2.6.x.y or 3.x.y kernel on which they are based on. > > > you could comment out the line > > > > > > device->max_speed = device->node->max_speed; > > > > > > in drivers/firewire/core-device.c and rebuild + reinstall > > > firewire-core. Then firewire-core will keep all requests to any > > > device down at S100. > > > > > > If it works then, we know that your bus is not capable to support 400 > > > Mbit/s properly but can limp along with 100 Mbit/s. > > > > juser@pc8:~$ ls /dev/fw? > > /dev/fw0 /dev/fw1 /dev/fw2 /dev/fw3 [...] > > [ 500.521851] firewire_ohci: AR spd 0 tl 3a, ffc0 -> ffc1, ack_complete, QR resp = 72650000 > > [ 500.521861] firewire_ohci: AT spd 0 tl 3a, ffc1 -> ffc0, pending/cancelled, QR req, fffff0000444 > > [ 500.522080] firewire_core: created device fw2: GUID 0108000000006351, S100 [...] > > [ 500.522924] firewire_core: created device fw3: GUID 00241b00964cac00, S100 [...] > > Any sense to making this a module parameter? Or we extend the retry mechanism to take repeated evt_missing_ack failures as a hint to try at a lower speed, and if that succeeds, log a warning and continue with degraded performance. In any case, we should make firewire-core's failure message a bit more informative than "giving up on config rom". We need to take care though: I have an SBP-2 bridge which keeps working as repeater while switched off (but being kept on bus power). It wrongly advertises "link on" in its selfID then, and all requests to it fail with evt_missing_ack. So there is nothing wrong with the cable or with the device, it is just a normal powered down state of the device (apart from one pin of its PHY not being controlled by the link as intended by the spec). Likewise, I have an old 6-port repeater (just a PHY without link) where the board designer miswired the respective pin of the PHY. So if we consistently get evt_missing_ack at fffff0000400, it can also be an awkward way of the device telling us that it does not have an active link. In that case, a log message from the kernel should not instill Fear, Uncertainty, nor Doubt into the user. > > I am now more motovated to invest in a cable tester. know of any? > > google showed me some, but I am cant tell if they are more than just a > > continuity tester. Not being an electrical engineer, I don't know what you would need for checking a 1394 cable for conformance. -- Stefan Richter -=====-==-== ==-- =-=-- http://arcgraph.de/sr/ |