Nabble - freebsd-firewire

Current problem reports assigned to freebsd-firewire@FreeBSD.org

2009-11-30T03:06:50Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/139549 firewire [firewire] reconnecting a firewire disk does not cause
o kern/136946 firewire [fwohci] fwohci throws an"unrecoverable error" upon re
p kern/125673 firewire [firewire] [panic] FreeBSD7 panics when kldunloading f
o kern/122951 firewire [firewire] video-transfer via fwcontrol triggers a pan
o kern/118093 firewire [firewire] firewire bus reset hogs CPU, causing data t
p kern/114646 firewire [firewire] [patch] firewire fails after suspend/resume
o kern/113785 firewire [firewire] dropouts when playing DV on firewire
o kern/97208 firewire [firewire] System hangs / locks up when a firewire dis
o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w

9 problems total.

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Current problem reports assigned to freebsd-firewire@FreeBSD.org

2009-11-23T03:06:51Z

Re: VIA firewire controller and "non CYCLEMASTER mode"

2009-11-17T10:05:12Z

On Mon, 2009-11-16 at 12:13 -0800, Dieter wrote:

> It has been over a year, time to ask again:
>
> > If we assume that I need to get the VIA into non-CYCLEMASTER mode,
> > (since that worked with the NEC), any ideas why
> >
> > fwcontrol -u 0 -f 0
> > fwcontrol -u 0 -r
> >
> > doesn't force the VIA into non-CYCLEMASTER mode the way
> > it (with -u 1) works for NEC?
>
> PR: kern/113785
>
> VIA 6307, reported as:
> fwohci0: <VIA Fire II (VT6306)> port 0xa800-0xa87f mem 0xfdffe000-0xfdffe7ff irq 18 at device 6.0 on pci1
> AFAIK, the difference between 6306 and 6307 is the number of ports.
>
> Currently running FreeBSD 7.1 amd64.

Some day. *sigh* ...

Sean

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

VIA firewire controller and "non CYCLEMASTER mode"

2009-11-16T12:13:46Z

It has been over a year, time to ask again:

> If we assume that I need to get the VIA into non-CYCLEMASTER mode,
> (since that worked with the NEC), any ideas why
>
> fwcontrol -u 0 -f 0
> fwcontrol -u 0 -r
>
> doesn't force the VIA into non-CYCLEMASTER mode the way
> it (with -u 1) works for NEC?

PR: kern/113785

VIA 6307, reported as:
fwohci0: <VIA Fire II (VT6306)> port 0xa800-0xa87f mem 0xfdffe000-0xfdffe7ff irq 18 at device 6.0 on pci1
AFAIK, the difference between 6306 and 6307 is the number of ports.

Currently running FreeBSD 7.1 amd64.
_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Current problem reports assigned to freebsd-firewire@FreeBSD.org

2009-11-16T03:06:50Z

Current problem reports assigned to freebsd-firewire@FreeBSD.org

2009-11-09T03:06:50Z

Re: Bootable Firewire Drives

2009-11-03T04:02:40Z

Sean Bruno <sean.bruno@...> writes:

> Does anyone have a good idea of what(if any) motherboard bios' support
> firewire as a bootable target?
>
> None of my machines seem to be able to boot off an external firewire
> drive which is hampering my efforts to prove out the code.

It could be implemented as Option ROM on a Firewire controller,
regardless of the BIOS. I haven't seen one, though.

Regards,
--
Julian Stecklina

The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners - Ernst Jan Plugge

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Current problem reports assigned to freebsd-firewire@FreeBSD.org

2009-11-02T03:06:52Z

Re: [Fwd: Re: firewire issue]

2009-10-31T16:29:38Z

Dear Andreas,

