Re: Again with the firewire

Re: Again with the firewire

[Stefan Piger]

> Ask Apple what they did ... their chipset isn't documented and they
> didn't opensource their firewire driver for it.
>
> Note that working firewire for pismo/tipb exist in my rsync tree
> or in the linux1394 CVS. Linus and bk _devel aren't up-to-date yet.
>
> Ben.

I can't get firewire to work with your rsync tree on my Pismo (at least
with no one up to yesterday). When I load the modules all looks ok (to
me):

Nov 22 07:23:06 localhost kernel: ohci1394: $Revision: 1.79 $ Ben
Collins <bcollins@debian.org>
Nov 22 07:23:06 localhost kernel: ohci1394_0: OHCI-1394 1.0 (PCI):
IRQ=[40]  MMIO=[f5000000-f5001000]  Max Packet=[2048]
Nov 22 07:23:06 localhost kernel: ieee1394: sbp2: Driver forced to
serialize I/O (serialize_io = 1)
Nov 22 07:23:06 localhost kernel: scsi1 : IEEE-1394 SBP-2 protocol
driver

After loading the modules, there is no /proc/ohci1394 as I remember from
earllier versions of linux1394.
When I plug in a firewire device the keyboard becomes unusable, but the
machine doesn't crash, I can reboot it via ssh.
I get no error messages in /var/log/messages.

Do you have any idea why it doesn't work? I tried the same on a friends
Pismo an had the same effects!

regards, Stefan

--
Dipl.-Ing. Stefan Piger
Lehrgebiet Rechnernetze und Verteilte Systeme
Universität Hannover
Tel. 0511-762-79-4726
Fax 0511-762-3003


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Again with the firewire

[Derrik Pates]

On 22 Nov 2001, Stefan Piger wrote:

> After loading the modules, there is no /proc/ohci1394 as I remember from
> earllier versions of linux1394.
> When I plug in a firewire device the keyboard becomes unusable, but the
> machine doesn't crash, I can reboot it via ssh.
> I get no error messages in /var/log/messages.

I actually just had the same thing happen, only the entire console froze,
X and all. I don't know if the kernel was still working or not, I didn't
have another machine connected at the time. However, this is actually an
improvement for me - the ohci1394 module doesn't lock the PMU up and cause
the system to suddenly shutdown (this is a FireWire iBook). If I boot the
system with the FireWire device - a QPS CD-RW drive - plugged in, all is
fine.

Ben? The FireWire controller didn't seem to have a problem with power
management per se - I ran 'gscanbus' after a suspend/unsuspend cycle, and
it seemed to be ok with that.

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@dsdk12.net |     District (dsdk12.net)    |    #linuxOS on OPN


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Again with the firewire

[benh]

>I actually just had the same thing happen, only the entire console froze,
>X and all. I don't know if the kernel was still working or not, I didn't
>have another machine connected at the time. However, this is actually an
>improvement for me - the ohci1394 module doesn't lock the PMU up and cause
>the system to suddenly shutdown (this is a FireWire iBook). If I boot the
>system with the FireWire device - a QPS CD-RW drive - plugged in, all is
>fine.
>
>Ben? The FireWire controller didn't seem to have a problem with power
>management per se - I ran 'gscanbus' after a suspend/unsuspend cycle, and
>it seemed to be ok with that.

Well, there is no code to handle power management in the driver, and
the controller do get powered down, so... If it works, maybe you are
just lucky ;)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Again with the firewire

[Derrik Pates]

On Thu, 22 Nov 2001 benh@kernel.crashing.org wrote:

> Well, there is no code to handle power management in the driver, and
> the controller do get powered down, so... If it works, maybe you are
> just lucky ;)

Doh. Oops on me. Brought the iBook up from sleep this morning, and ran
GScanBus to get the FireWire controller tested - hard freeze. Guess I
spoke too soon. :) But hey, it's serious progress already that FireWire
works at all, so I'm not complaining or anything...

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@dsdk12.net |     District (dsdk12.net)    |    #linuxOS on OPN


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Again with the firewire

