Re: [PATCH 1/2] firewire: endianess fix
On Thu, Mar 06, 2008 at 12:26:00AM +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. ... 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. That's great. Thanks for testing. The old stack also works. I forgot to mention that with the new stack (not with the old) there is a message when going to sleep: firewire_ohci: pci_set_power_state failed with -5 but it is harmless, and if I understand correctly due to the fact that the power management on this chip is not implemented through capability fields in the PCI configuration space. Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
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. ... 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. That's great. Thanks for testing. -- Stefan Richter -=-==--- --== --==- http://arcgraph.de/sr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On Fri, Feb 29, 2008 at 12:48:33AM -0500, Jarod Wilson wrote: Benjamin Herrenschmidt wrote: On Thu, 2008-02-28 at 13:42 -0500, Jarod Wilson wrote: On Thursday 28 February 2008 01:25:59 am Benjamin Herrenschmidt wrote: Under Mac OS X, system.log says FireWire (OHCI) Apple ID 31 built-in now active. Could still be lucent though, judging by the subsys device ID of 5811, which matches up w/the Lucent/Agere FW323. But no, apparently I don't have the interesting one. Well, it's interesting in the sense that it's a normal OHCI then on a BE machine :-) My Pismo, which had the weirdo one, unfortunately died a while ago. I'll see if I can find another machine with that one in. Ah, the pismo has it, eh? I think I may actually know of someone in the office that still has one of those that I might be able to borrow and poke at... I -think- it has it... Pismo definitely has one of the first variant of UniNorth with working FW afaik. The first UniNorth was used in the first toilet-seat ibook, but I think this one didn't have firewire, or a non-working one... and in the first Sawtooth G4 for which FW and Ethernet even were separate PCI chips because the ones in UniNorth were too broken. It's possible that early G4 titanium powerbooks or other model of FW iBooks have that UniNorth FW variant too. Still no luck finding one here. The person I was thinking of has a Lombard, which has no firewire. I did get ahold of a 667MHz Titanium, but its got an Agere FW323. Pretty sure my old man actually has a Pismo, but its about a 3000 mile drive over to my folks house. The search continues... I wonder how many people still actually 1) have a machine with this controller, 2) are running Linux on it and 3) use firewire devices with it. Both of you, please speak up, we're trying to help you! (if only out of morbid curiosity to see this mythical goofy controller). Definitely yes to 1) and 2), 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...). Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
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. :-) Regarding which of the two stacks to build: If you are going to test FireWire with a storage device only, then you can choose either stack. 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. For successful resume on the Pismo with the new stack, you will most certainly need the brand new patches which add PPC_PMAC platform support to firewire-ohci. From what I saw with the PowerBook, you will also need the UniNorth rev1 related patch. I wasn't able to fully test that patch though because the electrical interface of my PowerBook's onboard FireWire is dead. You can get the patches from kernel.org's linux1394-2.6.git (master branch, close to Linus's latest linux-2.6.git) or http://me.in-berlin.de/~s5r6/linux1394/updates/ (for a few kernel.org kernels). The old stack as found in any remotely recent 2.6 kernel should be OK out of the box without patches... in theory. I wouldn't be surprised of until now unreported bugs or old reported but forgotten bugs though. -- Stefan Richter -=-==--- --== ---== http://arcgraph.de/sr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On 23 Feb, I wrote: This needs to be tested on different big endian PCs, if possible with the Apple Uninorth FireWire controller and other types of controllers. I tested it myself now with VT6306 on PPC32. it should be triggered by replacing fw_high_memory_region by fw_private_region in drivers/firewire/fw-sbp2.c and testing with any SBP-2 device This indeed demonstrates the fix. Any IO to SBP-2 devices fails with timeouts. Just removing the posted write enable bit in fw-ohci wasn't sufficient to catch it though. Maybe the controller has write posting enabled by default. However, this endianess bug was low-profile because there are currently no kernelspace or userspace drivers for the firewire stack which need to respond in split transactions. -- Stefan Richter -=-==--- --== = http://arcgraph.de/sr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
Jarod Wilson writes: Still no luck finding one here. The person I was thinking of has a Lombard, which has no firewire. I did get ahold of a 667MHz Titanium, but its got an Agere FW323. Pretty sure my old man actually has a Pismo, but its about a 3000 mile drive over to my folks house. The search continues... I wonder how many people still actually 1) have a machine with this controller, 2) are running Linux on it and 3) use firewire devices with it. Both of you, please speak up, we're trying to help you! (if only out of morbid curiosity to see this mythical goofy controller). I have a first-generation titanium powerbook that has this controller (assuming we're talking about vendor/device id = 0x106b / 0x18), and yes I run Linux (only) on it and use firewire disks. :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
Paul Mackerras wrote: Jarod Wilson writes: I wonder how many people still actually 1) have a machine with this controller, 2) are running Linux on it and 3) use firewire devices with it. Both of you, please speak up, we're trying to help you! (if only out of morbid curiosity to see this mythical goofy controller). I have a first-generation titanium powerbook that has this controller (assuming we're talking about vendor/device id = 0x106b / 0x18), and yes I run Linux (only) on it and use firewire disks. :) I actually have a TiBook 400 myself, but so far without Linux, and its FireWire PHY is dead. But I can use CardBus FireWire cards on it to do basic testing on a big endian PC, and I can test the selfID byte-swapping by the PHY-less onboard controller. I now started a Fedora 8 live CD (self-test says the medium is corrupt... need to burn another one) and dmesg says: firewire_ohci: Added fw-ohci device 0002:24:0e.0, OHCI version 1.0 firewire_ohci: recursive bus reset detected, discarding self ids [...] The second line looks like this is indeed one of those which needs the header byte-swap workaround which ohci1394 has but firewire-ohci hasn't yet. On the weekend I'm going to attempt to put Linux on this PowerBook, at last. -- Stefan Richter -=-==--- --=- ===-= http://arcgraph.de/sr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On Friday 29 February 2008 06:26:34 am Paul Mackerras wrote: Jarod Wilson writes: Still no luck finding one here. The person I was thinking of has a Lombard, which has no firewire. I did get ahold of a 667MHz Titanium, but its got an Agere FW323. Pretty sure my old man actually has a Pismo, but its about a 3000 mile drive over to my folks house. The search continues... I wonder how many people still actually 1) have a machine with this controller, 2) are running Linux on it and 3) use firewire devices with it. Both of you, please speak up, we're trying to help you! (if only out of morbid curiosity to see this mythical goofy controller). I have a first-generation titanium powerbook that has this controller (assuming we're talking about vendor/device id = 0x106b / 0x18), and yes I run Linux (only) on it and use firewire disks. :) Yup, seems that's the one. Sounds like we had another one hiding in plain site in Stefan's hands too, the thing just was meeting criterion #2. ;) -- Jarod Wilson [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On Thursday 28 February 2008 01:25:59 am Benjamin Herrenschmidt wrote: Under Mac OS X, system.log says FireWire (OHCI) Apple ID 31 built-in now active. Could still be lucent though, judging by the subsys device ID of 5811, which matches up w/the Lucent/Agere FW323. But no, apparently I don't have the interesting one. Well, it's interesting in the sense that it's a normal OHCI then on a BE machine :-) My Pismo, which had the weirdo one, unfortunately died a while ago. I'll see if I can find another machine with that one in. Ah, the pismo has it, eh? I think I may actually know of someone in the office that still has one of those that I might be able to borrow and poke at... -- Jarod Wilson [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On Thu, 2008-02-28 at 13:42 -0500, Jarod Wilson wrote: On Thursday 28 February 2008 01:25:59 am Benjamin Herrenschmidt wrote: Under Mac OS X, system.log says FireWire (OHCI) Apple ID 31 built-in now active. Could still be lucent though, judging by the subsys device ID of 5811, which matches up w/the Lucent/Agere FW323. But no, apparently I don't have the interesting one. Well, it's interesting in the sense that it's a normal OHCI then on a BE machine :-) My Pismo, which had the weirdo one, unfortunately died a while ago. I'll see if I can find another machine with that one in. Ah, the pismo has it, eh? I think I may actually know of someone in the office that still has one of those that I might be able to borrow and poke at... I -think- it has it... Pismo definitely has one of the first variant of UniNorth with working FW afaik. The first UniNorth was used in the first toilet-seat ibook, but I think this one didn't have firewire, or a non-working one... and in the first Sawtooth G4 for which FW and Ethernet even were separate PCI chips because the ones in UniNorth were too broken. It's possible that early G4 titanium powerbooks or other model of FW iBooks have that UniNorth FW variant too. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
Benjamin Herrenschmidt wrote: On Thu, 2008-02-28 at 13:42 -0500, Jarod Wilson wrote: On Thursday 28 February 2008 01:25:59 am Benjamin Herrenschmidt wrote: Under Mac OS X, system.log says FireWire (OHCI) Apple ID 31 built-in now active. Could still be lucent though, judging by the subsys device ID of 5811, which matches up w/the Lucent/Agere FW323. But no, apparently I don't have the interesting one. Well, it's interesting in the sense that it's a normal OHCI then on a BE machine :-) My Pismo, which had the weirdo one, unfortunately died a while ago. I'll see if I can find another machine with that one in. Ah, the pismo has it, eh? I think I may actually know of someone in the office that still has one of those that I might be able to borrow and poke at... I -think- it has it... Pismo definitely has one of the first variant of UniNorth with working FW afaik. The first UniNorth was used in the first toilet-seat ibook, but I think this one didn't have firewire, or a non-working one... and in the first Sawtooth G4 for which FW and Ethernet even were separate PCI chips because the ones in UniNorth were too broken. It's possible that early G4 titanium powerbooks or other model of FW iBooks have that UniNorth FW variant too. Still no luck finding one here. The person I was thinking of has a Lombard, which has no firewire. I did get ahold of a 667MHz Titanium, but its got an Agere FW323. Pretty sure my old man actually has a Pismo, but its about a 3000 mile drive over to my folks house. The search continues... I wonder how many people still actually 1) have a machine with this controller, 2) are running Linux on it and 3) use firewire devices with it. Both of you, please speak up, we're trying to help you! (if only out of morbid curiosity to see this mythical goofy controller). -- Jarod Wilson [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
Still no luck finding one here. The person I was thinking of has a Lombard, which has no firewire. I did get ahold of a 667MHz Titanium, but its got an Agere FW323. Pretty sure my old man actually has a Pismo, but its about a 3000 mile drive over to my folks house. The search continues... I wonder how many people still actually 1) have a machine with this controller, 2) are running Linux on it and 3) use firewire devices with it. Both of you, please speak up, we're trying to help you! (if only out of morbid curiosity to see this mythical goofy controller). First gen titanium (400/500 Mhz models) might... Paulus has one at home I think, I'll chase that up here. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
Jarod Wilson wrote: Works just fine with the Apple UniNorth controller in my powerbook in cursory testing. Could you remove the OHCI1394_HCControl_postedWriteEnable flag from fw-ohci.c::ohci_enable() and test without and with the endianess patch? -- Stefan Richter -=-==--- --=- ==-== http://arcgraph.de/sr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On Saturday 23 February 2008 06:24:17 am Stefan Richter wrote: The generation of incoming requests was filled in in wrong byte order on machines with big endian CPU. Signed-off-by: Stefan Richter [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org --- This patch is a shot in the dark, based on a warning when building with C=1 CHECKFLAGS=-D__CHECK_ENDIAN__. Is it really a fix, or was the previous code accidentally correct? This needs to be tested on different big endian PCs, if possible with the Apple Uninorth FireWire controller and other types of controllers. One test which involves ohci-request_generation is simply with an SBP-2 device (harddisk, CD-ROM...). Does SBP-2 login etc. work? Works just fine with the Apple UniNorth controller in my powerbook in cursory testing. Tested with multiple sbp2 hard disks, plugging and unplugging, mounting and unmounting, etc. If possible, also test whether the device remains accessible after forcing a bus reset, e.g. by echo br short firecontrol. You need the easy to build utility firecontrol and a libraw1394 with juju backend. See wiki.linux1394.org for directions. Forgot to check that it survived bus resets. Will try to double-check that tonight. I don't have any other ppc systems w/firewire controllers handy at the moment to try other controllers, but can probably manage to get one set up soon... -- Jarod Wilson [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On Wednesday 27 February 2008 03:08:32 pm Stefan Richter wrote: Jarod Wilson wrote: Works just fine with the Apple UniNorth controller in my powerbook in cursory testing. Could you remove the OHCI1394_HCControl_postedWriteEnable flag from fw-ohci.c::ohci_enable() and test without and with the endianess patch? Sure, added to the todo list along with making sure things survive bus resets. -- Jarod Wilson [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On Wed, 2008-02-27 at 14:58 -0500, Jarod Wilson wrote: On Saturday 23 February 2008 06:24:17 am Stefan Richter wrote: The generation of incoming requests was filled in in wrong byte order on machines with big endian CPU. Signed-off-by: Stefan Richter [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org --- This patch is a shot in the dark, based on a warning when building with C=1 CHECKFLAGS=-D__CHECK_ENDIAN__. Is it really a fix, or was the previous code accidentally correct? This needs to be tested on different big endian PCs, if possible with the Apple Uninorth FireWire controller and other types of controllers. One test which involves ohci-request_generation is simply with an SBP-2 device (harddisk, CD-ROM...). Does SBP-2 login etc. work? Works just fine with the Apple UniNorth controller in my powerbook in cursory testing. Tested with multiple sbp2 hard disks, plugging and unplugging, mounting and unmounting, etc. Which specific rev/version of the uninorth controller ? There is the interesting one has vendorID Apple and deviceID 0x0018, the normal ones have different deviceIDs (and are just lucent controllers afaik). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On Sat, 2008-02-23 at 12:24 +0100, Stefan Richter wrote: The generation of incoming requests was filled in in wrong byte order on machines with big endian CPU. Signed-off-by: Stefan Richter [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org --- This patch is a shot in the dark, based on a warning when building with C=1 CHECKFLAGS=-D__CHECK_ENDIAN__. Is it really a fix, or was the previous code accidentally correct? This needs to be tested on different big endian PCs, if possible with the Apple Uninorth FireWire controller and other types of controllers. One test which involves ohci-request_generation is simply with an SBP-2 device (harddisk, CD-ROM...). Does SBP-2 login etc. work? Do we have the workaround for the old Apple UniNorth in the new FW OHCI driver (for selfID swapping iirc ?) There are several variants of Apple OHCI's here, but afaik only one with a problem. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On Wednesday 27 February 2008 09:40:22 pm Benjamin Herrenschmidt wrote: On Wed, 2008-02-27 at 14:58 -0500, Jarod Wilson wrote: On Saturday 23 February 2008 06:24:17 am Stefan Richter wrote: The generation of incoming requests was filled in in wrong byte order on machines with big endian CPU. Signed-off-by: Stefan Richter [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org --- This patch is a shot in the dark, based on a warning when building with C=1 CHECKFLAGS=-D__CHECK_ENDIAN__. Is it really a fix, or was the previous code accidentally correct? This needs to be tested on different big endian PCs, if possible with the Apple Uninorth FireWire controller and other types of controllers. One test which involves ohci-request_generation is simply with an SBP-2 device (harddisk, CD-ROM...). Does SBP-2 login etc. work? Works just fine with the Apple UniNorth controller in my powerbook in cursory testing. Tested with multiple sbp2 hard disks, plugging and unplugging, mounting and unmounting, etc. Which specific rev/version of the uninorth controller ? lspci says Apple Computer Inc. UniNorth 2 FireWire (rev 81), pci id 106b:0031, subsys id 106b:5811. (Its a circa 2004 Aluminum 15 PowerBook G4 @ 1.67GHz, fwiw). There is the interesting one has vendorID Apple and deviceID 0x0018, the normal ones have different deviceIDs (and are just lucent controllers afaik). Under Mac OS X, system.log says FireWire (OHCI) Apple ID 31 built-in now active. Could still be lucent though, judging by the subsys device ID of 5811, which matches up w/the Lucent/Agere FW323. But no, apparently I don't have the interesting one. -- Jarod Wilson [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
On Wednesday 27 February 2008 02:58:28 pm Jarod Wilson wrote: On Saturday 23 February 2008 06:24:17 am Stefan Richter wrote: The generation of incoming requests was filled in in wrong byte order on machines with big endian CPU. Signed-off-by: Stefan Richter [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org --- This patch is a shot in the dark, based on a warning when building with C=1 CHECKFLAGS=-D__CHECK_ENDIAN__. Is it really a fix, or was the previous code accidentally correct? This needs to be tested on different big endian PCs, if possible with the Apple Uninorth FireWire controller and other types of controllers. One test which involves ohci-request_generation is simply with an SBP-2 device (harddisk, CD-ROM...). Does SBP-2 login etc. work? Works just fine with the Apple UniNorth controller in my powerbook in cursory testing. Tested with multiple sbp2 hard disks, plugging and unplugging, mounting and unmounting, etc. If possible, also test whether the device remains accessible after forcing a bus reset, e.g. by echo br short firecontrol. You need the easy to build utility firecontrol and a libraw1394 with juju backend. See wiki.linux1394.org for directions. Forgot to check that it survived bus resets. Will try to double-check that tonight. Survives bus resets just fine, including with ongoing I/O from an sbp2 disk. -- Jarod Wilson [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
Under Mac OS X, system.log says FireWire (OHCI) Apple ID 31 built-in now active. Could still be lucent though, judging by the subsys device ID of 5811, which matches up w/the Lucent/Agere FW323. But no, apparently I don't have the interesting one. Well, it's interesting in the sense that it's a normal OHCI then on a BE machine :-) My Pismo, which had the weirdo one, unfortunately died a while ago. I'll see if I can find another machine with that one in. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] firewire: endianess fix
The generation of incoming requests was filled in in wrong byte order on machines with big endian CPU. Signed-off-by: Stefan Richter [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org --- This patch is a shot in the dark, based on a warning when building with C=1 CHECKFLAGS=-D__CHECK_ENDIAN__. Is it really a fix, or was the previous code accidentally correct? This needs to be tested on different big endian PCs, if possible with the Apple Uninorth FireWire controller and other types of controllers. One test which involves ohci-request_generation is simply with an SBP-2 device (harddisk, CD-ROM...). Does SBP-2 login etc. work? If possible, also test whether the device remains accessible after forcing a bus reset, e.g. by echo br short firecontrol. You need the easy to build utility firecontrol and a libraw1394 with juju backend. See wiki.linux1394.org for directions. drivers/firewire/fw-ohci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/drivers/firewire/fw-ohci.c === --- linux.orig/drivers/firewire/fw-ohci.c +++ linux/drivers/firewire/fw-ohci.c @@ -375,7 +375,7 @@ static __le32 *handle_ar_packet(struct a */ if (p.ack + 16 == 0x09) - ohci-request_generation = (buffer[2] 16) 0xff; + ohci-request_generation = (p.header[2] 16) 0xff; else if (ctx == ohci-ar_request_ctx) fw_core_handle_request(ohci-card, p); else -- Stefan Richter -=-==--- --=- =-=== http://arcgraph.de/sr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] firewire: endianess fix
I wrote: This needs to be tested on different big endian PCs, if possible with the Apple Uninorth FireWire controller and other types of controllers. One test which involves ohci-request_generation is simply with an SBP-2 device (harddisk, CD-ROM...). Does SBP-2 login etc. work? Hmm, no, tests with SBP-2 devices won't trigger that problem at all. All of the requests from the device will be: - read requests to the host's config ROM, handled by the controller's physical response unit instead of the driver stack's response handlers, - read requests to ORBs and read and write requests to SCSI data buffers which are DMA-mapped at bus addresses below 4G, hence be handled by the physical response unit as well, - write requests to firewire-sbp2's status FIFO which is mapped into a FireWire address range for which PCI write posting is enabled, hence no response subaction will be generated (unified transaction) and therefore ohci-request_generation remain unused. Alas I have no idea how to create a simple test setup which really triggers the questionable code. Or wait, it should be triggered by replacing fw_high_memory_region by fw_private_region in drivers/firewire/fw-sbp2.c and testing with any SBP-2 device which is _not_ based on the PL3507 bridge chip. This moves the status FIFO into an area outside of PCI write posting and forces the driver stack to generate response packets. (Some PL-3507 only accept unified transactions, hence this test needs to be performed with other bridge chips.) -- Stefan Richter -=-==--- --=- =-=== http://arcgraph.de/sr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