> Hi Fabio,
>
> Fabio wrote:
>> Le 26 oct. 2009 à 22:46, Andreas Tobler a écrit :
>
>>>> Thank you both for your quick answer. I'll see what I can do
>>>> with Andreas' diff. Right now, I'm still fighting with
>>>> sysinstall (trying to get the proper partition map) so it may
>>>> take a while.
>>> Are you trying to install FreeBSD on an external firewire disk?
>>> Or do you have a firewire device attached to you imac G3 and want
>>> to install to an internal disk?
>>> If the first is true, I'm sorry, I feel it won't work since early
>>> Apple Firewire chips are broken in several ways.
>>> If the second is true, please try to detach any firewire devices
>>> from your G3 before booting.
>> No FW device is attached at all.
>
> I experienced myself :(

Well at least the bug can be reproduced every times. That's a good
news actually.

> I saw that you managed to find a solution so far, w/o firewire.

Yes. For those that don't know, this is how I did it:
http://forums.freebsd.org/showthread.php?p=46921#post46921

I installed 8rc1 on a USB 1.1 HD. Right now I'm compiling firefox,
it's taking more than 10 hours ! My next step will be to figure out
how ACPI works.

> Myself I tried to get into the same stage as you're in.

I have a working freebsd with an internet connection. I've installed
ports and everything is working beautifully so far. I'd recommend to
install perl since it's required by a lot of stuff afaik.

> I think I'm there now. I learned a lot, thanks to Marcel@.
>
> I did an installation of RC2 on my ancient imac onto an USB based
> drive. Your hints about the 'free' slices seems to be worth.
> First I gpart'ed my drive w/o spare slices, I was not able that the
> installer recognized my drive. Later I added some free slices in
> between and then, surprise, the installer recognized my drive.

The only thing is that the drive mounts on mac os, but it appears
empty. Probably because we should change the Apple_HFS to something
else (UFS something, don't know what).

> I was able to install RC2 onto this drive including booting from it.
> With pressing 'alt' at boottime and selecting the USB drive as boot/
> root drive.

Great !

> Great so far. Now I have to jump into the fact where firewire kills
> the booting process. I think I know where, but it'll take some time.
>
> In short, I'm working on.

I have little spare time, but I'd be very happy to help. Let me know
if there is anything I can do.

> Gruss,
> Andreas

Fabio

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: [Fwd: Re: firewire issue]

2009-10-31T15:14:16Z

Hi Fabio,

Fabio wrote:
> Le 26 oct. 2009 à 22:46, Andreas Tobler a écrit :

>>> Thank you both for your quick answer. I'll see what I can do with
>>> Andreas' diff. Right now, I'm still fighting with sysinstall
>>> (trying to get the proper partition map) so it may take a while.
>> Are you trying to install FreeBSD on an external firewire disk? Or
>> do you have a firewire device attached to you imac G3 and want to
>> install to an internal disk?
>> If the first is true, I'm sorry, I feel it won't work since early
>> Apple Firewire chips are broken in several ways.
>> If the second is true, please try to detach any firewire devices
>> from your G3 before booting.
>
> No FW device is attached at all.

I experienced myself :(

>> The firewire code from 8.0/CURRENT goes into an infinite loop with
>> this crappy chip.
>
> Well for now I'm booting from an USB 1.0 HD, but my ultimate goal is
> to boot from the FW. I'm not ready to give up right now ^^
>
>> If both are not true, if you can, try to use the pdisk from OS-X to
>> format your partition you want fbsd installed on.
>
> That's what I did. In fact, this is my partition map:
>
> #: type name length
> base ( size )
> 1: Apple_partition_map Apple 63 @ 1
> 2: Apple_Bootstrap freebsd_boot 4000 @ 64 ( 2.0M)
> 3: Apple_HFS Extra 156297424 @ 4064 ( 74.5G)
>
> But I keep getting an "Operation not permitted" with sysinstall. I
> even tried fdisk. And I used the "dd" command to copy the boot1.hfs
> file.
> I'll see if I can find an answer in the freebsd-ppc list archive.

I saw that you managed to find a solution so far, w/o firewire.

Myself I tried to get into the same stage as you're in.

I think I'm there now. I learned a lot, thanks to Marcel@.

I did an installation of RC2 on my ancient imac onto an USB based drive.
Your hints about the 'free' slices seems to be worth.
First I gpart'ed my drive w/o spare slices, I was not able that the
installer recognized my drive. Later I added some free slices in between
and then, surprise, the installer recognized my drive.

I was able to install RC2 onto this drive including booting from it.
With pressing 'alt' at boottime and selecting the USB drive as boot/root
drive.

Great so far. Now I have to jump into the fact where firewire kills the
booting process. I think I know where, but it'll take some time.

In short, I'm working on.

Gruss,
Andreas
_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

kern/139549: [firewire] reconnecting a firewire disk does not cause the disklabel to update correctly/invalidate the cache

2009-10-31T11:00:13Z

The following reply was made to PR kern/139549; it has been noted by GNATS.

From: Dirk-Willem van Gulik <Dirk-Willem.van.Gulik@...>
To: FreeBSD-gnats-submit@..., freebsd-firewire@...
Cc:
Subject: kern/139549: [firewire] reconnecting a firewire disk does not cause
the disklabel to update correctly/invalidate the cache
Date: Sat, 31 Oct 2009 18:29:55 +0100

Sean wrote:

> pre-8.0 has a default of "3" set to the sysctl "firewire.hold_count" or
> some such thing that keeps the disconnect/removal of a firewire device
> from doing "things".
>
> Try setting that value to "1" and see if the problem manifests itself.

Regardless of the setting - it seems that the disklabel continues to be
cached - and thus no updating of the /dev's (e.g. matching the actual
slices/partitions) happens.

I guess that we need a

firewire.force_update_on_reconnect

which completley wacks any disklabel/da -or- perhaps abandons trying to
use the lowest number possible; but keeps on counting it as a higher one.

Thanks,

Dw

http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

kern/139549: [firewire] reconnecting a firewire disk does not cause the disklabel to update correctly/invalidate the cache

2009-10-31T10:29:55Z

Sean wrote:

> pre-8.0 has a default of "3" set to the sysctl "firewire.hold_count" or
> some such thing that keeps the disconnect/removal of a firewire device
> from doing "things".
>
> Try setting that value to "1" and see if the problem manifests itself.

Regardless of the setting - it seems that the disklabel continues to be
cached - and thus no updating of the /dev's (e.g. matching the actual
slices/partitions) happens.

I guess that we need a

firewire.force_update_on_reconnect

which completley wacks any disklabel/da -or- perhaps abandons trying to
use the lowest number possible; but keeps on counting it as a higher one.

Thanks,

Dw

http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: Bootable Firewire Drives

2009-10-28T18:14:40Z

On Thu, 29 Oct 2009, Sean Bruno wrote:
> Does anyone have a good idea of what(if any) motherboard bios'
> support firewire as a bootable target?
>
> None of my machines seem to be able to boot off an external firewire
> drive which is hampering my efforts to prove out the code.

No PC BIOS I have ever seen mentions it..

I believe Macs can do it (and have been able to do so for a while)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

signature.asc (195 bytes) Download Attachment

Bootable Firewire Drives

2009-10-28T13:34:22Z

Does anyone have a good idea of what(if any) motherboard bios' support
firewire as a bootable target?

None of my machines seem to be able to boot off an external firewire
drive which is hampering my efforts to prove out the code.

Sean

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: [Fwd: Re: firewire issue]

2009-10-27T00:17:44Z

Le 26 oct. 2009 à 22:46, Andreas Tobler a écrit :

> Fabio,
>
> Fabio wrote:
>
>> Thank you both for your quick answer. I'll see what I can do with
>> Andreas' diff. Right now, I'm still fighting with sysinstall
>> (trying to get the proper partition map) so it may take a while.
>
> Are you trying to install FreeBSD on an external firewire disk? Or
> do you have a firewire device attached to you imac G3 and want to
> install to an internal disk?
> If the first is true, I'm sorry, I feel it won't work since early
> Apple Firewire chips are broken in several ways.
> If the second is true, please try to detach any firewire devices
> from your G3 before booting.

No FW device is attached at all.

> The firewire code from 8.0/CURRENT goes into an infinite loop with
> this crappy chip.

Well for now I'm booting from an USB 1.0 HD, but my ultimate goal is
to boot from the FW. I'm not ready to give up right now ^^

> If both are not true, if you can, try to use the pdisk from OS-X to
> format your partition you want fbsd installed on.

That's what I did. In fact, this is my partition map:

#: type name length
base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Apple_Bootstrap freebsd_boot 4000 @ 64 ( 2.0M)
3: Apple_HFS Extra 156297424 @ 4064 ( 74.5G)

But I keep getting an "Operation not permitted" with sysinstall. I
even tried fdisk. And I used the "dd" command to copy the boot1.hfs
file.
I'll see if I can find an answer in the freebsd-ppc list archive.

Fabio

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: [Fwd: Re: firewire issue]

2009-10-26T14:46:50Z

Fabio,

Fabio wrote:

> Thank you both for your quick answer. I'll see what I can do with
> Andreas' diff. Right now, I'm still fighting with sysinstall (trying
> to get the proper partition map) so it may take a while.

Are you trying to install FreeBSD on an external firewire disk? Or do
you have a firewire device attached to you imac G3 and want to install
to an internal disk?
If the first is true, I'm sorry, I feel it won't work since early Apple
Firewire chips are broken in several ways.
If the second is true, please try to detach any firewire devices from
your G3 before booting. The firewire code from 8.0/CURRENT goes into an
infinite loop with this crappy chip.

If both are not true, if you can, try to use the pdisk from OS-X to
format your partition you want fbsd installed on.

Just guessing.

Andreas
_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: [Fwd: Re: firewire issue]

2009-10-26T14:04:12Z

I will ask around and see if I can get my hands on a G3 here in Oregon,
USA.

Sean

On Mon, 2009-10-26 at 21:18 +0100, Fabio wrote:

> Dear Andreas and Sean,
>
> Thank you both for your quick answer. I'll see what I can do with
> Andreas' diff. Right now, I'm still fighting with sysinstall (trying
> to get the proper partition map) so it may take a while.
>
> Fabio
>
> Le 26 oct. 2009 à 20:48, Andreas Tobler a écrit :
>
> > Fabio,
> >
> > I do not know what the issue is.
> >
> > Sean Bruno wrote:
> >> Look over this patch from Andreas. I haven't done anything with it
> >> as I
> >> don't have the h/w to test with.
> >
> > Please use the attached diff instead, it might bring you a bit
> > further.
> >
> > It is still not the final thing, but I did not have the time to
> > follow up here. Busy with other stuff.
> >
> > The patch forwared from Sean is a bit old.
> >
> > Regards,
> > Andreas
> >
> >
> >
> > Index: sys/dev/firewire/fwohci_pci.c
> > ===================================================================
> > --- sys/dev/firewire/fwohci_pci.c (revision 198452)
> > +++ sys/dev/firewire/fwohci_pci.c (working copy)
> > @@ -196,6 +196,10 @@
> > device_set_desc(dev, "Apple UniNorth");
> > return BUS_PROBE_DEFAULT;
> > }
> > + if (id == (FW_VENDORID_APPLE | FW_DEVICE_UNINORTH_V1)) {
> > + device_set_desc(dev, "Apple UniNorth, v1");
> > + return BUS_PROBE_DEFAULT;
> > + }
> > if (id == (FW_VENDORID_LUCENT | FW_DEVICE_FW322)) {
> > device_set_desc(dev, "Lucent FW322/323");
> > return BUS_PROBE_DEFAULT;
> > @@ -285,6 +289,10 @@
> > fwohci_softc_t *sc = device_get_softc(self);
> > int err;
> > int rid;
> > + uint32_t id;
> > +
> > + sc->old_uninorth = 0;
> > +
> > #if defined(__DragonFly__) || __FreeBSD_version < 500000
> > int intr;
> > /* For the moment, put in a message stating what is wrong */
> > @@ -383,6 +391,12 @@
> > return (ENOMEM);
> > }
> >
> > + id = pci_get_devid(self);
> > + if (id == (FW_VENDORID_APPLE | FW_DEVICE_UNINORTH_V1)) {
> > + sc->old_uninorth = 1;
> > + device_printf(self, "Uninorth V1\n");
> > + }
> > +
> > err = fwohci_init(sc, self);
> >
> > if (err) {
> > Index: sys/dev/firewire/fwohci.c
> > ===================================================================
> > --- sys/dev/firewire/fwohci.c (revision 198452)
> > +++ sys/dev/firewire/fwohci.c (working copy)
> > @@ -79,6 +79,7 @@
> > #undef OHCI_DEBUG
> >
> > static int nocyclemaster = 0;
> > +static int old_uninorth = 0;
> > int firewire_phydma_enable = 1;
> > SYSCTL_DECL(_hw_firewire);
> > SYSCTL_INT(_hw_firewire, OID_AUTO, nocyclemaster, CTLFLAG_RW,
> > &nocyclemaster, 0,
> > @@ -266,6 +267,15 @@
> >
> > d_ioctl_t fwohci_ioctl;
> >
> > +#if BYTE_ORDER == BIG_ENDIAN
> > +#define FWOHCI_DMA_READ_UNI(x) \
> > + old_uninorth ? (x) : FWOHCI_DMA_READ(x)
> > +#define FWOHCI_DMA_WRITE_UNI(x,y) \
> > + old_uninorth ? ((x) = (y)) : FWOHCI_DMA_WRITE(x,y)
> > +#else
> > +#define FWOHCI_DMA_READ_UNI(x) FWOHCI_DMA_READ(x)
> > +#define FWOHCI_DMA_WRITE_UNI(x,y) FWOHCI_DMA_WRITE(x,y)
> > +#endif
> > /*
> > * Communication with PHY device
> > */
> > @@ -624,6 +634,8 @@
> > return (ENXIO);
> > }
> >
> > + old_uninorth = sc->old_uninorth;
> > +
> > /* Available Isochronous DMA channel probe */
> > OWRITE(sc, OHCI_IT_MASK, 0xffffffff);
> > OWRITE(sc, OHCI_IR_MASK, 0xffffffff);
> > @@ -1811,7 +1823,7 @@
> > fwohci_dump_intr(struct fwohci_softc *sc, uint32_t stat)
> > {
> > if(stat & OREAD(sc, FWOHCI_INTMASK))
> > - device_printf(fc->dev, "INTERRUPT < %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s
> > %s%s%s%s%s%s> 0x%08x, 0x%08x\n",
> > + device_printf(sc->fc.dev, "INTERRUPT < %s%s%s%s%s%s%s%s%s%s%s%s%s
> > %s%s%s%s%s%s%s%s> 0x%08x, 0x%08x\n",
> > stat & OHCI_INT_EN ? "DMA_EN ":"",
> > stat & OHCI_INT_PHY_REG ? "PHY_REG ":"",
> > stat & OHCI_INT_CYC_LONG ? "CYC_LONG ":"",
> > @@ -1848,7 +1860,7 @@
> > fc->status = FWBUSRESET;
> > /* Disable bus reset interrupt until sid recv. */
> > OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_PHY_BUS_R);
> > -
> > +
> > device_printf(fc->dev, "%s: BUS reset\n", __func__);
> > OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_CYC_LOST);
> > OWRITE(sc, OHCI_LNKCTLCLR, OHCI_CNTL_CYCSRC);
> > @@ -2037,7 +2049,7 @@
> > return;
> > }
> > for (i = 0; i < plen / 4; i ++)
> > - buf[i] = FWOHCI_DMA_READ(sc->sid_buf[i+1]);
> > + buf[i] = FWOHCI_DMA_READ_UNI(sc->sid_buf[i+1]);
> >
> > /* pending all pre-bus_reset packets */
> > fwohci_txd(sc, &sc->atrq);
> > @@ -2068,6 +2080,7 @@
> > fwohci_check_stat(struct fwohci_softc *sc)
> > {
> > uint32_t stat, irstat, itstat;
> > + static int sid_count;
> >
> > FW_GLOCK_ASSERT(&sc->fc);
> > stat = OREAD(sc, FWOHCI_INTSTAT);
> > @@ -2076,8 +2089,14 @@
> > "device physically ejected?\n");
> > return (FILTER_STRAY);
> > }
> > - if (stat)
> > +
> > + if (stat && old_uninorth && (sid_count < 5)) {
> > + OWRITE(sc, FWOHCI_INTSTATCLR,
> > + stat & ~(OHCI_INT_PHY_BUS_R | OHCI_INT_PHY_SID));
> > + sid_count++;
> > + } else {
> > OWRITE(sc, FWOHCI_INTSTATCLR, stat & ~OHCI_INT_PHY_BUS_R);
> > + }
> >
> > stat &= sc->intmask;
> > if (stat == 0)
> > @@ -2657,7 +2676,7 @@
> > int i;
> > #endif
> >
> > - ld0 = FWOHCI_DMA_READ(fp->mode.ld[0]);
> > + ld0 = FWOHCI_DMA_READ_UNI(fp->mode.ld[0]);
> > #if 0
> > printf("ld0: x%08x\n", ld0);
> > #endif
> > @@ -2690,7 +2709,7 @@
> > }
> > #if BYTE_ORDER == BIG_ENDIAN
> > for(i = 0; i < slen/4; i ++)
> > - fp->mode.ld[i] = FWOHCI_DMA_READ(fp->mode.ld[i]);
> > + fp->mode.ld[i] = FWOHCI_DMA_READ_UNI(fp->mode.ld[i]);
> > #endif
> > return(hlen);
> > }
> > @@ -2884,7 +2903,7 @@
> > printf("nvec == 0\n");
> >
> > /* DMA result-code will be written at the tail of packet */
> > - stat = FWOHCI_DMA_READ(*(uint32_t *)(ld - sizeof(struct
> > fwohci_trailer)));
> > + stat = FWOHCI_DMA_READ_UNI(*(uint32_t *)(ld - sizeof(struct
> > fwohci_trailer)));
> > #if 0
> > printf("plen: %d, stat %x\n",
> > plen ,stat);
> > Index: sys/dev/firewire/fwohcireg.h
> > ===================================================================
> > --- sys/dev/firewire/fwohcireg.h (revision 198452)
> > +++ sys/dev/firewire/fwohcireg.h (working copy)
> > @@ -73,6 +73,7 @@
> > #define FW_DEVICE_R5C552 (0x0552 << 16)
> > #define FW_DEVICE_PANGEA (0x0030 << 16)
> > #define FW_DEVICE_UNINORTH (0x0031 << 16)
> > +#define FW_DEVICE_UNINORTH_V1 (0x0018 << 16)
> > #define FW_DEVICE_AIC5800 (0x5800 << 16)
> > #define FW_DEVICE_FW322 (0x5811 << 16)
> > #define FW_DEVICE_7007 (0x7007 << 16)
> > Index: sys/dev/firewire/fwohcivar.h
> > ===================================================================
> > --- sys/dev/firewire/fwohcivar.h (revision 198452)
> > +++ sys/dev/firewire/fwohcivar.h (working copy)
> > @@ -75,6 +75,7 @@
> > struct task fwohci_task_sid;
> > struct task fwohci_task_dma;
> > int cycle_lost;
> > + int old_uninorth;
> > } fwohci_softc_t;
> >
> > void fwohci_intr (void *arg);
>
> _______________________________________________
> freebsd-firewire@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
> To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: [Fwd: Re: firewire issue]