[Benjamin Herrenschmidt]

>
>I actually just had the same thing happen, only the entire console froze,
>X and all. I don't know if the kernel was still working or not, I didn't
>have another machine connected at the time. However, this is actually an
>improvement for me - the ohci1394 module doesn't lock the PMU up and cause
>the system to suddenly shutdown (this is a FireWire iBook). If I boot the
>system with the FireWire device - a QPS CD-RW drive - plugged in, all is
>fine.

In Stefan's case, it appears to be the transmit DMA of the chip stalling
for some unknown reason. I suggest moving that discussion to the
linux1394-devel list as I really don't know what may be going on.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Again with the firewire

[Derrik Pates]

On Thu, 22 Nov 2001, Benjamin Herrenschmidt wrote:

> In Stefan's case, it appears to be the transmit DMA of the chip stalling
> for some unknown reason. I suggest moving that discussion to the
> linux1394-devel list as I really don't know what may be going on.

After another test on my part, I discovered that I am not seeing a freeze
on hotplugging. Probably put this iBook to sleep before I plugged the CD
burner in, and the FireWire controller was already a lost cause.

Also, a heads up - I've found that unloading 'ohci1394' before suspend and
reloading it after yields a working system, no freezes after unsuspend. At
least on this FireWire iBook, anyway. If I don't, the system hangs after
unsuspending as soon as a FireWire device is accessed. May be useful for
suspend handling in the driver itself.

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@dsdk12.net |     District (dsdk12.net)    |    #linuxOS on OPN


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Again with the firewire

[Benjamin Herrenschmidt]

>After another test on my part, I discovered that I am not seeing a freeze
>on hotplugging. Probably put this iBook to sleep before I plugged the CD
>burner in, and the FireWire controller was already a lost cause.
>
>Also, a heads up - I've found that unloading 'ohci1394' before suspend and
>reloading it after yields a working system, no freezes after unsuspend. At
>least on this FireWire iBook, anyway. If I don't, the system hangs after
>unsuspending as soon as a FireWire device is accessed. May be useful for
>suspend handling in the driver itself.

Yes, unloading the driver should be enough.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Again with the firewire

[Derrik Pates]

Also, I've found that plugging in a FireWire device, then unplugging it
before doing anything with it (but after waiting ~30 seconds, long enough
for the kernel to see the plug event and try to load the driver) will
cause a system freeze. If I do something with the device (try to mount it
or something), then it's fine, the unplug goes off without a hitch, and
the system continues running.

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@dsdk12.net |     District (dsdk12.net)    |    #linuxOS on OPN


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Again with the firewire

[benh]

>
>After loading the modules, there is no /proc/ohci1394 as I remember from
>earllier versions of linux1394.
>When I plug in a firewire device the keyboard becomes unusable, but the
>machine doesn't crash, I can reboot it via ssh.
>I get no error messages in /var/log/messages.
>
>Do you have any idea why it doesn't work? I tried the same on a friends
>Pismo an had the same effects!

Forget about /proc/ohci1394, it was bogus anyway.

Since you can log via ssh, can you send me the dmesg log that gets
displayed when you plug your device ? Eventulally, compile with the
excessive debugging output enabled in .config, and send me a log
with that too.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Again with the firewire

[mocm]

Hi,
I don't know if you guys remember, but I posted about my problems with
my tibook and the firewire port a while ago. At that time the firewire
was broken in such a way that I couldn't boot into any MacOs anymore
and it crashed when insmodding the ohci1394 module.
Since then I had Apple take the notebook and repair it, which took
almost 3 weeks. After that firewireworked with MacOS X and 9.1 and I
didn't try it with Linux for a while.

