On Thu, Apr 9, 2009 at 12:32 AM, Jeff Garzik wrote:
> 3) As a result, Timur's 'ahci' is no longer receiving interrupts. Presumably
> this means that BOTH of the following conditions are true
>
> a) INTX is disabled
> b) MSI is not available
>
> Today I am thinking we should either r
On Thu, 2009-04-09 at 01:32 -0400, Jeff Garzik wrote:
> Michael Ellerman wrote:
> > On Wed, 2009-04-08 at 23:23 -0500, Kumar Gala wrote:
> >> On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
> >>
> >>> On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
> On Wed, Apr 8, 2009 at 4:31 PM, Te
On Thu, Apr 9, 2009 at 12:32 AM, Jeff Garzik wrote:
> 3) As a result, Timur's 'ahci' is no longer receiving interrupts. Presumably
> this means that BOTH of the following conditions are true
>
> a) INTX is disabled
> b) MSI is not available
>
> Today I am thinking we should either re
Michael Ellerman wrote:
On Wed, 2009-04-08 at 23:23 -0500, Kumar Gala wrote:
On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo wrote:
Hmmm... for now,
I think it would be best to revert the orig
On Apr 8, 2009, at 11:38 PM, Michael Ellerman wrote:
On Wed, 2009-04-08 at 23:23 -0500, Kumar Gala wrote:
On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo wrote:
Hmmm... for now,
I think it w
On Wed, 2009-04-08 at 23:23 -0500, Kumar Gala wrote:
> On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
>
> > On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
> >> On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo wrote:
> >>> Hmmm... for now,
> >>> I think it would be best to revert the original
On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo wrote:
Hmmm... for now,
I think it would be best to revert the original change. Jeff, can
you
please do that?
Actually, give me a few days
On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
> On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo wrote:
> > Hmmm... for now,
> > I think it would be best to revert the original change. Jeff, can you
> > please do that?
>
> Actually, give me a few days before you do that. A colleague gave me
> s
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo wrote:
> Hmmm... for now,
> I think it would be best to revert the original change. Jeff, can you
> please do that?
Actually, give me a few days before you do that. A colleague gave me
some suggestions to debug this.
--
Timur Tabi
Linux kernel develop
Timur Tabi wrote:
> Tejun Heo wrote:
>
>> Yeah, right. The following patch should do the trick then.
>
> Thanks, I appreciate it. I get this output:
>
> XXX PCI_COMMAND=0x407
^
Yeah, that's INTX disable. Strange that the controller has the bit
set on boot. I'm curious wh
Tejun Heo wrote:
> Yeah, right. The following patch should do the trick then.
Thanks, I appreciate it. I get this output:
XXX PCI_COMMAND=0x407
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Timur Tabi wrote:
> Tejun Heo wrote:
>
>> Running "lspci -nnvvvxxx" before loading the driver should be enough.
>
> That might be difficult. My root file system is on my SATA drive.
> It'll be a while before I can build an NFS rootfs.
>
Yeah, right. The following patch should do the trick the
Tejun Heo wrote:
> Running "lspci -nnvvvxxx" before loading the driver should be enough.
That might be difficult. My root file system is on my SATA drive.
It'll be a while before I can build an NFS rootfs.
--
Timur Tabi
Linux kernel developer at Freescale
__
Timur Tabi wrote:
> On Tue, Apr 7, 2009 at 9:09 PM, Michael Ellerman
> wrote:
>
>> Have you confirmed that INTX is disabled before that call?
>
> How do I do that?
Running "lspci -nnvvvxxx" before loading the driver should be enough.
--
tejun
___
L
On Tue, Apr 7, 2009 at 9:09 PM, Michael Ellerman wrote:
> Have you confirmed that INTX is disabled before that call?
How do I do that?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozl
Michael Ellerman wrote:
On Tue, 2009-04-07 at 19:36 -0500, Timur Tabi wrote:
On Tue, Apr 7, 2009 at 6:57 PM, Tejun Heo wrote:
Hmmm... that means intx isn't set by default. I'm not sure what is
the right thing to do here. I think it's something which should be
handled by the PCI layer. Oh w
On Tue, 2009-04-07 at 19:36 -0500, Timur Tabi wrote:
> On Tue, Apr 7, 2009 at 6:57 PM, Tejun Heo wrote:
>
> > Hmmm... that means intx isn't set by default. I'm not sure what is
> > the right thing to do here. I think it's something which should be
> > handled by the PCI layer. Oh well, maybe w
On Tue, Apr 7, 2009 at 7:52 PM, Michael Ellerman wrote:
> Can you post some more details, or point us at a thread?
http://marc.info/?t=12391165216&r=1&w=2
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-de
On Tue, 2009-04-07 at 19:36 -0500, Timur Tabi wrote:
> On Tue, Apr 7, 2009 at 6:57 PM, Tejun Heo wrote:
>
> > Hmmm... that means intx isn't set by default. I'm not sure what is
> > the right thing to do here. I think it's something which should be
> > handled by the PCI layer. Oh well, maybe w
On Tue, Apr 7, 2009 at 6:57 PM, Tejun Heo wrote:
> Hmmm... that means intx isn't set by default. I'm not sure what is
> the right thing to do here. I think it's something which should be
> handled by the PCI layer. Oh well, maybe we should just revert the
> change and keep setting intx?
cc'in
20 matches
Mail list logo