2009-10-26T13:18:54Z

Dear Andreas and Sean,

Thank you both for your quick answer. I'll see what I can do with
Andreas' diff. Right now, I'm still fighting with sysinstall (trying
to get the proper partition map) so it may take a while.

Fabio

Le 26 oct. 2009 à 20:48, Andreas Tobler a écrit :

> Fabio,
>
> I do not know what the issue is.
>
> Sean Bruno wrote:
>> Look over this patch from Andreas. I haven't done anything with it
>> as I
>> don't have the h/w to test with.
>
> Please use the attached diff instead, it might bring you a bit
> further.
>
> It is still not the final thing, but I did not have the time to
> follow up here. Busy with other stuff.
>
> The patch forwared from Sean is a bit old.
>
> Regards,
> Andreas
>
>
>
> Index: sys/dev/firewire/fwohci_pci.c
> ===================================================================
> --- sys/dev/firewire/fwohci_pci.c (revision 198452)
> +++ sys/dev/firewire/fwohci_pci.c (working copy)
> @@ -196,6 +196,10 @@
> device_set_desc(dev, "Apple UniNorth");
> return BUS_PROBE_DEFAULT;
> }
> + if (id == (FW_VENDORID_APPLE | FW_DEVICE_UNINORTH_V1)) {
> + device_set_desc(dev, "Apple UniNorth, v1");
> + return BUS_PROBE_DEFAULT;
> + }
> if (id == (FW_VENDORID_LUCENT | FW_DEVICE_FW322)) {
> device_set_desc(dev, "Lucent FW322/323");
> return BUS_PROBE_DEFAULT;
> @@ -285,6 +289,10 @@
> fwohci_softc_t *sc = device_get_softc(self);
> int err;
> int rid;
> + uint32_t id;
> +
> + sc->old_uninorth = 0;
> +
> #if defined(__DragonFly__) || __FreeBSD_version < 500000
> int intr;
> /* For the moment, put in a message stating what is wrong */
> @@ -383,6 +391,12 @@
> return (ENOMEM);
> }
>
> + id = pci_get_devid(self);
> + if (id == (FW_VENDORID_APPLE | FW_DEVICE_UNINORTH_V1)) {
> + sc->old_uninorth = 1;
> + device_printf(self, "Uninorth V1\n");
> + }
> +
> err = fwohci_init(sc, self);
>
> if (err) {
> Index: sys/dev/firewire/fwohci.c
> ===================================================================
> --- sys/dev/firewire/fwohci.c (revision 198452)
> +++ sys/dev/firewire/fwohci.c (working copy)
> @@ -79,6 +79,7 @@
> #undef OHCI_DEBUG
>
> static int nocyclemaster = 0;
> +static int old_uninorth = 0;
> int firewire_phydma_enable = 1;
> SYSCTL_DECL(_hw_firewire);
> SYSCTL_INT(_hw_firewire, OID_AUTO, nocyclemaster, CTLFLAG_RW,
> &nocyclemaster, 0,
> @@ -266,6 +267,15 @@
>
> d_ioctl_t fwohci_ioctl;
>
> +#if BYTE_ORDER == BIG_ENDIAN
> +#define FWOHCI_DMA_READ_UNI(x) \
> + old_uninorth ? (x) : FWOHCI_DMA_READ(x)
> +#define FWOHCI_DMA_WRITE_UNI(x,y) \
> + old_uninorth ? ((x) = (y)) : FWOHCI_DMA_WRITE(x,y)
> +#else
> +#define FWOHCI_DMA_READ_UNI(x) FWOHCI_DMA_READ(x)
> +#define FWOHCI_DMA_WRITE_UNI(x,y) FWOHCI_DMA_WRITE(x,y)
> +#endif
> /*
> * Communication with PHY device
> */
> @@ -624,6 +634,8 @@
> return (ENXIO);
> }
>
> + old_uninorth = sc->old_uninorth;
> +
> /* Available Isochronous DMA channel probe */
> OWRITE(sc, OHCI_IT_MASK, 0xffffffff);
> OWRITE(sc, OHCI_IR_MASK, 0xffffffff);
> @@ -1811,7 +1823,7 @@
> fwohci_dump_intr(struct fwohci_softc *sc, uint32_t stat)
> {
> if(stat & OREAD(sc, FWOHCI_INTMASK))
> - device_printf(fc->dev, "INTERRUPT < %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s
> %s%s%s%s%s%s> 0x%08x, 0x%08x\n",
> + device_printf(sc->fc.dev, "INTERRUPT < %s%s%s%s%s%s%s%s%s%s%s%s%s
> %s%s%s%s%s%s%s%s> 0x%08x, 0x%08x\n",
> stat & OHCI_INT_EN ? "DMA_EN ":"",
> stat & OHCI_INT_PHY_REG ? "PHY_REG ":"",
> stat & OHCI_INT_CYC_LONG ? "CYC_LONG ":"",
> @@ -1848,7 +1860,7 @@
> fc->status = FWBUSRESET;
> /* Disable bus reset interrupt until sid recv. */
> OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_PHY_BUS_R);
> -
> +
> device_printf(fc->dev, "%s: BUS reset\n", __func__);
> OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_CYC_LOST);
> OWRITE(sc, OHCI_LNKCTLCLR, OHCI_CNTL_CYCSRC);
> @@ -2037,7 +2049,7 @@
> return;
> }
> for (i = 0; i < plen / 4; i ++)
> - buf[i] = FWOHCI_DMA_READ(sc->sid_buf[i+1]);
> + buf[i] = FWOHCI_DMA_READ_UNI(sc->sid_buf[i+1]);
>
> /* pending all pre-bus_reset packets */
> fwohci_txd(sc, &sc->atrq);
> @@ -2068,6 +2080,7 @@
> fwohci_check_stat(struct fwohci_softc *sc)
> {
> uint32_t stat, irstat, itstat;
> + static int sid_count;
>
> FW_GLOCK_ASSERT(&sc->fc);
> stat = OREAD(sc, FWOHCI_INTSTAT);
> @@ -2076,8 +2089,14 @@
> "device physically ejected?\n");
> return (FILTER_STRAY);
> }
> - if (stat)
> +
> + if (stat && old_uninorth && (sid_count < 5)) {
> + OWRITE(sc, FWOHCI_INTSTATCLR,
> + stat & ~(OHCI_INT_PHY_BUS_R | OHCI_INT_PHY_SID));
> + sid_count++;
> + } else {
> OWRITE(sc, FWOHCI_INTSTATCLR, stat & ~OHCI_INT_PHY_BUS_R);
> + }
>
> stat &= sc->intmask;
> if (stat == 0)
> @@ -2657,7 +2676,7 @@
> int i;
> #endif
>
> - ld0 = FWOHCI_DMA_READ(fp->mode.ld[0]);
> + ld0 = FWOHCI_DMA_READ_UNI(fp->mode.ld[0]);
> #if 0
> printf("ld0: x%08x\n", ld0);
> #endif
> @@ -2690,7 +2709,7 @@
> }
> #if BYTE_ORDER == BIG_ENDIAN
> for(i = 0; i < slen/4; i ++)
> - fp->mode.ld[i] = FWOHCI_DMA_READ(fp->mode.ld[i]);
> + fp->mode.ld[i] = FWOHCI_DMA_READ_UNI(fp->mode.ld[i]);
> #endif
> return(hlen);
> }
> @@ -2884,7 +2903,7 @@
> printf("nvec == 0\n");
>
> /* DMA result-code will be written at the tail of packet */
> - stat = FWOHCI_DMA_READ(*(uint32_t *)(ld - sizeof(struct
> fwohci_trailer)));
> + stat = FWOHCI_DMA_READ_UNI(*(uint32_t *)(ld - sizeof(struct
> fwohci_trailer)));
> #if 0
> printf("plen: %d, stat %x\n",
> plen ,stat);
> Index: sys/dev/firewire/fwohcireg.h
> ===================================================================
> --- sys/dev/firewire/fwohcireg.h (revision 198452)
> +++ sys/dev/firewire/fwohcireg.h (working copy)
> @@ -73,6 +73,7 @@
> #define FW_DEVICE_R5C552 (0x0552 << 16)
> #define FW_DEVICE_PANGEA (0x0030 << 16)
> #define FW_DEVICE_UNINORTH (0x0031 << 16)
> +#define FW_DEVICE_UNINORTH_V1 (0x0018 << 16)
> #define FW_DEVICE_AIC5800 (0x5800 << 16)
> #define FW_DEVICE_FW322 (0x5811 << 16)
> #define FW_DEVICE_7007 (0x7007 << 16)
> Index: sys/dev/firewire/fwohcivar.h
> ===================================================================
> --- sys/dev/firewire/fwohcivar.h (revision 198452)
> +++ sys/dev/firewire/fwohcivar.h (working copy)
> @@ -75,6 +75,7 @@
> struct task fwohci_task_sid;
> struct task fwohci_task_dma;
> int cycle_lost;
> + int old_uninorth;
> } fwohci_softc_t;
>
> void fwohci_intr (void *arg);