Yesterday, I used the kernel-dev tree to build a new kernel with
firewire modules. The modules had some missing dependencies, so I took
the latest CVS from linux1394 which compiled fine and had no missing
dependencies. I modprobed ohci1394 and sbp2 and it didn't work. I
tried rescan-scsi-bus.sh and still nothing. So I tried loading and
unloading the mordules a couple of times until got an error from
get_phy_reg.
After that I gave up and wanted to see if MacOS still worked.
And, although I could still boot both MacOSs, as soon as I plug in the
firewire drive the system hangs. Unplugging the drive unfreezes the
system, but I couldn't get rid of the behaviour, even with
all the resets you guys told me the last time. Seems like it's broken
again. The firewire disk mode also doesn't work. This one freezes my
linux PC until I unplug the tibook.
My question is, how can the firewire chip get broken by software and
why can't it be reset? I had crashes of the Linux driver with my
desktop PC and Sony notebooks, but nothing like that ever happened there.
I guess Apple won't repair my tibook a second time, so I have to live
without firewire on the tibook, which otherwise is really great.

Marcus


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Again with the firewire

[benh]

>
>Hi,
>I don't know if you guys remember, but I posted about my problems with
>my tibook and the firewire port a while ago. At that time the firewire
>was broken in such a way that I couldn't boot into any MacOs anymore
>and it crashed when insmodding the ohci1394 module.
>Since then I had Apple take the notebook and repair it, which took
>almost 3 weeks. After that firewireworked with MacOS X and 9.1 and I
>didn't try it with Linux for a while.
>
>Yesterday, I used the kernel-dev tree to build a new kernel with
>firewire modules. The modules had some missing dependencies, so I took
>the latest CVS from linux1394 which compiled fine and had no missing
>dependencies. I modprobed ohci1394 and sbp2 and it didn't work. I
>tried rescan-scsi-bus.sh and still nothing. So I tried loading and
>unloading the mordules a couple of times until got an error from
>get_phy_reg.
>After that I gave up and wanted to see if MacOS still worked.
>And, although I could still boot both MacOSs, as soon as I plug in the
>firewire drive the system hangs. Unplugging the drive unfreezes the
>system, but I couldn't get rid of the behaviour, even with
>all the resets you guys told me the last time. Seems like it's broken
>again. The firewire disk mode also doesn't work. This one freezes my
>linux PC until I unplug the tibook.
>My question is, how can the firewire chip get broken by software and
>why can't it be reset? I had crashes of the Linux driver with my
>desktop PC and Sony notebooks, but nothing like that ever happened there.
>I guess Apple won't repair my tibook a second time, so I have to live
>without firewire on the tibook, which otherwise is really great.

Ask Apple what they did ... their chipset isn't documented and they
didn't opensource their firewire driver for it.

Note that working firewire for pismo/tipb exist in my rsync tree
or in the linux1394 CVS. Linus and bk _devel aren't up-to-date yet.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Again with the firewire

[Derrik Pates]

On Wed, 21 Nov 2001 benh@kernel.crashing.org wrote:

> Note that working firewire for pismo/tipb exist in my rsync tree
> or in the linux1394 CVS. Linus and bk _devel aren't up-to-date yet.

Well, I've just successfully loaded the 'ohci1394' driver on this iBook. I
don't have any actual FireWire devices available to plug into it right
_now_, but this is a step in the right direction, in that it didn't
proceed to hang up the PMU and shut the unit down. Maybe on Friday I'll
scoot out to work and plug in the 12x FireWire CD burner we have laying
around, and see if I can burn something. (Or at least read something -
that'd be progress.) (This is with 2.4.15-pre6-ben0, but I would presume
-pre7-ben0 would be the same story, but I haven't tried it yet.

I don't know what yoou changed, Ben, but I would say this is a major step
in the right direction. If it now proceeds to work right, then the only
remaining area of contention on this iBook with Linux will be DRI/AGP.
(Not really major to me, so for all practical purposes, that'd be
everything I care about.)

Hell, I'm tempted to make the half-hour trip to work, get the burner,
bring it back, and try it, even given the late hour. :)

Derrik Pates      |   Sysadmin, Douglas School   |    #linuxOS on EFnet
dpates@dsdk12.net |     District (dsdk12.net)    |    #linuxOS on OPN


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/