headers
Robert Hancock | 1 Feb 2008 01:09
Picon
Favicon

Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM

Alexander wrote:
> Hello!
> 
> The problem described at https://bugzilla.redhat.com/show_bug.cgi?id=351451 and
> at http://ubuntuforums.org/showthread.php?t=655772 and supposedly fixed by the
> patch http://kerneltrap.org/mailarchive/linux-kernel/2007/11/25/445094 is still
> there. I have compiled 2.6.24-rc7 kernel and booted my PC with it just to find
> out that my SATA DVD-RW is
> 
> sr0: scsi3-mmc drive: 0x/0x caddy
> 
> as it was before with 2.6.23.12 and earlier 2.6 kernels compiled for x86_64.
> Trying to use sr0 after this results in dead hang or reboot.
> When I put sata_nv.adma=0 or mem=4096M then it's all ok:

Can you (or others experiencing this problem) test the latest patch 
attached to the RH Bugzilla entry here:

https://bugzilla.redhat.com/show_bug.cgi?id=351451

and see if it resolves the problem? I have one report of success so far.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Borislav Petkov | 1 Feb 2008 08:51

Re: kernel BUG at ide-cd.c:1726 in 2.6.24-03863-g0ba6c33 && -g8561b089

On Thu, Jan 31, 2008 at 05:35:56PM -0500, Kiyoshi Ueda wrote:
> Hi Boris,
> 
> Thank you for the confirmation of original behavior.
> 
> On Thu, 31 Jan 2008 22:37:40 +0100, Borislav Petkov wrote:
> > On Thu, Jan 31, 2008 at 02:05:58PM +0100, Jens Axboe wrote:
> > > On Thu, Jan 31 2008, Nai Xia wrote:
> > > > My dmesg relevant info is quite similar:
> > > > 
> > > > [    6.875041] Freeing unused kernel memory: 320k freed
> > > > [    8.143120] ide-cd: rq still having bio: dev hdc: type=2, flags=114c8
> > > > [    8.144439]
> > > > [    8.144439] sector 10824201199534213, nr/cnr 0/0
> > > > [    8.144439] bio cf029280, biotail cf029280, buffer 00000000, data
> > > > 00000000, len 158
> > > > [    8.144439] cdb: 12 00 00 00 fe 00 00 00 00 00 00 00 00 00 00 00
> > > > [    8.144439] backup: data_len=158  bi_size=158
> > > > [    8.160756] ide-cd: rq still having bio: dev hdc: type=2, flags=114c8
> > > > [    8.160756]
> > > > [    8.160756] sector 2669858, nr/cnr 0/0
> > > > [    8.160756] bio cf029300, biotail cf029300, buffer 00000000, data
> > > > 00000000, len 158
> > > > [    8.160756] cdb: 12 01 00 00 fe 00 00 00 00 00 00 00 00 00 00 00
> > > > [    8.160756] backup: data_len=158  bi_size=158
> > > > [   14.851101] eth0: link up
> > > > [   27.121883] eth0: no IPv6 routers present
> > > > 
> > > > 
> > > > And by the way, Kiyoshi,
(Continue reading)

Permalink | Reply | 6 comments |
headers
Borislav Petkov | 1 Feb 2008 09:21

Re: [PATCH 0/32] ide-tape redux v1

On Wed, Jan 30, 2008 at 01:29:55AM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Monday 28 January 2008, Borislav Petkov wrote:
> > Hi Bart,
> > 
> > [...]
> > 
> > > > the BKL in idetape_write_release() with finer-grained locking etc, probably also
> > > > some pipeline improvements, removal of OnStream support, etc. but that'll come
> > > > later.
> > > 
> > > On-Stream support has been long gone but it seems that deprecation
> > > warning etc. managed to survive.
> > > 
> > > w.r.t. to the pipeline-mode: it should be pipelined into /dev/null
> > > 
> > > rationale:
> > > - it is _very_ complex
> > > - causes errors to be deferred till the next user-space access
> > > - direct I/O using blk_rq_map_user() will offer superior performance
> > > 
> > > the only question is whether to remove it...
> > 
> > Well, on the one hand, since the driver is only being maintained we should not
> > remove code that works. Also, i don't know how many users ide-tape really has
> > but, would it be worth the trouble at all? Because if nobody's using it, we
> > could just as well pipe the whole thing into /dev/null.. On the other hand, the
> 
> This may be the other alternative... [ there is always libata PATA... ]
> 
> If you want to give ide-tape removal a try, go ahead (I suggest starting
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Feb 2008 09:23
Picon

Re: About forcing 32bit DMA patch for AMD690G(SB600)

Shane Huang wrote:
> As Tejun mentioned, the test result on my SB600 engineering board
> (RS690 A12 +SB600 A21) is a little different from the result of Srihari.
> But I do not have other SB600 boards especially ASUS M2A-VM to do
> further debug. So if you can provide us your test result, that's really
> good.

My 5 cents: Just order the board.  These stock PC hardware are too cheap
these days, it doesn't make any sense to try to debug somewhat difficult
problem remotely if the hardware is available on the market.  Even if
you have to spend your own money, it will be money well spent compared
to the time and effort you'll have to spend in comparison - hardware is
just too cheap.

Thanks.

--

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Alexander | 1 Feb 2008 10:59
Picon

Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM

Robert Hancock wrote:
> Can you (or others experiencing this problem) test the latest patch 
> attached to the RH Bugzilla entry here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=351451
> 
> and see if it resolves the problem? I have one report of success so far.
> 

I'll test it at this weekend.
Permalink | Reply | 0 comments |
headers
dusty@gmx.li | 1 Feb 2008 14:42
Picon

Re: libata pm

>> Sorry for my late answer, but i had to sort this out first.
>> After replacing the first PSU with a new Corsair 650W the power no
>> longer fluctuated more than 0,01 V (and this only when booting up the
>> drives...) I did a full resync on both raid arrays and got no more
>> errors or resets, but there were some inconsitencies during sync and the
>> xfs filesystem on both arrays had to be repaired. Are these problems
>> caused by the pm resets ?
>>
>
> libata EH won't lose any data as long as the hardware doesn't.  If power
> fluctuates causing your drive to briefly power down - this does happen and
> you can hear the drive doing emergency unload when it happens, the data in
> write buffer can be lost.  On coming back, all that libata can know is
> that the PHY suffered brief connection loss, so it resets the device and
> goes on, so the data in the cache is lost now.  It's basically pulling the
> power plug from the harddrive while write is going on and connecting it
> back quickly.  You're bound to lose data.
>
After I got the new PSU and the raid was in full sync without any error
for 48h, I thought all problems were gone. Today the sata errors
reappeared and whenever the load is high enough I get the following:

ata10.00: failed to read SCR 1 (Emask=0x40)
ata10.01: failed to read SCR 1 (Emask=0x40)
ata10.02: failed to read SCR 1 (Emask=0x40)
ata10.03: failed to read SCR 1 (Emask=0x40)
ata10.04: failed to read SCR 1 (Emask=0x40)
ata10.05: failed to read SCR 1 (Emask=0x40)
ata10.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.01: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tejun Heo | 1 Feb 2008 14:53
Picon

Re: libata pm

dusty <at> gmx.li wrote:
>>> Sorry for my late answer, but i had to sort this out first.
>>> After replacing the first PSU with a new Corsair 650W the power no
>>> longer fluctuated more than 0,01 V (and this only when booting up the
>>> drives...) I did a full resync on both raid arrays and got no more
>>> errors or resets, but there were some inconsitencies during sync and the
>>> xfs filesystem on both arrays had to be repaired. Are these problems
>>> caused by the pm resets ?
>>>
>> libata EH won't lose any data as long as the hardware doesn't.  If power
>> fluctuates causing your drive to briefly power down - this does happen and
>> you can hear the drive doing emergency unload when it happens, the data in
>> write buffer can be lost.  On coming back, all that libata can know is
>> that the PHY suffered brief connection loss, so it resets the device and
>> goes on, so the data in the cache is lost now.  It's basically pulling the
>> power plug from the harddrive while write is going on and connecting it
>> back quickly.  You're bound to lose data.
>>
> After I got the new PSU and the raid was in full sync without any error
> for 48h, I thought all problems were gone. Today the sata errors
> reappeared and whenever the load is high enough I get the following:
> 
> ata10.02: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0
>          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

> ata10.02: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 2 cdb 0x0 data 0
>          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Those are time outs for FLUSH.  libata told the drive to flush its cache
onto the media and the drive failed to finish that in 30secs.  As FLUSH
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Lord | 1 Feb 2008 15:06
Picon
Favicon

Re: libata pm

dusty <at> gmx.li wrote:
>>> Sorry for my late answer, but i had to sort this out first.
>>> After replacing the first PSU with a new Corsair 650W the power no
>>> longer fluctuated more than 0,01 V (and this only when booting up the
>>> drives...) I did a full resync on both raid arrays and got no more
>>> errors or resets, but there were some inconsitencies during sync and the
>>> xfs filesystem on both arrays had to be repaired. Are these problems
>>> caused by the pm resets ?
>>>
>> libata EH won't lose any data as long as the hardware doesn't.  If power
>> fluctuates causing your drive to briefly power down - this does happen and
>> you can hear the drive doing emergency unload when it happens, the data in
>> write buffer can be lost.  On coming back, all that libata can know is
>> that the PHY suffered brief connection loss, so it resets the device and
>> goes on, so the data in the cache is lost now.  It's basically pulling the
>> power plug from the harddrive while write is going on and connecting it
>> back quickly.  You're bound to lose data.
>>
> After I got the new PSU and the raid was in full sync without any error
> for 48h, I thought all problems were gone. Today the sata errors
> reappeared and whenever the load is high enough I get the following:
..

What exact brand/model drives are those again (hdparm --Istdout, please) ?

If I have a similar unit here, I may try to reproduce this.

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tejun Heo | 1 Feb 2008 16:05
Picon

Re: libata pm

Mark Lord wrote:
>> After I got the new PSU and the raid was in full sync without any error
>> for 48h, I thought all problems were gone. Today the sata errors
>> reappeared and whenever the load is high enough I get the following:
> ..
> 
> What exact brand/model drives are those again (hdparm --Istdout, please) ?
> 
> If I have a similar unit here, I may try to reproduce this.

Dusty, can you please provide the info for Mark?  Let's see if Mark can
reproduce this.

Thanks.

--

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
dusty@gmx.li | 1 Feb 2008 16:12
Picon

Re: libata pm

Am Fr, 1.02.2008, 14:06, schrieb Mark Lord:
> dusty <at> gmx.li wrote:
>>>> Sorry for my late answer, but i had to sort this out first.
>>>> After replacing the first PSU with a new Corsair 650W the power no
>>>> longer fluctuated more than 0,01 V (and this only when booting up
>>>> the drives...) I did a full resync on both raid arrays and got no
>>>> more errors or resets, but there were some inconsitencies during
>>>> sync and the xfs filesystem on both arrays had to be repaired. Are
>>>> these problems caused by the pm resets ?
>>>>
>>> libata EH won't lose any data as long as the hardware doesn't.  If
>>> power fluctuates causing your drive to briefly power down - this does
>>> happen and you can hear the drive doing emergency unload when it
>>> happens, the data in write buffer can be lost.  On coming back, all
>>> that libata can know is that the PHY suffered brief connection loss,
>>> so it resets the device and goes on, so the data in the cache is lost
>>> now.  It's basically pulling the power plug from the harddrive while
>>> write is going on and connecting it back quickly.  You're bound to
>>> lose data.
>>>
>> After I got the new PSU and the raid was in full sync without any error
>>  for 48h, I thought all problems were gone. Today the sata errors
>> reappeared and whenever the load is high enough I get the following:
> ..
>
>
> What exact brand/model drives are those again (hdparm --Istdout, please)
> ?
>
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane