Re: Problems with Firewire and -mm kernels

[Stefan Richter]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/