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 proper
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
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.
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.
>
>
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 bu
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
> 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.
Those machines can netboot, or boot from USB. Might be easier
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
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
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.
> 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
> continu
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
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
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
Benjamin Herrenschmidt wrote:
> Do we have the workaround for the old Apple UniNorth in the new FW OHCI
> driver (for selfID swapping iirc ?)
According to ohci1394.c, it selfIDs and headers of incoming packets are
not byte-swapped by the old Apple Uninorth FireWire part. And no,
firewire-ohci d
> 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
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]>
> >
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
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
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: [
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 an
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
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
-=-==--- --=- ==-==
ht
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,
I wrote:
> If possible, also test whether the device remains accessible after
> forcing a bus reset, e.g. by "echo br short > firecontrol".
"echo br short | firecontrol" of course.
This test should actually not really be necessary because simply
plugging the SBP-2 device in should already cause e
25 matches
Mail list logo
