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
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...
On Wed, 17 Sep 2003 17:40:36 +0100, Alan Cox <[email protected]>
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
On Wednesday 17 of September 2003 20:49, Arve Knudsen wrote:
> On Wed, 17 Sep 2003 17:40:36 +0100, Alan Cox <[email protected]>
>
> 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
On Wed, 17 Sep 2003 21:09:54 +0200, Bartlomiej Zolnierkiewicz
<[email protected]> 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
Alan Cox <[email protected]> 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.
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.
On Mer, 2003-09-17 at 21:53, Andrew Morton wrote:
> Alan Cox <[email protected]> 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.
>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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>