On Mon, Jun 04, 2007 at 01:34:21PM -0700, Linus Torvalds wrote:
> Ok, I think everybody agreed.
>
> Jeff, do you want me to just take the patch you sent earlier if I can
> still find it, or should I pull it from somewhere (btw, the changelog
> should probably be fixed, since there were at least
On Mon, 4 Jun 2007, Alan Cox wrote:
> > At this point, I am only reluctant to push it for 2.6.22 since it is so
> > late in the -rc series.
> >
> > If we have another -rc, I would probably be OK with pushing it for
> > 2.6.22, otherwise I would prefer to wait for 2.6.23.
> >
> > Comments sol
> At this point, I am only reluctant to push it for 2.6.22 since it is so
> late in the -rc series.
>
> If we have another -rc, I would probably be OK with pushing it for
> 2.6.22, otherwise I would prefer to wait for 2.6.23.
>
> Comments solicited, from all involved...
Without a doubt it shou
On Sun, 3 Jun 2007, Jeff Garzik wrote:
>
> If we have another -rc, I would probably be OK with pushing it for 2.6.22,
> otherwise I would prefer to wait for 2.6.23.
We'll definitely have another -rc. I'll push -rc4 tonight, and while I'm
hoping that we'll have resolved a number of the regressi
On Sun, 3 Jun 2007, Bartlomiej Zolnierkiewicz wrote:
>
> The patch should be safe (drivers/ide has been doing SETXFER this way for
> ages) and fixes real user problems (which becomes even more important now as
> distros are converting to libata PATA).
I hadn't realized that Fedora 7 had convert
On Sun, 03 Jun 2007 12:00:51 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Tejun Heo wrote:
> > Several people have reported LITE-ON LTR-48246S detection failed
> > because SETXFER fails. It seems the device raises IRQ too early after
> > SETXFER. This is controller independent. The same probl
Hi,
On Sunday 03 June 2007, Jeff Garzik wrote:
> Tejun Heo wrote:
> > Several people have reported LITE-ON LTR-48246S detection failed
> > because SETXFER fails. It seems the device raises IRQ too early after
> > SETXFER. This is controller independent. The same problem has been
> > reported f
Tejun Heo wrote:
Several people have reported LITE-ON LTR-48246S detection failed
because SETXFER fails. It seems the device raises IRQ too early after
SETXFER. This is controller independent. The same problem has been
reported for different controllers.
So, now we have pata_via where the con
Several people have reported LITE-ON LTR-48246S detection failed
because SETXFER fails. It seems the device raises IRQ too early after
SETXFER. This is controller independent. The same problem has been
reported for different controllers.
So, now we have pata_via where the controller raises IRQ
Jeff Garzik wrote:
> Tejun Heo wrote:
>> So, I don't think the problem exists for SATA in the first place. At
>> least there hasn't been any report of it and doing SETXFER by polling
>> can handle all the existing cases. We can and probably should deal with
>> such SATA devices when and if they c
Tejun Heo wrote:
So, I don't think the problem exists for SATA in the first place. At
least there hasn't been any report of it and doing SETXFER by polling
can handle all the existing cases. We can and probably should deal with
such SATA devices when and if they come up. How are we gonna verif
>
> We are going to have to deal with the HSM issue underlying the need to
> do SET FEATURES - XFER MODE polling, and ultimately IDENTIFY DEVICE
> polling too.
>
> This is the main reason why I have resisted applying "[PATCH] libata:
> always use polling SETXFER"
ented as changing data fields in the packet stream.
We are going to have to deal with the HSM issue underlying the need to
do SET FEATURES - XFER MODE polling, and ultimately IDENTIFY DEVICE
polling too.
This is the main reason why I have resisted applying "[PATCH] libata:
always use polling
Tejun Heo wrote:
> Several people have reported LITE-ON LTR-48246S detection failed
> because SETXFER fails. It seems the device raises IRQ too early after
> SETXFER. This is controller independent. The same problem has been
> reported for different controllers.
>
> So, now we have pata_via whe
On Wednesday 14 March 2007, Tejun Heo wrote:
> Several people have reported LITE-ON LTR-48246S detection failed
> because SETXFER fails. It seems the device raises IRQ too early after
> SETXFER. This is controller independent. The same problem has been
> reported for different controllers.
>
>
Several people have reported LITE-ON LTR-48246S detection failed
because SETXFER fails. It seems the device raises IRQ too early after
SETXFER. This is controller independent. The same problem has been
reported for different controllers.
So, now we have pata_via where the controller raises IRQ
16 matches
Mail list logo
