Re: [PATCH 1/2] firewire: endianess fix

[Gabriel Paubert]

On Mon, Mar 03, 2008 at 03:35:01PM +0100, Stefan Richter wrote:
> Gabriel Paubert wrote:
> > I have a Pismo which I use on a virtually
> > daily basis (and about to remove the last remnants of MacOS on it). 
> > However I have disabled Firewire because it would not sleep and wake 
> > up properly. 
> > 
> > I can test it on Wednesday with a 5GB fireflly disk from 2001.
> > 
> > Please tell me which configuration options I need to set for
> > Firewire (which stack, etc...).
> 
> Config options of the new stack:
> FIREWIRE=m
> FIREWIRE_OHCI=m
> FIREWIRE_SBP2=m
> 
> Config options of the old stack:
> IEEE1394=m
> IEEE1394_OHCI1394=m
> IEEE1394_SBP2=m
> and if desired also the other drivers for raw userspace access,
> isochronous I/O (alias video1394 even though it can also be used for
> other purposes), DV I/O, and IPv4 over 1394.
> 
> The two SBP2 drivers also need SCSI and BLK_DEV_SD a.k.a. SCSI disk
> support or/and BLK_DEV_SR a.k.a. SCSI CDROM support.
> 
> You can also set the options to Y but I find loadable and hence
> unloadable modules more practical... 'cause I unload and reload them all
> the time.  :-)

Indeed, although this machine typically had non-modular kernels, I
compiled one for these tests.

For now I have only tested the new stack with a 6 year old 1.8" disk
and everything works, including suspend to RAM. The kernel is 2.6.25-rc4
plus additional pull from linux1394-2.6.git: 2.6.25-rc4-00032-g8d36ba4.

Thanks a lot.

	Regards,
	Gabriel

P.S: it seems that something broke in the APM emulation around rc2
on this machine, battery level reads at -1% from /proc/apm.
> Caveats:
>   - You could build and install both stacks but should then blacklist
>     at least one of ohci1394 or firewire-ohci.  Better keep it simple
>     and install only one of the stacks at a time.
>   - We still have a serious use-after-free bug in the new stack.  This
>     may lead to kernel panic if the kernel was build with (slab? or
>     page allocation?) debugging enabled.
> Users of IP over 1394 and pro/semipro audio still need the old stack.
> Users of video should stick with the stack which their distribution has
> enabled because our support in the lowlevel libraries libraw1394 and
> libdc1394 to switch between the stacks is not quite comfortable yet.
> 
> Suspend (to RAM) and resume worked for me [TM] when I last tested them
> with each stack.  I tested i586/APM, x86-64/ACPI, and last weekend ppc32
> on 1st generation PowerBook G4.  I haven't tested hibernate (to disk)
> and restore yet.

I have never used suspend to disk on this machine. Suspend to RAM
failed when ieee1394 was loaded (or built-in) since 2.6.22 or so. 

For now I have only tested the new stack with a 6 year old 1.8" disk
and everything works, including suspend to RAM. The kernel is 2.6.25-rc4
plus additional pull from linux1394-2.6.git: 2.6.25-rc4-00032-g8d36ba4.

Thanks a lot.

	Regards,
	Gabriel

P.S: it seems that something broke in the APM emulation around rc2
on this machine, battery level reads at -1% from /proc/apm.
--
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/