James Bottomley wrote:
On Mon, 2008-01-14 at 20:27 +0100, Hans de Goede wrote:
James Bottomley wrote:
Plus what is the rq->nr_sectors > sdp->sector_size /
512 test supposed to be doing? that being true is supposed to be a
guarantee of the block layer (and if something goes wrong there's a
chec
On Mon, 2008-01-14 at 20:27 +0100, Hans de Goede wrote:
> James Bottomley wrote:
> >>> Plus what is the rq->nr_sectors > sdp->sector_size /
> >>> 512 test supposed to be doing? that being true is supposed to be a
> >>> guarantee of the block layer (and if something goes wrong there's a
> >>> chec
James Bottomley wrote:
Plus what is the rq->nr_sectors > sdp->sector_size /
512 test supposed to be doing? that being true is supposed to be a
guarantee of the block layer (and if something goes wrong there's a
check for this lower down).
It first is was just:
rq->nr_sectors > 1
Then I change
Matthew Dharm wrote:
On Mon, Jan 14, 2008 at 10:33:08AM -0600, James Bottomley wrote:
On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
We may be able to convince the SCSI people to enable it for all devices,
regardless of HCD.
No ... I'm not particularly keen to have enterprise vendors
On Mon, 2008-01-14 at 19:37 +0100, Hans de Goede wrote:
> James Bottomley wrote:
> > On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
> >> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
> >>> Guillaume Bedot wrote:
> But it fixes only two models.
> Do you think oth
On Mon, Jan 14, 2008 at 10:33:08AM -0600, James Bottomley wrote:
>
> On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
> > We may be able to convince the SCSI people to enable it for all devices,
> > regardless of HCD.
>
> No ... I'm not particularly keen to have enterprise vendors after my
James Bottomley wrote:
> On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
>> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
>> > Guillaume Bedot wrote:
>> > >Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without
>> > >recompiling a kernel ?
>> >
>> > This
James Bottomley wrote:
On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
Guillaume Bedot wrote:
But it fixes only two models.
Do you think other devices (hp or not) can be impacted ?
There are hundreds of models with card rea
On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
> > Guillaume Bedot wrote:
> > >But it fixes only two models.
> > >Do you think other devices (hp or not) can be impacted ?
> > >There are hundreds of models with card readers o
On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
> Guillaume Bedot wrote:
> >But it fixes only two models.
> >Do you think other devices (hp or not) can be impacted ?
> >There are hundreds of models with card readers only for hp :
> >http://hplip.sourceforge.net/supported_devices/comb
Guillaume Bedot wrote:
I have tested this time with two PSC 1610 printers, and two SD cards,
the same bug occured without the patch.
And is fixed with your new patch. Good work !
Hi,
Thanks for testing!
But it fixes only two models.
Do you think other devices (hp or not) can be impacted ?
Hello,
On ven, 2008-01-11 at 21:14 +0100, Hans de Goede wrote:
> Boaz Harrosh wrote:
> > Yes, you're right. in ULDs it is a much proper way to do this.
> >
> > So I guess you'll have to do that special host flag or device
> > flag, and add a check for it in sd.c. You'll see that sd.c is
> > alre
On Fri, Jan 11, 2008 at 09:14:00PM +0100, Hans de Goede wrote:
> Boaz Harrosh wrote:
> >Yes, you're right. in ULDs it is a much proper way to do this.
> >
> >So I guess you'll have to do that special host flag or device
> >flag, and add a check for it in sd.c. You'll see that sd.c is
> >already do
Boaz Harrosh wrote:
Yes, you're right. in ULDs it is a much proper way to do this.
So I guess you'll have to do that special host flag or device
flag, and add a check for it in sd.c. You'll see that sd.c is
already doing bufflen truncation at sd_prep_fn(), just add one
more case.
Done, than
Hello,
Le vendredi 11 janvier 2008 à 13:48 +0100, Hans de Goede a écrit :
> That will work nicely, I'll write an updated patch this evening (when I have
> access to the printer to test again).
>
Great news, i am impatient to test this new patch.
I may face an other bug with the Transcend 1GB SD
Boaz Harrosh wrote:
On Thu, Jan 10 2008 at 12:52 +0200, Hans de Goede <[EMAIL PROTECTED]> wrote:
I'm not sure what the proper solution should be?
I guess the proper solution would be to add a special case to the scsi layer
where the read10 / write10 command is issued, and split the request in
D], USB development list
>> <[EMAIL PROTECTED]>, David Brown
>> <[EMAIL PROTECTED]>, Guillaume Bedot <[EMAIL PROTECTED]>,
>> linux-scsi@vger.kernel.org, [EMAIL PROTECTED]
>> *Sent:* Wed, Jan 09 2008 at 23:44 +0200
>> *Subject:* Linux scsi / usb-mass-sto
AIL PROTECTED]>,
linux-scsi@vger.kernel.org, [EMAIL PROTECTED]
*Sent:* Wed, Jan 09 2008 at 23:44 +0200
*Subject:* Linux scsi / usb-mass-storage and HP printer cardreader bug + fix
Hi All,
First of all sorry for the somewhat massive cross-posting, I've spend a
significant amount of time hunting down th
r.kernel.org, [EMAIL PROTECTED]
*Sent:* Wed, Jan 09 2008 at 23:44 +0200
*Subject:* Linux scsi / usb-mass-storage and HP printer cardreader bug + fix
> Hi All,
>
> First of all sorry for the somewhat massive cross-posting, I've spend a
> significant amount of time hunting down thi
On Wed, Jan 09, 2008 at 10:44:49PM +0100, Hans de Goede wrote:
> First of all sorry for the somewhat massive cross-posting, I've spend a
> significant amount of time hunting down this bug, and so far the response
> has been less the overwhelming.
> The cardreader of the multi function printers
Hi All,
First of all sorry for the somewhat massive cross-posting, I've spend a
significant amount of time hunting down this bug, and so far the response has
been less the overwhelming.
The problem is with the HP PSC 1350 (my printer and confirmed by 2 others) and
atleast also the HP PSC 161
21 matches
Mail list logo