Re: [Fwd: Re: firewire issue]

2009-10-26T12:48:56Z

Fabio,

I do not know what the issue is.

Sean Bruno wrote:
> Look over this patch from Andreas. I haven't done anything with it as I
> don't have the h/w to test with.

Please use the attached diff instead, it might bring you a bit further.

It is still not the final thing, but I did not have the time to follow
up here. Busy with other stuff.

The patch forwared from Sean is a bit old.

Regards,
Andreas

Index: sys/dev/firewire/fwohci_pci.c
===================================================================
--- sys/dev/firewire/fwohci_pci.c (revision 198452)
+++ sys/dev/firewire/fwohci_pci.c (working copy)
@@ -196,6 +196,10 @@
device_set_desc(dev, "Apple UniNorth");
return BUS_PROBE_DEFAULT;
}
+ if (id == (FW_VENDORID_APPLE | FW_DEVICE_UNINORTH_V1)) {
+ device_set_desc(dev, "Apple UniNorth, v1");
+ return BUS_PROBE_DEFAULT;
+ }
if (id == (FW_VENDORID_LUCENT | FW_DEVICE_FW322)) {
device_set_desc(dev, "Lucent FW322/323");
return BUS_PROBE_DEFAULT;
@@ -285,6 +289,10 @@
fwohci_softc_t *sc = device_get_softc(self);
int err;
int rid;
+ uint32_t id;
+
+ sc->old_uninorth = 0;
+
#if defined(__DragonFly__) || __FreeBSD_version < 500000
int intr;
/* For the moment, put in a message stating what is wrong */
@@ -383,6 +391,12 @@
return (ENOMEM);
}

+ id = pci_get_devid(self);
+ if (id == (FW_VENDORID_APPLE | FW_DEVICE_UNINORTH_V1)) {
+ sc->old_uninorth = 1;
+ device_printf(self, "Uninorth V1\n");
+ }
+
err = fwohci_init(sc, self);

if (err) {
Index: sys/dev/firewire/fwohci.c
===================================================================
--- sys/dev/firewire/fwohci.c (revision 198452)
+++ sys/dev/firewire/fwohci.c (working copy)
@@ -79,6 +79,7 @@
#undef OHCI_DEBUG

static int nocyclemaster = 0;
+static int old_uninorth = 0;
int firewire_phydma_enable = 1;
SYSCTL_DECL(_hw_firewire);
SYSCTL_INT(_hw_firewire, OID_AUTO, nocyclemaster, CTLFLAG_RW, &nocyclemaster, 0,
@@ -266,6 +267,15 @@

d_ioctl_t fwohci_ioctl;

+#if BYTE_ORDER == BIG_ENDIAN
+#define FWOHCI_DMA_READ_UNI(x) \
+ old_uninorth ? (x) : FWOHCI_DMA_READ(x)
+#define FWOHCI_DMA_WRITE_UNI(x,y) \
+ old_uninorth ? ((x) = (y)) : FWOHCI_DMA_WRITE(x,y)
+#else
+#define FWOHCI_DMA_READ_UNI(x) FWOHCI_DMA_READ(x)
+#define FWOHCI_DMA_WRITE_UNI(x,y) FWOHCI_DMA_WRITE(x,y)
+#endif
/*
* Communication with PHY device
*/
@@ -624,6 +634,8 @@
return (ENXIO);
}

+ old_uninorth = sc->old_uninorth;
+
/* Available Isochronous DMA channel probe */
OWRITE(sc, OHCI_IT_MASK, 0xffffffff);
OWRITE(sc, OHCI_IR_MASK, 0xffffffff);
@@ -1811,7 +1823,7 @@
fwohci_dump_intr(struct fwohci_softc *sc, uint32_t stat)
{
if(stat & OREAD(sc, FWOHCI_INTMASK))
- device_printf(fc->dev, "INTERRUPT < %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s> 0x%08x, 0x%08x\n",
+ device_printf(sc->fc.dev, "INTERRUPT < %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s> 0x%08x, 0x%08x\n",
stat & OHCI_INT_EN ? "DMA_EN ":"",
stat & OHCI_INT_PHY_REG ? "PHY_REG ":"",
stat & OHCI_INT_CYC_LONG ? "CYC_LONG ":"",
@@ -1848,7 +1860,7 @@
fc->status = FWBUSRESET;
/* Disable bus reset interrupt until sid recv. */
OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_PHY_BUS_R);
-
+
device_printf(fc->dev, "%s: BUS reset\n", __func__);
OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_CYC_LOST);
OWRITE(sc, OHCI_LNKCTLCLR, OHCI_CNTL_CYCSRC);
@@ -2037,7 +2049,7 @@
return;
}
for (i = 0; i < plen / 4; i ++)
- buf[i] = FWOHCI_DMA_READ(sc->sid_buf[i+1]);
+ buf[i] = FWOHCI_DMA_READ_UNI(sc->sid_buf[i+1]);

/* pending all pre-bus_reset packets */
fwohci_txd(sc, &sc->atrq);
@@ -2068,6 +2080,7 @@
fwohci_check_stat(struct fwohci_softc *sc)
{
uint32_t stat, irstat, itstat;
+ static int sid_count;

FW_GLOCK_ASSERT(&sc->fc);
stat = OREAD(sc, FWOHCI_INTSTAT);
@@ -2076,8 +2089,14 @@
"device physically ejected?\n");
return (FILTER_STRAY);
}
- if (stat)
+
+ if (stat && old_uninorth && (sid_count < 5)) {
+ OWRITE(sc, FWOHCI_INTSTATCLR,
+ stat & ~(OHCI_INT_PHY_BUS_R | OHCI_INT_PHY_SID));
+ sid_count++;
+ } else {
OWRITE(sc, FWOHCI_INTSTATCLR, stat & ~OHCI_INT_PHY_BUS_R);
+ }

stat &= sc->intmask;
if (stat == 0)
@@ -2657,7 +2676,7 @@
int i;
#endif

- ld0 = FWOHCI_DMA_READ(fp->mode.ld[0]);
+ ld0 = FWOHCI_DMA_READ_UNI(fp->mode.ld[0]);
#if 0
printf("ld0: x%08x\n", ld0);
#endif
@@ -2690,7 +2709,7 @@
}
#if BYTE_ORDER == BIG_ENDIAN
for(i = 0; i < slen/4; i ++)
- fp->mode.ld[i] = FWOHCI_DMA_READ(fp->mode.ld[i]);
+ fp->mode.ld[i] = FWOHCI_DMA_READ_UNI(fp->mode.ld[i]);
#endif
return(hlen);
}
@@ -2884,7 +2903,7 @@
printf("nvec == 0\n");

/* DMA result-code will be written at the tail of packet */
- stat = FWOHCI_DMA_READ(*(uint32_t *)(ld - sizeof(struct fwohci_trailer)));
+ stat = FWOHCI_DMA_READ_UNI(*(uint32_t *)(ld - sizeof(struct fwohci_trailer)));
#if 0
printf("plen: %d, stat %x\n",
plen ,stat);
Index: sys/dev/firewire/fwohcireg.h
===================================================================
--- sys/dev/firewire/fwohcireg.h (revision 198452)
+++ sys/dev/firewire/fwohcireg.h (working copy)
@@ -73,6 +73,7 @@
#define FW_DEVICE_R5C552 (0x0552 << 16)
#define FW_DEVICE_PANGEA (0x0030 << 16)
#define FW_DEVICE_UNINORTH (0x0031 << 16)
+#define FW_DEVICE_UNINORTH_V1 (0x0018 << 16)
#define FW_DEVICE_AIC5800 (0x5800 << 16)
#define FW_DEVICE_FW322 (0x5811 << 16)
#define FW_DEVICE_7007 (0x7007 << 16)
Index: sys/dev/firewire/fwohcivar.h
===================================================================
--- sys/dev/firewire/fwohcivar.h (revision 198452)
+++ sys/dev/firewire/fwohcivar.h (working copy)
@@ -75,6 +75,7 @@
struct task fwohci_task_sid;
struct task fwohci_task_dma;
int cycle_lost;
+ int old_uninorth;
} fwohci_softc_t;

void fwohci_intr (void *arg);

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

[Fwd: Re: firewire issue]

2009-10-26T12:31:12Z

Look over this patch from Andreas. I haven't done anything with it as I
don't have the h/w to test with.

Sean

Sean Bruno wrote:

> On Mon, 2009-05-25 at 22:30 +0200, Andreas Tobler wrote:
>> Sean Bruno wrote:
>>> On Mon, 2009-05-25 at 21:59 +0200, Andreas Tobler wrote:
>>>> Sean Bruno wrote:
>>>>> On Sun, 2009-05-24 at 22:57 +0200, Andreas Tobler wrote:
>>>>>> Sean Bruno wrote:
>>>>>>> On Sat, 2009-05-23 at 22:48 +0200, Andreas Tobler wrote:
>>>>>>>> Sean Bruno wrote:
>>>>>>>>> On Tue, 2009-05-19 at 06:49 +0200, Andreas Tobler wrote:
>>>>>>>>>> Sean Bruno wrote:
>>>>>>>>>>> Hey ... do you have the IEEE firewire specifications?
>>>>>>>>>>>
>>>>>>>>>>> I have them if you would like a copy.
>>>>>>>>>> Yes, please.
>>>>>>>>>>
>>>>>>>>>> Andreas
>>>>>>>>> http://consultcsg.com/firewire.tar.gz
>>>>>>>>>
>>>>>>>>> Everything I have.
>>>>>>>> Thank you!
>>>>>>>>
>>>>>>>> The docs confirmed that it is not a protocol issue.
>>>>>>>> Here I fight with silicon, I need to find out why the bus reset doesn't
>>>>>>>> behave as expected.
>>>>>>>> My current mods let me discover the attached fw disk. Unfortunately a
>>>>>>>> bus reset kills further operation.
>>>>>>>>
>>>>>>>> So I have to investigate in this direction...
>>>>>>>>
>>>>>>>> Anyway, thanks again for the standards.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Andreas
>>>>>>> I would *assume* that linux had dealt with this. However, I don't see
>>>>>>> any other FreeBSD users complaining about their G3's ... Is this problem
>>>>>>> specific to the Mac that you have, or is affecting all of the G3's?
>>>>>> I don't know if Linux finally dealt with this issue. I asked the fw guy
>>>>>> on the Linux side and he couldn't confirm if the issue is solved. I need
>>>>>> to ask BenH, the chief crack.
>>>>>>
>>>>>> It only affects the machines with
>>>>>> #define FW_DEVICE_UNINORTH_V1 (0x0018 << 16)
>>>>>> and
>>>>>> #define FW_VENDORID_APPLE 0x106b
>>>>>>
>>>>>> It is an old machine, but this hardware really rocks under *BSD iso. Darwin.
>>>>>>
>>>>>> And true, it is not lifetime critical :)
>>>>>>
>>>>>>
>>>>>> It is more a prove of concept.
>>>>>>
>>>>>> Andreas
>>>>> Interesting. Ask the freebsd-hackers list if anyone can reproduce the
>>>>> issue on the same hardware.
>>>> hehe, I doubt, but it might be chance.
>>>>
>>>> Btw, I noticed a panic when trying my mods with your latest patch you
>>>> sent me, the one for sparc64.
>>>> My mods are only related to byteswapping of packets. And there is no
>>>> device attached.
>>>>
>>>> I have to type the panic by hand:
>>>>
>>>> fwohci0: initiate bus reset
>>>> fwohci0: fwphy_rddata:: 0x1, retry=6
>>>> Sleeping thread (tid 100069, pid 840) owns a non-sleepable lock
>>>> mi_switch
>>>> sleepq_switch
>>>> sleepq_timedwait
>>>> _sleep
>>>> pause
>>>> fwphy_rddata
>>>> fwphy_wrdata
>>>> fwohci_ibr
>>>> firewire_attach
>>>> device_attach
>>>> device_probe_and_attach
>>>> fwohci_pci_add_child
>>>> firewire_identify
>>>> ....
>>>>
>>>> Any blinking leds on your side?
>>>>
>>>> I wonder why fwohci_ibr is coming in that early?
>>>>
>>>> Is this correct?
>>>>
>>>> Andreas
>>>>
>>> Ok, so your modifications without my changes for the card you have in
>>> your sparc64 don't panic? That would be wierd.
>> Aehm, I meant to say that your patch and my mods produce this panic on
>> the iMac. The sparc64 is in sleep mode until I get the second cpu. And I
>> doubt that my mods will panic the sparc64.
>>
>> I tested my mods against a newer PowerBook and an i386 and I took care
>> that I do not break existing functionalitiy. Also, my mods are towards
>> current svn. I only wondered if your patch might help here in my imac case.
>>
>>> Also, can you send me the pciconf -lv for the sparc64 board that I
>>> changed the code for?
>> I will, but as said, currently it is shutdown.
>>
>> Andreas
>
>
> Ah. Ok, please send me your current diff and I'll look at it.

Attached, I'm not happy with, but it is wip.

The mod in the firewire.c where I don't set the max_nod to -1 is
necessary to prohibit an infinite loop. The BusReset sets the max_node
to -1 and currently I can't set it to a meaningful value.

Below the messages w/o debug. the "< ------ this one" bothers me.
There is one disk attached. firewire and sbp loaded via kldload.
So far it looks correct to me except the bus resets?

Andreas

May 25 23:02:04 imacb kernel: fwohci0: <Apple UniNorth, v1> mem
0xf5000000-0xf5000fff irq 40 at device 14.0 on pci2
May 25 23:02:04 imacb kernel: fwohci0: [ITHREAD]
May 25 23:02:04 imacb kernel: fwohci0: Uninorth v1
May 25 23:02:04 imacb kernel: fwohci0: OHCI version 1.0 (ROM=0)
May 25 23:02:04 imacb kernel: fwohci0: No. of Isochronous channels is 4.
May 25 23:02:04 imacb kernel: fwohci0: EUI64 00:30:65:ff:fe:aa:7c:d0
May 25 23:02:04 imacb kernel: fwohci0: Phy 1394a available S400, 2 ports.
May 25 23:02:04 imacb kernel: fwohci0: Link S400, max_rec 2048 bytes.
May 25 23:02:04 imacb kernel: firewire0: <IEEE1394(FireWire) bus> on fwohci0
May 25 23:02:04 imacb kernel: fwohci0: Initiate bus reset
May 25 23:02:04 imacb kernel: fwohci0: fwohci_intr_core: BUS reset
status: 0xffffffff
May 25 23:02:04 imacb kernel: fwohci0: fwohci_intr_core: enable bus
reset interrupt
May 25 23:02:04 imacb kernel: fwohci0: fwohci_intr_core:
node_id=0x00000001, SelfID Count=1, CYCLEMASTER mode
May 25 23:02:04 imacb kernel: firewire0: 2 nodes, maxhop <= 1 cable IRM
irm(1) (me)
May 25 23:02:04 imacb kernel: firewire0: bus manager 1
May 25 23:02:04 imacb kernel: fwohci0: fwohci_intr_core: BUS reset
status: 0x6 < ------ this one
May 25 23:02:04 imacb kernel: fwohci0: txd err= 3 miss Ack err
May 25 23:02:05 imacb kernel: fwohci0: fwohci_intr_core: BUS reset
status: 0x5 < ------ this one
May 25 23:02:05 imacb kernel: firewire0: fw_explore_node: Pre 1394a-2000
detected
May 25 23:02:05 imacb kernel: firewire0: New S400 device ID:0050770e00002fd8
May 25 23:02:13 imacb kernel: sbp0: <SBP-2/SCSI over FireWire> on firewire0
May 25 23:02:13 imacb kernel: sbp0: sbp_show_sdev_info: sbp0:0:0:
ordered:1 type:14 EUI:0050770e00002fd8 node:0 speed:2 maxrec:8
May 25 23:02:13 imacb kernel: sbp0: sbp_show_sdev_info: sbp0:0:0
'Prolific PL3507 Combo Device' '(1394 ATAPI,Rev 1.00)' '012804'
May 25 23:02:14 imacb kernel: fwohci0: fwohci_intr_core: BUS reset
status: 0x7 < ---- this one

Index: fwohci_pci.c
===================================================================
--- fwohci_pci.c (revision 192695)
+++ fwohci_pci.c (working copy)
@@ -196,6 +196,10 @@
device_set_desc(dev, "Apple UniNorth");
return BUS_PROBE_DEFAULT;
}
+ if (id == (FW_VENDORID_APPLE | FW_DEVICE_UNINORTH_V1)) {
+ device_set_desc(dev, "Apple UniNorth, v1");
+ return BUS_PROBE_DEFAULT;
+ }
if (id == (FW_VENDORID_LUCENT | FW_DEVICE_FW322)) {
device_set_desc(dev, "Lucent FW322/323");
return BUS_PROBE_DEFAULT;
@@ -285,6 +289,10 @@
fwohci_softc_t *sc = device_get_softc(self);
int err;
int rid;
+ uint32_t id;
+
+ sc->old_uninorth = 0;
+
#if defined(__DragonFly__) || __FreeBSD_version < 500000
int intr;
/* For the moment, put in a message stating what is wrong */
@@ -383,6 +391,12 @@
return (ENOMEM);
}

+ id = pci_get_devid(self);
+ if (id == (FW_VENDORID_APPLE | FW_DEVICE_UNINORTH_V1)) {
+ sc->old_uninorth = 1;
+ device_printf(self, "Uninorth v1\n");
+ }
+
err = fwohci_init(sc, self);

if (err) {
Index: firewire.c
===================================================================
--- firewire.c (revision 192695)
+++ firewire.c (working copy)
@@ -77,7 +77,7 @@
struct crom_chunk hw;
};

-int firewire_debug=0, try_bmr=1, hold_count=0;
+int firewire_debug=2, try_bmr=1, hold_count=0;
SYSCTL_INT(_debug, OID_AUTO, firewire_debug, CTLFLAG_RW, &firewire_debug, 0,
"FireWire driver debug flag");
SYSCTL_NODE(_hw, OID_AUTO, firewire, CTLFLAG_RD, 0, "FireWire Subsystem");
@@ -632,7 +632,7 @@
CSRARC(fc, TOPO_MAP + 8) = 0;
fc->irm = -1;

- fc->max_node = -1;
+ /*fc->max_node = -1; */

for(i = 2; i < 0x100/4 - 2 ; i++){
CSRARC(fc, SPED_MAP + i * 4) = 0;
Index: fwohci.c
===================================================================
--- fwohci.c (revision 192695)
+++ fwohci.c (working copy)
@@ -79,6 +79,7 @@
#undef OHCI_DEBUG

static int nocyclemaster = 0;
+static int old_uninorth = 0;
int firewire_phydma_enable = 1;
SYSCTL_DECL(_hw_firewire);
SYSCTL_INT(_hw_firewire, OID_AUTO, nocyclemaster, CTLFLAG_RW, &nocyclemaster, 0,
@@ -266,6 +267,15 @@

d_ioctl_t fwohci_ioctl;

+#if BYTE_ORDER == BIG_ENDIAN
+#define FWOHCI_DMA_READ_UNI(x) \
+ old_uninorth ? (x) : FWOHCI_DMA_READ(x)
+#define FWOHCI_DMA_WRITE_UNI(x,y) \
+ old_uninorth ? ((x) = (y)) : FWOHCI_DMA_WRITE(x,y)
+#else
+#define FWOHCI_DMA_READ_UNI(x) FWOHCI_DMA_READ(x)
+#define FWOHCI_DMA_WRITE_UNI(x,y) FWOHCI_DMA_WRITE(x,y)
+#endif
/*
* Communication with PHY device
*/
@@ -624,6 +634,8 @@
return (ENXIO);
}

+ old_uninorth = sc->old_uninorth;
+
/* Available Isochronous DMA channel probe */
OWRITE(sc, OHCI_IT_MASK, 0xffffffff);
OWRITE(sc, OHCI_IR_MASK, 0xffffffff);
@@ -952,7 +964,7 @@
if (tcode == FWTCODE_WREQQ || tcode == FWTCODE_RRESQ)
hdr_len = 12;
for (i = 0; i < hdr_len/4; i ++)
- FWOHCI_DMA_WRITE(ld[i], ld[i]);
+ FWOHCI_DMA_WRITE(ld[i], ld[i]);
#endif

again:
@@ -1811,7 +1823,7 @@
fwohci_dump_intr(struct fwohci_softc *sc, uint32_t stat)
{
if(stat & OREAD(sc, FWOHCI_INTMASK))
- device_printf(fc->dev, "INTERRUPT < %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s> 0x%08x, 0x%08x\n",
+ device_printf(sc->fc.dev, "INTERRUPT < %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s> 0x%08x, 0x%08x\n",
stat & OHCI_INT_EN ? "DMA_EN ":"",
stat & OHCI_INT_PHY_REG ? "PHY_REG ":"",
stat & OHCI_INT_CYC_LONG ? "CYC_LONG ":"",
@@ -1845,11 +1857,13 @@

FW_GLOCK_ASSERT(fc);
if ((stat & OHCI_INT_PHY_BUS_R) && (fc->status != FWBUSRESET)) {
- fc->status = FWBUSRESET;
+
/* Disable bus reset interrupt until sid recv. */
OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_PHY_BUS_R);

- device_printf(fc->dev, "%s: BUS reset\n", __func__);
+ device_printf(fc->dev, "%s: BUS reset status: 0x%x\n",
+ __func__, fc->status);
+ fc->status = FWBUSRESET;
OWRITE(sc, FWOHCI_INTMASKCLR, OHCI_INT_CYC_LOST);
OWRITE(sc, OHCI_LNKCTLCLR, OHCI_CNTL_CYCSRC);

@@ -1863,6 +1877,8 @@
}
if (stat & OHCI_INT_PHY_SID) {
/* Enable bus reset interrupt */
+ device_printf(fc->dev, "%s: enable bus reset interrupt\n",
+ __func__);
OWRITE(sc, FWOHCI_INTSTATCLR, OHCI_INT_PHY_BUS_R);
OWRITE(sc, FWOHCI_INTMASK, OHCI_INT_PHY_BUS_R);

@@ -2037,7 +2053,7 @@
return;
}
for (i = 0; i < plen / 4; i ++)
- buf[i] = FWOHCI_DMA_READ(sc->sid_buf[i+1]);
+ buf[i] = FWOHCI_DMA_READ_UNI(sc->sid_buf[i+1]);

/* pending all pre-bus_reset packets */
fwohci_txd(sc, &sc->atrq);
@@ -2076,9 +2092,12 @@
"device physically ejected?\n");
return (FILTER_STRAY);
}
- if (stat)
- OWRITE(sc, FWOHCI_INTSTATCLR, stat & ~OHCI_INT_PHY_BUS_R);
+
+ if (stat) {
+ OWRITE(sc, FWOHCI_INTSTATCLR, stat & ~OHCI_INT_PHY_BUS_R);

+ }
+
stat &= sc->intmask;
if (stat == 0)
return (FILTER_STRAY);
@@ -2657,7 +2676,7 @@
int i;
#endif

- ld0 = FWOHCI_DMA_READ(fp->mode.ld[0]);
+ ld0 = FWOHCI_DMA_READ_UNI(fp->mode.ld[0]);
#if 0
printf("ld0: x%08x\n", ld0);
#endif
@@ -2690,7 +2709,7 @@
}
#if BYTE_ORDER == BIG_ENDIAN
for(i = 0; i < slen/4; i ++)
- fp->mode.ld[i] = FWOHCI_DMA_READ(fp->mode.ld[i]);
+ fp->mode.ld[i] = FWOHCI_DMA_READ_UNI(fp->mode.ld[i]);
#endif
return(hlen);
}
@@ -2884,7 +2903,7 @@
printf("nvec == 0\n");

/* DMA result-code will be written at the tail of packet */
- stat = FWOHCI_DMA_READ(*(uint32_t *)(ld - sizeof(struct fwohci_trailer)));
+ stat = FWOHCI_DMA_READ_UNI(*(uint32_t *)(ld - sizeof(struct fwohci_trailer)));
#if 0
printf("plen: %d, stat %x\n",
plen ,stat);
Index: fwohcireg.h
===================================================================
--- fwohcireg.h (revision 192695)
+++ fwohcireg.h (working copy)
@@ -73,6 +73,7 @@
#define FW_DEVICE_R5C552 (0x0552 << 16)
#define FW_DEVICE_PANGEA (0x0030 << 16)
#define FW_DEVICE_UNINORTH (0x0031 << 16)
+#define FW_DEVICE_UNINORTH_V1 (0x0018 << 16)
#define FW_DEVICE_AIC5800 (0x5800 << 16)
#define FW_DEVICE_FW322 (0x5811 << 16)
#define FW_DEVICE_7007 (0x7007 << 16)
Index: fwohcivar.h
===================================================================
--- fwohcivar.h (revision 192695)
+++ fwohcivar.h (working copy)
@@ -75,6 +75,7 @@
struct task fwohci_task_sid;
struct task fwohci_task_dma;
int cycle_lost;
+ int old_uninorth;
} fwohci_softc_t;

void fwohci_intr (void *arg);

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Current problem reports assigned to freebsd-firewire@FreeBSD.org

2009-10-26T04:06:57Z

Current problem reports assigned to freebsd-firewire@FreeBSD.org

2009-10-19T04:06:51Z

Re: kern/139549: [firewire] reconnecting a firewire disk does not cause the disklabel to update correctly/invalidate the cache

2009-10-13T17:10:03Z

The following reply was made to PR kern/139549; it has been noted by GNATS.

From: Sean Bruno <sean.bruno@...>
To: bug-followup@..., dirkx@...
Cc:
Subject: Re: kern/139549: [firewire] reconnecting a firewire disk does not
cause the disklabel to update correctly/invalidate the cache
Date: Tue, 13 Oct 2009 17:08:03 -0700

pre-8.0 has a default of "3" set to the sysctl "firewire.hold_count" or
some such thing that keeps the disconnect/removal of a firewire device
from doing "things".

Try setting that value to "1" and see if the problem manifests itself.

Sean

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: kern/139549: [firewire] reconnecting a firewire disk does not cause the disklabel to update correctly/invalidate the cache

2009-10-12T17:07:51Z

Old Synopsis: reconnecting a firewire disk does not cause the disklabel to update correctly/invalidate the cache
New Synopsis: [firewire] reconnecting a firewire disk does not cause the disklabel to update correctly/invalidate the cache

Responsible-Changed-From-To: freebsd-bugs->freebsd-firewire
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Oct 13 00:06:45 UTC 2009
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=139549
_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Current problem reports assigned to freebsd-firewire@FreeBSD.org

2009-10-12T04:06:50Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/136946 firewire [fwohci] fwohci throws an"unrecoverable error" upon re
p kern/125673 firewire [firewire] [panic] FreeBSD7 panics when kldunloading f
o kern/122951 firewire [firewire] video-transfer via fwcontrol triggers a pan
o kern/118093 firewire [firewire] firewire bus reset hogs CPU, causing data t
p kern/114646 firewire [firewire] [patch] firewire fails after suspend/resume
o kern/113785 firewire [firewire] dropouts when playing DV on firewire
o kern/97208 firewire [firewire] System hangs / locks up when a firewire dis
o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w

8 problems total.

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: fwcontrol and Freebsd7.2

2009-10-11T15:46:24Z

I *think* that in 7.1 and higher, you might have to specify the "bus"
number of the camera.

"fwcontrol -u 0 -R orig.avi" or something.

Let me know if this helps.

Sean

On Sun, 2009-10-11 at 21:04 +0400, Alexander Laroinov wrote:

> i have a problem with FreeBSD 7.2 and video-camera Panasonic GS-NV47
>
> fwcontrol works with 7.0 but not work with 7.1 and 7.2
>
> $ fwcontrol -R orig.avi
> fwcontrol: detect_recv_fn: ioctl FW_SSTBUF: Bad file descriptor
>
>
> freebsd 7.1 and 7.2 don`t look my device, but 7.0 look.
>
>
>
> _______________________________________________
> freebsd-firewire@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
> To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

fwcontrol and Freebsd7.2

2009-10-11T10:04:31Z

i have a problem with FreeBSD 7.2 and video-camera Panasonic GS-NV47

fwcontrol works with 7.0 but not work with 7.1 and 7.2

$ fwcontrol -R orig.avi
fwcontrol: detect_recv_fn: ioctl FW_SSTBUF: Bad file descriptor

freebsd 7.1 and 7.2 don`t look my device, but 7.0 look.

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Current problem reports assigned to freebsd-firewire@FreeBSD.org

2009-10-05T04:06:50Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/136946 firewire [fwohci] fwohci throws an"unrecoverable error" upon re
p kern/125673 firewire [firewire] [panic] FreeBSD7 panics when kldunloading f
o kern/122951 firewire [firewire] video-transfer via fwcontrol triggers a pan
o kern/118093 firewire [firewire] firewire bus reset hogs CPU, causing data t
p kern/114646 firewire [firewire] [patch] firewire fails after suspend/resume
o kern/113785 firewire [firewire] dropouts when playing DV on firewire
o kern/97208 firewire [firewire] System hangs / locks up when a firewire dis
o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w

8 problems total.

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Firewire Work

2009-10-01T09:42:26Z

I moved to a seperate tracking branch at:
http://svn.freebsd.org/base/projects/sbruno_firewire

I'm trying to keep a patchset at:
http://consultcsg.com/firewire.diff

Right now, this patchset should allow the systems that hang with
"xpt_config" timeouts to boot normally. They may be non-function with
regards to firewire as I have hacked in a timeout to resume processing.

If this patchset allows your system to boot, I would love to know so
that I can continue to hack upon your machine and figure out what needs
to be adjusted to allow normal booting.

Sean

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: kern/136652: [firewire] Firewire-attached "WD My Book 1028" does not mount at boot but is OK if connected after boot.

2009-09-29T10:34:47Z

Synopsis: [firewire] Firewire-attached "WD My Book 1028" does not mount at boot but is OK if connected after boot.

State-Changed-From-To: open->closed
State-Changed-By: sbruno
State-Changed-When: Tue Sep 29 17:33:17 UTC 2009
State-Changed-Why:
User reports problem has cleared.

http://www.freebsd.org/cgi/query-pr.cgi?pr=136652
_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: FireWire Patch [8/HEAD]

2009-09-29T06:37:48Z

Sean Bruno <sean.bruno@...> writes:

> Ok folks, some time has passed and I was able to get some wisdom from
> the CAM folks in Colorado (Thanks Scott, Justin, Warner, Ken).
>
> For those of you experiencing boot failures with firewire/sbp enabled in
> your configuration, please try the following patch and let me see the
> full boot dmesg.
>
> This is an extensive patch that does "stuff" and "things". :-)
>
> Mainly, it should behave better at initialization time and play nice
> with CAM and the scheduler via a config_intrhook.
>
> Let me know --> http://consultcsg.com/firewire.diff

The box that exhibits the problem is currently repurposed for other
tasks. So I cannot test this at the moment. If no one else steps up to
test this, I can test it in a week or so.

Regards,
--
Julian Stecklina

The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners - Ernst Jan Plugge

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Current problem reports assigned to freebsd-firewire@FreeBSD.org

2009-09-28T04:06:52Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/136946 firewire [fwohci] fwohci throws an"unrecoverable error" upon re
o kern/136652 firewire [firewire] Firewire-attached "WD My Book 1028" does no
p kern/125673 firewire [firewire] [panic] FreeBSD7 panics when kldunloading f
o kern/122951 firewire [firewire] video-transfer via fwcontrol triggers a pan
o kern/118093 firewire [firewire] firewire bus reset hogs CPU, causing data t
p kern/114646 firewire [firewire] [patch] firewire fails after suspend/resume
o kern/113785 firewire [firewire] dropouts when playing DV on firewire
o kern/97208 firewire [firewire] System hangs / locks up when a firewire dis
o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w

9 problems total.

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: kern/136652: [firewire] Firewire-attached "WD My Book 1028" does not mount at boot but is OK if connected after boot.

2009-09-26T23:50:02Z

The following reply was made to PR kern/136652; it has been noted by GNATS.

From: Andrew Reilly <areilly@...>
To: bug-followup@..., areilly@...
Cc:
Subject: Re: kern/136652: [firewire] Firewire-attached "WD My Book 1028"
does not mount at boot but is OK if connected after boot.
Date: Sun, 27 Sep 2009 15:27:19 +1000

As of this weekend, I've had two consecutive boots that ran all
the way through to multi-user, unassisted. Thanks guys! I
suspect that this PR can be closed...

Cheers,

--
Andrew
_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

FireWire Patch [8/HEAD]

2009-09-26T00:23:31Z

Ok folks, some time has passed and I was able to get some wisdom from
the CAM folks in Colorado (Thanks Scott, Justin, Warner, Ken).

For those of you experiencing boot failures with firewire/sbp enabled in
your configuration, please try the following patch and let me see the
full boot dmesg.

This is an extensive patch that does "stuff" and "things". :-)

Mainly, it should behave better at initialization time and play nice
with CAM and the scheduler via a config_intrhook.

Let me know --> http://consultcsg.com/firewire.diff

Sean

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."

Re: FA-101 audio interface support

2009-09-22T10:10:02Z

My first step would be to try 8/HEAD and see if you get any better
results.

After that, I'd like to get access to the laptop in question(ssh).

Sean

On Mon, 2009-09-21 at 20:15 +0000, Alexey Dokuchaev wrote:
> fw_rcv: unknown response RRESQ(6) src=0x3f tl=0x19 rt=1
> data=0x6ed42504

_______________________________________________
freebsd-firewire@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@..."