Re: Problems with Firewire and -mm kernels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rogério Brito wrote:
On Jun 28 2005, Stefan Richter wrote:
But again, I don't see how -mm and the stock kernel should differ to that
respect.

Well, I can only say that this problem is 100% reproducible with my
enclosure.

Perhaps more data is needed here? The 2.6.12 kernel is able to see the
drive without any problems while the -mm kernels aren't. I can provide
anything that you guys want.

What we know is:
 - With -mm, your machine started to require the switching of phy IDs
   for a proper cycle master.
 - With -mm, the device formerly sensed by scsi_mod's probe as
   "Direct-Access" device + SCSI rev 06 is allegedly of "Unknown" type +
   SCSI rev 04 now. Vendor and model are still recognized though.

So what we don't know at the moment is:
 - What did change to make the formerly "unlikely to happen" FireWire
   bus reset "extremely likely to happen" now? (That is how I interpret
   the ratio of 0% to 100% which you observed.)
 - Does this reset infuence how the device answers to scsi inquiries?
   So far there were only reports on the linux1394 mailinglists
   indicating that with this reset, devices respond differently to
   config ROM queries from the ieee1394 driver. This is way before sbp2
   and scsi_mod get to know about the device.

My current uneducated guess is that the FireWire bus reset and the SCSI probing problem are actually unrelated. The cause for the latter problem might be 2.6.12-mm2/broken-out/git-scsi-block.patch. At least that is what I think after a look through the -mm2 patch collection.

You could load ieee1394 with a new parameter that supresses the "Root node is not cycle master capable..." routine:
# modprobe ieee1394 disable_irm=1
before ohci1394 and the other 1394 related drivers are loaded.

Ok, I'll disable hotplug, udev etc and try to boot into single user mode
for that as soon as I wake up (I'm going to bed right now---had a lot of
work done for a day).

You do not need to go through all this. Unload all 1394 drivers (although this may fail sometimes when scsi does not let go of sbp2), then reload ieee1394 with the parameter, then ohci1394. No need to go into another runlevel or to mess around with hotplug or udev.

ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[0050c501e00010e8]

What caused these two messages? Did you disconnect the drive at this
point?

Yes, I did. In both cases, just to see if any messages issued to dmesg were
different when unplugging the drive.

Then these two messages are OK.
--
Stefan Richter
-=====-=-=-= -==- ===--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux