Re: Changes in siimage driver?

Re: Changes in siimage driver?

[CASINO_E]

On Wednesday 17 of September 2003 14:09, Bartlomiej Zolnierkiewicz wrote:
> controllers. I believe freebsd's workaround is correct and we can
adopt > it.
> For more details please see the other thread regarding siimage.

According to what I've seen in the release notes of the closed-source
siimage driver (I posted what I found), the right fix could be in
netbsd's code, but in sys/dev/ata/wd.c :

         * Some Seagate S-ATA drives have a PHY which can get confused
         * with the way data is packetized by some S-ATA controllers.
         *
         * The work-around is to split in two any write transfer whose
         * sector count % 15 == 1 (assuming 512 byte sectors).
 
I'm not smart enough to try and write a patch, but maybe the siimage
maintainer could have a look to that file...

Eduardo.

Re: Changes in siimage driver?

[Andre Hedrick]

Did that already, yet the linux does not like odd break point in the SG
list and thus there are some ugliess to solve.

Andre Hedrick
LAD Storage Consulting Group

On Thu, 18 Sep 2003, CASINO_E wrote:

> On Wednesday 17 of September 2003 14:09, Bartlomiej Zolnierkiewicz wrote:
> > controllers. I believe freebsd's workaround is correct and we can
> adopt > it.
> > For more details please see the other thread regarding siimage.
> 
> According to what I've seen in the release notes of the closed-source
> siimage driver (I posted what I found), the right fix could be in
> netbsd's code, but in sys/dev/ata/wd.c :
> 
>          * Some Seagate S-ATA drives have a PHY which can get confused
>          * with the way data is packetized by some S-ATA controllers.
>          *
>          * The work-around is to split in two any write transfer whose
>          * sector count % 15 == 1 (assuming 512 byte sectors).
>  
> I'm not smart enough to try and write a patch, but maybe the siimage
> maintainer could have a look to that file...
> 
> Eduardo.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Changes in siimage driver?

[Bartlomiej Zolnierkiewicz]

On Saturday 20 of September 2003 01:14, Bob Johnson wrote:
> >You are the first person reporting problems after syncing siimage driver
> > with 2.4.x ;-). It's unlikely that corruption is caused by siimage driver
> > update, we should have seen similar problems with 2.4.x, but...
>
> All my drives on the siimage controller recieved massive corruption
> after 2 days of running 2.6.0-test5-bk5, just now getting it back together
> to even look at mail :)

What kernel version were you using before 2.6.0-test5-bk5 ?

siimage changes happend in 2.6.0-test4-bk5
and driver is now almost identical to the one in 2.4.x.

--bartlomiej

re: Changes in siimage driver?

[Bob Johnson]

>You are the first person reporting problems after syncing siimage driver with
>2.4.x ;-). It's unlikely that corruption is caused by siimage driver update,
>we should have seen similar problems with 2.4.x, but...

All my drives on the siimage controller recieved massive corruption 
after 2 days of running 2.6.0-test5-bk5, just now getting it back together
to even look at mail :)	

					
				Bob

Re: Changes in siimage driver?

[Alan Cox]

On Mer, 2003-09-17 at 21:53, Andrew Morton wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >
> > On Mer, 2003-09-17 at 17:26, Arve Knudsen wrote:
> > > X66 etc.) with hdparm, I get ~50MB/S. It's not an ideal solution since now 
> > > and then I get a bunch of "disabling irq #18" messages after running 
> > > hdparm (I think, its part of the startup scripts), and I have to restart.
> > 
> > That is a bug in the 2.6.0 core still.
> 
> How come this driver is returning IRQ_NONE so much?

Lots of IDE interrupts get cleared directly in other code paths but I'm
not sure. I just know its happening.

Re: Changes in siimage driver?

[Andrew Morton]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> On Mer, 2003-09-17 at 17:26, Arve Knudsen wrote:
> > X66 etc.) with hdparm, I get ~50MB/S. It's not an ideal solution since now 
> > and then I get a bunch of "disabling irq #18" messages after running 
> > hdparm (I think, its part of the startup scripts), and I have to restart.
> 
> That is a bug in the 2.6.0 core still.

How come this driver is returning IRQ_NONE so much?

> Just hack out the code which does
> the IRQ disable on too many apparently unidentified interrupts.

You can boot with the `noirqdebug' option to disable it.

Re: Changes in siimage driver?

[Arve Knudsen]

On Wed, 17 Sep 2003 21:09:54 +0200, Bartlomiej Zolnierkiewicz 
<B.Zolnierkiewicz@elka.pw.edu.pl> wrote:
>> Well, I understand that, but the older version of the driver (as of
>> test4-mm4) doesn't have these problems (better performance according to
>> hdparm, no corruption). The latest changes to the driver seems to have
>> introduced problems, or is it just me?
>
> You are the first person reporting problems after syncing siimage driver 
> with
> 2.4.x ;-).  It's unlikely that corruption is caused by siimage driver 
> update,
> we should have seen similar problems with 2.4.x, but...
Yes, it's weird, but it happened the first time I tried the test5 kernel. 
Not a good feeling, sitting with directories you can't even delete :\ The 
computer had been up for some time (12 hours or so), and several files I 
had open for editing were zeroed out when I opened them after reboot. 
Could it have to do with my Maxtor DiamondMax drive perhaps? I guess most 
people got Seagate SATA drives, I've since then purchased a Seagate 7200.7 
SATA to complement the Maxtor.

> Performance is crippled because of workaround for buggy controllers.
> We turn it on unconditionally now, we should do it only on affected
> controllers.  I believe freebsd's workaround is correct and we can adopt 
> it.
> For more details please see the other thread regarding siimage.
Sounds great, I think I will migrate to a newer kernel once I have done 
some proper backups to an unmounted partition :]

Thanks

Arve Knudsen

Re: Changes in siimage driver?

[Bartlomiej Zolnierkiewicz]

On Wednesday 17 of September 2003 20:49, Arve Knudsen wrote:
> On Wed, 17 Sep 2003 17:40:36 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk>
>
> wrote:
> > On Mer, 2003-09-17 at 17:26, Arve Knudsen wrote:
> >> X66 etc.) with hdparm, I get ~50MB/S. It's not an ideal solution since
> >> now
> >> and then I get a bunch of "disabling irq #18" messages after running
> >> hdparm (I think, its part of the startup scripts), and I have to
> >> restart.
> >
> > That is a bug in the 2.6.0 core still. Just hack out the code which does
> > the IRQ disable on too many apparently unidentified interrupts.
>
> Ok, thanks for identifying the source of this. I'm no kernel hacker at
> all, but I'll see what I can find.

s/IRQ_NONE/IRQ_HANDLE/ in ide-io.c or trace which one is offending one.

> >> directories. Am I the only one who's run into any sort of issues with
> >> the
> >> updated driver? From what I can see it hasn't been modified in the last
> >> revision (test5-bk4), hopefully noone is losing important data because
> >> of
> >> this (fortunately I had some recent backups). Anyway, I'd like some
> >> feedback on this from those in the know (the performance drop should be
> >> fairly easy to verify, unless hdparm is playing tricks on me).
> >
> > Don't keep important data only on 2.6-test boxes. Its 'test' - it
> > shouldnt eat anything but...
>
> Well, I understand that, but the older version of the driver (as of
> test4-mm4) doesn't have these problems (better performance according to
> hdparm, no corruption). The latest changes to the driver seems to have
> introduced problems, or is it just me?

You are the first person reporting problems after syncing siimage driver with
2.4.x ;-).  It's unlikely that corruption is caused by siimage driver update,
we should have seen similar problems with 2.4.x, but...

Performance is crippled because of workaround for buggy controllers.
We turn it on unconditionally now, we should do it only on affected
controllers.  I believe freebsd's workaround is correct and we can adopt it.
For more details please see the other thread regarding siimage.

--bartlomiej

> Thanks for the swift reply
>
> Arve Knudsen

Re: Changes in siimage driver?

[Arve Knudsen]

On Wed, 17 Sep 2003 17:40:36 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> 
wrote:

> On Mer, 2003-09-17 at 17:26, Arve Knudsen wrote:
>> X66 etc.) with hdparm, I get ~50MB/S. It's not an ideal solution since 
>> now
>> and then I get a bunch of "disabling irq #18" messages after running
>> hdparm (I think, its part of the startup scripts), and I have to 
>> restart.
>
> That is a bug in the 2.6.0 core still. Just hack out the code which does
> the IRQ disable on too many apparently unidentified interrupts.
Ok, thanks for identifying the source of this. I'm no kernel hacker at 
all, but I'll see what I can find.

>> directories. Am I the only one who's run into any sort of issues with 
>> the
>> updated driver? From what I can see it hasn't been modified in the last
>> revision (test5-bk4), hopefully noone is losing important data because 
>> of
>> this (fortunately I had some recent backups). Anyway, I'd like some
>> feedback on this from those in the know (the performance drop should be
>> fairly easy to verify, unless hdparm is playing tricks on me).
>
> Don't keep important data only on 2.6-test boxes. Its 'test' - it
> shouldnt eat anything but...
Well, I understand that, but the older version of the driver (as of 
test4-mm4) doesn't have these problems (better performance according to 
hdparm, no corruption). The latest changes to the driver seems to have 
introduced problems, or is it just me?

Thanks for the swift reply

Arve Knudsen

Re: Changes in siimage driver?

[Alan Cox]

On Mer, 2003-09-17 at 17:26, Arve Knudsen wrote:
> X66 etc.) with hdparm, I get ~50MB/S. It's not an ideal solution since now 
> and then I get a bunch of "disabling irq #18" messages after running 
> hdparm (I think, its part of the startup scripts), and I have to restart.

That is a bug in the 2.6.0 core still. Just hack out the code which does
the IRQ disable on too many apparently unidentified interrupts.

> directories. Am I the only one who's run into any sort of issues with the 
> updated driver? From what I can see it hasn't been modified in the last 
> revision (test5-bk4), hopefully noone is losing important data because of 
> this (fortunately I had some recent backups). Anyway, I'd like some 
> feedback on this from those in the know (the performance drop should be 
> fairly easy to verify, unless hdparm is playing tricks on me).

Don't keep important data only on 2.6-test boxes. Its 'test' - it
shouldnt eat anything but...

Changes in siimage driver?

[Arve Knudsen]

Hello

I've noticed that the siimage driver has changed since a few revisions 
back, I ran into some problems probably related to the driver when 
updating to 2.6.0-test5-mm1 however. First of all, I noticed hdparm 
reported really bad performance numbers for my Maxtor DiamondMax9 120GB. 
About 16MB/sec is reported for a buffered disk reads. The older version of 
the driver doesnt turn on DMA, but after enabling certain options (-d1, 
X66 etc.) with hdparm, I get ~50MB/S. It's not an ideal solution since now 
and then I get a bunch of "disabling irq #18" messages after running 
hdparm (I think, its part of the startup scripts), and I have to restart.

The second issue is more serious; after rebooting I noticed 3 files I had 
been working on, and a couple of directories I had downloaded were 
corrupted. The single files were filled with zeros, while the directories 
were impossible to access (I/O error). I couldn't even rm (-r) the 
directories. Am I the only one who's run into any sort of issues with the 
updated driver? From what I can see it hasn't been modified in the last 
revision (test5-bk4), hopefully noone is losing important data because of 
this (fortunately I had some recent backups). Anyway, I'd like some 
feedback on this from those in the know (the performance drop should be 
fairly easy to verify, unless hdparm is playing tricks on me).

Thanks in advance

Arve Knudsen