LinuxLists.cc - 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
> Hi,
>
> well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in DAO
> mode to burn the cd ends up in non-bit identical copies, wheres ion TAO
> (atleast with my 10x CD-RW I tested) the copy succeded. I tried several
> times, and always got this issue.
>
> bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
> f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
>
> TAO:
> bash-2.05b$ md5sum /dev/cdroms/cdrom1
> f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
>
> DAO:
> bash-2.05b$ md5sum /dev/cdroms/cdrom1
> 09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1

Could you please try and cmp the two images, finding out how big the
corrupted chunks are and what kind of data they contain?

--
Jens Axboe

2003-11-05 09:56:02

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> Jens Axboe wrote:
>
> > On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
> >
> >> Hi,
> >>
> >> well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in
> DAO mode to burn the cd ends up in non-bit identical copies, wheres ion
> TAO (atleast with my 10x CD-RW I tested) the copy succeded. I tried
> several times, and always got this issue.
> >>
> >> bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
> >> f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
> >>
> >> TAO:
> >> bash-2.05b$ md5sum /dev/cdroms/cdrom1
> >> f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
> >>
> >> DAO:
> >> bash-2.05b$ md5sum /dev/cdroms/cdrom1
> >> 09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1
> >
> >
> >
> > Could you please try and cmp the two images, finding out how big the
> > corrupted chunks are and what kind of data they contain?
>
>
> After some further investigation I found out, that the data is NOT
> corrupted, but in a way truncated in DAO mode: When I read out the image
> from the CD-RW drive, about 5kbyte are missing at the end (and doing
> several burn, it is always the same amount). Strange enough if I read
> the DAO burnt disk out by my DVD-ROM, the image can be read out
> completely! Can you understand this behaviour? I don't think it is a
> problem of my burner, but rather of the atapi driver?

Is actual data missing at the end? If yes, I'd say this looks a lot more
like a cdrecord problem.

--
Jens Axboe

2003-11-05 09:54:17

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:

> On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
>
>> Hi,
>>
>> well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in
DAO mode to burn the cd ends up in non-bit identical copies, wheres ion
TAO (atleast with my 10x CD-RW I tested) the copy succeded. I tried
several times, and always got this issue.
>>
>> bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
>> f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
>>
>> TAO:
>> bash-2.05b$ md5sum /dev/cdroms/cdrom1
>> f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
>>
>> DAO:
>> bash-2.05b$ md5sum /dev/cdroms/cdrom1
>> 09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1
>
>
>
> Could you please try and cmp the two images, finding out how big the
> corrupted chunks are and what kind of data they contain?

After some further investigation I found out, that the data is NOT
corrupted, but in a way truncated in DAO mode: When I read out the image
from the CD-RW drive, about 5kbyte are missing at the end (and doing
several burn, it is always the same amount). Strange enough if I read
the DAO burnt disk out by my DVD-ROM, the image can be read out
completely! Can you understand this behaviour? I don't think it is a
problem of my burner, but rather of the atapi driver?

Cheers,

Prakash

--
=-----=
|=-P-=|
=-----=

2003-11-05 10:02:28

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> Jens Axboe wrote:
> >On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> >
> >>Jens Axboe wrote:
> >>
> >>
> >>>On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in
> >>
> >>DAO mode to burn the cd ends up in non-bit identical copies, wheres ion
> >>TAO (atleast with my 10x CD-RW I tested) the copy succeded. I tried
> >>several times, and always got this issue.
> >>
> >>>>bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
> >>>>f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
> >>>>
> >>>>TAO:
> >>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
> >>>>f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
> >>>>
> >>>>DAO:
> >>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
> >>>>09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1
> >>>
> >>>
> >>>
> >>>Could you please try and cmp the two images, finding out how big the
> >>>corrupted chunks are and what kind of data they contain?
> >>
> >>
> >>After some further investigation I found out, that the data is NOT
> >>corrupted, but in a way truncated in DAO mode: When I read out the image
> >>from the CD-RW drive, about 5kbyte are missing at the end (and doing
> >>several burn, it is always the same amount). Strange enough if I read
> >>the DAO burnt disk out by my DVD-ROM, the image can be read out
> >>completely! Can you understand this behaviour? I don't think it is a
> >>problem of my burner, but rather of the atapi driver?
> >
> >
> >Is actual data missing at the end? If yes, I'd say this looks a lot more
> >like a cdrecord problem.
>
> Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM restores
> the full image (md5sum matches), but the CD-RW does not.

You need to use the pad option to record.

--
Jens Axboe

2003-11-05 10:00:15

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>
>>Jens Axboe wrote:
>>
>>
>>>On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in
>>
>>DAO mode to burn the cd ends up in non-bit identical copies, wheres ion
>>TAO (atleast with my 10x CD-RW I tested) the copy succeded. I tried
>>several times, and always got this issue.
>>
>>>>bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
>>>>f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
>>>>
>>>>TAO:
>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
>>>>f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
>>>>
>>>>DAO:
>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
>>>>09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1
>>>
>>>
>>>
>>>Could you please try and cmp the two images, finding out how big the
>>>corrupted chunks are and what kind of data they contain?
>>
>>
>>After some further investigation I found out, that the data is NOT
>>corrupted, but in a way truncated in DAO mode: When I read out the image
>>from the CD-RW drive, about 5kbyte are missing at the end (and doing
>>several burn, it is always the same amount). Strange enough if I read
>>the DAO burnt disk out by my DVD-ROM, the image can be read out
>>completely! Can you understand this behaviour? I don't think it is a
>>problem of my burner, but rather of the atapi driver?
>
>
> Is actual data missing at the end? If yes, I'd say this looks a lot more
> like a cdrecord problem.

Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM restores
the full image (md5sum matches), but the CD-RW does not.

Prakash

--
=-----=
|=-P-=|
=-----=

2003-11-05 09:58:45

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>
>>Jens Axboe wrote:
>>
>>>On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in DAO
>>>>mode to burn the cd ends up in non-bit identical copies, wheres ion TAO
>>>>(atleast with my 10x CD-RW I tested) the copy succeded. I tried several
>>>>times, and always got this issue.
>>>>
>>>>bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
>>>>f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
>>>>
>>>>TAO:
>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
>>>>f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
>>>>
>>>>DAO:
>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
>>>>09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1
>>>
>>>
>>>Could you please try and cmp the two images, finding out how big the
>>>corrupted chunks are and what kind of data they contain?
>>
>>After some further investigation I found out, that the data is NOT
>>corrupted, but in a way truncated in DAO mode: When I read out the image
>>from the CD-RW drive, about 5kbyte are missing at the end (and doing
>>several burn, it is always the same amount). Strange enough if I read
>>the DAO burnt disk out by my DVD-ROM, the image can be read out
>>completely! Can you understand this behaviour? I don't think it is a
>>problem of my burner, but rather of the atapi driver?
>
>
> This is not a problem per-se (you can read the files, right?), it's just
> an artifact of burning the images differently. When you say truncated,
> do you mean that actual data is missing?

I am not an expert of iso image structure, but I would say yes. The
original iso is about 5kb bigger than the image read after DAO burning.
So when you imagine this truncated image would be burn, read, burnt etc,
nothing of the original image would be left.

Prakash

2003-11-05 10:13:15

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

2003-11-05 10:10:36

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>
>>Jens Axboe wrote:
>>
>>>On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>>>
>>>
>>>>Jens Axboe wrote:
>>>>
>>>>
>>>>
>>>>>On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in
>>>>
>>>>DAO mode to burn the cd ends up in non-bit identical copies, wheres ion
>>>>TAO (atleast with my 10x CD-RW I tested) the copy succeded. I tried
>>>>several times, and always got this issue.
>>>>
>>>>
>>>>>>bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
>>>>>>f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
>>>>>>
>>>>>>TAO:
>>>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
>>>>>>f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
>>>>>>
>>>>>>DAO:
>>>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
>>>>>>09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1
>>>>>
>>>>>
>>>>>
>>>>>Could you please try and cmp the two images, finding out how big the
>>>>>corrupted chunks are and what kind of data they contain?
>>>>
>>>>
>>>>After some further investigation I found out, that the data is NOT
>>>>corrupted, but in a way truncated in DAO mode: When I read out the image
>>>
>>>>from the CD-RW drive, about 5kbyte are missing at the end (and doing
>>>
>>>>several burn, it is always the same amount). Strange enough if I read
>>>>the DAO burnt disk out by my DVD-ROM, the image can be read out
>>>>completely! Can you understand this behaviour? I don't think it is a
>>>>problem of my burner, but rather of the atapi driver?
>>>
>>>
>>>Is actual data missing at the end? If yes, I'd say this looks a lot more
>>>like a cdrecord problem.
>>
>>Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM restores
>>the full image (md5sum matches), but the CD-RW does not.
>
>
> You need to use the pad option to record.

Uhm, could you be more specific? I just use the k3b frontend to burn,
and in the cdrdao manual I couldn't find something useful to it.

SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the mouse
stutters slighty when burning (in atapi mode). I am now using as
sheduler. Shoudl I try deadline or do you this it is something else?
Should I open a new topic?

Prakash

2003-11-05 10:24:03

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> Jens Axboe wrote:
> >On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> >
> >>Jens Axboe wrote:
> >>
> >>>On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> >>>
> >>>
> >>>>Jens Axboe wrote:
> >>>>
> >>>>
> >>>>>On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Jens Axboe wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Hi,
> >>>>>>>>
> >>>>>>>>well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in
> >>>>>>
> >>>>>>DAO mode to burn the cd ends up in non-bit identical copies, wheres
> >>>>>>ion TAO (atleast with my 10x CD-RW I tested) the copy succeded. I
> >>>>>>tried several times, and always got this issue.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
> >>>>>>>>f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
> >>>>>>>>
> >>>>>>>>TAO:
> >>>>>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
> >>>>>>>>f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
> >>>>>>>>
> >>>>>>>>DAO:
> >>>>>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
> >>>>>>>>09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>Could you please try and cmp the two images, finding out how big the
> >>>>>>>corrupted chunks are and what kind of data they contain?
> >>>>>>
> >>>>>>
> >>>>>>After some further investigation I found out, that the data is NOT
> >>>>>>corrupted, but in a way truncated in DAO mode: When I read out the
> >>>>>>image
> >>>>>
> >>>>>>from the CD-RW drive, about 5kbyte are missing at the end (and doing
> >>>>>
> >>>>>
> >>>>>>several burn, it is always the same amount). Strange enough if I read
> >>>>>>the DAO burnt disk out by my DVD-ROM, the image can be read out
> >>>>>>completely! Can you understand this behaviour? I don't think it is a
> >>>>>>problem of my burner, but rather of the atapi driver?
> >>>>>
> >>>>>
> >>>>>Is actual data missing at the end? If yes, I'd say this looks a lot
> >>>>>more
> >>>>>like a cdrecord problem.
> >>>>
> >>>>Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM
> >>>>restores the full image (md5sum matches), but the CD-RW does not.
> >>>
> >>>
> >>>You need to use the pad option to record.
> >>
> >>Uhm, could you be more specific? I just use the k3b frontend to burn,
> >>and in the cdrdao manual I couldn't find something useful to it.
> >
> >
> >it's a cdrecord option, I've never used k3b so cannot comment on how to
> >make it enable that.
>
> Hmm, I'll take a look, but I don't really think it is a problem of the
> recording programme, otherwise how could my reader read it out completely?

It isn't a problem of the recorder program. But some drives wont read
the very end of a disc unless there are some pad blocks at the end.
Thus, you should always use the cdrecord pad option.

>
> >>SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the mouse
> >>stutters slighty when burning (in atapi mode). I am now using as
> >>sheduler. Shoudl I try deadline or do you this it is something else?
> >>Should I open a new topic?
> >
> >
> >k3b is probably still going through ide-scsi which you must not. It
> >would be interesting if you could try without ide-scsi and use cdrecord
> >manually (maybe someone more knowledgable on k3b can common on whether
> >they support 2.6 or not). 2.6 will be a lot faster than 2.4.
>
> No, it uses atapi as a) it claims to be compatible with it and b) I have

SG_IO or CDROM_SEND_PACKET? The latter should never have been merged in
cdrecord, and you should never use it. If it is using SG_IO, I'm very
interested in knowing more. vmstat 1 while doing the burn would be
interesting, just for 10 seconds where you see the problem.

> neither activated scsi nor scsi-emulation in the kernel, so it most

Great

> probably is a new issue. Furthermore my hd reading (I once contacted you
> because of that) didn't improve with the new kernel, though some
> bugfixes in this directions are mentioned by Andrew Morton.

Don't remember, sorry :)

--
Jens Axboe

2003-11-05 10:18:10

by DervishD

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Hi Prakash :)

* Prakash K. Cheemplavam <[email protected]> dixit:
> well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in
> DAO mode to burn the cd ends up in non-bit identical copies, wheres ion
> TAO (atleast with my 10x CD-RW I tested) the copy succeded. I tried
> several times, and always got this issue.

Just FYI, I've had a similar problem a couple of days ago, and,
after a lot of testing I discovered that the problem was in the
motherboard. Try to isolate the problem: use the recorder in another
machine to see if that solves the problem (the recorder may be
damaged and may fail in DAO mode. Strange, but...). Check the cabling
and use another motherboard, or even another OS to do the burning in
DAO mode to see that it fails. And have a look at cdrdao, may the
problem is a cdrecord issue (don't think so, but...) :??

Ra?l N??ez de Arenas Coronado

--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

2003-11-05 10:19:03

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>
>>Jens Axboe wrote:
>>
>>>On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>>>
>>>
>>>>Jens Axboe wrote:
>>>>
>>>>
>>>>>On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Jens Axboe wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Hi,
>>>>>>>>
>>>>>>>>well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in
>>>>>>
>>>>>>DAO mode to burn the cd ends up in non-bit identical copies, wheres ion
>>>>>>TAO (atleast with my 10x CD-RW I tested) the copy succeded. I tried
>>>>>>several times, and always got this issue.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
>>>>>>>>f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
>>>>>>>>
>>>>>>>>TAO:
>>>>>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
>>>>>>>>f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
>>>>>>>>
>>>>>>>>DAO:
>>>>>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
>>>>>>>>09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Could you please try and cmp the two images, finding out how big the
>>>>>>>corrupted chunks are and what kind of data they contain?
>>>>>>
>>>>>>
>>>>>>After some further investigation I found out, that the data is NOT
>>>>>>corrupted, but in a way truncated in DAO mode: When I read out the
>>>>>>image
>>>>>
>>>>>>from the CD-RW drive, about 5kbyte are missing at the end (and doing
>>>>>
>>>>>
>>>>>>several burn, it is always the same amount). Strange enough if I read
>>>>>>the DAO burnt disk out by my DVD-ROM, the image can be read out
>>>>>>completely! Can you understand this behaviour? I don't think it is a
>>>>>>problem of my burner, but rather of the atapi driver?
>>>>>
>>>>>
>>>>>Is actual data missing at the end? If yes, I'd say this looks a lot more
>>>>>like a cdrecord problem.
>>>>
>>>>Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM restores
>>>>the full image (md5sum matches), but the CD-RW does not.
>>>
>>>
>>>You need to use the pad option to record.
>>
>>Uhm, could you be more specific? I just use the k3b frontend to burn,
>>and in the cdrdao manual I couldn't find something useful to it.
>
>
> it's a cdrecord option, I've never used k3b so cannot comment on how to
> make it enable that.

Hmm, I'll take a look, but I don't really think it is a problem of the
recording programme, otherwise how could my reader read it out completely?

>>SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the mouse
>>stutters slighty when burning (in atapi mode). I am now using as
>>sheduler. Shoudl I try deadline or do you this it is something else?
>>Should I open a new topic?
>
>
> k3b is probably still going through ide-scsi which you must not. It
> would be interesting if you could try without ide-scsi and use cdrecord
> manually (maybe someone more knowledgable on k3b can common on whether
> they support 2.6 or not). 2.6 will be a lot faster than 2.4.

No, it uses atapi as a) it claims to be compatible with it and b) I have
neither activated scsi nor scsi-emulation in the kernel, so it most
probably is a new issue. Furthermore my hd reading (I once contacted you
because of that) didn't improve with the new kernel, though some
bugfixes in this directions are mentioned by Andrew Morton.

Prakash

2003-11-05 10:29:55

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>
>>Jens Axboe wrote:
>>
>>>On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>>>
>>>
>>>>Jens Axboe wrote:
>>>>
>>>>
>>>>>On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Jens Axboe wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Jens Axboe wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Hi,
>>>>>>>>>>
>>>>>>>>>>well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in
>>>>>>>>
>>>>>>>>DAO mode to burn the cd ends up in non-bit identical copies, wheres
>>>>>>>>ion TAO (atleast with my 10x CD-RW I tested) the copy succeded. I
>>>>>>>>tried several times, and always got this issue.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
>>>>>>>>>>f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
>>>>>>>>>>
>>>>>>>>>>TAO:
>>>>>>>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
>>>>>>>>>>f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
>>>>>>>>>>
>>>>>>>>>>DAO:
>>>>>>>>>>bash-2.05b$ md5sum /dev/cdroms/cdrom1
>>>>>>>>>>09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Could you please try and cmp the two images, finding out how big the
>>>>>>>>>corrupted chunks are and what kind of data they contain?
>>>>>>>>
>>>>>>>>
>>>>>>>>After some further investigation I found out, that the data is NOT
>>>>>>>>corrupted, but in a way truncated in DAO mode: When I read out the
>>>>>>>>image
>>>>>>>
>>>>>>>>from the CD-RW drive, about 5kbyte are missing at the end (and doing
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>several burn, it is always the same amount). Strange enough if I read
>>>>>>>>the DAO burnt disk out by my DVD-ROM, the image can be read out
>>>>>>>>completely! Can you understand this behaviour? I don't think it is a
>>>>>>>>problem of my burner, but rather of the atapi driver?
>>>>>>>
>>>>>>>
>>>>>>>Is actual data missing at the end? If yes, I'd say this looks a lot
>>>>>>>more
>>>>>>>like a cdrecord problem.
>>>>>>
>>>>>>Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM
>>>>>>restores the full image (md5sum matches), but the CD-RW does not.
>>>>>
>>>>>
>>>>>You need to use the pad option to record.
>>>>
>>>>Uhm, could you be more specific? I just use the k3b frontend to burn,
>>>>and in the cdrdao manual I couldn't find something useful to it.
>>>
>>>
>>>it's a cdrecord option, I've never used k3b so cannot comment on how to
>>>make it enable that.
>>
>>Hmm, I'll take a look, but I don't really think it is a problem of the
>>recording programme, otherwise how could my reader read it out completely?
>
>
> It isn't a problem of the recorder program. But some drives wont read
> the very end of a disc unless there are some pad blocks at the end.
> Thus, you should always use the cdrecord pad option.

Uhm, ok, I just took a look at the source image and the last (missing)
4096 bytes are just 00, so nothing critical missing anyway...so your pad
parameter sounds sensible. :) Should drop a note to the k3b devs then,
as well...

> SG_IO or CDROM_SEND_PACKET? The latter should never have been merged in
> cdrecord, and you should never use it. If it is using SG_IO, I'm very
> interested in knowing more. vmstat 1 while doing the burn would be
> interesting, just for 10 seconds where you see the problem.

Uhh, I'll try to find out. I must go now, but I'll report back later.

>>probably is a new issue. Furthermore my hd reading (I once contacted you
>>because of that) didn't improve with the new kernel, though some
>>bugfixes in this directions are mentioned by Andrew Morton.
>
>
> Don't remember, sorry :)

I probably will make a new topic regarding issues (I think) I found with
the new mm kernel.

cya,

Prakash

2003-11-05 10:30:12

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, Nov 05 2003, Nick Piggin wrote:
>
>
> Prakash K. Cheemplavam wrote:
>
> >
> >SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the mouse
> >stutters slighty when burning (in atapi mode). I am now using as
> >sheduler. Shoudl I try deadline or do you this it is something else?
> >Should I open a new topic?
> >
>
> This is more likely to be the CPU scheduler or something holding
> interrupts for too long. Are you running anything at a modified
^^^^^^^^

precisely, that's why the actual interface that cdrecord uses is the
primary key to knowing what the problem is.

--
Jens Axboe

2003-11-05 10:28:15

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Prakash K. Cheemplavam wrote:

>
> SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the mouse
> stutters slighty when burning (in atapi mode). I am now using as
> sheduler. Shoudl I try deadline or do you this it is something else?
> Should I open a new topic?
>

This is more likely to be the CPU scheduler or something holding
interrupts for too long. Are you running anything at a modified
priority (nice)?

2003-11-05 10:36:00

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> On Wed, Nov 05 2003, Nick Piggin wrote:
>
>>
>>Prakash K. Cheemplavam wrote:
>>
>>
>>>SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the mouse
>>>stutters slighty when burning (in atapi mode). I am now using as
>>>sheduler. Shoudl I try deadline or do you this it is something else?
>>>Should I open a new topic?
>>>
>>
>>This is more likely to be the CPU scheduler or something holding
>>interrupts for too long. Are you running anything at a modified
>
> ^^^^^^^^
>
> precisely, that's why the actual interface that cdrecord uses is the
> primary key to knowing what the problem is.

As said, I'll report back later...

Prakash

[OT] Something about this kernel list is stupid: It always wants to
reply to the author instead of the list, generating double the traffic
if one doesn't pay attention...

2003-11-05 10:32:19

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Nick Piggin wrote:
>
>
> Prakash K. Cheemplavam wrote:
>
>>
>> SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the mouse
>> stutters slighty when burning (in atapi mode). I am now using as
>> sheduler. Shoudl I try deadline or do you this it is something else?
>> Should I open a new topic?
>>
>
> This is more likely to be the CPU scheduler or something holding
> interrupts for too long. Are you running anything at a modified
> priority (nice)?

No, I haven't changed anything (at least not knowingly ;-) but now using
the forcedeth driver instead of nvnet module when I went from mm1 to mm2.

Prakash

2003-11-05 10:54:45

by Gene Heskett

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wednesday 05 November 2003 05:29, Jens Axboe wrote:
>On Wed, Nov 05 2003, Nick Piggin wrote:
>> Prakash K. Cheemplavam wrote:
>> >SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the
>> > mouse stutters slighty when burning (in atapi mode). I am now
>> > using as sheduler. Shoudl I try deadline or do you this it is
>> > something else? Should I open a new topic?
>>
>> This is more likely to be the CPU scheduler or something holding
>> interrupts for too long. Are you running anything at a modified
>
> ^^^^^^^^
>
>precisely, that's why the actual interface that cdrecord uses is the
>primary key to knowing what the problem is.

Similar problem here Jens.

I have the emulation stuff turned on, and use /dev/scd0 to access my
12/10/32 Creative burner. I failed to complete an iso burn yesterday,
useing test9-mm1, and the initial logged message indicate an IRQ timeout.

Using k3b, how do I determine the answer to the above, or did I just do that?

Here is the first few lines of the log, there were many:
Nov 4 09:28:40 coyote kernel: hdc: irq timeout: status=0xd8 { Busy }
Nov 4 09:28:40 coyote kernel: hdc: DMA disabled
Nov 4 09:28:40 coyote kernel: ide-scsi: abort called for 9691
Nov 4 09:28:40 coyote kernel: Debug: sleeping function called from invalid context at include/asm/semaphore.h:119
Nov 4 09:28:40 coyote kernel: in_atomic():1, irqs_disabled():1
Nov 4 09:28:40 coyote kernel: Call Trace:
Nov 4 09:28:40 coyote kernel: [<c011c048>] __might_sleep+0xb8/0xf0
Nov 4 09:28:40 coyote kernel: [<c026e7dc>] scsi_sleep+0x6c/0x90
Nov 4 09:28:40 coyote kernel: [<c026e750>] scsi_sleep_done+0x0/0x20
Nov 4 09:28:40 coyote kernel: [<c027f11f>] idescsi_abort+0xef/0x100
Nov 4 09:28:40 coyote kernel: [<c026e0c2>] scsi_try_to_abort_cmd+0x62/0x80
Nov 4 09:28:40 coyote kernel: [<c026e1f0>] scsi_eh_abort_cmds+0x40/0x80
Nov 4 09:28:40 coyote kernel: [<c026ebe3>] scsi_unjam_host+0xa3/0xd0
Nov 4 09:28:40 coyote kernel: [<c026ecea>] scsi_error_handler+0xda/0x120
Nov 4 09:28:40 coyote kernel: [<c026ec10>] scsi_error_handler+0x0/0x120
Nov 4 09:28:40 coyote kernel: [<c0109349>] kernel_thread_helper+0x5/0xc
Nov 4 09:28:40 coyote kernel:
Nov 4 09:28:40 coyote kernel: bad: scheduling while atomic!
Nov 4 09:28:40 coyote kernel: Call Trace:
Nov 4 09:28:40 coyote kernel: [<c011a9eb>] schedule+0x57b/0x580
Nov 4 09:28:40 coyote kernel: [<c011ed2d>] printk+0x12d/0x190
Nov 4 09:28:40 coyote kernel: [<c010a2ac>] __down+0x8c/0x130
Nov 4 09:28:40 coyote kernel: [<c011aa50>] default_wake_function+0x0/0x30
Nov 4 09:28:40 coyote kernel: [<c010b5be>] dump_stack+0x1e/0x20
Nov 4 09:28:40 coyote kernel: [<c010a51f>] __down_failed+0xb/0x14
Nov 4 09:28:40 coyote kernel: [<c026ef42>] .text.lock.scsi_error+0x37/0x75
Nov 4 09:28:40 coyote kernel: [<c026e750>] scsi_sleep_done+0x0/0x20
Nov 4 09:28:40 coyote kernel: [<c027f11f>] idescsi_abort+0xef/0x100
Nov 4 09:28:40 coyote kernel: [<c026e0c2>] scsi_try_to_abort_cmd+0x62/0x80
Nov 4 09:28:40 coyote kernel: [<c026e1f0>] scsi_eh_abort_cmds+0x40/0x80
Nov 4 09:28:40 coyote kernel: [<c026ebe3>] scsi_unjam_host+0xa3/0xd0
Nov 4 09:28:40 coyote kernel: [<c026ecea>] scsi_error_handler+0xda/0x120
Nov 4 09:28:40 coyote kernel: [<c026ec10>] scsi_error_handler+0x0/0x120
Nov 4 09:28:40 coyote kernel: [<c0109349>] kernel_thread_helper+0x5/0xc

--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2003-11-05 11:21:31

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Prakash K. Cheemplavam wrote:

> Jens Axboe wrote:
>
>> On Wed, Nov 05 2003, Nick Piggin wrote:
>>
>>>
>>> Prakash K. Cheemplavam wrote:
>>>
>>>
>>>> SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the mouse
>>>> stutters slighty when burning (in atapi mode). I am now using as
>>>> sheduler. Shoudl I try deadline or do you this it is something
>>>> else? Should I open a new topic?
>>>>
>>>
>>> This is more likely to be the CPU scheduler or something holding
>>> interrupts for too long. Are you running anything at a modified
>>
>>
>> ^^^^^^^^
>>
>> precisely, that's why the actual interface that cdrecord uses is the
>> primary key to knowing what the problem is.
>
>
> As said, I'll report back later...

please do the following while burning is in progress
ps -Afl > file
and send me the file.

>
> Prakash
>
> [OT] Something about this kernel list is stupid: It always wants to
> reply to the author instead of the list, generating double the traffic
> if one doesn't pay attention...
>

The lkml convention is reply to all. It works well for a high volume list.

2003-11-05 14:36:30

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, Nov 05 2003, Nick Piggin wrote:
> >[OT] Something about this kernel list is stupid: It always wants to
> >reply to the author instead of the list, generating double the traffic
> >if one doesn't pay attention...
> >
>
> The lkml convention is reply to all. It works well for a high volume list.

Indeed. I can only talk for myself, but I read lkml very casually (once
a week or so), so I'll never see your mail if you don't cc me. It's as
simple as that.

--
Jens Axboe

2003-11-05 14:29:13

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

(cc me, just caught your message by luck)

On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> >>>it's a cdrecord option, I've never used k3b so cannot comment on how to
> >>>make it enable that.
> >>
> >>Hmm, I'll take a look, but I don't really think it is a problem of the
> >>recording programme, otherwise how could my reader read it out completely?
> >
> >
> >It isn't a problem of the recorder program. But some drives wont read
> >the very end of a disc unless there are some pad blocks at the end.
> >Thus, you should always use the cdrecord pad option.
>
> Uhm, ok, I just took a look at the source image and the last (missing)
> 4096 bytes are just 00, so nothing critical missing anyway...so your pad
> parameter sounds sensible. :) Should drop a note to the k3b devs then,
> as well...

Good idea, if it's not already an option.

> >Don't remember, sorry :)
>
> I probably will make a new topic regarding issues (I think) I found with
> the new mm kernel.

Fine, check the SG_IO thing first though.

--
Jens Axboe

2003-11-05 14:39:15

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, Nov 05 2003, Gene Heskett wrote:
> On Wednesday 05 November 2003 05:29, Jens Axboe wrote:
> >On Wed, Nov 05 2003, Nick Piggin wrote:
> >> Prakash K. Cheemplavam wrote:
> >> >SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the
> >> > mouse stutters slighty when burning (in atapi mode). I am now
> >> > using as sheduler. Shoudl I try deadline or do you this it is
> >> > something else? Should I open a new topic?
> >>
> >> This is more likely to be the CPU scheduler or something holding
> >> interrupts for too long. Are you running anything at a modified
> >
> > ^^^^^^^^
> >
> >precisely, that's why the actual interface that cdrecord uses is the
> >primary key to knowing what the problem is.
>
> Similar problem here Jens.
>
> I have the emulation stuff turned on, and use /dev/scd0 to access my
> 12/10/32 Creative burner. I failed to complete an iso burn yesterday,
> useing test9-mm1, and the initial logged message indicate an IRQ timeout.

Well don't, ide-scsi must not be used. So the dozens of messages to that
effect on this list, and Dave Jones 2.6 kernel document for more info.

--
Jens Axboe

2003-11-05 17:34:25

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> On Wed, Nov 05 2003, Nick Piggin wrote:
>
>>>[OT] Something about this kernel list is stupid: It always wants to
>>>reply to the author instead of the list, generating double the traffic
>>>if one doesn't pay attention...
>>>
>>
>>The lkml convention is reply to all. It works well for a high volume list.
>
>
> Indeed. I can only talk for myself, but I read lkml very casually (once
> a week or so), so I'll never see your mail if you don't cc me. It's as
> simple as that.

Uhh well OK, I thought you guys would receive all mails form the list,
because then it is a bit irritating to get everything twice in an active
discussion. Son now I gotta start testing...

Prakash

2003-11-05 18:42:35

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Nick Piggin wrote:
>
>
> Prakash K. Cheemplavam wrote:
>
>> Jens Axboe wrote:
>>
>>> On Wed, Nov 05 2003, Nick Piggin wrote:
>>>
>>>>
>>>> Prakash K. Cheemplavam wrote:
>>>>
>>>>
>>>>> SOmething else I noticed with new 2.6tes9-mm2 kernel: Now the mouse
>>>>> stutters slighty when burning (in atapi mode). I am now using as
>>>>> sheduler. Shoudl I try deadline or do you this it is something
>>>>> else? Should I open a new topic?
>>>>>
>>>>
>>>> This is more likely to be the CPU scheduler or something holding
>>>> interrupts for too long. Are you running anything at a modified
>>>
>>>
>>>
>>> ^^^^^^^^
>>>
>>> precisely, that's why the actual interface that cdrecord uses is the
>>> primary key to knowing what the problem is.
>>
>>
>>
>> As said, I'll report back later...
>
>
>
> please do the following while burning is in progress
> ps -Afl > file
> and send me the file.

So here is the ps:

F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY
TIME CMD
4 S root 1 0 0 76 0 - 365 schedu 19:21 ?
00:00:06 init [3]
1 S root 2 1 0 94 19 - 0 ksofti 19:21 ?
00:00:00 [ksoftirqd/0]
1 S root 3 1 0 65 -10 - 0 worker 19:21 ?
00:00:00 [events/0]
1 S root 4 1 0 65 -10 - 0 worker 19:21 ?
00:00:00 [kblockd/0]
1 S root 5 1 0 75 0 - 0 hub_th 19:21 ?
00:00:00 [khubd]
1 S root 6 1 0 85 0 - 0 pdflus 19:21 ?
00:00:00 [pdflush]
1 S root 7 1 0 75 0 - 0 pdflus 19:21 ?
00:00:00 [pdflush]
1 S root 8 1 0 85 0 - 0 kswapd 19:21 ?
00:00:00 [kswapd0]
1 S root 9 1 0 70 -10 - 0 worker 19:21 ?
00:00:00 [aio/0]
1 S root 10 1 0 70 -10 - 0 worker 19:21 ?
00:00:00 [aio_fput/0]
1 S root 11 1 0 65 -10 - 0 worker 19:21 ?
00:00:00 [xfslogd/0]
1 S root 12 1 0 70 -10 - 0 worker 19:21 ?
00:00:00 [xfsdatad/0]
1 S root 13 1 0 75 0 - 0 pagebu 19:21 ?
00:00:00 [pagebufd]
1 S root 14 1 0 77 0 - 0 serio_ 19:21 ?
00:00:00 [kseriod]
1 S root 15 1 0 77 0 - 0 down_i 19:21 ?
00:00:00 [i2oevtd]
1 S root 16 1 0 75 0 - 0 schedu 19:21 ?
00:00:00 [xfs_syncd]
5 S root 128 1 0 77 0 - 457 devfsd 19:21 ?
00:00:00 /sbin/devfsd /dev
5 S root 3122 1 0 75 0 - 391 schedu 19:21 ?
00:00:00 metalog [MASTER]
5 S root 3131 3122 0 75 0 - 385 syslog 19:21 ?
00:00:00 metalog [KERNEL]
5 S root 3153 1 0 76 0 - 1184 schedu 19:21 ?
00:00:00 /usr/sbin/cupsd
5 S xfs 3589 1 0 76 0 - 1893 schedu 19:21 ?
00:00:00 /usr/X11R6/bin/xfs -daemon -config /etc/X11/fs/config -droppriv
-user xfs -port -1
4 S root 3615 1 0 77 0 - 374 schedu 19:21 tty1
00:00:00 /sbin/agetty 38400 tty1 linux
4 S root 3616 1 0 77 0 - 374 schedu 19:21 tty2
00:00:00 /sbin/agetty 38400 tty2 linux
4 S root 3617 1 0 77 0 - 374 schedu 19:21 tty3
00:00:00 /sbin/agetty 38400 tty3 linux
4 S root 3618 1 0 77 0 - 374 schedu 19:21 tty4
00:00:00 /sbin/agetty 38400 tty4 linux
4 S root 3619 1 0 77 0 - 374 schedu 19:21 tty5
00:00:00 /sbin/agetty 38400 tty5 linux
4 S root 3620 1 0 77 0 - 374 schedu 19:21 tty6
00:00:00 /sbin/agetty 38400 tty6 linux
5 S root 3637 1 0 76 0 - 642 schedu 19:21 ?
00:00:00 /usr/kde/3.1/bin/kdm
4 S root 3639 3637 2 75 0 - 71390 schedu 19:21 ?
00:00:21 /etc/X11/X -auth /var/run/xauth/A:0-dp9cjG
5 S root 3640 3637 0 76 0 - 851 wait4 19:21 ?
00:00:00 -:0
4 S light 3711 3640 0 82 0 - 1094 wait4 19:21 ?
00:00:00 /bin/sh /etc/X11/Sessions/kde-3.1.4
0 S light 3733 3711 0 76 0 - 1095 wait4 19:21 ?
00:00:00 /bin/sh --login /usr/kde/3.1/bin/startkde
1 S light 3759 1 0 77 0 - 6613 schedu 19:21 ?
00:00:00 kdeinit: Running...
1 S light 3762 1 0 76 0 - 7092 schedu 19:21 ?
00:00:00 kdeinit: dcopserver --nosid
1 S light 3765 1 0 76 0 - 7457 schedu 19:21 ?
00:00:00 kdeinit: klauncher
1 S light 3767 1 0 75 0 - 7911 schedu 19:21 ?
00:00:00 kdeinit: kded
1 S light 3773 1 0 76 0 - 7962 schedu 19:22 ?
00:00:00 kdeinit: kxkb
1 S light 3789 1 0 76 0 - 9171 schedu 19:22 ?
00:00:00 kdeinit: knotify
0 S light 3790 3733 0 76 0 - 362 clock_ 19:22 ?
00:00:00 kwrapper ksmserver
1 S light 3792 1 0 76 0 - 7649 schedu 19:22 ?
00:00:00 kdeinit: ksmserver
1 S light 3793 3759 0 75 0 - 8074 schedu 19:22 ?
00:00:00 kdeinit: kwin
1 S light 3795 1 0 75 0 - 8277 schedu 19:22 ?
00:00:00 kdeinit: kdesktop
1 S light 3797 1 0 75 0 - 8642 schedu 19:22 ?
00:00:01 kdeinit: kicker
1 S light 3798 3759 0 76 0 - 6774 schedu 19:22 ?
00:00:00 kdeinit: kio_file file
/tmp/ksocket-light/klauncherSzBMlc.slave-socket
/tmp/ksocket-light/kdesktop4a5OQb.slave-socket
0 S light 3799 3795 0 75 0 - 6137 schedu 19:22 ?
00:00:00 /home/light/.kde/Autostart/gkrellm2
1 S light 3804 1 0 76 0 - 7946 schedu 19:22 ?
00:00:00 kdeinit: klipper
1 S light 3807 1 0 76 0 - 7622 schedu 19:22 ?
00:00:00 kalarmd --login
1 S light 3808 1 0 76 0 - 7819 schedu 19:22 ?
00:00:00 korgac --miniicon korganizer
0 S light 3810 3759 0 77 0 - 1094 wait4 19:22 ?
00:00:00 /bin/bash /home/light/mozilla-start
0 S light 3813 3810 0 75 0 - 27556 schedu 19:22 ?
00:00:06 /usr/lib/mozilla/mozilla-bin
0 S light 3846 1 0 76 0 - 1651 schedu 19:22 ?
00:00:00 /usr/libexec/gconfd-2 10
0 Z light 3856 3813 0 77 0 - 0 exit 19:22 ?
00:00:00 [netstat] <defunct>
0 S light 3859 1 0 75 0 - 649 schedu 19:22 ?
00:00:00 /usr/bin/esd -terminate -nobeeps -as 2 -spawnfd 43
1 S light 3869 3759 0 75 0 - 8482 schedu 19:22 ?
00:00:01 kdeinit: konsole
0 S light 3871 3869 0 75 0 - 1145 wait4 19:22 pts/0
00:00:00 /bin/bash
0 S light 3893 3759 1 75 0 - 13965 schedu 19:24 ?
00:00:08 k3b
1 S light 3933 3759 0 76 0 - 6770 schedu 19:24 ?
00:00:00 kdeinit: kio_file file
/tmp/ksocket-light/klauncherSzBMlc.slave-socket
/tmp/ksocket-light/k3bPj2Bsa.slave-socket
0 D light 4162 3893 0 78 0 - 1469 blk_do 19:36 ?
00:00:00 /usr/bin/cdrecord -v gracetime=2
dev=/dev/ide/host0/bus1/target0/lun0/cd speed=10 driveropts=burnfree
-eject -overburn -pad -dao -data /mnt/d/livecd-2.6_10-23-2003.iso
1 S light 4163 4162 0 75 0 - 1469 clock_ 19:36 ?
00:00:00 /usr/bin/cdrecord -v gracetime=2
dev=/dev/ide/host0/bus1/target0/lun0/cd speed=10 driveropts=burnfree
-eject -overburn -pad -dao -data /mnt/d/livecd-2.6_10-23-2003.iso
0 R light 4170 3871 0 77 0 - 611 - 19:37 pts/0
00:00:00 ps -Afl

2003-11-05 18:46:29

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> (cc me, just caught your message by luck)
>
> On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>
>>>>>it's a cdrecord option, I've never used k3b so cannot comment on how to
>>>>>make it enable that.
>>>>
>>>>Hmm, I'll take a look, but I don't really think it is a problem of the
>>>>recording programme, otherwise how could my reader read it out completely?
>>>
>>>
>>>It isn't a problem of the recorder program. But some drives wont read
>>>the very end of a disc unless there are some pad blocks at the end.
>>>Thus, you should always use the cdrecord pad option.

Well, I now used the -pad option, but now the image (naturally) gets
larger and thus k3b reports verify fail. I think the k3b people need to
ignore the last 00s and calc the md5sum according to the original iso
size...

>>>Don't remember, sorry :)
>>
>>I probably will make a new topic regarding issues (I think) I found with
>>the new mm kernel.
>
>
> Fine, check the SG_IO thing first though.

I am sorry, but could you explain how to find out? I dunno where to
look... But I made your vmstat output:

procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
2 0 0 579472 13976 308572 0 0 425 85 1255 645 5
3 84 9
2 0 0 579456 13976 308572 0 0 0 0 725 521 5
5 91 0
1 0 0 579448 13976 308572 0 0 0 0 736 523 2
5 94 0
0 0 0 579448 13976 308572 0 0 0 25 745 439 2
6 92 0
0 0 0 579448 13976 308572 0 0 0 0 723 541 2
6 92 0
1 0 0 579472 13976 308572 0 0 1 17 944 712 3
5 89 3
0 0 0 579280 13976 308624 0 0 35 26 919 869 11
8 77 5
0 0 0 579272 13976 308624 0 0 0 0 741 439 2
6 92 0
1 0 0 579192 13976 308624 0 0 0 2 743 1944 36
8 56 0
0 0 0 579200 13976 308624 0 0 0 0 741 491 3
5 92 0
0 0 0 579200 13976 308624 0 0 0 0 729 521 2
5 94 0
2 0 0 579208 13976 308624 0 0 0 0 733 478 3
6 91 0
0 0 0 579200 13976 308624 0 0 0 0 724 519 2
5 94 0
0 0 0 579216 13976 308624 0 0 0 0 739 470 3
6 91 0
1 0 0 579216 13976 308624 0 0 0 0 719 537 2
6 92 0
0 0 0 579216 13976 308624 0 0 0 0 736 495 3
6 91 0
0 0 0 579216 13976 308624 0 0 0 12 724 562 2
5 94 0
1 0 0 579200 13976 308624 0 0 0 0 844 1271 8
6 86 0
0 0 0 579192 13976 308624 0 0 0 17 930 815 3
6 91 0
0 0 0 579128 13976 308624 0 0 0 0 988 1808 28
8 64 0
1 0 0 579128 13976 308624 0 0 0 0 857 1056 26
8 67 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 579136 13976 308624 0 0 0 0 1023 911 12
9 78 0
0 0 0 579192 13976 308624 0 0 0 0 864 883 35
8 58 0
1 0 0 579000 13976 308624 0 0 0 4 830 932 48
6 46 0
1 0 0 579000 13976 308624 0 0 0 2 922 899 33
9 59 0
0 0 0 578816 13976 308824 0 0 192 4 766 847 38
8 52 2
1 0 0 578816 13976 308824 0 0 0 0 739 500 6
5 89 0
0 0 0 578816 13976 308824 0 0 0 0 787 744 5
6 89 0
0 0 0 578816 13976 308824 0 0 0 28 759 552 3
6 91 0
1 0 0 578832 13980 308824 0 0 3 0 840 823 17
8 75 0
0 0 0 578816 13980 308820 0 0 0 10 769 696 27
8 64 2
0 0 0 578824 13980 308820 0 0 0 0 761 626 3
6 91 0
2 0 0 578816 13980 308820 0 0 0 0 765 512 6
6 88 0
0 0 0 578808 13980 308820 0 0 0 20 863 860 11
5 85 0
0 0 0 578808 13980 308820 0 0 0 0 744 524 2
8 91 0
1 0 0 578808 13980 308820 0 0 0 0 736 547 3
5 92 0
0 0 0 578808 13980 308820 0 0 0 0 890 699 8
8 84 0
0 0 0 578824 13980 308820 0 0 0 25 932 805 9
5 86 0
1 0 0 578872 13980 308824 0 0 0 1 836 913 33
10 57 0
1 0 0 578872 13980 308824 0 0 0 0 842 776 23
6 71 0
3 0 0 578872 13980 308824 0 0 0 0 889 806 17
9 74 0
1 0 0 578952 13980 308824 0 0 0 5 842 995 68
9 23 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
2 0 0 578944 13980 308828 0 0 0 11 835 979 36
13 52 0
0 0 0 578944 13980 308828 0 0 0 0 843 852 38
7 55 0
1 0 0 578944 13980 308828 0 0 0 0 1171 650 8
3 89 0
0 0 0 578960 13980 308828 0 0 0 0 1182 419 13
1 86 0
0 0 0 578960 13980 308832 0 0 0 0 1119 371 2
0 98 0
2 0 0 578880 13980 308832 0 0 0 1 1269 600 16
2 82 0
0 1 0 578240 13980 309128 0 0 288 14 1265 626 26
2 69 3
0 0 0 576720 13996 309940 0 0 825 10 1333 1230 46
6 39 9
0 0 0 576720 13996 309952 0 0 0 10 1101 759 38
4 57 1
0 0 0 576528 13996 310088 0 0 128 5 1257 730 22
2 75 1
0 0 0 576528 13996 310088 0 0 0 0 1161 621 11
2 87 0
0 0 0 576624 13996 310088 0 0 0 0 1115 346 1
1 98 0
0 0 0 576624 13996 310088 0 0 0 0 1099 249 1
0 99 0
0 0 0 576624 13996 310088 0 0 0 0 1067 199 0
0 100 0
0 0 0 576624 13996 310088 0 0 0 0 1104 258 1
1 98 0
2 0 0 576632 13996 310088 0 0 0 24 1104 440 3
2 94 0
0 0 0 576632 13996 310088 0 0 0 0 1037 242 0
0 100 0
0 0 0 576640 13996 310088 0 0 0 0 1221 408 4
0 96 0
0 0 0 580928 13996 305988 0 0 0 0 1050 269 1
1 98 0
5 0 0 581008 13996 305988 0 0 0 0 1234 482 10
2 88 0
3 0 0 580928 13996 305988 0 0 0 223 1289 1420 88
12 0 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 580928 13996 305988 0 0 0 0 1138 1194 39
5 56 0
0 0 0 580928 13996 305988 0 0 0 0 1065 145 1
0 99 0

2003-11-06 09:59:22

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> Jens Axboe wrote:
> >(cc me, just caught your message by luck)
> >
> >On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> >
> >>>>>it's a cdrecord option, I've never used k3b so cannot comment on how to
> >>>>>make it enable that.
> >>>>
> >>>>Hmm, I'll take a look, but I don't really think it is a problem of the
> >>>>recording programme, otherwise how could my reader read it out
> >>>>completely?
> >>>
> >>>
> >>>It isn't a problem of the recorder program. But some drives wont read
> >>>the very end of a disc unless there are some pad blocks at the end.
> >>>Thus, you should always use the cdrecord pad option.
>
> Well, I now used the -pad option, but now the image (naturally) gets
> larger and thus k3b reports verify fail. I think the k3b people need to
> ignore the last 00s and calc the md5sum according to the original iso
> size...

Sounds right, yes.

> >>>Don't remember, sorry :)
> >>
> >>I probably will make a new topic regarding issues (I think) I found with
> >>the new mm kernel.
> >
> >
> >Fine, check the SG_IO thing first though.
>
> I am sorry, but could you explain how to find out? I dunno where to
> look... But I made your vmstat output:

Your other mail showed the device argument being the actual device, so
unless cdrecord screws, it is using SG_IO.

> procs -----------memory---------- ---swap-- -----io---- --system--
> ----cpu----
> r b swpd free buff cache si so bi bo in cs us
> sy id wa
> 2 0 0 579472 13976 308572 0 0 425 85 1255 645 5
> 3 84 9
> 2 0 0 579456 13976 308572 0 0 0 0 725 521 5
> 5 91 0
> 1 0 0 579448 13976 308572 0 0 0 0 736 523 2
> 5 94 0
> 0 0 0 579448 13976 308572 0 0 0 25 745 439 2

[snip]

This looks good, from a system utilization point of view. I'm wondering
whether you have the iso image cached? There's no block io going on.

It does like more like a CPU scheduler problem at this point.

--
Jens Axboe

2003-11-06 12:40:57

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

>>procs -----------memory---------- ---swap-- -----io---- --system--
>>----cpu----
>> r b swpd free buff cache si so bi bo in cs us
>>sy id wa
>> 2 0 0 579472 13976 308572 0 0 425 85 1255 645 5
>>3 84 9
>> 2 0 0 579456 13976 308572 0 0 0 0 725 521 5
>>5 91 0
>> 1 0 0 579448 13976 308572 0 0 0 0 736 523 2
>>5 94 0
>> 0 0 0 579448 13976 308572 0 0 0 25 745 439 2
>
>
> [snip]
>
> This looks good, from a system utilization point of view. I'm wondering
> whether you have the iso image cached? There's no block io going on.
>
> It does like more like a CPU scheduler problem at this point.

Ok, then it is Nick's turn, I guess. :-) Yeah most probably the iso is
cached, as it was not the first time I burnt the iso when I did the
vmstat, furthermore I have 1 GB of RAM... The other thing which doesn't
speack for i/o problems, I guess: Just the first seconds when I start
erasing the CD-RW the mouse hangs and heavily stutters, then it is OK
until actual burning of image begins, then the mouse slightly stutters.
All this was not with test9-mm1.

2003-11-06 13:06:08

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:

>On Thu, Nov 06 2003, Nick Piggin wrote:
>
>>
>>Prakash K. Cheemplavam wrote:
>>
>>
>>>>>procs -----------memory---------- ---swap-- -----io---- --system--
>>>>>----cpu----
>>>>>r b swpd free buff cache si so bi bo in cs us
>>>>>sy id wa
>>>>>2 0 0 579472 13976 308572 0 0 425 85 1255 645 5
>>>>>3 84 9
>>>>>2 0 0 579456 13976 308572 0 0 0 0 725 521 5
>>>>>5 91 0
>>>>>1 0 0 579448 13976 308572 0 0 0 0 736 523 2
>>>>>5 94 0
>>>>>0 0 0 579448 13976 308572 0 0 0 25 745 439 2
>>>>>
>>>>
>>>>
>>>>[snip]
>>>>
>>>>This looks good, from a system utilization point of view. I'm wondering
>>>>whether you have the iso image cached? There's no block io going on.
>>>>
>>>>It does like more like a CPU scheduler problem at this point.
>>>>
>>>
>>>
>>>Ok, then it is Nick's turn, I guess. :-) Yeah most probably the iso is
>>>cached, as it was not the first time I burnt the iso when I did the
>>>vmstat, furthermore I have 1 GB of RAM... The other thing which
>>>doesn't speack for i/o problems, I guess: Just the first seconds when
>>>I start erasing the CD-RW the mouse hangs and heavily stutters, then
>>>it is OK until actual burning of image begins, then the mouse slightly
>>>stutters. All this was not with test9-mm1.
>>>
>>>
>>I don't think the scheduler is the problem if you didn't have these problems
>>in mm1. The scheduler is quite good when nothing is reniced. Whats funny
>>though is it looks like you're losing timer interrupts, this is a sign that
>>something is holding interrupts off for too long, and would also cause
>>problems with your mouse.
>>
>
>sys time is usually pretty high if that is the case, and it's hovering
>around 5% here... Prakash, are you sure that dma is enabled on the
>drive? When you see the problem, do a vmstat 1 for 10 seconds so you are
>absolutely sure you are sending the info from when the problem occurs.
>

Although have a look at the interrupts field in vmstat 1255, 725, 736 ...

>
>>I guess its over to Andrew.
>>
>
>Back to you, Kent! :-)
>

:)

2003-11-06 12:59:30

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Prakash K. Cheemplavam wrote:

>>> procs -----------memory---------- ---swap-- -----io---- --system--
>>> ----cpu----
>>> r b swpd free buff cache si so bi bo in cs us
>>> sy id wa
>>> 2 0 0 579472 13976 308572 0 0 425 85 1255 645 5
>>> 3 84 9
>>> 2 0 0 579456 13976 308572 0 0 0 0 725 521 5
>>> 5 91 0
>>> 1 0 0 579448 13976 308572 0 0 0 0 736 523 2
>>> 5 94 0
>>> 0 0 0 579448 13976 308572 0 0 0 25 745 439 2
>>
>>
>>
>> [snip]
>>
>> This looks good, from a system utilization point of view. I'm wondering
>> whether you have the iso image cached? There's no block io going on.
>>
>> It does like more like a CPU scheduler problem at this point.
>
>
>
> Ok, then it is Nick's turn, I guess. :-) Yeah most probably the iso is
> cached, as it was not the first time I burnt the iso when I did the
> vmstat, furthermore I have 1 GB of RAM... The other thing which
> doesn't speack for i/o problems, I guess: Just the first seconds when
> I start erasing the CD-RW the mouse hangs and heavily stutters, then
> it is OK until actual burning of image begins, then the mouse slightly
> stutters. All this was not with test9-mm1.
>

I don't think the scheduler is the problem if you didn't have these problems
in mm1. The scheduler is quite good when nothing is reniced. Whats funny
though is it looks like you're losing timer interrupts, this is a sign that
something is holding interrupts off for too long, and would also cause
problems with your mouse.

I guess its over to Andrew.

2003-11-06 13:07:46

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Fri, Nov 07 2003, Nick Piggin wrote:
>
>
> Jens Axboe wrote:
>
> >On Thu, Nov 06 2003, Nick Piggin wrote:
> >
> >>
> >>Prakash K. Cheemplavam wrote:
> >>
> >>
> >>>>>procs -----------memory---------- ---swap-- -----io---- --system--
> >>>>>----cpu----
> >>>>>r b swpd free buff cache si so bi bo in cs us
> >>>>>sy id wa
> >>>>>2 0 0 579472 13976 308572 0 0 425 85 1255 645 5
> >>>>>3 84 9
> >>>>>2 0 0 579456 13976 308572 0 0 0 0 725 521 5
> >>>>>5 91 0
> >>>>>1 0 0 579448 13976 308572 0 0 0 0 736 523 2
> >>>>>5 94 0
> >>>>>0 0 0 579448 13976 308572 0 0 0 25 745 439 2
> >>>>>
> >>>>
> >>>>
> >>>>[snip]
> >>>>
> >>>>This looks good, from a system utilization point of view. I'm wondering
> >>>>whether you have the iso image cached? There's no block io going on.
> >>>>
> >>>>It does like more like a CPU scheduler problem at this point.
> >>>>
> >>>
> >>>
> >>>Ok, then it is Nick's turn, I guess. :-) Yeah most probably the iso is
> >>>cached, as it was not the first time I burnt the iso when I did the
> >>>vmstat, furthermore I have 1 GB of RAM... The other thing which
> >>>doesn't speack for i/o problems, I guess: Just the first seconds when
> >>>I start erasing the CD-RW the mouse hangs and heavily stutters, then
> >>>it is OK until actual burning of image begins, then the mouse slightly
> >>>stutters. All this was not with test9-mm1.
> >>>
> >>>
> >>I don't think the scheduler is the problem if you didn't have these
> >>problems
> >>in mm1. The scheduler is quite good when nothing is reniced. Whats funny
> >>though is it looks like you're losing timer interrupts, this is a sign
> >>that
> >>something is holding interrupts off for too long, and would also cause
> >>problems with your mouse.
> >>
> >
> >sys time is usually pretty high if that is the case, and it's hovering
> >around 5% here... Prakash, are you sure that dma is enabled on the
> >drive? When you see the problem, do a vmstat 1 for 10 seconds so you are
> >absolutely sure you are sending the info from when the problem occurs.
> >
>
> Although have a look at the interrupts field in vmstat 1255, 725, 736 ...

Yeah that is pretty high for just doing a burn, maybe something else is
happening in the system? It would be more reliable to run Andrews
cyclesoak, sys time is usually not very well reported by linux (if the
interrupt handler runs for a long time).

--
Jens Axboe

2003-11-06 13:02:22

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 06 2003, Nick Piggin wrote:
>
>
> Prakash K. Cheemplavam wrote:
>
> >>>procs -----------memory---------- ---swap-- -----io---- --system--
> >>>----cpu----
> >>>r b swpd free buff cache si so bi bo in cs us
> >>>sy id wa
> >>>2 0 0 579472 13976 308572 0 0 425 85 1255 645 5
> >>>3 84 9
> >>>2 0 0 579456 13976 308572 0 0 0 0 725 521 5
> >>>5 91 0
> >>>1 0 0 579448 13976 308572 0 0 0 0 736 523 2
> >>>5 94 0
> >>>0 0 0 579448 13976 308572 0 0 0 25 745 439 2
> >>
> >>
> >>
> >>[snip]
> >>
> >>This looks good, from a system utilization point of view. I'm wondering
> >>whether you have the iso image cached? There's no block io going on.
> >>
> >>It does like more like a CPU scheduler problem at this point.
> >
> >
> >
> >Ok, then it is Nick's turn, I guess. :-) Yeah most probably the iso is
> >cached, as it was not the first time I burnt the iso when I did the
> >vmstat, furthermore I have 1 GB of RAM... The other thing which
> >doesn't speack for i/o problems, I guess: Just the first seconds when
> >I start erasing the CD-RW the mouse hangs and heavily stutters, then
> >it is OK until actual burning of image begins, then the mouse slightly
> >stutters. All this was not with test9-mm1.
> >
>
> I don't think the scheduler is the problem if you didn't have these problems
> in mm1. The scheduler is quite good when nothing is reniced. Whats funny
> though is it looks like you're losing timer interrupts, this is a sign that
> something is holding interrupts off for too long, and would also cause
> problems with your mouse.

sys time is usually pretty high if that is the case, and it's hovering
around 5% here... Prakash, are you sure that dma is enabled on the
drive? When you see the problem, do a vmstat 1 for 10 seconds so you are
absolutely sure you are sending the info from when the problem occurs.

> I guess its over to Andrew.

Back to you, Kent! :-)

--
Jens Axboe

2003-11-06 13:11:34

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:

>On Fri, Nov 07 2003, Nick Piggin wrote:
>
>>
>>Jens Axboe wrote:
>>
>>
>>>sys time is usually pretty high if that is the case, and it's hovering
>>>around 5% here... Prakash, are you sure that dma is enabled on the
>>>drive? When you see the problem, do a vmstat 1 for 10 seconds so you are
>>>absolutely sure you are sending the info from when the problem occurs.
>>>
>>>
>>Although have a look at the interrupts field in vmstat 1255, 725, 736 ...
>>
>
>Yeah that is pretty high for just doing a burn, maybe something else is
>

;) you are forgetting 2.6 should give 1000 timer interrupts per second!

2003-11-06 13:13:32

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Fri, Nov 07 2003, Nick Piggin wrote:
>
>
> Jens Axboe wrote:
>
> >On Fri, Nov 07 2003, Nick Piggin wrote:
> >
> >>
> >>Jens Axboe wrote:
> >>
> >>
> >>>sys time is usually pretty high if that is the case, and it's hovering
> >>>around 5% here... Prakash, are you sure that dma is enabled on the
> >>>drive? When you see the problem, do a vmstat 1 for 10 seconds so you are
> >>>absolutely sure you are sending the info from when the problem occurs.
> >>>
> >>>
> >>Although have a look at the interrupts field in vmstat 1255, 725, 736 ...
> >>
> >
> >Yeah that is pretty high for just doing a burn, maybe something else is
> >
>
> ;) you are forgetting 2.6 should give 1000 timer interrupts per second!

Heh indeed, maybe because the archs I use are still at 100. Looks
suspiciously like it's loosing timer interrupts, which would indeed
point to PIO.

--
Jens Axboe

2003-11-06 13:30:12

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> On Fri, Nov 07 2003, Nick Piggin wrote:
>
>>
>>Jens Axboe wrote:
>>
>>
>>>On Fri, Nov 07 2003, Nick Piggin wrote:
>>>
>>>
>>>>Jens Axboe wrote:
>>>>
>>>>
>>>>
>>>>>sys time is usually pretty high if that is the case, and it's hovering
>>>>>around 5% here... Prakash, are you sure that dma is enabled on the
>>>>>drive? When you see the problem, do a vmstat 1 for 10 seconds so you are
>>>>>absolutely sure you are sending the info from when the problem occurs.
>>>>>
>>>>>
>>>>
>>>>Although have a look at the interrupts field in vmstat 1255, 725, 736 ...
>>>>
>>>
>>>Yeah that is pretty high for just doing a burn, maybe something else is
>>>
>>
>>;) you are forgetting 2.6 should give 1000 timer interrupts per second!
>
>
> Heh indeed, maybe because the archs I use are still at 100. Looks
> suspiciously like it's loosing timer interrupts, which would indeed
> point to PIO.
>
bash-2.05b# hdparm -I /dev/hdc

/dev/hdc:

ATAPI CD-ROM, with removable media
Model Number: LITE-ON LTR-16102B
Serial Number:
Firmware Revision: OS0K
Standards:
Used: ATAPI for CD-ROMs, SFF-8020i, r2.5
Supported: CD-ROM ATAPI-2
Configuration:
DRQ response: 50us.
Packet size: 12 bytes
Capabilities:
LBA, IORDY(cannot be disabled)
DMA: mdma0 mdma1 *mdma2
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=227ns IORDY flow control=120ns

For me it looks as though multiword dma 2 is being used, isnt it?

Another question: When doing dmesg, I see this:

...
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCS] (IRQs *23)
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
ACPI: PCI Interrupt Link [LSMB] enabled at IRQ 10
ACPI: PCI Interrupt Link [LUBA] enabled at IRQ 11
ACPI: PCI Interrupt Link [LUBB] enabled at IRQ 5
ACPI: PCI Interrupt Link [LUB2] enabled at IRQ 10
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 10
ACPI: PCI Interrupt Link [LAPU] enabled at IRQ 10
...

Is it normal that SCSI subsystem gets init'ed, even though nothing of it
is activated in the kernel?

Prakash

2003-11-06 13:42:49

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

>>>Heh indeed, maybe because the archs I use are still at 100. Looks
>>>suspiciously like it's loosing timer interrupts, which would indeed
>>>point to PIO.
>>>
>>
>>bash-2.05b# hdparm -I /dev/hdc
>
>
> -i please

bash-2.05b# hdparm -i /dev/hdc

/dev/hdc:

Model=LITE-ON LTR-16102B, FwRev=OS0K, SerialNo=
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:227,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 *mdma2
AdvancedPM=no

* signifies the current active mode

The same: dma is active.

>
>
>>Is it normal that SCSI subsystem gets init'ed, even though nothing of it
>>is activated in the kernel?
>
>
> No, you still have it left in your kernel options.

Cannot be or there is a bug in the makefile. First I tried make
oldconfig, then I noticed this thing coming up, so I did make clen and
still it caame, then mrproper and everything in config by hand, and
still coming up. But I booted the "old" kernel up, where I didn't have
thouse mouse stutterings and it alsa shows that scsi subsystem gets
activated. What do I do wrong then? Should I post the .config?

Prakash

2003-11-06 13:33:27

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
> Jens Axboe wrote:
> >On Fri, Nov 07 2003, Nick Piggin wrote:
> >
> >>
> >>Jens Axboe wrote:
> >>
> >>
> >>>On Fri, Nov 07 2003, Nick Piggin wrote:
> >>>
> >>>
> >>>>Jens Axboe wrote:
> >>>>
> >>>>
> >>>>
> >>>>>sys time is usually pretty high if that is the case, and it's hovering
> >>>>>around 5% here... Prakash, are you sure that dma is enabled on the
> >>>>>drive? When you see the problem, do a vmstat 1 for 10 seconds so you
> >>>>>are
> >>>>>absolutely sure you are sending the info from when the problem occurs.
> >>>>>
> >>>>>
> >>>>
> >>>>Although have a look at the interrupts field in vmstat 1255, 725, 736
> >>>>...
> >>>>
> >>>
> >>>Yeah that is pretty high for just doing a burn, maybe something else is
> >>>
> >>
> >>;) you are forgetting 2.6 should give 1000 timer interrupts per second!
> >
> >
> >Heh indeed, maybe because the archs I use are still at 100. Looks
> >suspiciously like it's loosing timer interrupts, which would indeed
> >point to PIO.
> >
> bash-2.05b# hdparm -I /dev/hdc

-i please

> Is it normal that SCSI subsystem gets init'ed, even though nothing of it
> is activated in the kernel?

No, you still have it left in your kernel options.

--
Jens Axboe

2003-11-06 13:58:43

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

> Indeed, so you are ysing multiword mode 2. Can you try and do a dd from
> the drive, while doing a vmstat 1? Also, does that show the jerky
> behaviour?

Nope, then everything seems perfectly alright (dd if=/dev/hdc of=temp).

>>>>Is it normal that SCSI subsystem gets init'ed, even though nothing of it
>>>>is activated in the kernel?
>>>
>>>
>>>No, you still have it left in your kernel options.
>>
>>Cannot be or there is a bug in the makefile. First I tried make
>>oldconfig, then I noticed this thing coming up, so I did make clen and
>>still it caame, then mrproper and everything in config by hand, and
>>still coming up. But I booted the "old" kernel up, where I didn't have
>>thouse mouse stutterings and it alsa shows that scsi subsystem gets
>>activated. What do I do wrong then? Should I post the .config?
>
>
> I can't believe there's such a bug, so yeah put your .config somewhere.

Here we go:

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
# CONFIG_STANDALONE is not set
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
# CONFIG_X86_4G is not set
# CONFIG_X86_SWITCH_PAGETABLES is not set
# CONFIG_X86_4G_VM_LAYOUT is not set
# CONFIG_X86_UACCESS_INDIRECT is not set
# CONFIG_X86_HIGH_ENTRY is not set
# CONFIG_HPET_TIMER is not set
# CONFIG_HPET_EMULATE_RTC is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_SOFTWARE_SUSPEND is not set
# CONFIG_PM_DISK is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_RELAXED_AML is not set

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_FW_LOADER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
# CONFIG_ISAPNP is not set
# CONFIG_PNPBIOS is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_LBD=y

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
CONFIG_BLK_DEV_IDEFLOPPY=y
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_TASKFILE_IO=y

#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDE_TCQ is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
CONFIG_BLK_DEV_SIIMAGE=y
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_REPORT_LUNS is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
CONFIG_I2O=y
CONFIG_I2O_PCI=y
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_SCSI is not set
CONFIG_I2O_PROC=y

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_IPV6 is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_NETFILTER is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
CONFIG_FORCEDETH=y
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# Bluetooth support
#
# CONFIG_BT is not set

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_PS2_SYNAPTICS is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELV is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_ISA is not set
CONFIG_I2C_NFORCE2=y
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VELLEMAN is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set

#
# I2C Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=y
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_IT87 is not set
CONFIG_SENSORS_LM75=y
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_VIA686A is not set
CONFIG_SENSORS_W83781D=y

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=y

#
# Video For Linux
#

#
# Video Adapters
#
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
CONFIG_DVB_CORE=y

#
# Supported Frontend Modules
#
# CONFIG_DVB_STV0299 is not set
# CONFIG_DVB_SP887X is not set
# CONFIG_DVB_ALPS_TDLB7 is not set
# CONFIG_DVB_ALPS_TDMB7 is not set
# CONFIG_DVB_ATMEL_AT76C651 is not set
# CONFIG_DVB_CX24110 is not set
# CONFIG_DVB_GRUNDIG_29504_491 is not set
# CONFIG_DVB_GRUNDIG_29504_401 is not set
CONFIG_DVB_MT312=y
# CONFIG_DVB_VES1820 is not set
# CONFIG_DVB_VES1X93 is not set
# CONFIG_DVB_TDA1004X is not set

#
# Supported SAA7146 based PCI Adapters
#
# CONFIG_DVB_AV7110 is not set
# CONFIG_DVB_BUDGET is not set
# CONFIG_DVB_BUDGET_CI is not set
# CONFIG_DVB_BUDGET_AV is not set

#
# Supported USB Adapters
#
# CONFIG_DVB_TTUSB_BUDGET is not set
# CONFIG_DVB_TTUSB_DEC is not set

#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_SKYSTAR=y
# CONFIG_VIDEO_BTCX is not set

#
# Graphics support
#
CONFIG_FB=y
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# ALSA USB devices
#
# CONFIG_SND_USB_AUDIO is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
# CONFIG_USB_DYNAMIC_MINORS is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_UHCI_HCD=y

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Human Interface Devices (HID)
#
# CONFIG_USB_HID is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_XPAD is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
CONFIG_USB_SCANNER=y
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_PWC is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_STV680 is not set

#
# USB Network adaptors
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_BRLVGER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_LOCKD=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_GSS is not set
CONFIG_SMB_FS=y
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_FRAME_POINTER is not set

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

2003-11-06 14:01:02

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
> #
> # SCSI device support
> #
> CONFIG_SCSI=y

Need I say more?

--
Jens Axboe

2003-11-06 13:54:49

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:

>On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
>
>>>>>Heh indeed, maybe because the archs I use are still at 100. Looks
>>>>>suspiciously like it's loosing timer interrupts, which would indeed
>>>>>point to PIO.
>>>>>
>>>>>
>>>>bash-2.05b# hdparm -I /dev/hdc
>>>>
>>>
>>>-i please
>>>
>>bash-2.05b# hdparm -i /dev/hdc
>>
>>/dev/hdc:
>>
>> Model=LITE-ON LTR-16102B, FwRev=OS0K, SerialNo=
>> Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
>> RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
>> BuffType=unknown, BuffSize=0kB, MaxMultSect=0
>> (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
>> IORDY=yes, tPIO={min:227,w/IORDY:120}, tDMA={min:120,rec:120}
>> PIO modes: pio0 pio1 pio2 pio3 pio4
>> DMA modes: mdma0 mdma1 *mdma2
>> AdvancedPM=no
>>
>> * signifies the current active mode
>>
>>The same: dma is active.
>>
>
>Indeed, so you are ysing multiword mode 2. Can you try and do a dd from
>the drive, while doing a vmstat 1? Also, does that show the jerky
>behaviour?
>

AFAIK, Prakash cannot reproduce this bad behaviour with mm1, only mm2 (is
this right, Prakash?). So its something there (don't forget Andrew merges
the latest bk with his releases too).

2003-11-06 14:00:50

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Nick Piggin wrote:
>
>
> Jens Axboe wrote:
>
>> On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
>>
>>>>>> Heh indeed, maybe because the archs I use are still at 100. Looks
>>>>>> suspiciously like it's loosing timer interrupts, which would indeed
>>>>>> point to PIO.
>>>>>>
>>>>>>
>>>>> bash-2.05b# hdparm -I /dev/hdc
>>>>>
>>>>
>>>> -i please
>>>>
>>> bash-2.05b# hdparm -i /dev/hdc
>>>
>>> /dev/hdc:
>>>
>>> Model=LITE-ON LTR-16102B, FwRev=OS0K, SerialNo=
>>> Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
>>> RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
>>> BuffType=unknown, BuffSize=0kB, MaxMultSect=0
>>> (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
>>> IORDY=yes, tPIO={min:227,w/IORDY:120}, tDMA={min:120,rec:120}
>>> PIO modes: pio0 pio1 pio2 pio3 pio4
>>> DMA modes: mdma0 mdma1 *mdma2
>>> AdvancedPM=no
>>>
>>> * signifies the current active mode
>>>
>>> The same: dma is active.
>>>
>>
>> Indeed, so you are ysing multiword mode 2. Can you try and do a dd from
>> the drive, while doing a vmstat 1? Also, does that show the jerky
>> behaviour?
>>
>
> AFAIK, Prakash cannot reproduce this bad behaviour with mm1, only mm2 (is
> this right, Prakash?). So its something there (don't forget Andrew merges
> the latest bk with his releases too).

AFAIK, yes. Just too be 100% sure, I rather boot up mm1 and will do a
test-run...

Prakash

2003-11-06 13:49:25

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
>
> >>>Heh indeed, maybe because the archs I use are still at 100. Looks
> >>>suspiciously like it's loosing timer interrupts, which would indeed
> >>>point to PIO.
> >>>
> >>
> >>bash-2.05b# hdparm -I /dev/hdc
> >
> >
> >-i please
>
> bash-2.05b# hdparm -i /dev/hdc
>
> /dev/hdc:
>
> Model=LITE-ON LTR-16102B, FwRev=OS0K, SerialNo=
> Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
> RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
> BuffType=unknown, BuffSize=0kB, MaxMultSect=0
> (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
> IORDY=yes, tPIO={min:227,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 *mdma2
> AdvancedPM=no
>
> * signifies the current active mode
>
> The same: dma is active.

Indeed, so you are ysing multiword mode 2. Can you try and do a dd from
the drive, while doing a vmstat 1? Also, does that show the jerky
behaviour?

> >>Is it normal that SCSI subsystem gets init'ed, even though nothing of it
> >>is activated in the kernel?
> >
> >
> >No, you still have it left in your kernel options.
>
> Cannot be or there is a bug in the makefile. First I tried make
> oldconfig, then I noticed this thing coming up, so I did make clen and
> still it caame, then mrproper and everything in config by hand, and
> still coming up. But I booted the "old" kernel up, where I didn't have
> thouse mouse stutterings and it alsa shows that scsi subsystem gets
> activated. What do I do wrong then? Should I post the .config?

I can't believe there's such a bug, so yeah put your .config somewhere.

--
Jens Axboe

2003-11-06 14:02:59

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Fri, Nov 07 2003, Nick Piggin wrote:
>
>
> Jens Axboe wrote:
>
> >On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
> >
> >>>>>Heh indeed, maybe because the archs I use are still at 100. Looks
> >>>>>suspiciously like it's loosing timer interrupts, which would indeed
> >>>>>point to PIO.
> >>>>>
> >>>>>
> >>>>bash-2.05b# hdparm -I /dev/hdc
> >>>>
> >>>
> >>>-i please
> >>>
> >>bash-2.05b# hdparm -i /dev/hdc
> >>
> >>/dev/hdc:
> >>
> >>Model=LITE-ON LTR-16102B, FwRev=OS0K, SerialNo=
> >>Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
> >>RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
> >>BuffType=unknown, BuffSize=0kB, MaxMultSect=0
> >>(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
> >>IORDY=yes, tPIO={min:227,w/IORDY:120}, tDMA={min:120,rec:120}
> >>PIO modes: pio0 pio1 pio2 pio3 pio4
> >>DMA modes: mdma0 mdma1 *mdma2
> >>AdvancedPM=no
> >>
> >>* signifies the current active mode
> >>
> >>The same: dma is active.
> >>
> >
> >Indeed, so you are ysing multiword mode 2. Can you try and do a dd from
> >the drive, while doing a vmstat 1? Also, does that show the jerky
> >behaviour?
> >
>
> AFAIK, Prakash cannot reproduce this bad behaviour with mm1, only mm2 (is
> this right, Prakash?). So its something there (don't forget Andrew merges
> the latest bk with his releases too).

I'm not aware of anything in that area that could explain the change.

--
Jens Axboe

2003-11-06 14:29:32

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
>
>>#
>># SCSI device support
>>#
>>CONFIG_SCSI=y
>
>
> Need I say more?

But then it is a bug: In menuconfig nothing is activated or please tell
me how through the menu it is possible to set this to "no". The beauty
is: I tested mm1 again, and yes, NO problems. I even threw out the
forcedeth driver of mm2 just to have identical config and it doesn't
make a change (still mouse stuttering). Further more mm1's .config had a
CONFIG_SCSI=y as well, but no probs, so somewhere is a bug...

2003-11-06 14:36:13

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Ok, I found the bugger: It *IS* the sheduler. I tried elevator=deadline
and all stuttering went away. Before I was using as. mm1 used default
sheduler (as I think) and ther eno probs. So the (updated?) as sheduler
in mm2 has a problem...

Prakash

2003-11-06 17:42:45

by Matthew Reppert

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 2003-11-06 at 08:31, Prakash K. Cheemplavam wrote:
> Jens Axboe wrote:
> > On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
> >
> >>#
> >># SCSI device support
> >>#
> >>CONFIG_SCSI=y
> >
> >
> > Need I say more?
>
> But then it is a bug: In menuconfig nothing is activated or please tell
> me how through the menu it is possible to set this to "no".

You have CONFIG_USB_STORAGE=y in your config; USB storage does a
"select SCSI", which means that if USB storage is active, it forces
CONFIG_SCSI=y. So, if you turn off USB storage, you can turn off SCSI.
Making USB storage a module won't help; select seems to always select
Y.

Matt

2003-11-06 18:49:36

by Martin Josefsson

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 2003-11-06 at 15:38, Prakash K. Cheemplavam wrote:
> Ok, I found the bugger: It *IS* the sheduler. I tried elevator=deadline
> and all stuttering went away. Before I was using as. mm1 used default
> sheduler (as I think) and ther eno probs. So the (updated?) as sheduler
> in mm2 has a problem...

Can you run the attached script when you repeat the test?
With both elevator=deadline and without.

./diskstat.sh hdc

Your problem sounds a little like the one I'm seeing, only I'm seeing it
with both deadline and as. I can't really see if I'm loosing
timer-interrupts or not since the only way I've found to reproduce it is
to recieve a file via network and write it to disk, and that generates
lots of interrupts...

--
/Martin

Attachments:

diskstat.sh (881.00 B)
signature.asc (189.00 B)
This is a digitally signed message part Download all attachments

2003-11-06 18:46:55

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Matthew Reppert wrote:

> On Thu, 2003-11-06 at 08:31, Prakash K. Cheemplavam wrote:
>
>>Jens Axboe wrote:
>>
>>>On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
>>>
>>>
>>>>#
>>>># SCSI device support
>>>>#
>>>>CONFIG_SCSI=y
>>>
>>>
>>>Need I say more?
>>
>>But then it is a bug: In menuconfig nothing is activated or please tell
>>me how through the menu it is possible to set this to "no".
>
>
> You have CONFIG_USB_STORAGE=y in your config; USB storage does a
> "select SCSI", which means that if USB storage is active, it forces
> CONFIG_SCSI=y. So, if you turn off USB storage, you can turn off SCSI.
> Making USB storage a module won't help; select seems to always select
> Y.
>
> Matt

Oh, ok, thanx for clarification. That explains, why scsi subsystem is
lobed before usbfs. :-) Nevertheless, as said, the as scheduler causes
the problems.

Prakash

2003-11-06 19:05:11

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Martin Josefsson wrote:
> On Thu, 2003-11-06 at 15:38, Prakash K. Cheemplavam wrote:
>
>>Ok, I found the bugger: It *IS* the sheduler. I tried elevator=deadline
>>and all stuttering went away. Before I was using as. mm1 used default
>>sheduler (as I think) and ther eno probs. So the (updated?) as sheduler
>>in mm2 has a problem...
>
>
> Can you run the attached script when you repeat the test?
> With both elevator=deadline and without.
>
> ./diskstat.sh hdc
>
> Your problem sounds a little like the one I'm seeing, only I'm seeing it
> with both deadline and as. I can't really see if I'm loosing
> timer-interrupts or not since the only way I've found to reproduce it is
> to recieve a file via network and write it to disk, and that generates
> lots of interrupts...
>
>
>
> ------------------------------------------------------------------------
>
> #/bin/bash

A ! is missing there... Only 0 are appearing...what is expected? Do I
have do do anything else?

Prakash

2003-11-06 19:25:00

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>, Jens Axboe <[email protected]> wrote:

| k3b is probably still going through ide-scsi which you must not. It
| would be interesting if you could try without ide-scsi and use cdrecord
| manually (maybe someone more knowledgable on k3b can common on whether
| they support 2.6 or not). 2.6 will be a lot faster than 2.4.

I'm not sure what you mean by faster, burning runs at device limited
speed in CPU time in the less than 1% range if you remember to enable
DMA. The last time I looked DMA didn't work in either kernel if write
size was not a multiple of 1k, (or 2k?) has that changed?

I'm not sure what you meant by faster, so don't think I'm disagreeing
with you.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-06 19:19:26

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>,
Prakash K. Cheemplavam <[email protected]> wrote:

| Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM restores
| the full image (md5sum matches), but the CD-RW does not.

There is a problem with ide-scsi in 2.6, and rather than fix it someone
came up with a patch to cdrecord to allow that application to work
properly, and perhaps "better" in some way. Since the problem with
ide-scsi seems to still exist for other applications, you will probably
find you have to work around the problem, by using the -pad option of
cdrecord (thought that was standard now for TAO at least) or reading
using the ide-cd driver.

I don't remember what the issue was for using ZIP drives with ide-scsi,
other than that using the alternate driver didn't do something right.
That might be fixed, I just went back to 2.4 on my machine which needs
that.

The problem using ide tapes was that you needed ide-scsi to make 'mt'
work, there's no patch for that AFAIK, and tape operations work without
kernel errors, but the data read back didn't have the same md5 as the
data written out. My one IDE tape drive is on the same box as the ZIP,
both seem to work fine with ide-scsi under 2.4. I only use those devices
for exchange with a few clients, so spending time on the problem wasn't
and isn't justified.

Hope this helps you define your problem more clearly.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-06 19:35:52

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On 6 Nov 2003, bill davidsen wrote:
>
> There is a problem with ide-scsi in 2.6, and rather than fix it someone
> came up with a patch to cdrecord to allow that application to work
> properly, and perhaps "better" in some way.

Wrong.

The "somebody" strongly felt that ide-scsi was not just ugly but _evil_,
and that the syntax and usage of "cdrecord" was absolutely stupid.

That somebody was me.

ide-scsi has always been broken. You should not use it, and indeed there
was never any good reason for it existing AT ALL. But because of a broken
interface to cdrecord, cdrecord historically only wanted to touch SCSI
devices. Ergo, a silly emulation layer that wasn't really worth it.

The fact that nobody has bothered to fix ide-scsi seems to be a result of
nobody _wanting_ to really fix it.

So don't use it. Or if you do use it, send the fixes over.

Linus

2003-11-06 19:45:53

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On 6 Nov 2003, bill davidsen wrote:
>
> I'm not sure what you mean by faster, burning runs at device limited
> speed in CPU time in the less than 1% range if you remember to enable
> DMA. The last time I looked DMA didn't work in either kernel if write
> size was not a multiple of 1k, (or 2k?) has that changed?

DMA works fine

IF YOU DON'T USE IDE-SCSI

Don't use it. Please. There's no point.

It's much more readable to do

cdrecord dev=/dev/hdc

than it is to do some stupid "scan SCSI devices" + "dev=0,1,0" or similar
totally incomprehensible crap that doesn't even work right.

> I'm not sure what you meant by faster, so don't think I'm disagreeing
> with you.

Faster as in "it uses DMA for everything, so you can actually burn at full
speed without having to worry about it or sucking up CPU".

Linus

2003-11-06 19:47:10

by Maciej Żenczykowski

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

> You have CONFIG_USB_STORAGE=y in your config; USB storage does a
> "select SCSI", which means that if USB storage is active, it forces
> CONFIG_SCSI=y. So, if you turn off USB storage, you can turn off SCSI.

> Making USB storage a module won't help; select seems to always select Y.

Now that I would say is a bug, it should either default to the item
which selected it or somehow ask during configuration...

Cheers,
MaZe.

2003-11-06 19:55:50

by Gene Heskett

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thursday 06 November 2003 14:14, bill davidsen wrote:
>In article <[email protected]>, Jens Axboe
<[email protected]> wrote:
>| k3b is probably still going through ide-scsi which you must not.
>| It would be interesting if you could try without ide-scsi and use
>| cdrecord manually (maybe someone more knowledgable on k3b can
>| common on whether they support 2.6 or not). 2.6 will be a lot
>| faster than 2.4.
>
>I'm not sure what you mean by faster, burning runs at device limited
>speed in CPU time in the less than 1% range if you remember to
> enable DMA. The last time I looked DMA didn't work in either kernel
> if write size was not a multiple of 1k, (or 2k?) has that changed?
>
>I'm not sure what you meant by faster, so don't think I'm
> disagreeing with you.

As in it actually said it was burning at 12x, and could do a 650 meg
iso in a bit over 6 minutes including fixating. Thats about 3 to 4
minutes faster than its ever been.

--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2003-11-06 19:53:51

by John Bradford

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Quote from Linus Torvalds <[email protected]>:

> ide-scsi has always been broken. You should not use it, and indeed there
> was never any good reason for it existing AT ALL. But because of a broken
> interface to cdrecord, cdrecord historically only wanted to touch SCSI
> devices. Ergo, a silly emulation layer that wasn't really worth it.

Hmmm, but ide-scsi is used for a lot more than cd recorders these
days. Alan mentioned 'crazy' SATA devices back in April.

http://marc.theaimsgroup.com/?l=linux-kernel&m=105000779411632&w=2

(Not that I'm suggesting that it is particularly sane to deal with an
SATA connected printer by presenting it as a SCSI device, but I just
can't see how ide-scsi could successfully be removed now :-( )

John.

2003-11-06 20:07:44

by Martin Josefsson

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 2003-11-06 at 20:06, Prakash K. Cheemplavam wrote:

> > #/bin/bash
>
> A ! is missing there... Only 0 are appearing...what is expected? Do I
> have do do anything else?

Hmm how did I miss that... fixed now, thanks.

diskstat.sh hde

My output looks like this:

row reads rmerge rsect rms writes wmerge wsect wms io ms ms2
241 3 2 40 0 123 33 296 62384 0 146 12798
242 0 0 0 0 0 0 0 0 0 0 0
243 0 0 0 0 3 0 24 3 0 3 3
244 3 7 80 26 244 110 3984 23688 144 368 44683
245 1 0 8 20 325 8505 70600 118889 139 1015 143674
246 3 0 24 51 172 924 7656 115233 0 851 69550
247 2 0 16 44 0 0 0 0 0 44 44
248 2 0 16 24 0 0 0 0 0 24 24
249 4 0 32 62 531 301 7800 61074 143 863 83732
250 5 0 40 80 553 125 5568 155622 161 1032 153844
251 8 0 64 222 486 147 4824 164073 131 1099 176655
252 2 7 72 36 526 160 5464 156330 128 1014 145540
253 0 0 0 0 599 74 5472 132976 139 1034 146270
254 1 0 8 13 551 163 5720 141778 140 1018 149876
255 4 0 32 100 642 248 7256 225351 157 1433 207807
256 0 0 0 0 716 254 7896 211376 173 1470 211602
257 2 0 16 37 502 74 4368 129258 143 1015 149133
258 1 0 8 20 537 147 5352 162866 128 1010 150900

This is during a sequential write, only one writer. File received via
network.

Everything's humming along fine at 11-12MB/s until row 249, there it
drops to 2-4MB/s and the machine freezes for 1-2 seconds every 3-10
seconds. Data taken from /proc/diskstats and is in the same order as
those fields (documented in Documentation/iostats.txt).

Don't know if it's related to your problems in any way.

--
/Martin

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2003-11-06 21:08:21

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

bill davidsen wrote:
> In article <[email protected]>,
> Prakash K. Cheemplavam <[email protected]> wrote:
>
> | Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM restores
> | the full image (md5sum matches), but the CD-RW does not.
>
> There is a problem with ide-scsi in 2.6, and rather than fix it someone
> came up with a patch to cdrecord to allow that application to work

I *didn't* use ide-scsi. I used ATAPI and I have to agree with Linus,
that it is sane to use ATAPI, instead of wrapping things up.
Nevertheless, there are some issues left, which need further investigation.

a) The as scheduler in 2.6-test9-mm2 behaves not as nicely as in mm1.
(see other messeages in thread)

b) The writing or reading issue mentioned above. It is a bit hard to
find out, whether cdrecord actually *writes* an incomplete image
(without using -pad), ie. throwing away the last 4096 bytes, which
*only* happens in non-TAO mode. The programme CDRDAO shows the same
behaviour. Strange enough reading this DAO written image out with my
DVD-ROM makes this (missing?) 4096 bytes reappear... Well, maybe I
should patch the image and put some other bytes instead of the 00s at
the end to see, whether it is a write issue, a read issue of the writer
or a read issue of the reader. Anyway, it doesn't sound right to me,
what is happening at the moment...

c) That scsi gets selected when using usbfs seams to be some sort of
wrapper being used...(just guessing without actually knowing the code).
WOuld be nice if a note in the kernel menuconfig or alike would be left
so that one doesn't have to wonder... But IIRC usbfs will be dropped anyway.

Prakash

2003-11-06 21:22:39

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 06 Nov 2003 20:40:37 +0100, you wrote in linux.kernel:

> ide-scsi has always been broken. You should not use it, and indeed there
> was never any good reason for it existing AT ALL.

So, why is it that my ATAPI MO drive works perfectly with ide-scsi and
sd but not with any of the IDE drivers (even if I hack them to accept
an ATAPI OPTICAL device)?

In 2.6, we have a patch allowing at least read-only use via ide-cd,
but writing still requires ide-scsi. I did the read support part, but
writing eludes me... and the read support is also unlikely to work on
MO discs with a sector size other than 2048 or partitioned ones (I only
use my discs as ext2 superfloppies).

--
Ciao,
Pascal

2003-11-06 21:38:22

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Prakash K. Cheemplavam wrote:
> bill davidsen wrote:
>
>> In article <[email protected]>,
>> Prakash K. Cheemplavam <[email protected]> wrote:
>>
>> | Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM
>> restores | the full image (md5sum matches), but the CD-RW does not.
>>
>> There is a problem with ide-scsi in 2.6, and rather than fix it someone
>> came up with a patch to cdrecord to allow that application to work

> b) The writing or reading issue mentioned above. It is a bit hard to
> find out, whether cdrecord actually *writes* an incomplete image
> (without using -pad), ie. throwing away the last 4096 bytes, which
> *only* happens in non-TAO mode. The programme CDRDAO shows the same
> behaviour. Strange enough reading this DAO written image out with my
> DVD-ROM makes this (missing?) 4096 bytes reappear... Well, maybe I
> should patch the image and put some other bytes instead of the 00s at
> the end to see, whether it is a write issue, a read issue of the writer
> or a read issue of the reader. Anyway, it doesn't sound right to me,
> what is happening at the moment...

So tested further: I patched the very last byts of the image and these
are my findings:

In DAO mode, the complete image is actually written, but the writer is
not able to read it out! The last 4096 bytes are not read. I put the
CD-RW into my DVD-ROM, and it reads it out completely.

So: Is cdrecord/cdrdao making something wrong (yes, I know I can use
-pad, but I want an *identical copy*) or has the kernel ATAPI reading
routine a bug? (Or has my drive a bug???? Well, I need to read the disc
out in windows I guess...)

Prakash

2003-11-06 22:47:19

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 6 Nov 2003, Gene Heskett wrote:

> On Thursday 06 November 2003 14:14, bill davidsen wrote:
> >In article <[email protected]>, Jens Axboe
> <[email protected]> wrote:
> >| k3b is probably still going through ide-scsi which you must not.
> >| It would be interesting if you could try without ide-scsi and use
> >| cdrecord manually (maybe someone more knowledgable on k3b can
> >| common on whether they support 2.6 or not). 2.6 will be a lot
> >| faster than 2.4.
> >
> >I'm not sure what you mean by faster, burning runs at device limited
> >speed in CPU time in the less than 1% range if you remember to
> > enable DMA. The last time I looked DMA didn't work in either kernel
> > if write size was not a multiple of 1k, (or 2k?) has that changed?
> >
> >I'm not sure what you meant by faster, so don't think I'm
> > disagreeing with you.
>
> As in it actually said it was burning at 12x, and could do a 650 meg
> iso in a bit over 6 minutes including fixating. Thats about 3 to 4
> minutes faster than its ever been.

Okay, more or less as expected, 650MB and 380sec (just over six minutes)
is 10.17x, allowing for OPC and fixating that's about what you would
expect.

Are you saying that a 12x burn using a 2.4 kernel and ide-scsi doesn't
take the same time? Because I see ~1.7MB/s if I use speed=12 with
ide-scsi, and that's as expected (1x = 44100*4/1024 kB/s). Haven't got a
2.6 system with a burner here, but I do at my other site.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-07 00:51:32

by Gene Heskett

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thursday 06 November 2003 17:36, Bill Davidsen wrote:
>On Thu, 6 Nov 2003, Gene Heskett wrote:
>> On Thursday 06 November 2003 14:14, bill davidsen wrote:
>> >In article <[email protected]>, Jens Axboe
>>
>> <[email protected]> wrote:
>> >| k3b is probably still going through ide-scsi which you must
>> >| not. It would be interesting if you could try without ide-scsi
>> >| and use cdrecord manually (maybe someone more knowledgable on
>> >| k3b can common on whether they support 2.6 or not). 2.6 will be
>> >| a lot faster than 2.4.
>> >
>> >I'm not sure what you mean by faster, burning runs at device
>> > limited speed in CPU time in the less than 1% range if you
>> > remember to enable DMA. The last time I looked DMA didn't work
>> > in either kernel if write size was not a multiple of 1k, (or
>> > 2k?) has that changed?
>> >
>> >I'm not sure what you meant by faster, so don't think I'm
>> > disagreeing with you.
>>
>> As in it actually said it was burning at 12x, and could do a 650
>> meg iso in a bit over 6 minutes including fixating. Thats about 3
>> to 4 minutes faster than its ever been.
>
>Okay, more or less as expected, 650MB and 380sec (just over six
> minutes) is 10.17x, allowing for OPC and fixating that's about what
> you would expect.
>
>Are you saying that a 12x burn using a 2.4 kernel and ide-scsi
> doesn't take the same time? Because I see ~1.7MB/s if I use
> speed=12 with ide-scsi, and that's as expected (1x = 44100*4/1024
> kB/s). Haven't got a 2.6 system with a burner here, but I do at my
> other site.

Mmm, thats pretty close, Bill. Maybe its something I just noted the
last time I tried to burn a disk under ide-scsi, but I caught it
turning the write speed down to 8x from the 12x setting. It may have
been doing that previously without advising me or?? The old times
were usually just short of 10 minutes.

--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2003-11-07 22:19:06

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 06 2003, bill davidsen wrote:
> In article <[email protected]>,
> Prakash K. Cheemplavam <[email protected]> wrote:
>
> | Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM restores
> | the full image (md5sum matches), but the CD-RW does not.
>
> There is a problem with ide-scsi in 2.6, and rather than fix it someone
> came up with a patch to cdrecord to allow that application to work
> properly, and perhaps "better" in some way. Since the problem with

You have this completely backwards. A way to eliminate ide-scsi for cd
burning was invented for 2.6, which is both more efficient wrt space
consumption and cpu usage. Naturally, this is now the preferred way to
burns CD's. It works equally well with whatever burner you have, be it
atapi, scsi, or usb.

ide-scsi being broken is an orthogonal issue. The incentive to fix it
isn't that big, because its area of use has diminished a _lot_.

Just setting the record straight.

--
Jens Axboe

2003-11-07 22:28:26

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
> Prakash K. Cheemplavam wrote:
> >bill davidsen wrote:
> >
> >>In article <[email protected]>,
> >>Prakash K. Cheemplavam <[email protected]> wrote:
> >>
> >>| Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM
> >>restores | the full image (md5sum matches), but the CD-RW does not.
> >>
> >>There is a problem with ide-scsi in 2.6, and rather than fix it someone
> >>came up with a patch to cdrecord to allow that application to work
>
> >b) The writing or reading issue mentioned above. It is a bit hard to
> >find out, whether cdrecord actually *writes* an incomplete image
> >(without using -pad), ie. throwing away the last 4096 bytes, which
> >*only* happens in non-TAO mode. The programme CDRDAO shows the same
> >behaviour. Strange enough reading this DAO written image out with my
> >DVD-ROM makes this (missing?) 4096 bytes reappear... Well, maybe I
> >should patch the image and put some other bytes instead of the 00s at
> >the end to see, whether it is a write issue, a read issue of the writer
> >or a read issue of the reader. Anyway, it doesn't sound right to me,
> >what is happening at the moment...
>
> So tested further: I patched the very last byts of the image and these
> are my findings:
>
> In DAO mode, the complete image is actually written, but the writer is
> not able to read it out! The last 4096 bytes are not read. I put the
> CD-RW into my DVD-ROM, and it reads it out completely.
>
> So: Is cdrecord/cdrdao making something wrong (yes, I know I can use
> -pad, but I want an *identical copy*) or has the kernel ATAPI reading
> routine a bug? (Or has my drive a bug???? Well, I need to read the disc
> out in windows I guess...)

See one of my mails from a few days ago. It's a hardware issue, some
drives need a bit of pad at the end.

--
Jens Axboe

2003-11-07 22:42:26

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 06 2003, Linus Torvalds wrote:
> > I'm not sure what you meant by faster, so don't think I'm disagreeing
> > with you.
>
> Faster as in "it uses DMA for everything, so you can actually burn at full
> speed without having to worry about it or sucking up CPU".

And it doesn't do unnecessary data copies either. Not as important as
the DMA issue, but still not completely uninteresting on slower boxes.

--
Jens Axboe

2003-11-07 22:25:52

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

> Oh ok. Well whenever you get a chance to... Sorry that last patch
> I sent was empty. Here is the correct one for when you get time.

Yeah, runs nicely. (dmesg is quiet, as well.) Seems like it was only a
minor issue in mm2, lloking at the patch...Very well.

Prakash

2003-11-07 23:13:55

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

linux-2.6-npiggin/drivers/block/as-iosched.c | 219 +++++++++------------------
1 files changed, 78 insertions(+), 141 deletions(-)

diff -puN drivers/block/as-iosched.c~as-revert2 drivers/block/as-iosched.c
--- linux-2.6/drivers/block/as-iosched.c~as-revert2 2003-11-07 23:59:20.000000000 +1100
+++ linux-2.6-npiggin/drivers/block/as-iosched.c 2003-11-08 00:00:25.000000000 +1100
@@ -70,7 +70,6 @@
/* Bits in as_io_context.state */
enum as_io_states {
AS_TASK_RUNNING=0, /* Process has not exitted */
- AS_TASK_IOSTARTED, /* Process has started some IO */
AS_TASK_IORUNNING, /* Process has completed some IO */
};

@@ -100,14 +99,6 @@ struct as_data {
sector_t last_sector[2]; /* last REQ_SYNC & REQ_ASYNC sectors */
struct list_head *dispatch; /* driver dispatch queue */
struct list_head *hash; /* request hash */
-
- unsigned long exit_prob; /* probability a task will exit while
- being waited on */
- unsigned long new_ttime_total; /* mean thinktime on new proc */
- unsigned long new_ttime_mean;
- u64 new_seek_total; /* mean seek on new proc */
- sector_t new_seek_mean;
-
unsigned long current_batch_expires;
unsigned long last_check_fifo[2];
int changed_batch; /* 1: waiting for old batch to end */
@@ -195,7 +186,6 @@ static void free_as_io_context(struct as
/* Called when the task exits */
static void exit_as_io_context(struct as_io_context *aic)
{
- WARN_ON(!test_bit(AS_TASK_RUNNING, &aic->state));
clear_bit(AS_TASK_RUNNING, &aic->state);
}

@@ -618,15 +608,8 @@ static void as_antic_timeout(unsigned lo
spin_lock_irqsave(q->queue_lock, flags);
if (ad->antic_status == ANTIC_WAIT_REQ
|| ad->antic_status == ANTIC_WAIT_NEXT) {
- struct as_io_context *aic = ad->io_context->aic;
-
ad->antic_status = ANTIC_FINISHED;
kblockd_schedule_work(&ad->antic_work);
-
- if (aic->ttime_samples == 0) {
- /* process anticipated on has exitted or timed out*/
- ad->exit_prob = (7*ad->exit_prob + 256)/8;
- }
}
spin_unlock_irqrestore(q->queue_lock, flags);
}
@@ -640,7 +623,7 @@ static int as_close_req(struct as_data *
unsigned long delay; /* milliseconds */
sector_t last = ad->last_sector[ad->batch_data_dir];
sector_t next = arq->request->sector;
- sector_t delta; /* acceptable close offset (in sectors) */
+ sector_t delta; /* acceptable close offset (in sectors) */

if (ad->antic_status == ANTIC_OFF || !ad->ioc_finished)
delay = 0;
@@ -657,7 +640,6 @@ static int as_close_req(struct as_data *
return (last - (delta>>1) <= next) && (next <= last + delta);
}

-static void as_update_thinktime(struct as_data *ad, struct as_io_context *aic, unsigned long ttime);
/*
* as_can_break_anticipation returns true if we have been anticipating this
* request.
@@ -675,27 +657,9 @@ static int as_can_break_anticipation(str
{
struct io_context *ioc;
struct as_io_context *aic;
- sector_t s;
-
- ioc = ad->io_context;
- BUG_ON(!ioc);
-
- if (arq && ioc == arq->io_context) {
- /* request from same process */
- return 1;
- }

if (arq && arq->is_sync == REQ_SYNC && as_close_req(ad, arq)) {
/* close request */
- struct as_io_context *aic = ioc->aic;
- if (aic) {
- unsigned long thinktime;
- spin_lock(&aic->lock);
- thinktime = jiffies - aic->last_end_request;
- aic->last_end_request = jiffies;
- as_update_thinktime(ad, aic, thinktime);
- spin_unlock(&aic->lock);
- }
return 1;
}

@@ -707,14 +671,20 @@ static int as_can_break_anticipation(str
return 1;
}

+ ioc = ad->io_context;
+ BUG_ON(!ioc);
+
+ if (arq && ioc == arq->io_context) {
+ /* request from same process */
+ return 1;
+ }
+
aic = ioc->aic;
if (!aic)
return 0;

if (!test_bit(AS_TASK_RUNNING, &aic->state)) {
/* process anticipated on has exitted */
- if (aic->ttime_samples == 0)
- ad->exit_prob = (7*ad->exit_prob + 256)/8;
return 1;
}

@@ -728,36 +698,27 @@ static int as_can_break_anticipation(str
return 1;
}

- if (aic->ttime_samples == 0) {
- if (ad->new_ttime_mean > ad->antic_expire)
- return 1;
- if (ad->exit_prob > 128)
- return 1;
- } else if (aic->ttime_mean > ad->antic_expire) {
- /* the process thinks too much between requests */
+ if (aic->seek_samples == 0 || aic->ttime_samples == 0) {
+ /*
+ * Process has just started IO. Don't anticipate.
+ * TODO! Must fix this up.
+ */
return 1;
}

- if (!arq)
- return 0;
-
- if (ad->last_sector[REQ_SYNC] < arq->request->sector)
- s = arq->request->sector - ad->last_sector[REQ_SYNC];
- else
- s = ad->last_sector[REQ_SYNC] - arq->request->sector;
+ if (aic->ttime_mean > ad->antic_expire) {
+ /* the process thinks too much between requests */
+ return 1;
+ }

- if (aic->seek_samples == 0) {
- /*
- * Process has just started IO. Use past statistics to
- * guage success possibility
- */
- if (ad->new_seek_mean/2 > s) {
- /* this request is better than what we're expecting */
- return 1;
- }
+ if (arq && aic->seek_samples) {
+ sector_t s;
+ if (ad->last_sector[REQ_SYNC] < arq->request->sector)
+ s = arq->request->sector - ad->last_sector[REQ_SYNC];
+ else
+ s = ad->last_sector[REQ_SYNC] - arq->request->sector;

- } else {
- if (aic->seek_mean/2 > s) {
+ if (aic->seek_mean > (s>>1)) {
/* this request is better than what we're expecting */
return 1;
}
@@ -802,51 +763,12 @@ static int as_can_anticipate(struct as_d
return 1;
}

-static void as_update_thinktime(struct as_data *ad, struct as_io_context *aic, unsigned long ttime)
-{
- /* fixed point: 1.0 == 1<<8 */
- if (aic->ttime_samples == 0) {
- ad->new_ttime_total = (7*ad->new_ttime_total + 256*ttime) / 8;
- ad->new_ttime_mean = ad->new_ttime_total / 256;
-
- ad->exit_prob = (7*ad->exit_prob)/8;
- }
- aic->ttime_samples = (7*aic->ttime_samples + 256) / 8;
- aic->ttime_total = (7*aic->ttime_total + 256*ttime) / 8;
- aic->ttime_mean = (aic->ttime_total + 128) / aic->ttime_samples;
-}
-
-static void as_update_seekdist(struct as_data *ad, struct as_io_context *aic, sector_t sdist)
-{
- u64 total;
-
- if (aic->seek_samples == 0) {
- ad->new_seek_total = (7*ad->new_seek_total + 256*(u64)sdist)/8;
- ad->new_seek_mean = ad->new_seek_total / 256;
- }
-
- /*
- * Don't allow the seek distance to get too large from the
- * odd fragment, pagein, etc
- */
- if (aic->seek_samples <= 60) /* second&third seek */
- sdist = min(sdist, (aic->seek_mean * 4) + 2*1024*1024);
- else
- sdist = min(sdist, (aic->seek_mean * 4) + 2*1024*64);
-
- aic->seek_samples = (7*aic->seek_samples + 256) / 8;
- aic->seek_total = (7*aic->seek_total + (u64)256*sdist) / 8;
- total = aic->seek_total + (aic->seek_samples/2);
- do_div(total, aic->seek_samples);
- aic->seek_mean = (sector_t)total;
-}
-
/*
* as_update_iohist keeps a decaying histogram of IO thinktimes, and
* updates @aic->ttime_mean based on that. It is called when a new
* request is queued.
*/
-static void as_update_iohist(struct as_data *ad, struct as_io_context *aic, struct request *rq)
+static void as_update_iohist(struct as_io_context *aic, struct request *rq)
{
struct as_rq *arq = RQ_DATA(rq);
int data_dir = arq->is_sync;
@@ -857,29 +779,60 @@ static void as_update_iohist(struct as_d
return;

if (data_dir == REQ_SYNC) {
- unsigned long in_flight = atomic_read(&aic->nr_queued)
- + atomic_read(&aic->nr_dispatched);
spin_lock(&aic->lock);
- if (test_bit(AS_TASK_IORUNNING, &aic->state) ||
- test_bit(AS_TASK_IOSTARTED, &aic->state)) {
+
+ if (test_bit(AS_TASK_IORUNNING, &aic->state)
+ && !atomic_read(&aic->nr_queued)
+ && !atomic_read(&aic->nr_dispatched)) {
/* Calculate read -> read thinktime */
- if (test_bit(AS_TASK_IORUNNING, &aic->state)
- && in_flight == 0) {
- thinktime = jiffies - aic->last_end_request;
- thinktime = min(thinktime, MAX_THINKTIME-1);
- } else
- thinktime = 0;
- as_update_thinktime(ad, aic, thinktime);
-
- /* Calculate read -> read seek distance */
- if (aic->last_request_pos < rq->sector)
- seek_dist = rq->sector - aic->last_request_pos;
- else
- seek_dist = aic->last_request_pos - rq->sector;
- as_update_seekdist(ad, aic, seek_dist);
- }
+ thinktime = jiffies - aic->last_end_request;
+ thinktime = min(thinktime, MAX_THINKTIME-1);
+ /* fixed point: 1.0 == 1<<8 */
+ aic->ttime_samples += 256;
+ aic->ttime_total += 256*thinktime;
+ if (aic->ttime_samples)
+ /* fixed point factor is cancelled here */
+ aic->ttime_mean = (aic->ttime_total + 128)
+ / aic->ttime_samples;
+ aic->ttime_samples = (aic->ttime_samples>>1)
+ + (aic->ttime_samples>>2);
+ aic->ttime_total = (aic->ttime_total>>1)
+ + (aic->ttime_total>>2);
+ }
+
+ /* Calculate read -> read seek distance */
+ if (!aic->seek_samples)
+ seek_dist = 0;
+ else if (aic->last_request_pos < rq->sector)
+ seek_dist = rq->sector - aic->last_request_pos;
+ else
+ seek_dist = aic->last_request_pos - rq->sector;
+
aic->last_request_pos = rq->sector + rq->nr_sectors;
- set_bit(AS_TASK_IOSTARTED, &aic->state);
+
+ /*
+ * Don't allow the seek distance to get too large from the
+ * odd fragment, pagein, etc
+ */
+ if (aic->seek_samples < 400) /* second&third seek */
+ seek_dist = min(seek_dist, (aic->seek_mean * 4)
+ + 2*1024*1024);
+ else
+ seek_dist = min(seek_dist, (aic->seek_mean * 4)
+ + 2*1024*64);
+
+ aic->seek_samples += 256;
+ aic->seek_total += (u64)256*seek_dist;
+ if (aic->seek_samples) {
+ u64 total = aic->seek_total + (aic->seek_samples>>1);
+ do_div(total, aic->seek_samples);
+ aic->seek_mean = (sector_t)total;
+ }
+ aic->seek_samples = (aic->seek_samples>>1)
+ + (aic->seek_samples>>2);
+ aic->seek_total = (aic->seek_total>>1)
+ + (aic->seek_total>>2);
+
spin_unlock(&aic->lock);
}
}
@@ -1426,8 +1379,8 @@ static void as_add_request(struct as_dat
arq->io_context = as_get_io_context();

if (arq->io_context) {
- as_update_iohist(ad, arq->io_context->aic, arq->request);
atomic_inc(&arq->io_context->aic->nr_queued);
+ as_update_iohist(arq->io_context->aic, arq->request);
}

alias = as_add_arq_rb(ad, arq);
@@ -1933,17 +1886,6 @@ as_var_store(unsigned long *var, const c
return count;
}

-static ssize_t as_est_show(struct as_data *ad, char *page)
-{
- int pos = 0;
-
- pos += sprintf(page+pos, "%lu %% exit probability\n", 100*ad->exit_prob/256);
- pos += sprintf(page+pos, "%lu ms new thinktime\n", ad->new_ttime_mean);
- pos += sprintf(page+pos, "%llu sectors new seek distance\n", (unsigned long long)ad->new_seek_mean);
-
- return pos;
-}
-
#define SHOW_FUNCTION(__FUNC, __VAR) \
static ssize_t __FUNC(struct as_data *ad, char *page) \
{ \
@@ -1975,10 +1917,6 @@ STORE_FUNCTION(as_write_batchexpire_stor
&ad->batch_expire[REQ_ASYNC], 0, INT_MAX);
#undef STORE_FUNCTION

-static struct as_fs_entry as_est_entry = {
- .attr = {.name = "est_time", .mode = S_IRUGO },
- .show = as_est_show,
-};
static struct as_fs_entry as_readexpire_entry = {
.attr = {.name = "read_expire", .mode = S_IRUGO | S_IWUSR },
.show = as_readexpire_show,
@@ -2006,7 +1944,6 @@ static struct as_fs_entry as_write_batch
};

static struct attribute *default_attrs[] = {
- &as_est_entry.attr,
&as_readexpire_entry.attr,
&as_writeexpire_entry.attr,
&as_anticexpire_entry.attr,

_

Attachments:

as-revert2.patch (11.02 kB)

2003-11-07 22:21:56

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Fri, 7 Nov 2003, Rob Landley wrote:

> Note this still doesn't mean you can scroll large X windows for two or three
> seconds at a time without burning a coaster.
>
> I had high hopes with the new scheduler, but no. (Maybe if I niced the heck
> out of cdrecord...)

Wow, is the new scheduler that broken? cdrecord run as a realtime process
and should definitely keep going pretty much in spite of what you do. It's
realtime priority and locked in core IIRC. The only problem I've had is
running out of data burning from NFS mounted data, if I get a load of SPAM
the network gets slow. My fault for not spending the time to copy the data
twice or buy a burnfree device.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-07 23:29:10

by Rob Landley

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Friday 07 November 2003 08:21, Bill Davidsen wrote:
> On Fri, 7 Nov 2003, Rob Landley wrote:
> > Note this still doesn't mean you can scroll large X windows for two or
> > three seconds at a time without burning a coaster.
> >
> > I had high hopes with the new scheduler, but no. (Maybe if I niced the
> > heck out of cdrecord...)
>
> Wow, is the new scheduler that broken? cdrecord run as a realtime process
> and should definitely keep going pretty much in spite of what you do. It's
> realtime priority and locked in core IIRC. The only problem I've had is
> running out of data burning from NFS mounted data, if I get a load of SPAM
> the network gets slow. My fault for not spending the time to copy the data
> twice or buy a burnfree device.

I dunno what I did. This was -test9, using dev=/dev/hdc. It was also
something like a week ago. Halfway through the burn it died because the
buffer had run dry, and I made a second coaster to confirm that it was
scrolling a konqueror window that had done it.

I probably forgot to run it as root. (I don't remember it complaining, but I
was in the middle of about four other things at the time. It did _start_ the
burn, and made it about halfway through.) My laptop was also on battery
power, which may have had something to do with it, although I have a vague
recollection of that working previously, and the battery wasn't anywhere near
dead...

It's not something I've really followed up on. It works if I leave it alone
while it burns, and I haven't had to burn that many cds recently. (I was
burning a knoppix cd for a friend.) I mostly back up through the network...

Rob

2003-11-07 23:45:44

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Nick Piggin wrote:
>
>
> Prakash K. Cheemplavam wrote:
>
>> Nick Piggin wrote:
>>
>>>
>>>
>>> Prakash K. Cheemplavam wrote:
>>>
>>>> Nick Piggin wrote:
>>>>
>>>>>
>>>>>
>>>>> Prakash K. Cheemplavam wrote:
>>>>>
>>>>>> Ok, I found the bugger: It *IS* the sheduler. I tried
>>>>>> elevator=deadline and all stuttering went away. Before I was using
>>>>>> as. mm1 used default sheduler (as I think) and ther eno probs. So
>>>>>> the (updated?) as sheduler in mm2 has a problem...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Weird. I have a few new AS patches in mm2 so its probably them. I
>>>>> can't
>>>>> see why they'd be causing you to lose interrupts though. Could you try
>>>>> this patch please.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So i tried the patch, but it didn't help. I cannot feel any
>>>> difference. Here are the vstats. First for dealine and second fro
>>>> patched as. Please keep in mind that (at the end of the stat) I
>>>> fiddled a bit around with the kernel sources while doing the burn.
>>>> Intersting would be the start of the erasing and start of burning.
>>>> There as gives serious stuttering.
>>>
>>>
>>>
>>>
>>>
>>>
>>> OK thanks. Please try this patch then. Thank you.
>>>
>>
>> Should I first revert the other patch or just use this over the
>> patched file?
>
>
>
> Yeah revert the other I sent you.

Yes, with this patch, it seems to be like in mm1 again, no more
stuttering (or at least I can't notice it anymore, as since 2 daysI have
an LCD), but also the bad stuttering at erase and burn start are gone
again. So do you have an idea what causes the problem?

vmstat:
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 773064 13936 134680 0 0 1504 34 1850 1046 12
16 48 24
0 0 0 772984 13936 134680 0 0 0 27 1170 248 1
2 97 0
0 0 0 772984 13936 134680 0 0 0 0 1440 690 0
0 100 0
0 0 0 772856 13936 134680 0 0 0 0 1269 1063 8
2 90 0
0 0 0 772872 13936 134680 0 0 0 0 1391 602 2
0 98 0
0 0 0 772704 13936 134684 0 0 4 24 1130 328 2
0 97 1
0 0 0 772608 13936 134688 0 0 4 0 1207 449 1
2 96 1
0 0 0 772608 13936 134688 0 0 0 0 1333 539 2
0 98 0
2 0 0 762304 13944 139472 0 0 4792 0 2392 2849 26
8 23 43
0 1 0 737984 13944 163712 0 0 24240 0 7145 7058 37
26 0 36
0 1 0 712640 13944 189056 0 0 25344 17 7416 7348 35
25 0 41
0 0 0 693824 13952 207780 0 0 18732 0 5892 5574 28
17 25 30
0 0 0 693864 13952 207780 0 0 0 0 1223 337 0
0 100 0
0 0 0 693864 13952 207780 0 0 0 0 1229 296 1
1 98 0
0 0 0 693864 13952 207780 0 0 0 0 1370 427 0
0 100 0
0 0 0 693848 13952 207780 0 0 0 67 1285 607 1
2 97 0
0 0 0 693880 13952 207780 0 0 0 13 1258 425 1
0 99 0
0 0 0 693520 13972 207844 0 0 84 0 1349 1620 10
4 83 3
0 0 0 689232 13972 211944 0 0 0 0 1485 1122 5
2 93 0
0 0 0 689232 13972 211944 0 0 0 0 1452 551 1
1 98 0
0 0 0 689232 13972 211944 0 0 0 18 1461 586 1
0 99 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 689232 13972 211944 0 0 0 0 1464 609 1
2 97 0
0 0 0 689232 13972 211944 0 0 0 0 1384 486 1
1 98 0
0 0 0 689232 13972 211944 0 0 0 0 1486 647 2
0 98 0
0 0 0 689280 13972 211944 0 0 0 0 1450 594 1
1 98 0
0 0 0 689264 13972 211944 0 0 0 4 1403 539 1
1 98 0
0 0 0 689264 13972 211944 0 0 0 0 1459 631 1
2 97 0
0 0 0 689264 13972 211944 0 0 0 0 1456 607 1
1 98 0
0 0 0 689280 13972 211944 0 0 0 0 1458 632 1
1 98 0
0 0 0 689280 13972 211944 0 0 0 0 1460 640 1
1 98 0
0 0 0 689280 13972 211944 0 0 0 19 1467 618 2
1 97 0
0 0 0 689280 13972 211944 0 0 0 0 1448 587 1
1 98 0
0 0 0 689288 13972 211944 0 0 0 0 1461 593 1
0 99 0
0 0 0 689288 13972 211944 0 0 0 0 1478 595 1
2 97 0
0 0 0 689288 13972 211944 0 0 0 0 1464 605 2
1 97 0
0 0 0 689280 13972 211944 0 0 0 4 1454 615 1
1 98 0
0 0 0 689280 13972 211944 0 0 0 0 1462 597 1
1 98 0
0 0 0 689280 13972 211944 0 0 0 0 1446 573 1
1 98 0
0 0 0 689280 13972 211944 0 0 0 0 1426 544 1
1 98 0
0 0 0 689280 13972 211944 0 0 0 0 1359 465 1
0 99 0
0 0 0 689280 13972 211944 0 0 0 3 1432 549 0
1 99 0
0 0 0 689280 13972 211944 0 0 0 0 1464 550 1
1 98 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 689280 13972 211944 0 0 0 0 1462 580 1
1 98 0
1 0 0 693376 13972 207844 0 0 0 0 1475 637 1
1 98 0
0 0 0 693392 13972 207844 0 0 0 0 1458 577 1
1 98 0
0 0 0 693384 13972 207844 0 0 0 0 1475 682 2
0 98 0
0 0 0 693384 13972 207848 0 0 0 0 1479 586 1
2 97 0
0 0 0 693384 13972 207848 0 0 0 0 1447 540 0
0 100 0
0 0 0 693448 13972 207848 0 0 0 0 1450 738 3
2 95 0
0 0 0 693448 13972 207848 0 0 0 0 1460 673 1
0 99 0
0 0 0 693448 13972 207848 0 0 0 28 1454 681 0
2 98 0
0 0 0 693448 13972 207848 0 0 0 0 1459 655 1
0 99 0
0 0 0 693456 13972 207848 0 0 0 0 1454 668 1
2 97 0
0 0 0 693456 13972 207848 0 0 0 0 1451 636 1
1 98 0
0 0 0 693456 13972 207848 0 0 0 0 1450 595 0
1 99 0
0 0 0 693448 13972 207848 0 0 0 0 1460 636 1
1 98 0
0 0 0 686608 13996 208004 0 0 176 0 1550 1461 17
5 71 7
0 0 0 686608 13996 208004 0 0 0 0 1447 809 1
2 97 0
0 0 0 686608 13996 208004 0 0 0 0 1455 786 1
0 99 0
0 0 0 686608 13996 208004 0 0 0 0 1458 763 1
0 99 0
0 0 0 686624 13996 208004 0 0 0 24 1463 776 1
2 97 0
0 0 0 686624 13996 208004 0 0 0 16 1454 813 1
2 97 0
0 0 0 686624 13996 208004 0 0 0 0 1448 836 1
0 99 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 686624 13996 208004 0 0 0 0 1448 796 0
1 99 0
0 0 0 686656 13996 208004 0 0 0 0 1449 793 1
1 98 0
0 0 0 686648 13996 208004 0 0 0 0 1466 770 1
1 98 0
0 0 0 686648 13996 208004 0 0 0 0 1450 744 1
1 98 0
0 0 0 686648 13996 208004 0 0 0 0 1465 781 1
1 98 0
0 0 0 686648 13996 208004 0 0 0 0 1467 786 1
1 98 0
0 0 0 686584 13996 208004 0 0 0 0 1496 1263 4
1 95 0
0 0 0 686584 13996 208004 0 0 0 16 1470 802 1
3 96 0
0 0 0 686576 13996 208004 0 0 0 33 1476 864 1
1 98 0
0 0 0 686576 13996 208004 0 0 0 0 1452 797 1
1 98 0
0 0 0 686576 13996 208004 0 0 0 0 1460 805 0
1 99 0
0 0 0 686576 13996 208004 0 0 0 0 1446 833 1
1 98 0
0 0 0 686384 13996 208004 0 0 0 6 1347 1741 9
4 87 0
0 0 0 686384 13996 208004 0 0 0 0 1450 771 3
0 97 0
0 0 0 686384 13996 208004 0 0 0 0 1447 775 2
2 96 0
0 0 0 686368 13996 208004 0 0 0 0 1440 1330 23
3 74 0
0 0 0 686368 13996 208024 0 0 20 0 1493 1236 18
3 79 0
1 0 0 686368 13996 208024 0 0 0 0 1400 1194 7
1 92 0
0 0 0 686368 13996 208024 0 0 0 0 1489 1108 2
3 95 0
0 0 0 686304 13996 208024 0 0 0 0 1419 1753 30
3 67 0
0 0 0 686304 13996 208024 0 0 0 0 1408 774 5
2 93 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 686336 13996 208024 0 0 0 0 1485 728 3
2 95 0
3 0 0 685736 13996 208024 0 0 0 0 1433 1137 12
2 86 0
0 0 0 686312 13996 208024 0 0 0 0 1413 2277 29
7 64 0
0 0 0 686312 13996 208024 0 0 0 17 1304 1081 5
1 94 0
0 0 0 686312 13996 208024 0 0 0 0 1404 1166 7
4 89 0
0 0 0 686376 13996 208024 0 0 0 0 1273 994 4
0 96 0
1 1 0 683584 14004 208636 0 0 620 24 1272 1758 58
5 28 9
0 0 0 681296 14012 209616 0 0 984 11 1638 1523 24
5 56 15
0 0 0 681296 14012 209616 0 0 0 0 1324 1117 15
1 84 0
0 0 0 681296 14012 209616 0 0 0 0 1158 885 5
1 94 0
0 0 0 681296 14012 209620 0 0 0 0 1257 823 2
2 96 0
0 0 0 681296 14012 209652 0 0 27 1 1453 1027 10
1 87 2
0 0 0 681336 14012 209652 0 0 0 0 1114 903 5
2 93 0
0 0 0 681336 14012 209652 0 0 0 0 1124 1039 10
1 89 0
2 0 0 681336 14012 209652 0 0 0 0 1109 819 2
1 97 0
0 0 0 681336 14012 209652 0 0 0 0 1108 826 3
1 96 0
0 0 0 681352 14012 209652 0 0 0 0 1115 999 9
2 89 0
0 0 0 681352 14012 209652 0 0 0 0 1120 927 5
1 94 0
0 0 0 681352 14012 209652 0 0 0 0 1118 1040 11
1 88 0
1 0 0 681352 14012 209652 0 0 0 0 1115 945 9
1 90 0
0 0 0 681360 14012 209652 0 0 0 28 1135 1167 13
1 86 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 681352 14012 209652 0 0 0 17 1203 1032 5
3 92 0
0 0 0 681352 14012 209652 0 0 0 0 1132 824 4
0 96 0
0 0 0 681352 14012 209652 0 0 0 0 1112 847 2
1 97 0
0 0 0 681352 14012 209652 0 0 0 0 1116 901 5
2 93 0
0 0 0 681288 14012 209652 0 0 0 2 1142 865 6
2 92 0
0 0 0 680840 14012 209744 0 0 92 0 1376 1255 16
1 82 1
0 0 0 680840 14012 209744 0 0 0 0 1308 1065 10
2 88 0
0 0 0 678840 14016 210288 0 0 262 0 1264 1935 38
5 53 4
0 0 0 678840 14016 210288 0 0 0 0 1440 1208 6
2 92 0
0 0 0 678840 14016 210288 0 0 0 0 1348 1656 19
3 78 0
0 0 0 678840 14016 210288 0 0 0 0 1156 903 5
1 94 0
0 0 0 678856 14016 210292 0 0 0 0 1121 860 10
2 88 0
0 0 0 678856 14016 210292 0 0 0 0 1136 934 2
1 97 0
0 0 0 678856 14016 210292 0 0 0 0 1112 814 2
0 98 0
0 0 0 678856 14016 210292 0 0 0 0 1124 929 8
1 91 0
0 0 0 678872 14016 210292 0 0 0 8 1127 925 7
2 91 0
0 0 0 678872 14016 210292 0 0 0 0 1121 903 8
1 91 0
0 0 0 678872 14016 210292 0 0 0 0 1119 872 5
1 94 0
0 0 0 678872 14016 210292 0 0 0 0 1130 902 7
2 91 0
0 0 0 678880 14016 210292 0 0 0 216 1157 881 7
0 93 0
0 0 0 678872 14016 210292 0 0 0 0 1121 901 8
1 91 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 678872 14016 210292 0 0 0 0 1117 860 7
1 92 0
0 0 0 678872 14016 210292 0 0 0 0 1120 902 8
2 90 0
0 0 0 678872 14016 210292 0 0 0 0 1123 947 8
1 91 0
0 0 0 678872 14016 210292 0 0 0 0 1120 921 8
1 91 0
0 0 0 678872 14016 210292 0 0 0 0 1143 770 7
2 91 0
0 0 0 678872 14016 210292 0 0 0 0 1514 1090 7
3 90 0
0 0 0 678888 14016 210292 0 0 0 0 1473 761 3
2 95 0
0 0 0 678888 14016 210292 0 0 0 0 1467 587 5
2 93 0
0 0 0 678696 14016 210292 0 0 0 0 1455 230 5
0 95 0
0 0 0 678496 14016 210292 0 0 0 0 1458 265 6
1 93 0
0 0 0 678368 14016 210292 0 0 0 0 1456 278 6
2 92 0
0 0 0 678368 14016 210292 0 0 0 0 1450 225 1
1 98 0
0 0 0 678240 14016 210292 0 0 0 23 3710 468 4
2 94 0
0 0 0 678112 14016 210292 0 0 0 17 3805 268 5
2 93 0
0 0 0 677920 14016 210292 0 0 0 0 2048 272 6
2 92 0
0 0 0 677792 14016 210292 0 0 0 0 1461 327 6
1 93 0
0 0 0 677664 14016 210296 0 0 0 0 1458 288 11
1 88 0
0 0 0 677664 14016 210296 0 0 0 0 3543 172 1
2 97 0
0 0 0 677672 14016 210296 0 0 0 8 1858 224 3
1 96 0
0 0 0 677664 14016 210296 0 0 0 0 1456 248 4
1 95 0
0 0 0 682400 14016 210296 0 0 0 0 1470 378 6
1 93 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 682400 14016 210296 0 0 0 0 1456 255 6
0 94 0
0 0 0 682400 14016 210296 0 0 0 0 1457 247 5
2 93 0
0 0 0 682712 14016 210300 0 0 4 43 1493 493 5
0 94 1
3 0 0 682712 14016 210300 0 0 0 0 1458 421 29
6 65 0
2 0 0 682712 14016 210300 0 0 0 8 1451 2945 89
11 0 0
2 0 0 682712 14016 210300 0 0 0 0 1449 15514 83
17 0 0
0 0 0 682712 14016 210300 0 0 0 0 1459 9377 53
11 36 0
0 0 0 682648 14016 210300 0 0 0 0 1456 212 3
1 96 0
0 1 0 682520 14080 210300 0 0 64 0 1476 288 7
1 82 10
0 1 0 682400 14208 210300 0 0 128 0 1455 192 4
1 0 95
1 1 0 682016 14592 210300 0 0 384 0 1457 226 3
1 0 96
0 1 0 679776 16768 210300 0 0 2176 0 1467 993 9
2 0 89
0 1 0 677472 19072 210300 0 0 2304 0 1464 942 7
2 0 91
0 1 0 675040 21504 210300 0 0 2432 0 1468 935 7
2 0 91
0 1 0 672608 23936 210300 0 0 2432 0 1468 1053 10
2 0 88
0 1 0 670112 26368 210300 0 0 2432 0 1470 947 9
2 0 89
0 1 0 667616 28800 210300 0 0 2432 0 1473 979 10
3 0 87
0 1 0 665072 31104 210300 0 0 2304 21 1474 898 8
3 0 89
0 1 0 662568 33536 210300 0 0 2432 0 1481 1085 14
3 0 83
0 1 0 660072 35968 210300 0 0 2432 0 1477 1072 14
2 0 84
0 1 0 657576 38400 210300 0 0 2432 0 1497 1099 14
3 0 83
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 1 0 655080 40832 210300 0 0 2432 0 1475 1015 12
3 0 85
0 1 0 652584 43264 210300 0 0 2432 2 1477 1000 14
1 0 85
0 1 0 650152 45568 210300 0 0 2304 0 1472 918 11
3 0 86
0 1 0 647656 48000 210300 0 0 2432 0 1481 1070 14
2 0 84
0 1 0 645160 50432 210300 0 0 2432 0 1473 1017 14
2 0 84
0 1 0 642664 52864 210300 0 0 2432 0 1479 1086 18
2 0 80
0 1 0 640168 55296 210300 0 0 2432 16 1500 1010 15
3 0 82
0 1 0 637672 57728 210300 0 0 2432 0 1479 1152 16
2 0 82
0 1 0 635304 60032 210300 0 0 2304 0 1469 1044 11
3 0 86
0 1 0 632872 62464 210300 0 0 2432 0 1479 1130 13
3 0 84
1 1 0 630248 64896 210300 0 0 2432 0 1476 1005 12
2 0 86
0 1 0 627744 67328 210300 0 0 2432 12 1481 1028 12
2 0 86
1 1 0 625248 69760 210300 0 0 2432 0 1480 1014 13
3 0 84
0 1 0 622880 72064 210300 0 0 2304 1 1481 1085 14
2 0 84
0 1 0 620384 74496 210300 0 0 2432 0 1475 995 13
2 0 85
0 1 0 617888 76928 210300 0 0 2432 0 1472 1017 13
3 0 84
0 1 0 615400 79360 210300 0 0 2432 3 1476 1074 10
3 0 87
1 1 0 612896 81792 210300 0 0 2432 0 1477 1005 13
2 0 85
0 1 0 610464 84096 210300 0 0 2304 0 1473 967 11
2 0 87
0 1 0 607968 86528 210300 0 0 2432 0 1481 1120 15
3 0 82
0 0 0 682448 14024 210348 0 0 582 0 1481 503 5
4 67 24
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 682320 14024 210356 0 0 4 0 1460 223 4
1 95 0
0 0 0 682448 14024 210356 0 0 0 0 1459 260 5
0 95 0
0 0 0 682448 14024 210356 0 0 0 0 1449 213 0
1 99 0
0 0 0 682480 14024 210356 0 0 0 0 1458 356 7
1 92 0
0 0 0 682480 14024 210356 0 0 0 0 1455 229 3
1 96 0
0 0 0 682480 14024 210356 0 0 0 0 1310 341 4
0 96 0
0 0 0 682472 14024 210356 0 0 0 8 1097 287 5
2 93 0
0 0 0 682472 14024 210356 0 0 0 0 1084 250 3
0 97 0
0 0 0 682472 14024 210356 0 0 0 0 1087 240 4
0 96 0
0 0 0 682472 14024 210356 0 0 0 0 1082 183 2
0 98 0
0 0 0 682472 14024 210356 0 0 0 0 1322 605 4
1 95 0
0 0 0 682472 14024 210356 0 0 0 0 1250 590 0
1 99 0
0 0 0 682456 14024 210356 0 0 0 0 1266 1138 8
1 91 0

Prakash

2003-11-07 22:18:18

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Fri, 7 Nov 2003, Bill Davidsen wrote:
>
> I mentioned ide tapes and ZIP drives, Linus didn't mention how one gets
> around those.

The thing is, the non-ide-scsi interfaces really _should_ work. The fact
is, SG_IO ("send a SCSI command") just _works_.

However, right now only the CD-ROM driver exposes those commands. Why?
Because nobody has apparently cared enough about those theoretical IDE
tapes and ZIP drives.

In other words, they seem to "exist" in the same sense that soubdblaster
CD-ROM users "exist". True in theory, but apparently only really useful
for theoretical arguments.

Getting SCSI command support is not complicated: you add

ret = scsi_cmd_ioctl(dev, cmd, arg);

to your ioctl routine. Of course, since so far nobody seems to have cared
about anything but CD writing, it's not really tested for anything else.

Linus

2003-11-07 22:11:56

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Nick Piggin wrote:
>
>
> Prakash K. Cheemplavam wrote:
>
>> Ok, I found the bugger: It *IS* the sheduler. I tried
>> elevator=deadline and all stuttering went away. Before I was using as.
>> mm1 used default sheduler (as I think) and ther eno probs. So the
>> (updated?) as sheduler in mm2 has a problem...
>
>
>
> Weird. I have a few new AS patches in mm2 so its probably them. I can't
> see why they'd be causing you to lose interrupts though. Could you try
> this patch please.

So i tried the patch, but it didn't help. I cannot feel any difference.
Here are the vstats. First for dealine and second fro patched as. Please
keep in mind that (at the end of the stat) I fiddled a bit around with
the kernel sources while doing the burn. Intersting would be the start
of the erasing and start of burning. There as gives serious stuttering.

deadline:
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 455400 52760 309808 0 0 464 430 1824 1107 13
6 72 8
0 0 0 455400 52760 309808 0 0 0 31 1264 617 2
0 98 0
1 0 0 455384 52760 309808 0 0 0 0 1441 1267 4
2 94 0
0 0 0 455376 52760 309808 0 0 0 0 1489 1957 4
3 93 0
0 0 0 455616 52800 309912 0 0 144 0 1390 1519 13
5 69 13
1 0 0 447016 52800 312712 0 0 2800 0 2040 1476 34
7 35 24
0 1 0 442072 52808 315812 0 0 3108 25 2101 5618 26
23 11 41
0 0 0 440024 52864 316076 0 0 320 8 1259 2515 26
5 48 20
1 0 0 439832 52864 316076 0 0 0 13 1328 950 4
3 93 0
0 0 0 439704 52880 316096 0 0 36 0 1438 1361 7
2 89 2
0 0 0 439704 52880 316096 0 0 0 0 1424 839 2
2 96 0
0 0 0 439656 52880 316100 0 0 4 8 1312 1008 6
1 92 1
0 0 0 439592 52880 316104 0 0 4 8 1302 803 3
2 95 0
0 0 0 439592 52880 316104 0 0 0 0 1315 929 3
2 95 0
0 0 0 439592 52880 316104 0 0 0 0 1268 679 2
1 97 0
0 1 0 430136 52888 320524 0 0 4432 0 2400 2780 14
10 38 38
0 1 0 409912 52888 340132 0 0 19604 19 6318 6255 43
24 0 32
0 1 0 384952 52888 365092 0 0 24960 0 7557 7140 37
27 0 37
0 0 0 360760 52896 389192 0 0 24108 0 7198 6982 38
22 3 37
0 0 0 360792 52896 389192 0 0 0 0 1166 540 1
1 98 0
0 0 0 360520 52908 389220 0 0 40 0 1231 1858 12
3 83 2
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 356168 52908 393360 0 0 40 8 1524 1444 6
3 91 0
0 0 0 356168 52908 393360 0 0 0 0 1201 595 2
2 96 0
0 0 0 356168 52908 393360 0 0 0 13 1196 601 1
1 98 0
0 0 0 356168 52908 393360 0 0 0 0 1165 541 1
0 99 0
0 0 0 356168 52908 393360 0 0 0 0 1224 604 2
1 97 0
0 0 0 356168 52908 393360 0 0 0 20 1173 531 2
1 97 0
0 0 0 356208 52908 393360 0 0 0 0 1171 484 2
0 98 0
0 0 0 356200 52908 393360 0 0 0 24 1176 524 2
2 96 0
0 0 0 356200 52908 393360 0 0 0 0 1164 486 2
1 97 0
0 0 0 356200 52908 393360 0 0 0 0 1165 474 2
0 98 0
0 0 0 356224 52908 393360 0 0 0 4 1293 654 2
2 96 0
0 0 0 356224 52908 393360 0 0 0 0 1367 923 4
0 96 0
0 0 0 356224 52908 393360 0 0 0 0 1397 1006 1
3 96 0
0 0 0 356224 52908 393360 0 0 0 0 1293 1482 9
2 89 0
0 0 0 356224 52908 393360 0 0 0 0 1227 596 1
0 99 0
1 0 0 356224 52908 393360 0 0 0 18 1171 535 2
2 96 0
0 0 0 356224 52908 393360 0 0 0 0 1263 635 1
0 99 0
0 0 0 356224 52908 393360 0 0 0 0 1409 945 2
4 94 0
1 0 0 356304 52908 393360 0 0 0 0 1366 1415 22
3 75 0
0 0 0 356288 52908 393360 0 0 0 0 1496 2760 47
6 47 0
0 0 0 356288 52908 393360 0 0 0 12 1371 1356 21
4 75 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 356288 52908 393360 0 0 0 0 1303 1087 12
1 87 0
0 0 0 356288 52908 393360 0 0 0 0 1458 1786 6
3 91 0
0 0 0 356288 52908 393360 0 0 0 0 1366 768 1
2 97 0
0 0 0 356224 52908 393360 0 0 0 0 1485 2345 22
4 74 0
0 0 0 356224 52908 393364 0 0 0 1 1401 1638 15
4 81 0
0 0 0 360272 52908 389264 0 0 0 9 1436 1673 5
3 92 0
0 0 0 360264 52908 389264 0 0 0 0 1428 2057 14
2 84 0
0 0 0 360264 52908 389264 0 0 0 0 1308 960 5
3 92 0
0 0 0 360264 52908 389264 0 0 0 0 1207 618 1
0 99 0
0 0 0 360264 52908 389264 0 0 0 0 1477 1346 6
3 91 0
0 0 0 360264 52908 389264 0 0 0 0 1368 754 2
1 97 0
0 0 0 360256 52908 389264 0 0 0 0 1366 974 3
3 94 0
0 0 0 360256 52908 389264 0 0 0 0 1263 694 1
1 98 0
0 0 0 359872 52936 389364 0 0 128 0 1360 1024 6
3 88 3
0 0 0 359872 52936 389364 0 0 0 3 1413 925 2
2 96 0
0 0 0 359872 52936 389364 0 0 0 0 1388 1628 20
3 77 0
0 0 0 359872 52936 389364 0 0 0 0 1360 1008 8
3 89 0
0 0 0 355712 52936 393468 0 0 4 0 1634 1414 8
5 87 0
0 0 0 355520 52936 393468 0 0 0 0 1351 1156 34
3 63 0
0 0 0 355520 52936 393468 0 0 0 0 1413 1030 7
2 91 0
0 0 0 355520 52936 393468 0 0 0 0 1234 788 18
2 80 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 355552 52936 393468 0 0 0 0 1457 1020 6
2 92 0
0 0 0 355552 52936 393468 0 0 0 0 1264 795 3
2 95 0
0 0 0 355552 52936 393468 0 0 0 0 1187 701 2
1 97 0
0 0 0 355552 52936 393468 0 0 0 16 1204 867 7
1 92 0
0 0 0 355592 52936 393468 0 0 0 0 1169 685 1
1 98 0
0 0 0 355584 52936 393468 0 0 0 8 1198 758 6
3 90 1
0 0 0 355584 52936 393468 0 0 0 9 1496 1115 8
2 90 0
0 0 0 355584 52936 393496 0 0 25 0 1240 905 19
2 78 1
0 0 0 355584 52936 393496 0 0 0 18 1247 1020 13
2 85 0
2 0 0 355584 52936 393496 0 0 0 0 1327 877 7
2 91 0
0 0 0 355584 52936 393496 0 0 0 2 1407 1285 31
3 66 0
0 0 0 355392 52936 393500 0 0 0 3 1396 1312 28
4 68 0
0 0 0 355392 52936 393500 0 0 0 0 1225 725 7
0 93 0
0 0 0 355392 52936 393500 0 0 0 0 1321 905 4
3 93 0
0 0 0 355392 52936 393500 0 0 0 0 1387 911 4
2 94 0
0 0 0 355384 52936 393500 0 0 0 0 1235 806 9
1 90 0
0 0 0 355400 52936 393500 0 0 0 0 1226 921 15
3 82 0
0 0 0 355400 52936 393500 0 0 0 0 1244 750 2
1 97 0
0 0 0 355400 52936 393500 0 0 0 0 1167 664 2
1 97 0
0 0 0 355400 52936 393500 0 0 0 0 1168 624 1
1 98 0
0 0 0 355256 52936 393580 0 0 44 0 1280 1762 36
5 55 4
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 355256 52936 393580 0 0 0 0 1474 1016 4
2 94 0
0 0 0 355256 52936 393580 0 0 0 0 1388 989 6
1 93 0
0 0 0 355248 52936 393584 0 0 0 14 1289 1482 32
5 63 0
0 0 0 355248 52936 393584 0 0 0 0 1457 948 5
1 94 0
0 0 0 355248 52936 393584 0 0 0 2 1319 1090 8
3 89 0
0 0 0 355184 52936 393584 0 0 0 0 1320 2149 18
3 79 0
0 0 0 355184 52936 393584 0 0 0 0 1333 958 2
2 96 0
0 0 0 355264 52936 393584 0 0 0 1 1199 941 3
1 96 0
0 0 0 355264 52936 393584 0 0 0 0 1200 926 2
2 96 0
0 0 0 355264 52936 393584 0 0 0 0 1194 871 3
2 95 0
0 0 0 355264 52936 393588 0 0 0 0 1203 892 2
1 97 0
0 0 0 355288 52936 393588 0 0 0 0 1197 963 2
2 96 0
0 0 0 355288 52936 393588 0 0 0 0 1199 948 3
1 96 0
0 0 0 355288 52936 393588 0 0 0 0 1198 912 2
1 97 0
0 0 0 355288 52936 393588 0 0 0 0 1206 1039 2
3 95 0
0 0 0 352888 53288 394936 0 0 1700 0 1617 1220 9
5 58 28
0 1 0 350968 53924 395484 0 0 1184 0 1485 1165 4
3 54 39
0 0 0 349624 54340 395868 0 0 800 18 1397 1041 4
3 53 40
0 0 0 347256 54744 396376 0 0 912 21 1427 1180 8
3 44 44
0 0 0 347248 54744 396376 0 0 0 0 1191 757 3
1 96 0
0 0 0 347248 54744 396376 0 0 0 0 1193 819 3
1 96 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 347056 54744 396376 0 0 0 0 1190 793 6
2 92 0
0 0 0 347056 54744 396376 0 0 0 5 1194 866 3
1 96 0
0 0 0 347192 54744 396376 0 0 0 0 1196 742 3
2 95 0
0 0 0 350064 54744 396376 0 0 0 0 1196 923 3
2 95 0
0 0 0 350064 54744 396376 0 0 0 0 1190 720 2
1 97 0
0 0 0 350064 54744 396376 0 0 0 0 1193 820 3
0 97 0
0 0 0 350064 54744 396376 0 0 0 0 1195 778 3
2 95 0
0 0 0 350064 54744 396376 0 0 0 0 1200 922 3
1 96 0
0 0 0 350064 54744 396376 0 0 0 0 1193 809 2
1 97 0
0 0 0 350064 54744 396376 0 0 0 0 1193 784 3
2 95 0
0 0 0 350080 54744 396376 0 0 0 0 1199 938 3
1 96 0
0 0 0 350080 54744 396376 0 0 0 16 1197 771 2
1 97 0
0 0 0 350080 54744 396376 0 0 0 0 1199 936 3
1 96 0
0 0 0 350080 54744 396376 0 0 0 0 1198 806 3
1 96 0
0 0 0 350080 54744 396376 0 0 0 0 1196 917 3
2 95 0
0 0 0 350016 54744 396472 0 0 96 0 1216 833 3
1 94 2
0 0 0 350016 54744 396472 0 0 0 41 1199 804 2
2 96 0
0 0 0 350016 54744 396472 0 0 0 0 1191 756 3
0 97 0
0 0 0 350024 54744 396472 0 0 0 0 1195 886 4
1 95 0
0 0 0 350024 54744 396472 0 0 0 0 1193 786 2
1 97 0
0 0 0 350024 54744 396472 0 0 0 0 1202 887 3
1 96 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 350024 54744 396472 0 0 0 0 1205 921 2
1 97 0
1 0 0 350024 54744 396472 0 0 0 0 1205 900 3
2 95 0
0 1 0 349952 54744 396524 0 0 52 0 1208 893 3
2 95 0
0 0 0 349952 54744 396524 0 0 0 0 1205 856 3
2 94 1
0 0 0 349952 54744 396524 0 0 0 0 1189 738 3
0 97 0
0 0 0 349952 54744 396524 0 0 0 13 1196 810 2
1 97 0
0 0 0 349952 54744 396524 0 0 0 0 1192 865 2
1 97 0
0 0 0 349952 54744 396524 0 0 0 0 1191 777 2
2 96 0
0 0 0 350016 54744 396524 0 0 0 0 1190 769 2
1 97 0
0 0 0 350024 54744 396524 0 0 0 0 1211 701 3
0 97 0
0 0 0 350024 54744 396524 0 0 0 12 1246 828 3
2 95 0
0 0 0 350032 54744 396524 0 0 0 0 1221 597 2
0 98 0
0 0 0 350032 54744 396524 0 0 0 0 1204 589 2
2 96 0
0 0 0 350032 54744 396524 0 0 0 0 1196 569 1
2 97 0
0 0 0 350032 54744 396524 0 0 0 0 1180 501 2
1 97 0
1 0 0 349048 54768 396532 0 0 32 2 1189 780 7
2 91 0
0 0 0 346896 55352 397016 0 0 1064 0 1428 1136 35
11 38 16
0 0 0 345744 55828 397720 0 0 1180 0 1598 1227 33
11 36 21
0 0 0 341904 56116 399056 0 0 1624 26 1659 1464 40
9 21 30
0 0 0 339856 56476 400100 0 0 1404 0 1575 1223 32
10 33 26
0 0 0 338704 56708 401360 0 0 1492 19 1549 1317 43
8 17 31
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 1 0 331344 56844 403132 0 0 1908 0 1666 1206 27
9 10 54
0 1 0 335176 56860 405068 0 0 1752 47 1627 1000 72
6 1 21
1 0 0 333192 57108 405888 0 0 1068 0 1735 1386 34
11 21 35
1 0 0 331784 57236 406968 0 0 1208 0 1773 1541 39
8 8 44
2 0 0 324168 57352 412360 0 0 3212 29 2178 1946 31
13 10 47
0 0 0 325320 57444 412868 0 0 600 0 1670 1472 34
12 12 42
1 0 0 324096 57524 409928 0 0 1240 0 1575 1444 52
13 7 28
2 0 0 317248 57524 419300 0 0 3980 32 2181 2554 51
12 0 37
4 0 0 311936 57524 419948 0 0 0 32 1197 1105 87
13 0 0
2 0 0 312320 57524 425304 0 0 0 31 1174 3964 86
14 0 0
2 0 0 304512 57524 431520 0 0 0 32 1226 1725 91
9 0 0
1 0 0 298616 57544 437856 0 0 340 53 3619 820 76
9 4 11
3 0 0 290112 57544 446952 0 0 44 54 3552 797 87
11 0 2
0 0 0 291072 57544 446952 0 0 0 0 3505 573 1
3 96 0
0 1 0 291008 57608 446952 0 0 64 87 1448 555 1
1 33 65
0 1 0 290752 57864 446952 0 0 256 12 1191 777 3
2 0 95
1 1 0 289344 59272 446952 0 0 1408 9 3442 971 6
3 0 91
0 1 0 287040 61584 446952 0 0 2307 1 1441 1542 10
4 0 86
0 1 0 284608 64016 446952 0 0 2432 0 1187 1343 10
1 0 89
0 1 0 282176 66448 446952 0 0 2432 27 1205 1490 10
3 0 87
0 1 0 279760 68880 446952 0 0 2432 0 1189 1426 9
3 0 88
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 1 0 277328 71312 446952 0 0 2432 34 1200 1554 9
3 0 88
0 1 0 275024 73616 446952 0 0 2304 9 1191 1492 9
3 0 88
0 1 0 272528 76048 446952 0 0 2432 12 1197 1544 9
2 0 89
0 1 0 270120 78480 446952 0 0 2432 16 1194 1517 9
4 0 87
0 1 0 267624 80912 446956 0 0 2433 0 1190 1327 9
2 0 89
2 1 0 265192 83344 446956 0 0 2432 34 1199 1400 9
3 0 88
0 1 0 260648 85716 448944 0 0 2316 4 1208 1493 8
4 0 88
0 1 0 258248 88148 448944 0 0 2432 0 1188 1409 10
1 0 89
1 1 0 257672 90504 446984 0 0 2464 2016 1696 1522 9
7 0 84
0 1 0 255240 92936 446984 0 0 2432 0 1190 1434 8
4 0 88
2 1 0 252744 95376 446984 0 0 2435 106 1227 1426 9
4 0 87
0 1 0 250456 97680 446984 0 0 2304 0 1183 1368 9
2 0 89
0 1 0 248024 100112 446984 0 0 2432 0 1191 1343 10
3 0 87
0 1 0 245592 102544 446984 0 0 2432 2543 1829 1640 9
5 0 86
0 1 0 243160 104976 446984 0 0 2432 0 1192 1452 8
3 0 89
0 1 0 240728 107408 446984 0 0 2432 0 1190 1460 9
3 0 88
0 1 0 238360 109712 446988 0 0 2305 0 1188 1380 8
2 0 90
0 1 0 235936 112144 446988 0 0 2432 0 1184 1290 9
2 0 89
0 1 0 233440 114580 446988 0 0 2433 11450 4041 1612 9
12 0 79
0 1 0 230816 117012 446996 0 0 2435 0 1192 1413 9
3 0 88
1 1 0 228312 119444 446996 0 0 2432 0 1198 1399 8
3 0 89
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 1 0 226008 121748 447000 0 0 2304 0 1189 1355 9
3 0 88
0 1 0 223576 124180 447000 0 0 2432 0 1192 1514 9
2 0 89
0 2 0 221072 126612 447000 0 0 2432 15160 4843 1727 10
15 0 75
0 1 0 218576 129044 447000 0 0 2432 6200 2871 1468 10
7 0 83
0 0 0 290808 57556 447048 0 0 1628 0 1214 1432 8
4 23 64
0 0 0 290808 57556 447048 0 0 0 0 1167 640 2
2 96 0
0 0 0 290808 57556 447048 0 0 0 0 1175 715 2
0 98 0
0 0 0 290808 57556 447048 0 0 0 71 1190 650 2
1 97 0
0 0 0 290808 57556 447048 0 0 0 0 1171 649 2
2 96 0
0 0 0 290808 57556 447048 0 0 0 0 1166 550 1
1 98 0
0 0 0 291032 57560 447048 0 0 1 0 1169 664 2
1 96 1
0 0 0 291032 57560 447048 0 0 0 0 1281 665 1
1 98 0
0 0 0 291032 57560 447048 0 0 0 25 1295 769 2
2 96 0
1 0 0 291032 57560 447048 0 0 0 0 1344 758 2
1 97 0
0 0 0 291032 57560 447048 0 0 0 0 1318 853 3
2 95 0

patched as:
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 805128 13404 113496 0 0 1708 37 1653 1043 12
20 40 28
0 0 0 805112 13404 113496 0 0 0 0 1181 276 1
0 99 0
0 0 0 805112 13404 113496 0 0 0 9 1386 534 1
0 99 0
0 0 0 804984 13404 113496 0 0 0 0 1254 968 8
2 90 0
0 0 0 804656 13412 113508 0 0 20 73 1199 638 6
1 92 1
0 0 0 804584 13412 113512 0 0 4 0 1220 456 2
2 95 1
0 0 0 804584 13412 113512 0 0 0 0 1262 428 1
1 98 0
0 1 0 797352 13420 116992 0 0 3488 0 1954 1841 13
4 51 32
0 1 0 777272 13420 135368 0 0 18376 0 5864 6052 42
21 0 37
0 1 0 753080 13420 159560 0 0 24192 138 7435 7471 33
30 0 36
2 1 0 728120 13420 184512 0 0 24952 0 7644 7337 34
29 0 37
0 0 0 725616 13440 186668 0 0 2176 0 1736 2148 16
6 73 6
2 0 0 721328 13440 190768 0 0 0 0 1299 916 5
3 92 0
1 0 0 721328 13440 190776 0 0 0 0 400 542 13
56 31 0
1 0 0 721264 13440 190776 0 0 0 66 502 557 5
38 57 0
0 0 0 721264 13440 190776 0 0 0 0 1130 522 3
4 94 0
0 0 0 721296 13440 190776 0 0 0 12 1465 595 1
0 99 0
0 0 0 721296 13440 190776 0 0 0 0 1459 599 1
1 98 0
0 0 0 721296 13440 190776 0 0 0 0 1332 426 1
1 98 0
0 0 0 721296 13448 190776 0 0 8 63 1426 533 0
1 99 0
0 0 0 721328 13448 190776 0 0 0 0 1470 574 1
1 98 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 721328 13448 190796 0 0 20 0 1419 847 3
1 96 0
0 0 0 721328 13448 190796 0 0 0 0 1246 526 0
1 99 0
0 0 0 721328 13448 190796 0 0 0 0 1379 1142 2
2 96 0
0 0 0 721216 13448 190796 0 0 0 73 1305 789 6
2 92 0
0 0 0 721208 13448 190796 0 0 0 0 1417 1021 8
2 90 0
0 0 0 721208 13448 190796 0 0 0 0 1382 496 1
0 99 0
0 0 0 721208 13448 190796 0 0 0 0 1382 493 1
1 98 0
0 0 0 721232 13448 190796 0 0 0 0 1446 1455 7
2 91 0
0 0 0 721232 13448 190796 0 0 0 40 1358 509 2
1 97 0
0 0 0 721232 13448 190800 0 0 4 0 1356 548 2
1 97 0
1 0 0 714872 13448 193180 0 0 2245 0 1818 1299 51
6 19 24
2 0 0 706408 13936 195444 0 0 2657 0 3223 2994 44
10 2 45
0 0 0 705704 13944 198540 0 0 3103 0 4273 1826 24
8 28 39
0 0 0 705696 13944 198540 0 0 0 33 2605 382 1
2 97 0
0 0 0 705696 13944 198540 0 0 0 0 1091 452 2
1 97 0
0 1 0 703072 13944 201044 0 0 2502 10 3043 2099 17
6 33 44
0 1 0 694368 13944 207968 0 0 6921 6 4588 5447 13
10 0 77
0 0 0 690336 13948 211476 0 0 3499 0 3548 3837 7
7 4 82
1 0 0 690336 13948 211480 0 0 1 3 3540 568 3
1 96 0
0 0 0 694208 13948 207540 0 0 156 11 3219 546 10
4 74 12
0 0 0 694208 13948 207540 0 0 0 0 2236 323 2
1 97 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 694104 13948 207540 0 0 0 0 1222 586 20
2 78 0
0 0 0 693720 13948 207864 0 0 324 1 1242 552 28
3 65 4
0 0 0 693720 13948 207864 0 0 0 16 1197 329 2
0 98 0
0 0 0 693720 13948 207864 0 0 0 0 1252 500 5
2 93 0
0 0 0 693720 13948 207868 0 0 0 0 1402 550 4
2 94 0
0 0 0 693592 13948 207880 0 0 9 4 1172 519 16
1 82 1
1 0 0 693600 13948 207880 0 0 0 0 1449 1654 31
5 64 0
0 0 0 693600 13948 207880 0 0 0 44 1245 528 3
1 96 0
0 0 0 693600 13948 207880 0 0 0 0 1080 151 0
0 100 0
0 0 0 693600 13948 207880 0 0 0 0 1438 588 1
1 98 0
0 0 0 693616 13948 207880 0 0 0 0 1446 648 1
0 99 0
1 0 0 689584 13948 211984 0 0 4 0 525 587 11
32 54 4
1 0 0 689592 13948 211984 0 0 0 28 400 556 14
57 29 0
0 0 0 689400 13948 211984 0 0 0 0 754 629 2
16 81 0
0 0 0 689400 13948 211984 0 0 0 0 1452 703 2
2 96 0
1 0 0 689400 13948 211988 0 0 0 0 1091 780 1
4 94 0
0 0 0 689400 13948 211988 0 0 0 0 1437 842 2
0 98 0
0 0 0 689400 13948 211988 0 0 0 0 1450 796 0
2 98 0
0 0 0 689400 13948 211988 0 0 0 0 1458 753 1
1 98 0
0 0 0 689400 13948 211988 0 0 0 0 1465 762 1
1 98 0
0 0 0 689400 13948 211988 0 0 0 0 1446 752 1
1 98 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 689400 13948 211988 0 0 0 0 1251 493 0
0 100 0
0 0 0 689416 13948 211988 0 0 0 5 1463 752 1
1 98 0
0 0 0 689408 13948 211988 0 0 0 0 1467 716 2
2 96 0
0 0 0 689408 13948 211988 0 0 0 0 1376 613 0
1 99 0
0 0 0 689408 13948 211988 0 0 0 0 1451 771 1
0 99 0
0 0 0 689408 13948 211988 0 0 0 0 1452 827 1
2 97 0
0 0 0 689408 13948 211988 0 0 0 21 1406 813 1
0 99 0
0 0 0 689408 13948 211992 0 0 0 0 963 944 7
10 83 0
0 0 0 689408 13948 211992 0 0 0 0 1475 786 1
0 99 0
0 0 0 689408 13948 211992 0 0 0 0 1448 875 1
2 97 0
0 0 0 689408 13948 211992 0 0 0 0 1410 918 1
0 99 0
0 0 0 689408 13948 211992 0 0 0 0 1453 796 0
2 98 0
0 0 0 689408 13948 211992 0 0 0 0 1430 765 1
0 99 0
1 0 0 684672 13948 211992 0 0 0 0 1471 1193 7
4 89 0
0 0 0 689216 13948 211992 0 0 0 0 1314 731 3
1 96 0
0 0 0 689216 13948 211992 0 0 0 4 1448 722 3
1 96 0
0 0 0 689200 13948 211992 0 0 0 0 1424 1127 19
3 78 0
0 0 0 689200 13948 211992 0 0 0 0 1384 622 3
1 96 0
0 0 0 689200 13948 211992 0 0 0 0 1450 765 6
2 92 0
0 0 0 689200 13948 211992 0 0 0 0 1355 595 2
1 97 0
0 0 0 689200 13948 211992 0 0 0 16 1462 637 3
1 96 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 689224 13948 211992 0 0 0 0 1355 599 4
2 94 0
0 0 0 689208 13948 211992 0 0 0 1 1437 689 5
1 94 0
1 0 0 689208 13948 211992 0 0 0 0 1155 742 5
6 88 0
2 0 0 685096 13948 211992 0 0 0 0 938 869 17
6 77 0
2 0 0 689192 13948 211992 0 0 0 16 947 1175 25
8 67 0
0 0 0 689192 13948 211992 0 0 0 0 1012 758 5
6 89 0
0 0 0 689312 13948 211992 0 0 0 0 948 1311 33
11 56 0
1 0 0 689312 13948 211992 0 0 0 0 954 772 9
8 83 0
0 0 0 689336 13948 211992 0 0 0 0 744 470 3
5 92 0
0 0 0 689320 13948 211992 0 0 0 0 885 1171 30
9 61 0
1 0 0 689320 13948 211996 0 0 0 0 883 1425 22
6 71 0
0 0 0 689312 13948 211996 0 0 0 0 998 789 5
9 86 0
0 0 0 689312 13948 211996 0 0 0 0 915 684 2
5 94 0
1 0 0 689312 13948 211996 0 0 0 0 946 1206 6
8 86 0
0 0 0 689312 13948 211996 0 0 0 5 951 628 3
6 91 0
0 0 0 689312 13948 211996 0 0 0 0 921 635 3
6 90 0
1 0 0 687280 13948 211996 0 0 0 0 812 2274 36
11 53 0
0 0 0 687280 13948 211996 0 0 0 0 909 635 5
5 90 0
0 0 0 687280 13948 211996 0 0 0 0 752 411 0
6 94 0
1 0 0 687024 13956 212056 0 0 68 35 803 623 3
5 89 3
0 0 0 687024 13956 212056 0 0 0 0 743 437 2
6 92 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 686688 13964 212108 0 0 56 32 764 693 5
9 83 3
1 0 0 686688 13964 212108 0 0 0 0 763 460 3
5 92 0
0 0 0 686688 13964 212108 0 0 0 0 749 577 2
5 94 0
0 0 0 686688 13964 212108 0 0 0 1 763 370 1
6 93 0
1 0 0 686432 13996 212116 0 0 40 0 759 643 5
6 88 2
0 0 0 686368 14000 212196 0 0 84 0 783 561 0
6 92 2
2 0 0 686368 14000 212196 0 0 0 13 757 468 3
6 91 0
1 0 0 686408 14000 212196 0 0 0 0 971 646 2
6 92 0
1 0 0 686408 14000 212196 0 0 0 0 1016 692 3
5 92 0
1 0 0 686408 14000 212196 0 0 0 0 1063 929 3
7 90 0
1 0 0 686408 14000 212196 0 0 0 24 983 719 3
6 91 0
0 0 0 686416 14000 212196 0 0 0 21 1033 970 2
6 92 0
0 0 0 686416 14000 212196 0 0 0 0 901 599 1
7 91 0
1 0 0 686416 14000 212196 0 0 0 20 735 469 3
5 92 0
0 0 0 686416 14000 212196 0 0 0 0 695 404 2
5 93 0
0 0 0 686416 14000 212196 0 0 0 0 684 533 2
10 88 0
1 0 0 686416 14000 212196 0 0 0 13 744 568 3
5 92 0
0 0 0 686416 14000 212196 0 0 0 0 719 510 2
6 92 0
0 0 0 686416 14000 212196 0 0 0 12 726 427 2
5 94 0
3 0 0 686416 14000 212196 0 0 0 0 721 536 5
5 90 0
0 0 0 686408 14000 212196 0 0 0 0 735 509 3
8 89 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 686408 14000 212196 0 0 0 0 715 516 3
5 92 0
1 0 0 686408 14000 212196 0 0 0 0 729 534 2
5 93 0
0 0 0 686400 14000 212196 0 0 0 12 743 619 3
5 92 0
0 0 0 686400 14000 212196 0 0 0 0 767 494 2
6 92 0
1 0 0 686400 14000 212196 0 0 0 0 747 547 3
6 91 0
0 0 0 686016 14024 212600 0 0 428 0 819 423 2
7 84 8
0 0 0 686016 14024 212600 0 0 0 0 692 338 2
5 93 0
0 0 0 686016 14024 212600 0 0 0 18 665 456 2
5 93 0
0 0 0 686016 14024 212600 0 0 0 0 1079 133 0
0 100 0
0 0 0 686016 14024 212600 0 0 0 0 1079 146 0
1 99 0
0 0 0 686016 14024 212600 0 0 0 0 1078 136 0
1 99 0
0 0 0 686016 14024 212600 0 0 0 0 1089 194 0
0 100 0
0 0 0 686016 14024 212600 0 0 0 26 1115 276 0
0 100 0
0 0 0 686016 14024 212600 0 0 0 0 1098 258 0
0 100 0
0 0 0 686088 14024 212600 0 0 0 0 1083 238 0
0 100 0
0 0 0 686088 14024 212600 0 0 0 0 1085 215 0
0 100 0
0 0 0 686088 14024 212604 0 0 0 0 1084 188 1
2 97 0
0 0 0 686088 14024 212604 0 0 0 3 1092 435 1
0 99 0
0 0 0 686096 14024 212604 0 0 0 8 1088 232 1
0 99 0
0 0 0 686096 14032 212604 0 0 8 0 1086 247 0
1 99 0
0 0 0 686096 14036 212608 0 0 4 0 934 327 1
1 98 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 686096 14036 212604 0 0 0 0 1083 171 0
1 99 0
0 0 0 686096 14036 212604 0 0 0 0 1081 184 0
0 100 0
0 0 0 690384 14036 208504 0 0 0 9 1077 347 2
1 97 0
0 0 0 690384 14044 208504 0 0 8 0 1088 261 1
1 98 0
3 0 0 690384 14044 208504 0 0 0 0 1077 700 64
8 28 0
3 0 0 690384 14048 208504 0 0 4 0 1085 9681 86
14 0 0
1 0 0 690384 14048 208504 0 0 0 0 1086 15947 83
17 0 0
0 0 0 690384 14048 208504 0 0 0 8 1096 3238 16
5 79 0
0 0 0 690320 14048 208504 0 0 0 0 1084 189 1
1 98 0
0 1 0 690256 14112 208504 0 0 64 0 1097 104 0
0 44 56
0 1 0 690000 14368 208504 0 0 256 0 1080 205 1
0 0 99
0 1 0 688464 15904 208504 0 0 1536 0 1092 671 4
2 0 94
0 1 0 686160 18208 208504 0 0 2304 0 1103 1067 8
2 0 90
0 1 0 683744 20640 208504 0 0 2432 0 1099 1028 8
2 0 90
1 1 0 681312 23072 208504 0 0 2432 0 1097 900 8
1 0 91
0 1 0 678936 25384 208504 0 0 2312 0 1101 947 7
2 0 91
0 1 0 676504 27816 208504 0 0 2432 5 1101 1000 8
2 0 90
0 1 0 674080 30248 208504 0 0 2432 0 1098 906 7
1 0 92
0 1 0 671576 32680 208504 0 0 2432 0 1097 1052 8
2 0 90
0 1 0 669144 35112 208504 0 0 2432 0 1097 950 8
3 0 89
0 1 0 666776 37416 208504 0 0 2304 0 1097 941 7
1 0 92
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 1 0 664352 39848 208504 0 0 2432 8 1099 995 8
1 0 91
0 1 0 661856 42280 208504 0 0 2432 0 1098 967 7
3 0 90
0 1 0 659424 44712 208504 0 0 2432 0 1107 1121 8
3 0 89
2 1 0 654728 47768 209484 0 0 4036 0 1510 1343 15
5 0 80
0 1 0 651144 50944 209484 0 0 3176 0 1530 1457 12
5 0 83
0 2 0 647040 54192 209600 0 0 3364 24 1706 1784 18
4 0 78
0 1 0 641688 57324 210132 0 0 3664 0 1620 1790 31
9 0 60
1 1 0 637784 60136 211096 0 0 3776 51 1641 1849 40
9 0 51
1 1 0 632600 62912 212180 0 0 3860 0 1831 1908 42
10 0 48
0 2 0 628376 65636 213080 0 0 3624 17 1807 1972 38
7 0 55
1 2 0 624536 68364 214316 0 0 3964 9 1544 1808 45
8 0 47
0 3 0 618840 71088 215676 0 0 4084 0 1497 1439 32
7 0 61
1 1 0 601936 73520 217388 0 0 4144 0 1562 1403 62
6 0 32
1 1 0 611472 76204 218840 0 0 3924 0 1470 1354 44
10 0 47
1 1 0 607952 78712 219720 0 0 3388 0 1370 1466 38
8 0 54
1 1 0 597520 81304 223632 0 0 5292 47 1832 1759 32
10 0 58
2 1 0 595664 83876 225792 0 0 3648 0 1427 1469 40
7 0 53
1 1 0 591952 86416 226740 0 0 3488 0 1410 1560 45
9 0 46
1 2 0 585608 88928 228528 0 0 4256 64 1566 1658 47
14 0 40
1 1 0 570632 91232 237320 0 0 5100 32 1810 2002 64
12 0 24
1 0 0 633720 19744 248936 0 0 1624 58 1125 1463 85
15 0 0
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
1 0 0 630008 19764 254900 0 0 348 37 1191 1059 79
6 4 11
1 0 0 628728 19764 256404 0 0 0 0 1154 315 99
1 0 0
0 0 0 622192 19772 264368 0 0 52 32 1458 765 4
8 87 1
0 0 0 622192 19772 264368 0 0 0 0 1330 551 1
1 98 0

Prakash

2003-11-07 22:02:27

by Xavier Bestel

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Le jeu 06/11/2003 ? 22:10, Prakash K. Cheemplavam a ?crit :
> c) That scsi gets selected when using usbfs seams to be some sort of
> wrapper being used...(just guessing without actually knowing the code).
> WOuld be nice if a note in the kernel menuconfig or alike would be left
> so that one doesn't have to wonder... But IIRC usbfs will be dropped anyway.

SCSI is not used for usbfs. It's simply the protocol for USB storage
devices (same case as FireWire/IEEE1394 storage devices). So it won't
get dropped any sooner. As SATA devices may be using SCSI in linux soon,
it even could be always selected.

Xav

2003-11-07 22:04:11

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

linux-2.6-npiggin/drivers/block/as-iosched.c | 320 +++++++++------------------
1 files changed, 109 insertions(+), 211 deletions(-)

diff -puN drivers/block/as-iosched.c~as-revert drivers/block/as-iosched.c
--- linux-2.6/drivers/block/as-iosched.c~as-revert 2003-11-07 22:26:43.000000000 +1100
+++ linux-2.6-npiggin/drivers/block/as-iosched.c 2003-11-07 22:28:59.000000000 +1100
@@ -70,7 +70,6 @@
/* Bits in as_io_context.state */
enum as_io_states {
AS_TASK_RUNNING=0, /* Process has not exitted */
- AS_TASK_IOSTARTED, /* Process has started some IO */
AS_TASK_IORUNNING, /* Process has completed some IO */
};

@@ -100,14 +99,6 @@ struct as_data {
sector_t last_sector[2]; /* last REQ_SYNC & REQ_ASYNC sectors */
struct list_head *dispatch; /* driver dispatch queue */
struct list_head *hash; /* request hash */
-
- unsigned long exit_prob; /* probability a task will exit while
- being waited on */
- unsigned long new_ttime_total; /* mean thinktime on new proc */
- unsigned long new_ttime_mean;
- u64 new_seek_total; /* mean seek on new proc */
- sector_t new_seek_mean;
-
unsigned long current_batch_expires;
unsigned long last_check_fifo[2];
int changed_batch; /* 1: waiting for old batch to end */
@@ -145,10 +136,6 @@ enum arq_state {
scheduler */
AS_RQ_DISPATCHED, /* On the dispatch list. It belongs to the
driver now */
- AS_RQ_PRESCHED, /* Debug poisoning for requests being used */
- AS_RQ_REMOVED,
- AS_RQ_MERGED,
- AS_RQ_POSTSCHED, /* when they shouldn't be */
};

struct as_rq {
@@ -195,7 +182,6 @@ static void free_as_io_context(struct as
/* Called when the task exits */
static void exit_as_io_context(struct as_io_context *aic)
{
- WARN_ON(!test_bit(AS_TASK_RUNNING, &aic->state));
clear_bit(AS_TASK_RUNNING, &aic->state);
}

@@ -618,15 +604,8 @@ static void as_antic_timeout(unsigned lo
spin_lock_irqsave(q->queue_lock, flags);
if (ad->antic_status == ANTIC_WAIT_REQ
|| ad->antic_status == ANTIC_WAIT_NEXT) {
- struct as_io_context *aic = ad->io_context->aic;
-
ad->antic_status = ANTIC_FINISHED;
kblockd_schedule_work(&ad->antic_work);
-
- if (aic->ttime_samples == 0) {
- /* process anticipated on has exitted or timed out*/
- ad->exit_prob = (7*ad->exit_prob + 256)/8;
- }
}
spin_unlock_irqrestore(q->queue_lock, flags);
}
@@ -640,7 +619,7 @@ static int as_close_req(struct as_data *
unsigned long delay; /* milliseconds */
sector_t last = ad->last_sector[ad->batch_data_dir];
sector_t next = arq->request->sector;
- sector_t delta; /* acceptable close offset (in sectors) */
+ sector_t delta; /* acceptable close offset (in sectors) */

if (ad->antic_status == ANTIC_OFF || !ad->ioc_finished)
delay = 0;
@@ -657,7 +636,6 @@ static int as_close_req(struct as_data *
return (last - (delta>>1) <= next) && (next <= last + delta);
}

-static void as_update_thinktime(struct as_data *ad, struct as_io_context *aic, unsigned long ttime);
/*
* as_can_break_anticipation returns true if we have been anticipating this
* request.
@@ -675,27 +653,9 @@ static int as_can_break_anticipation(str
{
struct io_context *ioc;
struct as_io_context *aic;
- sector_t s;
-
- ioc = ad->io_context;
- BUG_ON(!ioc);
-
- if (arq && ioc == arq->io_context) {
- /* request from same process */
- return 1;
- }

if (arq && arq->is_sync == REQ_SYNC && as_close_req(ad, arq)) {
/* close request */
- struct as_io_context *aic = ioc->aic;
- if (aic) {
- unsigned long thinktime;
- spin_lock(&aic->lock);
- thinktime = jiffies - aic->last_end_request;
- aic->last_end_request = jiffies;
- as_update_thinktime(ad, aic, thinktime);
- spin_unlock(&aic->lock);
- }
return 1;
}

@@ -707,14 +667,20 @@ static int as_can_break_anticipation(str
return 1;
}

+ ioc = ad->io_context;
+ BUG_ON(!ioc);
+
+ if (arq && ioc == arq->io_context) {
+ /* request from same process */
+ return 1;
+ }
+
aic = ioc->aic;
if (!aic)
return 0;

if (!test_bit(AS_TASK_RUNNING, &aic->state)) {
/* process anticipated on has exitted */
- if (aic->ttime_samples == 0)
- ad->exit_prob = (7*ad->exit_prob + 256)/8;
return 1;
}

@@ -728,36 +694,27 @@ static int as_can_break_anticipation(str
return 1;
}

- if (aic->ttime_samples == 0) {
- if (ad->new_ttime_mean > ad->antic_expire)
- return 1;
- if (ad->exit_prob > 128)
- return 1;
- } else if (aic->ttime_mean > ad->antic_expire) {
- /* the process thinks too much between requests */
+ if (aic->seek_samples == 0 || aic->ttime_samples == 0) {
+ /*
+ * Process has just started IO. Don't anticipate.
+ * TODO! Must fix this up.
+ */
return 1;
}

- if (!arq)
- return 0;
-
- if (ad->last_sector[REQ_SYNC] < arq->request->sector)
- s = arq->request->sector - ad->last_sector[REQ_SYNC];
- else
- s = ad->last_sector[REQ_SYNC] - arq->request->sector;
+ if (aic->ttime_mean > ad->antic_expire) {
+ /* the process thinks too much between requests */
+ return 1;
+ }

- if (aic->seek_samples == 0) {
- /*
- * Process has just started IO. Use past statistics to
- * guage success possibility
- */
- if (ad->new_seek_mean/2 > s) {
- /* this request is better than what we're expecting */
- return 1;
- }
+ if (arq && aic->seek_samples) {
+ sector_t s;
+ if (ad->last_sector[REQ_SYNC] < arq->request->sector)
+ s = arq->request->sector - ad->last_sector[REQ_SYNC];
+ else
+ s = ad->last_sector[REQ_SYNC] - arq->request->sector;

- } else {
- if (aic->seek_mean/2 > s) {
+ if (aic->seek_mean > (s>>1)) {
/* this request is better than what we're expecting */
return 1;
}
@@ -802,51 +759,12 @@ static int as_can_anticipate(struct as_d
return 1;
}

-static void as_update_thinktime(struct as_data *ad, struct as_io_context *aic, unsigned long ttime)
-{
- /* fixed point: 1.0 == 1<<8 */
- if (aic->ttime_samples == 0) {
- ad->new_ttime_total = (7*ad->new_ttime_total + 256*ttime) / 8;
- ad->new_ttime_mean = ad->new_ttime_total / 256;
-
- ad->exit_prob = (7*ad->exit_prob)/8;
- }
- aic->ttime_samples = (7*aic->ttime_samples + 256) / 8;
- aic->ttime_total = (7*aic->ttime_total + 256*ttime) / 8;
- aic->ttime_mean = (aic->ttime_total + 128) / aic->ttime_samples;
-}
-
-static void as_update_seekdist(struct as_data *ad, struct as_io_context *aic, sector_t sdist)
-{
- u64 total;
-
- if (aic->seek_samples == 0) {
- ad->new_seek_total = (7*ad->new_seek_total + 256*(u64)sdist)/8;
- ad->new_seek_mean = ad->new_seek_total / 256;
- }
-
- /*
- * Don't allow the seek distance to get too large from the
- * odd fragment, pagein, etc
- */
- if (aic->seek_samples <= 60) /* second&third seek */
- sdist = min(sdist, (aic->seek_mean * 4) + 2*1024*1024);
- else
- sdist = min(sdist, (aic->seek_mean * 4) + 2*1024*64);
-
- aic->seek_samples = (7*aic->seek_samples + 256) / 8;
- aic->seek_total = (7*aic->seek_total + (u64)256*sdist) / 8;
- total = aic->seek_total + (aic->seek_samples/2);
- do_div(total, aic->seek_samples);
- aic->seek_mean = (sector_t)total;
-}
-
/*
* as_update_iohist keeps a decaying histogram of IO thinktimes, and
* updates @aic->ttime_mean based on that. It is called when a new
* request is queued.
*/
-static void as_update_iohist(struct as_data *ad, struct as_io_context *aic, struct request *rq)
+static void as_update_iohist(struct as_io_context *aic, struct request *rq)
{
struct as_rq *arq = RQ_DATA(rq);
int data_dir = arq->is_sync;
@@ -857,29 +775,60 @@ static void as_update_iohist(struct as_d
return;

if (data_dir == REQ_SYNC) {
- unsigned long in_flight = atomic_read(&aic->nr_queued)
- + atomic_read(&aic->nr_dispatched);
spin_lock(&aic->lock);
- if (test_bit(AS_TASK_IORUNNING, &aic->state) ||
- test_bit(AS_TASK_IOSTARTED, &aic->state)) {
+
+ if (test_bit(AS_TASK_IORUNNING, &aic->state)
+ && !atomic_read(&aic->nr_queued)
+ && !atomic_read(&aic->nr_dispatched)) {
/* Calculate read -> read thinktime */
- if (test_bit(AS_TASK_IORUNNING, &aic->state)
- && in_flight == 0) {
- thinktime = jiffies - aic->last_end_request;
- thinktime = min(thinktime, MAX_THINKTIME-1);
- } else
- thinktime = 0;
- as_update_thinktime(ad, aic, thinktime);
-
- /* Calculate read -> read seek distance */
- if (aic->last_request_pos < rq->sector)
- seek_dist = rq->sector - aic->last_request_pos;
- else
- seek_dist = aic->last_request_pos - rq->sector;
- as_update_seekdist(ad, aic, seek_dist);
- }
+ thinktime = jiffies - aic->last_end_request;
+ thinktime = min(thinktime, MAX_THINKTIME-1);
+ /* fixed point: 1.0 == 1<<8 */
+ aic->ttime_samples += 256;
+ aic->ttime_total += 256*thinktime;
+ if (aic->ttime_samples)
+ /* fixed point factor is cancelled here */
+ aic->ttime_mean = (aic->ttime_total + 128)
+ / aic->ttime_samples;
+ aic->ttime_samples = (aic->ttime_samples>>1)
+ + (aic->ttime_samples>>2);
+ aic->ttime_total = (aic->ttime_total>>1)
+ + (aic->ttime_total>>2);
+ }
+
+ /* Calculate read -> read seek distance */
+ if (!aic->seek_samples)
+ seek_dist = 0;
+ else if (aic->last_request_pos < rq->sector)
+ seek_dist = rq->sector - aic->last_request_pos;
+ else
+ seek_dist = aic->last_request_pos - rq->sector;
+
aic->last_request_pos = rq->sector + rq->nr_sectors;
- set_bit(AS_TASK_IOSTARTED, &aic->state);
+
+ /*
+ * Don't allow the seek distance to get too large from the
+ * odd fragment, pagein, etc
+ */
+ if (aic->seek_samples < 400) /* second&third seek */
+ seek_dist = min(seek_dist, (aic->seek_mean * 4)
+ + 2*1024*1024);
+ else
+ seek_dist = min(seek_dist, (aic->seek_mean * 4)
+ + 2*1024*64);
+
+ aic->seek_samples += 256;
+ aic->seek_total += (u64)256*seek_dist;
+ if (aic->seek_samples) {
+ u64 total = aic->seek_total + (aic->seek_samples>>1);
+ do_div(total, aic->seek_samples);
+ aic->seek_mean = (sector_t)total;
+ }
+ aic->seek_samples = (aic->seek_samples>>1)
+ + (aic->seek_samples>>2);
+ aic->seek_total = (aic->seek_total>>1)
+ + (aic->seek_total>>2);
+
spin_unlock(&aic->lock);
}
}
@@ -944,22 +893,12 @@ static void as_completed_request(request
{
struct as_data *ad = q->elevator.elevator_data;
struct as_rq *arq = RQ_DATA(rq);
+ struct as_io_context *aic;

WARN_ON(!list_empty(&rq->queuelist));

- if (arq->state == AS_RQ_PRESCHED) {
- WARN_ON(arq->io_context);
- goto out;
- }
-
- if (arq->state == AS_RQ_MERGED)
- goto out_ioc;
-
- if (arq->state != AS_RQ_REMOVED) {
- printk("arq->state %d\n", arq->state);
- WARN_ON(1);
- goto out;
- }
+ if (unlikely(arq->state != AS_RQ_DISPATCHED))
+ return;

if (!blk_fs_request(rq))
return;
@@ -989,7 +928,10 @@ static void as_completed_request(request
ad->new_batch = 0;
}

- if (ad->io_context == arq->io_context && ad->io_context) {
+ if (!arq->io_context)
+ return;
+
+ if (ad->io_context == arq->io_context) {
ad->antic_start = jiffies;
ad->ioc_finished = 1;
if (ad->antic_status == ANTIC_WAIT_REQ) {
@@ -1001,23 +943,18 @@ static void as_completed_request(request
}
}

-out_ioc:
- if (!arq->io_context)
- goto out;
+ aic = arq->io_context->aic;
+ if (!aic)
+ return;

+ spin_lock(&aic->lock);
if (arq->is_sync == REQ_SYNC) {
- struct as_io_context *aic = arq->io_context->aic;
- if (aic) {
- spin_lock(&aic->lock);
- set_bit(AS_TASK_IORUNNING, &aic->state);
- aic->last_end_request = jiffies;
- spin_unlock(&aic->lock);
- }
+ set_bit(AS_TASK_IORUNNING, &aic->state);
+ aic->last_end_request = jiffies;
}
+ spin_unlock(&aic->lock);

put_io_context(arq->io_context);
-out:
- arq->state = AS_RQ_POSTSCHED;
}

/*
@@ -1086,14 +1023,14 @@ static void as_remove_request(request_qu
struct as_rq *arq = RQ_DATA(rq);

if (unlikely(arq->state == AS_RQ_NEW))
- goto out;
+ return;
+
+ if (!arq) {
+ WARN_ON(1);
+ return;
+ }

if (ON_RB(&arq->rb_node)) {
- if (arq->state != AS_RQ_QUEUED) {
- printk("arq->state %d\n", arq->state);
- WARN_ON(1);
- goto out;
- }
/*
* We'll lose the aliased request(s) here. I don't think this
* will ever happen, but if it does, hopefully someone will
@@ -1101,16 +1038,8 @@ static void as_remove_request(request_qu
*/
WARN_ON(!list_empty(&rq->queuelist));
as_remove_queued_request(q, rq);
- } else {
- if (arq->state != AS_RQ_DISPATCHED) {
- printk("arq->state %d\n", arq->state);
- WARN_ON(1);
- goto out;
- }
+ } else
as_remove_dispatched_request(q, rq);
- }
-out:
- arq->state = AS_RQ_REMOVED;
}

/*
@@ -1288,9 +1217,9 @@ static int as_dispatch_request(struct as
*/
goto dispatch_writes;

- if (ad->batch_data_dir == REQ_ASYNC) {
+ if (ad->batch_data_dir == REQ_ASYNC) {
WARN_ON(ad->new_batch);
- ad->changed_batch = 1;
+ ad->changed_batch = 1;
}
ad->batch_data_dir = REQ_SYNC;
arq = list_entry_fifo(ad->fifo_list[ad->batch_data_dir].next);
@@ -1306,8 +1235,8 @@ static int as_dispatch_request(struct as
dispatch_writes:
BUG_ON(RB_EMPTY(&ad->sort_list[REQ_ASYNC]));

- if (ad->batch_data_dir == REQ_SYNC) {
- ad->changed_batch = 1;
+ if (ad->batch_data_dir == REQ_SYNC) {
+ ad->changed_batch = 1;

/*
* new_batch might be 1 when the queue runs out of
@@ -1350,6 +1279,8 @@ fifo_expired:
ad->new_batch = 1;

ad->changed_batch = 0;
+
+// arq->request->flags |= REQ_SOFTBARRIER;
}

/*
@@ -1426,8 +1357,8 @@ static void as_add_request(struct as_dat
arq->io_context = as_get_io_context();

if (arq->io_context) {
- as_update_iohist(ad, arq->io_context->aic, arq->request);
atomic_inc(&arq->io_context->aic->nr_queued);
+ as_update_iohist(arq->io_context->aic, arq->request);
}

alias = as_add_arq_rb(ad, arq);
@@ -1474,11 +1405,6 @@ static void as_requeue_request(request_q
struct as_rq *arq = RQ_DATA(rq);

if (arq) {
- if (arq->state != AS_RQ_REMOVED) {
- printk("arq->state %d\n", arq->state);
- WARN_ON(1);
- }
-
arq->state = AS_RQ_DISPATCHED;
if (arq->io_context && arq->io_context->aic)
atomic_inc(&arq->io_context->aic->nr_dispatched);
@@ -1498,18 +1424,12 @@ as_insert_request(request_queue_t *q, st
struct as_data *ad = q->elevator.elevator_data;
struct as_rq *arq = RQ_DATA(rq);

- if (arq) {
- if (arq->state != AS_RQ_PRESCHED) {
- printk("arq->state: %d\n", arq->state);
- WARN_ON(1);
- }
- arq->state = AS_RQ_NEW;
- }
-
+#if 0
/* barriers must flush the reorder queue */
if (unlikely(rq->flags & (REQ_SOFTBARRIER | REQ_HARDBARRIER)
&& where == ELEVATOR_INSERT_SORT))
where = ELEVATOR_INSERT_BACK;
+#endif

switch (where) {
case ELEVATOR_INSERT_BACK:
@@ -1744,8 +1664,7 @@ as_merged_requests(request_queue_t *q, s
* kill knowledge of next, this one is a goner
*/
as_remove_queued_request(q, next);
-
- anext->state = AS_RQ_MERGED;
+ put_io_context(anext->io_context);
}

/*
@@ -1778,11 +1697,6 @@ static void as_put_request(request_queue
return;
}

- if (arq->state != AS_RQ_POSTSCHED) {
- printk("arq->state %d\n", arq->state);
- WARN_ON(1);
- }
-
mempool_free(arq, ad->arq_pool);
rq->elevator_private = NULL;
}
@@ -1796,7 +1710,7 @@ static int as_set_request(request_queue_
memset(arq, 0, sizeof(*arq));
RB_CLEAR(&arq->rb_node);
arq->request = rq;
- arq->state = AS_RQ_PRESCHED;
+ arq->state = AS_RQ_NEW;
arq->io_context = NULL;
INIT_LIST_HEAD(&arq->hash);
arq->on_hash = 0;
@@ -1933,17 +1847,6 @@ as_var_store(unsigned long *var, const c
return count;
}

-static ssize_t as_est_show(struct as_data *ad, char *page)
-{
- int pos = 0;
-
- pos += sprintf(page+pos, "%lu %% exit probability\n", 100*ad->exit_prob/256);
- pos += sprintf(page+pos, "%lu ms new thinktime\n", ad->new_ttime_mean);
- pos += sprintf(page+pos, "%llu sectors new seek distance\n", (unsigned long long)ad->new_seek_mean);
-
- return pos;
-}
-
#define SHOW_FUNCTION(__FUNC, __VAR) \
static ssize_t __FUNC(struct as_data *ad, char *page) \
{ \
@@ -1975,10 +1878,6 @@ STORE_FUNCTION(as_write_batchexpire_stor
&ad->batch_expire[REQ_ASYNC], 0, INT_MAX);
#undef STORE_FUNCTION

-static struct as_fs_entry as_est_entry = {
- .attr = {.name = "est_time", .mode = S_IRUGO },
- .show = as_est_show,
-};
static struct as_fs_entry as_readexpire_entry = {
.attr = {.name = "read_expire", .mode = S_IRUGO | S_IWUSR },
.show = as_readexpire_show,
@@ -2006,7 +1905,6 @@ static struct as_fs_entry as_write_batch
};

static struct attribute *default_attrs[] = {
- &as_est_entry.attr,
&as_readexpire_entry.attr,
&as_writeexpire_entry.attr,
&as_anticexpire_entry.attr,

_

Attachments:

as-revert.patch (16.15 kB)

2003-11-08 00:24:45

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 6 Nov 2003, John Bradford wrote:

> Quote from Linus Torvalds <[email protected]>:
>
> > ide-scsi has always been broken. You should not use it, and indeed there
> > was never any good reason for it existing AT ALL. But because of a broken
> > interface to cdrecord, cdrecord historically only wanted to touch SCSI
> > devices. Ergo, a silly emulation layer that wasn't really worth it.
>
> Hmmm, but ide-scsi is used for a lot more than cd recorders these
> days. Alan mentioned 'crazy' SATA devices back in April.
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=105000779411632&w=2

I mentioned ide tapes and ZIP drives, Linus didn't mention how one gets
around those.

> (Not that I'm suggesting that it is particularly sane to deal with an
> SATA connected printer by presenting it as a SCSI device, but I just
> can't see how ide-scsi could successfully be removed now :-( )

And I don't see the joy of doing so. Unless someone wants to write new
versions of all the SCSI software out in use, a lot of functionality is
lost. In the long run it might have been better to simply fix or rewrite
ide-scsi and stop using the ide interface, becuase disk manufacturers
certainly aren't going to stop making scsi and it needs to be supported
anyway. I guess Doug Gilbert is doing other things now, I would have
expected at least an opinion out of him ;-)

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-07 22:02:27

by Rob Landley

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thursday 06 November 2003 13:45, Linus Torvalds wrote:
> On 6 Nov 2003, bill davidsen wrote:
> > I'm not sure what you mean by faster, burning runs at device limited
> > speed in CPU time in the less than 1% range if you remember to enable
> > DMA. The last time I looked DMA didn't work in either kernel if write
> > size was not a multiple of 1k, (or 2k?) has that changed?
>
> DMA works fine
>
> IF YOU DON'T USE IDE-SCSI
>
> Don't use it. Please. There's no point.
>
> It's much more readable to do
>
> cdrecord dev=/dev/hdc
>
> than it is to do some stupid "scan SCSI devices" + "dev=0,1,0" or similar
> totally incomprehensible crap that doesn't even work right.
>
> > I'm not sure what you meant by faster, so don't think I'm disagreeing
> > with you.
>
> Faster as in "it uses DMA for everything, so you can actually burn at full
> speed without having to worry about it or sucking up CPU".
>
> Linus

Note this still doesn't mean you can scroll large X windows for two or three
seconds at a time without burning a coaster.

I had high hopes with the new scheduler, but no. (Maybe if I niced the heck
out of cdrecord...)

Rob

2003-11-08 02:15:05

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Prakash K. Cheemplavam wrote:

>
>> Oh ok. Well whenever you get a chance to... Sorry that last patch
>> I sent was empty. Here is the correct one for when you get time.
>
>
> Yeah, runs nicely. (dmesg is quiet, as well.) Seems like it was only a
> minor issue in mm2, lloking at the patch...Very well.

Thanks a lot for your patience Prakash. Looks like its fixed then.
Yeah it was a pretty minor problem: you were triggering lots of warnings,
but if you can't see them in dmesg, maybe /proc/sys/kernel/printk is
configured to not show them.

Have a look at Documentation/sysctl/kernel.txt if you'd like to fix that
up. Thanks again.

Nick

2003-11-08 02:39:28

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Rob Landley wrote:

>On Thursday 06 November 2003 13:45, Linus Torvalds wrote:
>
>>On 6 Nov 2003, bill davidsen wrote:
>>
>>>I'm not sure what you mean by faster, burning runs at device limited
>>>speed in CPU time in the less than 1% range if you remember to enable
>>>DMA. The last time I looked DMA didn't work in either kernel if write
>>>size was not a multiple of 1k, (or 2k?) has that changed?
>>>
>>DMA works fine
>>
>> IF YOU DON'T USE IDE-SCSI
>>
>>Don't use it. Please. There's no point.
>>
>>It's much more readable to do
>>
>> cdrecord dev=/dev/hdc
>>
>>than it is to do some stupid "scan SCSI devices" + "dev=0,1,0" or similar
>>totally incomprehensible crap that doesn't even work right.
>>
>>
>>>I'm not sure what you meant by faster, so don't think I'm disagreeing
>>>with you.
>>>
>>Faster as in "it uses DMA for everything, so you can actually burn at full
>>speed without having to worry about it or sucking up CPU".
>>
>> Linus
>>
>
>Note this still doesn't mean you can scroll large X windows for two or three
>seconds at a time without burning a coaster.
>
>I had high hopes with the new scheduler, but no. (Maybe if I niced the heck
>out of cdrecord...)
>

RT processes should work well with the scheduler. renicing if it is not
RT will help a little bit, but it doesn't do much to help maximum latency.

2003-11-08 12:28:54

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Nick Piggin wrote:
>
>
> Prakash K. Cheemplavam wrote:
>
>>
>>> Oh ok. Well whenever you get a chance to... Sorry that last patch
>>> I sent was empty. Here is the correct one for when you get time.
>>
>>
>>
>> Yeah, runs nicely. (dmesg is quiet, as well.) Seems like it was only a
>> minor issue in mm2, lloking at the patch...Very well.
>
>
>
> Thanks a lot for your patience Prakash. Looks like its fixed then.

Happy I could help. :-)

> Yeah it was a pretty minor problem: you were triggering lots of warnings,
> but if you can't see them in dmesg, maybe /proc/sys/kernel/printk is
> configured to not show them.
>
> Have a look at Documentation/sysctl/kernel.txt if you'd like to fix that
> up. Thanks again.

Hmm, the document explains the setting but not exactly how to change
them. cat printk gives me:

1 4 1 7

which according to the doc means:

- console_loglevel: messages with a higher priority than
this will be printed to the console
- default_message_level: messages without an explicit priority
will be printed with this priority
- minimum_console_loglevel: minimum (highest) value to which
console_loglevel can be set
- default_console_loglevel: default value for console_loglevel

Are my settings not enough? How to change them? Using echo x y z w >
bla/printk ?

Another q: I guess I should enable frame pointers in kernel compilation
otherwise I won't get call traces, right?

bye,

Prakash

2003-11-08 15:04:35

by Ragnar Hojland Espinosa

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Fri, Nov 07, 2003 at 07:01:22AM -0800, Linus Torvalds wrote:
> In other words, they seem to "exist" in the same sense that soubdblaster
> CD-ROM users "exist". True in theory, but apparently only really useful
> for theoretical arguments.

Well, I hope its in better state than the Mitsumi driver, because last
time I tried it was broken (oopsed in a simple cat) since a 2.3.xx
IIRC [0]

[0] Tracked it down to a -pre if anyone is interested and its still
broken..
--
Ragnar Hojland - Project Manager
Linalco "Specialists in Linux and Free Software"
http://www.linalco.com Tel: +34-91-4561700

2003-11-08 17:53:04

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Sat, 8 Nov 2003, Ragnar Hojland Espinosa wrote:
>
> Well, I hope its in better state than the Mitsumi driver, because last
> time I tried it was broken (oopsed in a simple cat) since a 2.3.xx
> IIRC [0]

Since 2._3_.xx?

> [0] Tracked it down to a -pre if anyone is interested and its still
> broken..

Quite frankly, if it's literally been broken since 2.3.x, I think the best
thing to do would be to remove the driver entirely.

Yeah, there's probably a fair number of those old CD-ROM drivers that
nobody uses with modern kernels (ie they might be used on some router that
hasn't been touched in forever, still running 2.2.x on a 8MB 386SX-16).

Linus

2003-11-08 18:16:32

by Al Viro

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Sat, Nov 08, 2003 at 09:52:52AM -0800, Linus Torvalds wrote:
>
> On Sat, 8 Nov 2003, Ragnar Hojland Espinosa wrote:
> >
> > Well, I hope its in better state than the Mitsumi driver, because last
> > time I tried it was broken (oopsed in a simple cat) since a 2.3.xx
> > IIRC [0]
>
> Since 2._3_.xx?
>
> > [0] Tracked it down to a -pre if anyone is interested and its still
> > broken..
>
> Quite frankly, if it's literally been broken since 2.3.x, I think the best
> thing to do would be to remove the driver entirely.

... or give it to somebody on kernel-janitors and tell them to bring the
series of *provable* cleanups and fixes, getting the driver into decent
form. Would be a good exercise.

2003-11-08 21:19:53

by Randy.Dunlap

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Sat, 08 Nov 2003 13:31:06 +0100 "Prakash K. Cheemplavam" <[email protected]> wrote:

| Nick Piggin wrote:
| >
| >
| > Prakash K. Cheemplavam wrote:
| >
| >>
| >>> Oh ok. Well whenever you get a chance to... Sorry that last patch
| >>> I sent was empty. Here is the correct one for when you get time.
| >>
| >>
| >> Yeah, runs nicely. (dmesg is quiet, as well.) Seems like it was only a
| >> minor issue in mm2, lloking at the patch...Very well.
| >
| >
| > Thanks a lot for your patience Prakash. Looks like its fixed then.
|
| Happy I could help. :-)
|
| > Yeah it was a pretty minor problem: you were triggering lots of warnings,
| > but if you can't see them in dmesg, maybe /proc/sys/kernel/printk is
| > configured to not show them.
| >
| > Have a look at Documentation/sysctl/kernel.txt if you'd like to fix that
| > up. Thanks again.
|
| Hmm, the document explains the setting but not exactly how to change
| them. cat printk gives me:
|
| 1 4 1 7
|
| which according to the doc means:
|
| - console_loglevel: messages with a higher priority than
| this will be printed to the console
| - default_message_level: messages without an explicit priority
| will be printed with this priority
| - minimum_console_loglevel: minimum (highest) value to which
| console_loglevel can be set
| - default_console_loglevel: default value for console_loglevel
|
| Are my settings not enough? How to change them? Using echo x y z w >
| bla/printk ?

Yes, that works. Or to change only console_loglevel, you can use
Alt-SysRq-# (use 9 for # to print/log all messages) [works only if
you have Magic SysRq key enabled].

| Another q: I guess I should enable frame pointers in kernel compilation
| otherwise I won't get call traces, right?

Frame pointers can help with call traces, but we usually get decent
back traces even without them. IOW, they aren't required for
back traces.

--
~Randy

2003-11-09 10:47:09

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe wrote:
> On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
>
>>Prakash K. Cheemplavam wrote:
>>
>>>bill davidsen wrote:
>>>
>>>
>>>>In article <[email protected]>,
>>>>Prakash K. Cheemplavam <[email protected]> wrote:
>>>>
>>>>| Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM
>>>>restores | the full image (md5sum matches), but the CD-RW does not.
>>>>
>>>>There is a problem with ide-scsi in 2.6, and rather than fix it someone
>>>>came up with a patch to cdrecord to allow that application to work
>>
>>>b) The writing or reading issue mentioned above. It is a bit hard to
>>>find out, whether cdrecord actually *writes* an incomplete image
>>>(without using -pad), ie. throwing away the last 4096 bytes, which
>>>*only* happens in non-TAO mode. The programme CDRDAO shows the same
>>>behaviour. Strange enough reading this DAO written image out with my
>>>DVD-ROM makes this (missing?) 4096 bytes reappear... Well, maybe I
>>>should patch the image and put some other bytes instead of the 00s at
>>>the end to see, whether it is a write issue, a read issue of the writer
>>>or a read issue of the reader. Anyway, it doesn't sound right to me,
>>>what is happening at the moment...
>>
>>So tested further: I patched the very last byts of the image and these
>>are my findings:
>>
>>In DAO mode, the complete image is actually written, but the writer is
>>not able to read it out! The last 4096 bytes are not read. I put the
>>CD-RW into my DVD-ROM, and it reads it out completely.
>>
>>So: Is cdrecord/cdrdao making something wrong (yes, I know I can use
>>-pad, but I want an *identical copy*) or has the kernel ATAPI reading
>>routine a bug? (Or has my drive a bug???? Well, I need to read the disc
>>out in windows I guess...)
>
>
> See one of my mails from a few days ago. It's a hardware issue, some
> drives need a bit of pad at the end.

Yup, I verified it in windows. Same issue, so it is a hardware and not
software issue.

Prakash

--
=-----=
|=-P-=|
=-----=

2003-11-10 19:12:53

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Fri, 7 Nov 2003, Linus Torvalds wrote:

>
> On Fri, 7 Nov 2003, Bill Davidsen wrote:
> >
> > I mentioned ide tapes and ZIP drives, Linus didn't mention how one gets
> > around those.
>
> The thing is, the non-ide-scsi interfaces really _should_ work. The fact
> is, SG_IO ("send a SCSI command") just _works_.
>
> However, right now only the CD-ROM driver exposes those commands. Why?
> Because nobody has apparently cared enough about those theoretical IDE
> tapes and ZIP drives.
>
> In other words, they seem to "exist" in the same sense that soubdblaster
> CD-ROM users "exist". True in theory, but apparently only really useful
> for theoretical arguments.

I take it that if the IDE maintainer and you don't use a device it will
not be supported in the future? There's nothing theoretical about ZIP
drives and ATAPI tape drives, you can order them mail order or buy them at
any computer show. And 2.4 ide-scsi seems to support them perfectly, or at
least usefully, which is probably why there haven't been any complaints.

I admit I can't understand why 2.6 supports old NICs and motherboard
chipsets which haven't been made in five years, and then deliberately
desupports devices which did work and which are available at computer
stores and mail order today.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-10 19:25:50

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Mon, 10 Nov 2003, Bill Davidsen wrote:
>
> I take it that if the IDE maintainer and you don't use a device it will
> not be supported in the future?

You take it wrong.

However, I'll spell this out in small words, since you don't seem to be
getting it:

open source is not about me and the IDE maintainer doing all the
work.

Nobody seems to be sending patches either to fix ide-scsi _or_
those other devices you claim you're so interested in.

I fixed the IDE CD driver to work. I care. The fact that nobody
else seems to care about anything else is the final word.

Do you get it? It's all about technology. I don't hate you. Really. I'm
not here to try to make things difficult for you. But also, I'm not here
to be your personal slave, and if you think I am, you're just WRONG and
you should just realize that I don't care about what you think.

> I admit I can't understand why 2.6 supports old NICs and motherboard
> chipsets which haven't been made in five years, and then deliberately
> desupports devices which did work and which are available at computer
> stores and mail order today.

Those other devices have people MAINTAINING THEM AND CARING!

What's so horribly hard to understand about this? You're barking up the
wrong tree.

Again, I tell you once more:

- for burning IDE CD-ROM's you should use the IDE driver. Not ide-scsi.
End of discussion. It's a supported and _improved_ situation from where
it was in 2.4.x.

- For all those devices you claim exists, show me the patches. Nobody
broke ide-scsi on purpose - but the fact is that nobody also ever came
forward and _fixed_ it.

Get it now?

So come back to me when you find somebody who cares enough about the
devices you claim exists enough that he actually _does_ something about
it. Until then, there's just no point in bothering me. Comprende?

Linus

2003-11-10 19:36:52

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Sat, 8 Nov 2003, Linus Torvalds wrote:

> Quite frankly, if it's literally been broken since 2.3.x, I think the best
> thing to do would be to remove the driver entirely.

For no-longer-current hardware that would probably not be such a bad
thing.
>
> Yeah, there's probably a fair number of those old CD-ROM drivers that
> nobody uses with modern kernels (ie they might be used on some router that
> hasn't been touched in forever, still running 2.2.x on a 8MB 386SX-16).

Well, I ran DNS on such a beast with 1.2.13 (from memory) until Y2k scared
me into updating the whole setup. But iptables is so much better than
ipchains that I hope there are fewer people using 2.2 for routers!

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-10 20:13:59

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Mon, 10 Nov 2003, Linus Torvalds wrote:

>
> On Mon, 10 Nov 2003, Bill Davidsen wrote:
> >
> > I take it that if the IDE maintainer and you don't use a device it will
> > not be supported in the future?
>
> You take it wrong.
>
> However, I'll spell this out in small words, since you don't seem to be
> getting it:
>
> open source is not about me and the IDE maintainer doing all the
> work.
>
> Nobody seems to be sending patches either to fix ide-scsi _or_
> those other devices you claim you're so interested in.
>
> I fixed the IDE CD driver to work. I care. The fact that nobody
> else seems to care about anything else is the final word.

Obviously you count the users for nothing, because someone is sure buying
those ATAPI tape drives, it's just that the people using them aren't
kernel developers. A major difference between Linux and commercial
operating systems, to be sure, no one has a financial motive to fix things
like this, so features which worked in 2.4 remain broken unless someone
cares to fix them.
>
> Do you get it? It's all about technology. I don't hate you. Really. I'm
> not here to try to make things difficult for you. But also, I'm not here
> to be your personal slave, and if you think I am, you're just WRONG and
> you should just realize that I don't care about what you think.
>
> > I admit I can't understand why 2.6 supports old NICs and motherboard
> > chipsets which haven't been made in five years, and then deliberately
> > desupports devices which did work and which are available at computer
> > stores and mail order today.
>
> Those other devices have people MAINTAINING THEM AND CARING!
>
> What's so horribly hard to understand about this? You're barking up the
> wrong tree.
>
> Again, I tell you once more:
>
> - for burning IDE CD-ROM's you should use the IDE driver. Not ide-scsi.
> End of discussion. It's a supported and _improved_ situation from where
> it was in 2.4.x.

That was never the issue. The need for ide-scsi is for other devices which
are useful, and software which assume SCSI.

> - For all those devices you claim exists, show me the patches. Nobody
> broke ide-scsi on purpose - but the fact is that nobody also ever came
> forward and _fixed_ it.

And if they had they would have sent the patches to the maintainer, only
there doesn't seem to be one...
>
> Get it now?
>
> So come back to me when you find somebody who cares enough about the
> devices you claim exists enough that he actually _does_ something about
> it. Until then, there's just no point in bothering me. Comprende?

Claim exist? ATAPI tape drives are made by Compaq, Exabyte and Seagate,
capacities 20-200GB/tape, and prices from $150-$650 depending on capacity.
Small businesses use these for backup, because SCSI costs too much and
DVDs aren't large enough. Individuals use them because they have a low
initial cost. Guess kernel developers use something else, or don't do
backups.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-10 20:22:13

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Mon, 10 Nov 2003, Bill Davidsen wrote:
>
> > - For all those devices you claim exists, show me the patches. Nobody
> > broke ide-scsi on purpose - but the fact is that nobody also ever came
> > forward and _fixed_ it.
>
> And if they had they would have sent the patches to the maintainer, only
> there doesn't seem to be one...

Don't be silly. This is what linux-kernel is about.

Feel free to send out patches to be tested.

I'll be waiting for the people out there to test them. But so far I
haven't heard anything but misplaced whining from you.

Linus

2003-11-10 21:36:28

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>, Jens Axboe <[email protected]> wrote:

| It isn't a problem of the recorder program. But some drives wont read
| the very end of a disc unless there are some pad blocks at the end.
| Thus, you should always use the cdrecord pad option.

I think the previous answer, some devices will read without pad and some
won't, is probably a good place to stop. It turns out that some device
not only don't need the pad, but will read it if you are in the raw read
mode, and thus "read more than you wrote" of data. For iso9660 images
being mounted the pad option should be used, and I believe that it does
in fact default to on in recent versions of cdrecord.

In any case I would add "with iso9660 images" to your fine advice, and
suggest that getting the iso filesystem size (from isoinfo) and reading
exactly that much is still probably desirable. There are too many TAO
vs. DAO and -pad or not magic solutions, unfortunately, and too much
dubious firmware for anything else to work every time.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-10 21:56:12

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>, Jens Axboe <[email protected]> wrote:

| > AFAIK, Prakash cannot reproduce this bad behaviour with mm1, only mm2 (is
| > this right, Prakash?). So its something there (don't forget Andrew merges
| > the latest bk with his releases too).
|
| I'm not aware of anything in that area that could explain the change.

I think it's interesting that he saw it with oldconfig. That would
indicate that the way the config was interpreted changed rather than the
config itself. That don't mean that he didn't have an undetected oddness
in the original config which wasn't detected in mm1, but it seems
unlikely.

I looked at some of my old make logs, but I haven't yet built test9 for
a system which doesn't have SCSI.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-10 22:17:19

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>,
Prakash K. Cheemplavam <[email protected]> wrote:

| Yup, I verified it in windows. Same issue, so it is a hardware and not
| software issue.

Would you humor me and get the isosize of the image from isoinfo, then
try to read the image with
"dd if=/dev/cdrom bs=2k count={ISOSIZE} of=copy.iso"
and see if reading just the correct amount will in fact get the last
data? Note that this is another of those "sometimes works" things, your
firmware may really not allow you to avoid readahead, but I have several
drives (one CD one CD-R) which do work this way.

Curiosity only, but easier than doing md5sum on all the files after
mounting the CD.

I think the issue is pretty well defined, with no pad some drives can't
read to the end, and with pad a few drives will read the pad if you just
copy all the drive can read. And use of DAO vs TAO to record makes a
difference with some burners as well.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-10 22:24:53

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>,
Gene Heskett <[email protected]> wrote:
| On Thursday 06 November 2003 17:36, Bill Davidsen wrote:

| >Are you saying that a 12x burn using a 2.4 kernel and ide-scsi
| > doesn't take the same time? Because I see ~1.7MB/s if I use
| > speed=12 with ide-scsi, and that's as expected (1x = 44100*4/1024
| > kB/s). Haven't got a 2.6 system with a burner here, but I do at my
| > other site.
|
| Mmm, thats pretty close, Bill. Maybe its something I just noted the
| last time I tried to burn a disk under ide-scsi, but I caught it
| turning the write speed down to 8x from the 12x setting. It may have
| been doing that previously without advising me or?? The old times
| were usually just short of 10 minutes.

Thanks, I hope to try this Friday, I have a system I can update to 2.6
and try it. I'll try the bttv stuff again as well. I have noticed that
the audio burns in 2.4, which don't use DMA, seem to take a lot of CPU,
but not that they run slower. More to come.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-10 22:36:46

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>,
Prakash K. Cheemplavam <[email protected]> wrote:

| So i tried the patch, but it didn't help. I cannot feel any difference.
| Here are the vstats. First for dealine and second fro patched as. Please
| keep in mind that (at the end of the stat) I fiddled a bit around with
| the kernel sources while doing the burn. Intersting would be the start
| of the erasing and start of burning. There as gives serious stuttering.

Please ignore my comment on system time, unwrapping the lines
misalligned them!
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-10 22:35:07

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>,
Prakash K. Cheemplavam <[email protected]> wrote:
| Nick Piggin wrote:
| >
| >
| > Prakash K. Cheemplavam wrote:
| >
| >> Ok, I found the bugger: It *IS* the sheduler. I tried
| >> elevator=deadline and all stuttering went away. Before I was using as.
| >> mm1 used default sheduler (as I think) and ther eno probs. So the
| >> (updated?) as sheduler in mm2 has a problem...
| >
| >
| >
| > Weird. I have a few new AS patches in mm2 so its probably them. I can't
| > see why they'd be causing you to lose interrupts though. Could you try
| > this patch please.
|
| So i tried the patch, but it didn't help. I cannot feel any difference.
| Here are the vstats. First for dealine and second fro patched as. Please
| keep in mind that (at the end of the stat) I fiddled a bit around with
| the kernel sources while doing the burn. Intersting would be the start
| of the erasing and start of burning. There as gives serious stuttering.

Looking at the system time being used I would say that this is doing
something odd. If that's using DMA then for some reason is it doing a
shitload of system calls at those times? I bet you're losing interrupts,
getting nasty mousing, and I would wonder about dropping incoming
network packets as well.

| deadline:
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 455400 52760 309808 0 0 464 430 1824 1107 13
| 6 72 8
| 0 0 0 455400 52760 309808 0 0 0 31 1264 617 2
| 0 98 0
| 1 0 0 455384 52760 309808 0 0 0 0 1441 1267 4
| 2 94 0
| 0 0 0 455376 52760 309808 0 0 0 0 1489 1957 4
| 3 93 0
| 0 0 0 455616 52800 309912 0 0 144 0 1390 1519 13
| 5 69 13
| 1 0 0 447016 52800 312712 0 0 2800 0 2040 1476 34
| 7 35 24
| 0 1 0 442072 52808 315812 0 0 3108 25 2101 5618 26
| 23 11 41
| 0 0 0 440024 52864 316076 0 0 320 8 1259 2515 26
| 5 48 20
| 1 0 0 439832 52864 316076 0 0 0 13 1328 950 4
| 3 93 0
| 0 0 0 439704 52880 316096 0 0 36 0 1438 1361 7
| 2 89 2
| 0 0 0 439704 52880 316096 0 0 0 0 1424 839 2
| 2 96 0
| 0 0 0 439656 52880 316100 0 0 4 8 1312 1008 6
| 1 92 1
| 0 0 0 439592 52880 316104 0 0 4 8 1302 803 3
| 2 95 0
| 0 0 0 439592 52880 316104 0 0 0 0 1315 929 3
| 2 95 0
| 0 0 0 439592 52880 316104 0 0 0 0 1268 679 2
| 1 97 0
| 0 1 0 430136 52888 320524 0 0 4432 0 2400 2780 14
| 10 38 38
| 0 1 0 409912 52888 340132 0 0 19604 19 6318 6255 43
| 24 0 32
| 0 1 0 384952 52888 365092 0 0 24960 0 7557 7140 37
| 27 0 37
| 0 0 0 360760 52896 389192 0 0 24108 0 7198 6982 38
| 22 3 37
| 0 0 0 360792 52896 389192 0 0 0 0 1166 540 1
| 1 98 0
| 0 0 0 360520 52908 389220 0 0 40 0 1231 1858 12
| 3 83 2
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 356168 52908 393360 0 0 40 8 1524 1444 6
| 3 91 0
| 0 0 0 356168 52908 393360 0 0 0 0 1201 595 2
| 2 96 0
| 0 0 0 356168 52908 393360 0 0 0 13 1196 601 1
| 1 98 0
| 0 0 0 356168 52908 393360 0 0 0 0 1165 541 1
| 0 99 0
| 0 0 0 356168 52908 393360 0 0 0 0 1224 604 2
| 1 97 0
| 0 0 0 356168 52908 393360 0 0 0 20 1173 531 2
| 1 97 0
| 0 0 0 356208 52908 393360 0 0 0 0 1171 484 2
| 0 98 0
| 0 0 0 356200 52908 393360 0 0 0 24 1176 524 2
| 2 96 0
| 0 0 0 356200 52908 393360 0 0 0 0 1164 486 2
| 1 97 0
| 0 0 0 356200 52908 393360 0 0 0 0 1165 474 2
| 0 98 0
| 0 0 0 356224 52908 393360 0 0 0 4 1293 654 2
| 2 96 0
| 0 0 0 356224 52908 393360 0 0 0 0 1367 923 4
| 0 96 0
| 0 0 0 356224 52908 393360 0 0 0 0 1397 1006 1
| 3 96 0
| 0 0 0 356224 52908 393360 0 0 0 0 1293 1482 9
| 2 89 0
| 0 0 0 356224 52908 393360 0 0 0 0 1227 596 1
| 0 99 0
| 1 0 0 356224 52908 393360 0 0 0 18 1171 535 2
| 2 96 0
| 0 0 0 356224 52908 393360 0 0 0 0 1263 635 1
| 0 99 0
| 0 0 0 356224 52908 393360 0 0 0 0 1409 945 2
| 4 94 0
| 1 0 0 356304 52908 393360 0 0 0 0 1366 1415 22
| 3 75 0
| 0 0 0 356288 52908 393360 0 0 0 0 1496 2760 47
| 6 47 0
| 0 0 0 356288 52908 393360 0 0 0 12 1371 1356 21
| 4 75 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 356288 52908 393360 0 0 0 0 1303 1087 12
| 1 87 0
| 0 0 0 356288 52908 393360 0 0 0 0 1458 1786 6
| 3 91 0
| 0 0 0 356288 52908 393360 0 0 0 0 1366 768 1
| 2 97 0
| 0 0 0 356224 52908 393360 0 0 0 0 1485 2345 22
| 4 74 0
| 0 0 0 356224 52908 393364 0 0 0 1 1401 1638 15
| 4 81 0
| 0 0 0 360272 52908 389264 0 0 0 9 1436 1673 5
| 3 92 0
| 0 0 0 360264 52908 389264 0 0 0 0 1428 2057 14
| 2 84 0
| 0 0 0 360264 52908 389264 0 0 0 0 1308 960 5
| 3 92 0
| 0 0 0 360264 52908 389264 0 0 0 0 1207 618 1
| 0 99 0
| 0 0 0 360264 52908 389264 0 0 0 0 1477 1346 6
| 3 91 0
| 0 0 0 360264 52908 389264 0 0 0 0 1368 754 2
| 1 97 0
| 0 0 0 360256 52908 389264 0 0 0 0 1366 974 3
| 3 94 0
| 0 0 0 360256 52908 389264 0 0 0 0 1263 694 1
| 1 98 0
| 0 0 0 359872 52936 389364 0 0 128 0 1360 1024 6
| 3 88 3
| 0 0 0 359872 52936 389364 0 0 0 3 1413 925 2
| 2 96 0
| 0 0 0 359872 52936 389364 0 0 0 0 1388 1628 20
| 3 77 0
| 0 0 0 359872 52936 389364 0 0 0 0 1360 1008 8
| 3 89 0
| 0 0 0 355712 52936 393468 0 0 4 0 1634 1414 8
| 5 87 0
| 0 0 0 355520 52936 393468 0 0 0 0 1351 1156 34
| 3 63 0
| 0 0 0 355520 52936 393468 0 0 0 0 1413 1030 7
| 2 91 0
| 0 0 0 355520 52936 393468 0 0 0 0 1234 788 18
| 2 80 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 355552 52936 393468 0 0 0 0 1457 1020 6
| 2 92 0
| 0 0 0 355552 52936 393468 0 0 0 0 1264 795 3
| 2 95 0
| 0 0 0 355552 52936 393468 0 0 0 0 1187 701 2
| 1 97 0
| 0 0 0 355552 52936 393468 0 0 0 16 1204 867 7
| 1 92 0
| 0 0 0 355592 52936 393468 0 0 0 0 1169 685 1
| 1 98 0
| 0 0 0 355584 52936 393468 0 0 0 8 1198 758 6
| 3 90 1
| 0 0 0 355584 52936 393468 0 0 0 9 1496 1115 8
| 2 90 0
| 0 0 0 355584 52936 393496 0 0 25 0 1240 905 19
| 2 78 1
| 0 0 0 355584 52936 393496 0 0 0 18 1247 1020 13
| 2 85 0
| 2 0 0 355584 52936 393496 0 0 0 0 1327 877 7
| 2 91 0
| 0 0 0 355584 52936 393496 0 0 0 2 1407 1285 31
| 3 66 0
| 0 0 0 355392 52936 393500 0 0 0 3 1396 1312 28
| 4 68 0
| 0 0 0 355392 52936 393500 0 0 0 0 1225 725 7
| 0 93 0
| 0 0 0 355392 52936 393500 0 0 0 0 1321 905 4
| 3 93 0
| 0 0 0 355392 52936 393500 0 0 0 0 1387 911 4
| 2 94 0
| 0 0 0 355384 52936 393500 0 0 0 0 1235 806 9
| 1 90 0
| 0 0 0 355400 52936 393500 0 0 0 0 1226 921 15
| 3 82 0
| 0 0 0 355400 52936 393500 0 0 0 0 1244 750 2
| 1 97 0
| 0 0 0 355400 52936 393500 0 0 0 0 1167 664 2
| 1 97 0
| 0 0 0 355400 52936 393500 0 0 0 0 1168 624 1
| 1 98 0
| 0 0 0 355256 52936 393580 0 0 44 0 1280 1762 36
| 5 55 4
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 355256 52936 393580 0 0 0 0 1474 1016 4
| 2 94 0
| 0 0 0 355256 52936 393580 0 0 0 0 1388 989 6
| 1 93 0
| 0 0 0 355248 52936 393584 0 0 0 14 1289 1482 32
| 5 63 0
| 0 0 0 355248 52936 393584 0 0 0 0 1457 948 5
| 1 94 0
| 0 0 0 355248 52936 393584 0 0 0 2 1319 1090 8
| 3 89 0
| 0 0 0 355184 52936 393584 0 0 0 0 1320 2149 18
| 3 79 0
| 0 0 0 355184 52936 393584 0 0 0 0 1333 958 2
| 2 96 0
| 0 0 0 355264 52936 393584 0 0 0 1 1199 941 3
| 1 96 0
| 0 0 0 355264 52936 393584 0 0 0 0 1200 926 2
| 2 96 0
| 0 0 0 355264 52936 393584 0 0 0 0 1194 871 3
| 2 95 0
| 0 0 0 355264 52936 393588 0 0 0 0 1203 892 2
| 1 97 0
| 0 0 0 355288 52936 393588 0 0 0 0 1197 963 2
| 2 96 0
| 0 0 0 355288 52936 393588 0 0 0 0 1199 948 3
| 1 96 0
| 0 0 0 355288 52936 393588 0 0 0 0 1198 912 2
| 1 97 0
| 0 0 0 355288 52936 393588 0 0 0 0 1206 1039 2
| 3 95 0
| 0 0 0 352888 53288 394936 0 0 1700 0 1617 1220 9
| 5 58 28
| 0 1 0 350968 53924 395484 0 0 1184 0 1485 1165 4
| 3 54 39
| 0 0 0 349624 54340 395868 0 0 800 18 1397 1041 4
| 3 53 40
| 0 0 0 347256 54744 396376 0 0 912 21 1427 1180 8
| 3 44 44
| 0 0 0 347248 54744 396376 0 0 0 0 1191 757 3
| 1 96 0
| 0 0 0 347248 54744 396376 0 0 0 0 1193 819 3
| 1 96 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 347056 54744 396376 0 0 0 0 1190 793 6
| 2 92 0
| 0 0 0 347056 54744 396376 0 0 0 5 1194 866 3
| 1 96 0
| 0 0 0 347192 54744 396376 0 0 0 0 1196 742 3
| 2 95 0
| 0 0 0 350064 54744 396376 0 0 0 0 1196 923 3
| 2 95 0
| 0 0 0 350064 54744 396376 0 0 0 0 1190 720 2
| 1 97 0
| 0 0 0 350064 54744 396376 0 0 0 0 1193 820 3
| 0 97 0
| 0 0 0 350064 54744 396376 0 0 0 0 1195 778 3
| 2 95 0
| 0 0 0 350064 54744 396376 0 0 0 0 1200 922 3
| 1 96 0
| 0 0 0 350064 54744 396376 0 0 0 0 1193 809 2
| 1 97 0
| 0 0 0 350064 54744 396376 0 0 0 0 1193 784 3
| 2 95 0
| 0 0 0 350080 54744 396376 0 0 0 0 1199 938 3
| 1 96 0
| 0 0 0 350080 54744 396376 0 0 0 16 1197 771 2
| 1 97 0
| 0 0 0 350080 54744 396376 0 0 0 0 1199 936 3
| 1 96 0
| 0 0 0 350080 54744 396376 0 0 0 0 1198 806 3
| 1 96 0
| 0 0 0 350080 54744 396376 0 0 0 0 1196 917 3
| 2 95 0
| 0 0 0 350016 54744 396472 0 0 96 0 1216 833 3
| 1 94 2
| 0 0 0 350016 54744 396472 0 0 0 41 1199 804 2
| 2 96 0
| 0 0 0 350016 54744 396472 0 0 0 0 1191 756 3
| 0 97 0
| 0 0 0 350024 54744 396472 0 0 0 0 1195 886 4
| 1 95 0
| 0 0 0 350024 54744 396472 0 0 0 0 1193 786 2
| 1 97 0
| 0 0 0 350024 54744 396472 0 0 0 0 1202 887 3
| 1 96 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 350024 54744 396472 0 0 0 0 1205 921 2
| 1 97 0
| 1 0 0 350024 54744 396472 0 0 0 0 1205 900 3
| 2 95 0
| 0 1 0 349952 54744 396524 0 0 52 0 1208 893 3
| 2 95 0
| 0 0 0 349952 54744 396524 0 0 0 0 1205 856 3
| 2 94 1
| 0 0 0 349952 54744 396524 0 0 0 0 1189 738 3
| 0 97 0
| 0 0 0 349952 54744 396524 0 0 0 13 1196 810 2
| 1 97 0
| 0 0 0 349952 54744 396524 0 0 0 0 1192 865 2
| 1 97 0
| 0 0 0 349952 54744 396524 0 0 0 0 1191 777 2
| 2 96 0
| 0 0 0 350016 54744 396524 0 0 0 0 1190 769 2
| 1 97 0
| 0 0 0 350024 54744 396524 0 0 0 0 1211 701 3
| 0 97 0
| 0 0 0 350024 54744 396524 0 0 0 12 1246 828 3
| 2 95 0
| 0 0 0 350032 54744 396524 0 0 0 0 1221 597 2
| 0 98 0
| 0 0 0 350032 54744 396524 0 0 0 0 1204 589 2
| 2 96 0
| 0 0 0 350032 54744 396524 0 0 0 0 1196 569 1
| 2 97 0
| 0 0 0 350032 54744 396524 0 0 0 0 1180 501 2
| 1 97 0
| 1 0 0 349048 54768 396532 0 0 32 2 1189 780 7
| 2 91 0
| 0 0 0 346896 55352 397016 0 0 1064 0 1428 1136 35
| 11 38 16
| 0 0 0 345744 55828 397720 0 0 1180 0 1598 1227 33
| 11 36 21
| 0 0 0 341904 56116 399056 0 0 1624 26 1659 1464 40
| 9 21 30
| 0 0 0 339856 56476 400100 0 0 1404 0 1575 1223 32
| 10 33 26
| 0 0 0 338704 56708 401360 0 0 1492 19 1549 1317 43
| 8 17 31
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 1 0 331344 56844 403132 0 0 1908 0 1666 1206 27
| 9 10 54
| 0 1 0 335176 56860 405068 0 0 1752 47 1627 1000 72
| 6 1 21
| 1 0 0 333192 57108 405888 0 0 1068 0 1735 1386 34
| 11 21 35
| 1 0 0 331784 57236 406968 0 0 1208 0 1773 1541 39
| 8 8 44
| 2 0 0 324168 57352 412360 0 0 3212 29 2178 1946 31
| 13 10 47
| 0 0 0 325320 57444 412868 0 0 600 0 1670 1472 34
| 12 12 42
| 1 0 0 324096 57524 409928 0 0 1240 0 1575 1444 52
| 13 7 28
| 2 0 0 317248 57524 419300 0 0 3980 32 2181 2554 51
| 12 0 37
| 4 0 0 311936 57524 419948 0 0 0 32 1197 1105 87
| 13 0 0
| 2 0 0 312320 57524 425304 0 0 0 31 1174 3964 86
| 14 0 0
| 2 0 0 304512 57524 431520 0 0 0 32 1226 1725 91
| 9 0 0
| 1 0 0 298616 57544 437856 0 0 340 53 3619 820 76
| 9 4 11
| 3 0 0 290112 57544 446952 0 0 44 54 3552 797 87
| 11 0 2
| 0 0 0 291072 57544 446952 0 0 0 0 3505 573 1
| 3 96 0
| 0 1 0 291008 57608 446952 0 0 64 87 1448 555 1
| 1 33 65
| 0 1 0 290752 57864 446952 0 0 256 12 1191 777 3
| 2 0 95
| 1 1 0 289344 59272 446952 0 0 1408 9 3442 971 6
| 3 0 91
| 0 1 0 287040 61584 446952 0 0 2307 1 1441 1542 10
| 4 0 86
| 0 1 0 284608 64016 446952 0 0 2432 0 1187 1343 10
| 1 0 89
| 0 1 0 282176 66448 446952 0 0 2432 27 1205 1490 10
| 3 0 87
| 0 1 0 279760 68880 446952 0 0 2432 0 1189 1426 9
| 3 0 88
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 1 0 277328 71312 446952 0 0 2432 34 1200 1554 9
| 3 0 88
| 0 1 0 275024 73616 446952 0 0 2304 9 1191 1492 9
| 3 0 88
| 0 1 0 272528 76048 446952 0 0 2432 12 1197 1544 9
| 2 0 89
| 0 1 0 270120 78480 446952 0 0 2432 16 1194 1517 9
| 4 0 87
| 0 1 0 267624 80912 446956 0 0 2433 0 1190 1327 9
| 2 0 89
| 2 1 0 265192 83344 446956 0 0 2432 34 1199 1400 9
| 3 0 88
| 0 1 0 260648 85716 448944 0 0 2316 4 1208 1493 8
| 4 0 88
| 0 1 0 258248 88148 448944 0 0 2432 0 1188 1409 10
| 1 0 89
| 1 1 0 257672 90504 446984 0 0 2464 2016 1696 1522 9
| 7 0 84
| 0 1 0 255240 92936 446984 0 0 2432 0 1190 1434 8
| 4 0 88
| 2 1 0 252744 95376 446984 0 0 2435 106 1227 1426 9
| 4 0 87
| 0 1 0 250456 97680 446984 0 0 2304 0 1183 1368 9
| 2 0 89
| 0 1 0 248024 100112 446984 0 0 2432 0 1191 1343 10
| 3 0 87
| 0 1 0 245592 102544 446984 0 0 2432 2543 1829 1640 9
| 5 0 86
| 0 1 0 243160 104976 446984 0 0 2432 0 1192 1452 8
| 3 0 89
| 0 1 0 240728 107408 446984 0 0 2432 0 1190 1460 9
| 3 0 88
| 0 1 0 238360 109712 446988 0 0 2305 0 1188 1380 8
| 2 0 90
| 0 1 0 235936 112144 446988 0 0 2432 0 1184 1290 9
| 2 0 89
| 0 1 0 233440 114580 446988 0 0 2433 11450 4041 1612 9
| 12 0 79
| 0 1 0 230816 117012 446996 0 0 2435 0 1192 1413 9
| 3 0 88
| 1 1 0 228312 119444 446996 0 0 2432 0 1198 1399 8
| 3 0 89
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 1 0 226008 121748 447000 0 0 2304 0 1189 1355 9
| 3 0 88
| 0 1 0 223576 124180 447000 0 0 2432 0 1192 1514 9
| 2 0 89
| 0 2 0 221072 126612 447000 0 0 2432 15160 4843 1727 10
| 15 0 75
| 0 1 0 218576 129044 447000 0 0 2432 6200 2871 1468 10
| 7 0 83
| 0 0 0 290808 57556 447048 0 0 1628 0 1214 1432 8
| 4 23 64
| 0 0 0 290808 57556 447048 0 0 0 0 1167 640 2
| 2 96 0
| 0 0 0 290808 57556 447048 0 0 0 0 1175 715 2
| 0 98 0
| 0 0 0 290808 57556 447048 0 0 0 71 1190 650 2
| 1 97 0
| 0 0 0 290808 57556 447048 0 0 0 0 1171 649 2
| 2 96 0
| 0 0 0 290808 57556 447048 0 0 0 0 1166 550 1
| 1 98 0
| 0 0 0 291032 57560 447048 0 0 1 0 1169 664 2
| 1 96 1
| 0 0 0 291032 57560 447048 0 0 0 0 1281 665 1
| 1 98 0
| 0 0 0 291032 57560 447048 0 0 0 25 1295 769 2
| 2 96 0
| 1 0 0 291032 57560 447048 0 0 0 0 1344 758 2
| 1 97 0
| 0 0 0 291032 57560 447048 0 0 0 0 1318 853 3
| 2 95 0
|
| patched as:
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 805128 13404 113496 0 0 1708 37 1653 1043 12
| 20 40 28
| 0 0 0 805112 13404 113496 0 0 0 0 1181 276 1
| 0 99 0
| 0 0 0 805112 13404 113496 0 0 0 9 1386 534 1
| 0 99 0
| 0 0 0 804984 13404 113496 0 0 0 0 1254 968 8
| 2 90 0
| 0 0 0 804656 13412 113508 0 0 20 73 1199 638 6
| 1 92 1
| 0 0 0 804584 13412 113512 0 0 4 0 1220 456 2
| 2 95 1
| 0 0 0 804584 13412 113512 0 0 0 0 1262 428 1
| 1 98 0
| 0 1 0 797352 13420 116992 0 0 3488 0 1954 1841 13
| 4 51 32
| 0 1 0 777272 13420 135368 0 0 18376 0 5864 6052 42
| 21 0 37
| 0 1 0 753080 13420 159560 0 0 24192 138 7435 7471 33
| 30 0 36
| 2 1 0 728120 13420 184512 0 0 24952 0 7644 7337 34
| 29 0 37
| 0 0 0 725616 13440 186668 0 0 2176 0 1736 2148 16
| 6 73 6
| 2 0 0 721328 13440 190768 0 0 0 0 1299 916 5
| 3 92 0
| 1 0 0 721328 13440 190776 0 0 0 0 400 542 13
| 56 31 0
| 1 0 0 721264 13440 190776 0 0 0 66 502 557 5
| 38 57 0
| 0 0 0 721264 13440 190776 0 0 0 0 1130 522 3
| 4 94 0
| 0 0 0 721296 13440 190776 0 0 0 12 1465 595 1
| 0 99 0
| 0 0 0 721296 13440 190776 0 0 0 0 1459 599 1
| 1 98 0
| 0 0 0 721296 13440 190776 0 0 0 0 1332 426 1
| 1 98 0
| 0 0 0 721296 13448 190776 0 0 8 63 1426 533 0
| 1 99 0
| 0 0 0 721328 13448 190776 0 0 0 0 1470 574 1
| 1 98 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 721328 13448 190796 0 0 20 0 1419 847 3
| 1 96 0
| 0 0 0 721328 13448 190796 0 0 0 0 1246 526 0
| 1 99 0
| 0 0 0 721328 13448 190796 0 0 0 0 1379 1142 2
| 2 96 0
| 0 0 0 721216 13448 190796 0 0 0 73 1305 789 6
| 2 92 0
| 0 0 0 721208 13448 190796 0 0 0 0 1417 1021 8
| 2 90 0
| 0 0 0 721208 13448 190796 0 0 0 0 1382 496 1
| 0 99 0
| 0 0 0 721208 13448 190796 0 0 0 0 1382 493 1
| 1 98 0
| 0 0 0 721232 13448 190796 0 0 0 0 1446 1455 7
| 2 91 0
| 0 0 0 721232 13448 190796 0 0 0 40 1358 509 2
| 1 97 0
| 0 0 0 721232 13448 190800 0 0 4 0 1356 548 2
| 1 97 0
| 1 0 0 714872 13448 193180 0 0 2245 0 1818 1299 51
| 6 19 24
| 2 0 0 706408 13936 195444 0 0 2657 0 3223 2994 44
| 10 2 45
| 0 0 0 705704 13944 198540 0 0 3103 0 4273 1826 24
| 8 28 39
| 0 0 0 705696 13944 198540 0 0 0 33 2605 382 1
| 2 97 0
| 0 0 0 705696 13944 198540 0 0 0 0 1091 452 2
| 1 97 0
| 0 1 0 703072 13944 201044 0 0 2502 10 3043 2099 17
| 6 33 44
| 0 1 0 694368 13944 207968 0 0 6921 6 4588 5447 13
| 10 0 77
| 0 0 0 690336 13948 211476 0 0 3499 0 3548 3837 7
| 7 4 82
| 1 0 0 690336 13948 211480 0 0 1 3 3540 568 3
| 1 96 0
| 0 0 0 694208 13948 207540 0 0 156 11 3219 546 10
| 4 74 12
| 0 0 0 694208 13948 207540 0 0 0 0 2236 323 2
| 1 97 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 694104 13948 207540 0 0 0 0 1222 586 20
| 2 78 0
| 0 0 0 693720 13948 207864 0 0 324 1 1242 552 28
| 3 65 4
| 0 0 0 693720 13948 207864 0 0 0 16 1197 329 2
| 0 98 0
| 0 0 0 693720 13948 207864 0 0 0 0 1252 500 5
| 2 93 0
| 0 0 0 693720 13948 207868 0 0 0 0 1402 550 4
| 2 94 0
| 0 0 0 693592 13948 207880 0 0 9 4 1172 519 16
| 1 82 1
| 1 0 0 693600 13948 207880 0 0 0 0 1449 1654 31
| 5 64 0
| 0 0 0 693600 13948 207880 0 0 0 44 1245 528 3
| 1 96 0
| 0 0 0 693600 13948 207880 0 0 0 0 1080 151 0
| 0 100 0
| 0 0 0 693600 13948 207880 0 0 0 0 1438 588 1
| 1 98 0
| 0 0 0 693616 13948 207880 0 0 0 0 1446 648 1
| 0 99 0
| 1 0 0 689584 13948 211984 0 0 4 0 525 587 11
| 32 54 4
| 1 0 0 689592 13948 211984 0 0 0 28 400 556 14
| 57 29 0
| 0 0 0 689400 13948 211984 0 0 0 0 754 629 2
| 16 81 0
| 0 0 0 689400 13948 211984 0 0 0 0 1452 703 2
| 2 96 0
| 1 0 0 689400 13948 211988 0 0 0 0 1091 780 1
| 4 94 0
| 0 0 0 689400 13948 211988 0 0 0 0 1437 842 2
| 0 98 0
| 0 0 0 689400 13948 211988 0 0 0 0 1450 796 0
| 2 98 0
| 0 0 0 689400 13948 211988 0 0 0 0 1458 753 1
| 1 98 0
| 0 0 0 689400 13948 211988 0 0 0 0 1465 762 1
| 1 98 0
| 0 0 0 689400 13948 211988 0 0 0 0 1446 752 1
| 1 98 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 689400 13948 211988 0 0 0 0 1251 493 0
| 0 100 0
| 0 0 0 689416 13948 211988 0 0 0 5 1463 752 1
| 1 98 0
| 0 0 0 689408 13948 211988 0 0 0 0 1467 716 2
| 2 96 0
| 0 0 0 689408 13948 211988 0 0 0 0 1376 613 0
| 1 99 0
| 0 0 0 689408 13948 211988 0 0 0 0 1451 771 1
| 0 99 0
| 0 0 0 689408 13948 211988 0 0 0 0 1452 827 1
| 2 97 0
| 0 0 0 689408 13948 211988 0 0 0 21 1406 813 1
| 0 99 0
| 0 0 0 689408 13948 211992 0 0 0 0 963 944 7
| 10 83 0
| 0 0 0 689408 13948 211992 0 0 0 0 1475 786 1
| 0 99 0
| 0 0 0 689408 13948 211992 0 0 0 0 1448 875 1
| 2 97 0
| 0 0 0 689408 13948 211992 0 0 0 0 1410 918 1
| 0 99 0
| 0 0 0 689408 13948 211992 0 0 0 0 1453 796 0
| 2 98 0
| 0 0 0 689408 13948 211992 0 0 0 0 1430 765 1
| 0 99 0
| 1 0 0 684672 13948 211992 0 0 0 0 1471 1193 7
| 4 89 0
| 0 0 0 689216 13948 211992 0 0 0 0 1314 731 3
| 1 96 0
| 0 0 0 689216 13948 211992 0 0 0 4 1448 722 3
| 1 96 0
| 0 0 0 689200 13948 211992 0 0 0 0 1424 1127 19
| 3 78 0
| 0 0 0 689200 13948 211992 0 0 0 0 1384 622 3
| 1 96 0
| 0 0 0 689200 13948 211992 0 0 0 0 1450 765 6
| 2 92 0
| 0 0 0 689200 13948 211992 0 0 0 0 1355 595 2
| 1 97 0
| 0 0 0 689200 13948 211992 0 0 0 16 1462 637 3
| 1 96 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 689224 13948 211992 0 0 0 0 1355 599 4
| 2 94 0
| 0 0 0 689208 13948 211992 0 0 0 1 1437 689 5
| 1 94 0
| 1 0 0 689208 13948 211992 0 0 0 0 1155 742 5
| 6 88 0
| 2 0 0 685096 13948 211992 0 0 0 0 938 869 17
| 6 77 0
| 2 0 0 689192 13948 211992 0 0 0 16 947 1175 25
| 8 67 0
| 0 0 0 689192 13948 211992 0 0 0 0 1012 758 5
| 6 89 0
| 0 0 0 689312 13948 211992 0 0 0 0 948 1311 33
| 11 56 0
| 1 0 0 689312 13948 211992 0 0 0 0 954 772 9
| 8 83 0
| 0 0 0 689336 13948 211992 0 0 0 0 744 470 3
| 5 92 0
| 0 0 0 689320 13948 211992 0 0 0 0 885 1171 30
| 9 61 0
| 1 0 0 689320 13948 211996 0 0 0 0 883 1425 22
| 6 71 0
| 0 0 0 689312 13948 211996 0 0 0 0 998 789 5
| 9 86 0
| 0 0 0 689312 13948 211996 0 0 0 0 915 684 2
| 5 94 0
| 1 0 0 689312 13948 211996 0 0 0 0 946 1206 6
| 8 86 0
| 0 0 0 689312 13948 211996 0 0 0 5 951 628 3
| 6 91 0
| 0 0 0 689312 13948 211996 0 0 0 0 921 635 3
| 6 90 0
| 1 0 0 687280 13948 211996 0 0 0 0 812 2274 36
| 11 53 0
| 0 0 0 687280 13948 211996 0 0 0 0 909 635 5
| 5 90 0
| 0 0 0 687280 13948 211996 0 0 0 0 752 411 0
| 6 94 0
| 1 0 0 687024 13956 212056 0 0 68 35 803 623 3
| 5 89 3
| 0 0 0 687024 13956 212056 0 0 0 0 743 437 2
| 6 92 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 686688 13964 212108 0 0 56 32 764 693 5
| 9 83 3
| 1 0 0 686688 13964 212108 0 0 0 0 763 460 3
| 5 92 0
| 0 0 0 686688 13964 212108 0 0 0 0 749 577 2
| 5 94 0
| 0 0 0 686688 13964 212108 0 0 0 1 763 370 1
| 6 93 0
| 1 0 0 686432 13996 212116 0 0 40 0 759 643 5
| 6 88 2
| 0 0 0 686368 14000 212196 0 0 84 0 783 561 0
| 6 92 2
| 2 0 0 686368 14000 212196 0 0 0 13 757 468 3
| 6 91 0
| 1 0 0 686408 14000 212196 0 0 0 0 971 646 2
| 6 92 0
| 1 0 0 686408 14000 212196 0 0 0 0 1016 692 3
| 5 92 0
| 1 0 0 686408 14000 212196 0 0 0 0 1063 929 3
| 7 90 0
| 1 0 0 686408 14000 212196 0 0 0 24 983 719 3
| 6 91 0
| 0 0 0 686416 14000 212196 0 0 0 21 1033 970 2
| 6 92 0
| 0 0 0 686416 14000 212196 0 0 0 0 901 599 1
| 7 91 0
| 1 0 0 686416 14000 212196 0 0 0 20 735 469 3
| 5 92 0
| 0 0 0 686416 14000 212196 0 0 0 0 695 404 2
| 5 93 0
| 0 0 0 686416 14000 212196 0 0 0 0 684 533 2
| 10 88 0
| 1 0 0 686416 14000 212196 0 0 0 13 744 568 3
| 5 92 0
| 0 0 0 686416 14000 212196 0 0 0 0 719 510 2
| 6 92 0
| 0 0 0 686416 14000 212196 0 0 0 12 726 427 2
| 5 94 0
| 3 0 0 686416 14000 212196 0 0 0 0 721 536 5
| 5 90 0
| 0 0 0 686408 14000 212196 0 0 0 0 735 509 3
| 8 89 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 686408 14000 212196 0 0 0 0 715 516 3
| 5 92 0
| 1 0 0 686408 14000 212196 0 0 0 0 729 534 2
| 5 93 0
| 0 0 0 686400 14000 212196 0 0 0 12 743 619 3
| 5 92 0
| 0 0 0 686400 14000 212196 0 0 0 0 767 494 2
| 6 92 0
| 1 0 0 686400 14000 212196 0 0 0 0 747 547 3
| 6 91 0
| 0 0 0 686016 14024 212600 0 0 428 0 819 423 2
| 7 84 8
| 0 0 0 686016 14024 212600 0 0 0 0 692 338 2
| 5 93 0
| 0 0 0 686016 14024 212600 0 0 0 18 665 456 2
| 5 93 0
| 0 0 0 686016 14024 212600 0 0 0 0 1079 133 0
| 0 100 0
| 0 0 0 686016 14024 212600 0 0 0 0 1079 146 0
| 1 99 0
| 0 0 0 686016 14024 212600 0 0 0 0 1078 136 0
| 1 99 0
| 0 0 0 686016 14024 212600 0 0 0 0 1089 194 0
| 0 100 0
| 0 0 0 686016 14024 212600 0 0 0 26 1115 276 0
| 0 100 0
| 0 0 0 686016 14024 212600 0 0 0 0 1098 258 0
| 0 100 0
| 0 0 0 686088 14024 212600 0 0 0 0 1083 238 0
| 0 100 0
| 0 0 0 686088 14024 212600 0 0 0 0 1085 215 0
| 0 100 0
| 0 0 0 686088 14024 212604 0 0 0 0 1084 188 1
| 2 97 0
| 0 0 0 686088 14024 212604 0 0 0 3 1092 435 1
| 0 99 0
| 0 0 0 686096 14024 212604 0 0 0 8 1088 232 1
| 0 99 0
| 0 0 0 686096 14032 212604 0 0 8 0 1086 247 0
| 1 99 0
| 0 0 0 686096 14036 212608 0 0 4 0 934 327 1
| 1 98 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 0 0 686096 14036 212604 0 0 0 0 1083 171 0
| 1 99 0
| 0 0 0 686096 14036 212604 0 0 0 0 1081 184 0
| 0 100 0
| 0 0 0 690384 14036 208504 0 0 0 9 1077 347 2
| 1 97 0
| 0 0 0 690384 14044 208504 0 0 8 0 1088 261 1
| 1 98 0
| 3 0 0 690384 14044 208504 0 0 0 0 1077 700 64
| 8 28 0
| 3 0 0 690384 14048 208504 0 0 4 0 1085 9681 86
| 14 0 0
| 1 0 0 690384 14048 208504 0 0 0 0 1086 15947 83
| 17 0 0
| 0 0 0 690384 14048 208504 0 0 0 8 1096 3238 16
| 5 79 0
| 0 0 0 690320 14048 208504 0 0 0 0 1084 189 1
| 1 98 0
| 0 1 0 690256 14112 208504 0 0 64 0 1097 104 0
| 0 44 56
| 0 1 0 690000 14368 208504 0 0 256 0 1080 205 1
| 0 0 99
| 0 1 0 688464 15904 208504 0 0 1536 0 1092 671 4
| 2 0 94
| 0 1 0 686160 18208 208504 0 0 2304 0 1103 1067 8
| 2 0 90
| 0 1 0 683744 20640 208504 0 0 2432 0 1099 1028 8
| 2 0 90
| 1 1 0 681312 23072 208504 0 0 2432 0 1097 900 8
| 1 0 91
| 0 1 0 678936 25384 208504 0 0 2312 0 1101 947 7
| 2 0 91
| 0 1 0 676504 27816 208504 0 0 2432 5 1101 1000 8
| 2 0 90
| 0 1 0 674080 30248 208504 0 0 2432 0 1098 906 7
| 1 0 92
| 0 1 0 671576 32680 208504 0 0 2432 0 1097 1052 8
| 2 0 90
| 0 1 0 669144 35112 208504 0 0 2432 0 1097 950 8
| 3 0 89
| 0 1 0 666776 37416 208504 0 0 2304 0 1097 941 7
| 1 0 92
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 0 1 0 664352 39848 208504 0 0 2432 8 1099 995 8
| 1 0 91
| 0 1 0 661856 42280 208504 0 0 2432 0 1098 967 7
| 3 0 90
| 0 1 0 659424 44712 208504 0 0 2432 0 1107 1121 8
| 3 0 89
| 2 1 0 654728 47768 209484 0 0 4036 0 1510 1343 15
| 5 0 80
| 0 1 0 651144 50944 209484 0 0 3176 0 1530 1457 12
| 5 0 83
| 0 2 0 647040 54192 209600 0 0 3364 24 1706 1784 18
| 4 0 78
| 0 1 0 641688 57324 210132 0 0 3664 0 1620 1790 31
| 9 0 60
| 1 1 0 637784 60136 211096 0 0 3776 51 1641 1849 40
| 9 0 51
| 1 1 0 632600 62912 212180 0 0 3860 0 1831 1908 42
| 10 0 48
| 0 2 0 628376 65636 213080 0 0 3624 17 1807 1972 38
| 7 0 55
| 1 2 0 624536 68364 214316 0 0 3964 9 1544 1808 45
| 8 0 47
| 0 3 0 618840 71088 215676 0 0 4084 0 1497 1439 32
| 7 0 61
| 1 1 0 601936 73520 217388 0 0 4144 0 1562 1403 62
| 6 0 32
| 1 1 0 611472 76204 218840 0 0 3924 0 1470 1354 44
| 10 0 47
| 1 1 0 607952 78712 219720 0 0 3388 0 1370 1466 38
| 8 0 54
| 1 1 0 597520 81304 223632 0 0 5292 47 1832 1759 32
| 10 0 58
| 2 1 0 595664 83876 225792 0 0 3648 0 1427 1469 40
| 7 0 53
| 1 1 0 591952 86416 226740 0 0 3488 0 1410 1560 45
| 9 0 46
| 1 2 0 585608 88928 228528 0 0 4256 64 1566 1658 47
| 14 0 40
| 1 1 0 570632 91232 237320 0 0 5100 32 1810 2002 64
| 12 0 24
| 1 0 0 633720 19744 248936 0 0 1624 58 1125 1463 85
| 15 0 0
| procs -----------memory---------- ---swap-- -----io---- --system--
| ----cpu----
| r b swpd free buff cache si so bi bo in cs us
| sy id wa
| 1 0 0 630008 19764 254900 0 0 348 37 1191 1059 79
| 6 4 11
| 1 0 0 628728 19764 256404 0 0 0 0 1154 315 99
| 1 0 0
| 0 0 0 622192 19772 264368 0 0 52 32 1458 765 4
| 8 87 1
| 0 0 0 622192 19772 264368 0 0 0 0 1330 551 1
| 1 98 0
|
|
| Prakash
|
| -
| 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/
|

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-11 04:58:42

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>,
Linus Torvalds <[email protected]> wrote:
|
| On Mon, 10 Nov 2003, Bill Davidsen wrote:
| >
| > > - For all those devices you claim exists, show me the patches. Nobody
| > > broke ide-scsi on purpose - but the fact is that nobody also ever came
| > > forward and _fixed_ it.
| >
| > And if they had they would have sent the patches to the maintainer, only
| > there doesn't seem to be one...
|
| Don't be silly. This is what linux-kernel is about.
|
| Feel free to send out patches to be tested.
|
| I'll be waiting for the people out there to test them. But so far I
| haven't heard anything but misplaced whining from you.

You musta' missed the post from the user with the MO that requires
ide-scsi... And I'm sure you didn't see Alan's post on SATA devices, and
won't see any other posts in favor of providing the same functionality
as 2.4. Point closed.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-11 05:41:09

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On 11 Nov 2003, bill davidsen wrote:
> Linus Torvalds <[email protected]> wrote:
> |
> | Feel free to send out patches to be tested.
> |
> | I'll be waiting for the people out there to test them. But so far I
> | haven't heard anything but misplaced whining from you.
>
> You musta' missed the post from the user with the MO that requires
> ide-scsi... And I'm sure you didn't see Alan's post on SATA devices, and
> won't see any other posts in favor of providing the same functionality
> as 2.4. Point closed.

You can't read. Point closed.

NOBODY IS SENDING ME PATCHES.

What part of "open source" do you not understand?

SATA devices work fine. They have all the SCSI infrastructure working for
them. They'll "just work", even though I fervently hope that we can move
them over to the block device layer later to make them work more
efficiently.

As per the MO device that wants ide-scsi, send out patches to the kernel
mailing list, and maybe the person can test it. I certainly can't test it.

My point is that YOU ARE BARKING UP THE WRONG TREE. It does not help to
complain to me - since I don't even have the hardware to test anything
with. I fixed the IDE CD burning issue. That I had hardware for, and knew
how to fix properly.

Now it's your turn. Instead of wasting my time complaining, how about you
put up or shut up? Show me the code. THEN post it. Until you do, there's
no point to your mails.

Linus

2003-11-11 14:47:12

by Zwane Mwaikambo

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Mon, 10 Nov 2003, bill davidsen wrote:

> Looking at the system time being used I would say that this is doing
> something odd. If that's using DMA then for some reason is it doing a
> shitload of system calls at those times? I bet you're losing interrupts,
> getting nasty mousing, and I would wonder about dropping incoming
> network packets as well.
>
> | deadline:
> | procs -----------memory---------- ---swap-- -----io---- --system--
> | ----cpu----
> | r b swpd free buff cache si so bi bo in cs us
> | sy id wa
> | 0 0 0 455400 52760 309808 0 0 464 430 1824 1107 13
> | 6 72 8
> | 0 0 0 455400 52760 309808 0 0 0 31 1264 617 2
> | 0 98 0
> | 1 0 0 455384 52760 309808 0 0 0 0 1441 1267 4
> | 2 94 0
> | 0 0 0 455376 52760 309808 0 0 0 0 1489 1957 4
> | 3 93 0
> | 0 0 0 455616 52800 309912 0 0 144 0 1390 1519 13
> | 5 69 13
> | 1 0 0 447016 52800 312712 0 0 2800 0 2040 1476 34
> | 7 35 24

procs -----------memory---------- ---swap-- -----io---- --system------cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 455400 52760 309808 0 0 464 430 1824 1107 13 6 72 8
0 0 0 455400 52760 309808 0 0 0 31 1264 617 2 0 98 0
1 0 0 455384 52760 309808 0 0 0 0 1441 1267 4 2 94 0

That looks like fairly low system time and generally idle system to me,
and the interrupt rate isn't high at all.

2003-11-11 15:42:03

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>,
Zwane Mwaikambo <[email protected]> wrote:
| On Mon, 10 Nov 2003, bill davidsen wrote:
|
| > Looking at the system time being used I would say that this is doing
| > something odd. If that's using DMA then for some reason is it doing a
| > shitload of system calls at those times? I bet you're losing interrupts,
| > getting nasty mousing, and I would wonder about dropping incoming
| > network packets as well.

| That looks like fairly low system time and generally idle system to me,
| and the interrupt rate isn't high at all.

Yes, I added a followup a few minutes later noting that I had a
line-wrap problem and misread the data. I haven't seen that post, but
that's what happened.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-11 16:43:59

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 11 Nov 2003 06:50:07 +0100, you wrote in linux.kernel:

> As per the MO device that wants ide-scsi, send out patches to the kernel
> mailing list, and maybe the person can test it. I certainly can't test it.

Well, that person is me and I tried making it work with ide-cd. Got read
support to work, submitted to Jens, you have it in your kernel. No luck
with write support. I could get it to mount read-write and data actually
made it to disk, but umount lead to a BUG_ON. Details in:

http://www.ussg.iu.edu/hypermail/linux/kernel/0305.0/1307.html
(the patch in there won't apply due to minor renaming of flags and the
fact that the read support part is already in your tree)

So I'm not only complaining. ;)

--
Ciao,
Pascal

2003-11-11 17:00:27

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 11 Nov 2003, Pascal Schmidt wrote:
>
> Well, that person is me and I tried making it work with ide-cd. Got read
> support to work, submitted to Jens, you have it in your kernel. No luck
> with write support. I could get it to mount read-write and data actually
> made it to disk, but umount lead to a BUG_ON.

Hmm.. That looks "impossible", so it's most likely a serious bh corruption
issue. But what corrupts it is hard to guess at - the actual trace to that
point has nothing to do with the MO drive itself, so you've either hit a
generic ext2 bug (hey, it's possible, I guess, but sounds very unlikely),
or the ide-scsi driver has corrupted memory.

The latter is obviously the more likely schenario, but it does require
somebody with the MO device to actually try to figure out how the
corruption occurs.. Probably with a big printk buffer and a lot of
printk's..

Linus

2003-11-11 17:50:28

by Diego Calleja

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

El Mon, 10 Nov 2003 21:40:58 -0800 (PST) Linus Torvalds <[email protected]>
escribi?:

> Now it's your turn. Instead of wasting my time complaining, how about you
> put up or shut up? Show me the code. THEN post it. Until you do, there's
> no point to your mails.

Until then, I'd suggest this patch to avoid more complains about this:

diff -puN drivers/ide/Kconfig~idescsi-broken drivers/ide/Kconfig
--- tim/drivers/ide/Kconfig~idescsi-broken 2003-11-11 18:35:23.000000000 +0100
+++ tim-diego/drivers/ide/Kconfig 2003-11-11 18:36:07.000000000 +0100
@@ -247,7 +247,7 @@ config BLK_DEV_IDEFLOPPY

config BLK_DEV_IDESCSI
tristate "SCSI emulation support"
- depends on SCSI
+ depends on SCSI && BROKEN
---help---
This will provide SCSI host adapter emulation for IDE ATAPI
devices, and will allow you to use a SCSI device driver instead of
a native

_

2003-11-11 18:16:05

by Diego Calleja

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

El Tue, 11 Nov 2003 18:49:19 +0100 Diego Calleja Garc?a <[email protected]> escribi?:

> Until then, I'd suggest this patch to avoid more complains about this:

Sorry, the previous one was sent with a broken MUA

diff -puN drivers/ide/Kconfig~idescsi-broken drivers/ide/Kconfig
--- tim/drivers/ide/Kconfig~idescsi-broken 2003-11-11 18:35:23.000000000 +0100
+++ tim-diego/drivers/ide/Kconfig 2003-11-11 18:36:07.000000000 +0100
@@ -247,7 +247,7 @@ config BLK_DEV_IDEFLOPPY

config BLK_DEV_IDESCSI
tristate "SCSI emulation support"
- depends on SCSI
+ depends on SCSI && BROKEN
---help---
This will provide SCSI host adapter emulation for IDE ATAPI devices,
and will allow you to use a SCSI device driver instead of a native

_

2003-11-11 19:41:36

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 11 Nov 2003, Linus Torvalds wrote:

> Can you try just writing to the thing as a raw device, ie simply doing
> something like
[...]

Will do and report on what I find.

>> I didn't see problems with using ide-scsi/sd for that drive in 2.5.7x,
>> by the way, so I'm not so sure ide-scsi is really broken for that
>> purpose.
> It would be interesting to hear if ide-scsi works.

I'll check on that, too.

--
Ciao,
Pascal

2003-11-11 21:41:56

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 11 Nov 2003, Linus Torvalds wrote:

> # Write it out
> dd if=testfile of=/dev/hdc bs=4096 count=1

dd behaves strangly on the MO drive. I've tried with 2.6.0-test9 and
the patch appended to the end of this mail.

# dd if=testfile of=/dev/hde bs=4096 count=1
dd: writing `/dev/hde': no space left on device
1+0 records in
0+0 records out

# dd if=/dev/hde of=mofile bs=4096 count=1
0+0 records in
0+0 records out

Mounting the disc read-only works, however, and I can read all the data
on it without problems.

Mounting read-write yields the same old problem:

# mount -t ext2 /dev/hde /mnt/mo
# echo "bar" > /mnt/mo/foo
# umount /mnt/mo

kernel BUG at fs/buffer.c:2658!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<c014e11c>] Not tainted
EFLAGS: 00010202
EIP is at submit_bh+0x15c/0x180
eax: 00000010 ebx: e5365360 ecx: c0332b74 edx: e7fe2a40
esi: 00000001 edi: c0334ca0 ebp: e5ad9ecc esp: e5ad9ebc
ds: 007b es: 007b ss: 0068
Process umount (pid: 918, threadinfo=e5ad8000 task=e6134d00)
Stack: c0334ca0 e5ad9ed8 e5c2d400 e5365360 e5ad9eec c014e22e 00000001 e5365360
c014c0d3 c15e6708 e5c2d400 e72d3b80 e5ad9f00 c0191faf e5365360 e72d3b80
e6f1e40c e5ad9f20 c0190fdd e72d3b80 e5c2d400 e72d3b80 e72d3b80 e72d3bcc
Call Trace:
[<c014e22e>] sync_dirty_buffer+0x5e/0xc0
[<c014c0d3>] mark_buffer_dirty+0x33/0x50
[<c0191faf>] ext2_sync_super+0x4f/0x60
[<c0190fdd>] ext2_put_super+0x9d/0xb0
[<c014f858>] generic_shutdown_super+0xf8/0x110
[<c01500fd>] kill_block_super+0x1d/0x50
[<c014f6c4>] deactivate_super+0x44/0x70
[<c016269c>] sys_umount+0x3c/0xa0
[<c0162719>] sys_oldumount+0x19/0x20
[<c010addf>] syscall_call+0x7/0xb

Code: 0f 0b 62 0a a6 c7 2f c0 e9 c1 fe ff ff 0f 0b 61 0a a6 c7 2f

After that, the MO is dead, "reboot" doesn't do anything, and all that
I can do is press the reset button or use Alt-SysRq-B. Trying to sync
with SysRq-S or remount r/o with SysRq-U don't work anymore at this
point.

Rebooted into 2.4/ide-scsi and ran e2fsck. The directory entry made it
to disk, nothing else.

Rebooted into 2.6/ide-scsi. Mounting read-only once again works
flawlessly. Mounted read-write, then wrote a small file as above. Tried
to umount. umount sat there in D state for about half a minute, then
ide-scsi aborted the operation and an ATAPI reset took place. After that,
umount completed. Again mounting it read-only confirmed that the file made
it to disk correctly.

Then I tried "e2fsck -f /dev/sda". This hung the machine almost
immediately. Even Alt-SysRq stopped working. Going back to 2.4 and
running e2fsck there shows that the filesystem on the MO is clean, and
a forced fsck doesn't find anything suspicious.

>> I didn't see problems with using ide-scsi/sd for that drive in 2.5.7x,
>> by the way, so I'm not so sure ide-scsi is really broken for that
>> purpose.
> It would be interesting to hear if ide-scsi works.

See above, it doesn't.

--- drivers/cdrom/cdrom.c.orig Tue Nov 11 22:21:25 2003
+++ drivers/cdrom/cdrom.c Tue Nov 11 21:49:19 2003
@@ -426,7 +426,8 @@
if ((fp->f_flags & O_NONBLOCK) && (cdi->options & CDO_USE_FFLAGS))
ret = cdi->ops->open(cdi, 1);
else {
- if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
+ if ((fp->f_mode & FMODE_WRITE) &&
+ !(CDROM_CAN(CDC_DVD_RAM) || CDROM_CAN(CDC_MO_DRIVE)))
return -EROFS;

ret = open_for_data(cdi);
--- drivers/ide/ide-cd.c.orig Tue Nov 11 22:21:38 2003
+++ drivers/ide/ide-cd.c Tue Nov 11 21:26:11 2003
@@ -3211,7 +3211,8 @@

nslots = ide_cdrom_probe_capabilities (drive);

- if (CDROM_CONFIG_FLAGS(drive)->dvd_ram)
+ if (CDROM_CONFIG_FLAGS(drive)->dvd_ram
+ || CDROM_CONFIG_FLAGS(drive)->mo_drive)
set_disk_ro(drive->disk, 0);

#if 0

--
Ciao,
Pascal

2003-11-11 22:04:24

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 11 Nov 2003, Pascal Schmidt wrote:
>
> dd behaves strangly on the MO drive. I've tried with 2.6.0-test9 and
> the patch appended to the end of this mail.
>
> # dd if=testfile of=/dev/hde bs=4096 count=1
> dd: writing `/dev/hde': no space left on device
> 1+0 records in
> 0+0 records out
>
> # dd if=/dev/hde of=mofile bs=4096 count=1
> 0+0 records in
> 0+0 records out
>
> Mounting the disc read-only works, however, and I can read all the data
> on it without problems.

Ok, that's just strange. You can't even _read_ from the raw device, but
the mount works ok?

And you got no IO errors anywhere? I don't see why the write would fail
silently.

I wonder whether the disk capacity is set to zero. See
drivers/ide/ide-cd.c, and in particular the

/* Now try to get the total cdrom capacity. */
stat = cdrom_get_last_written(cdi, (long *) &toc->capacity);
if (stat || !toc->capacity)
stat = cdrom_read_capacity(drive, &toc->capacity, sense);
if (stat)
toc->capacity = 0x1fffff;

and see what that says.. I really think you should start sprinkling
printk's around the thing to determine what goes on..

Linus

2003-11-11 22:49:32

by Martin Schlemmer

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 2003-11-11 at 21:41, Pascal Schmidt wrote:
> On Tue, 11 Nov 2003, Linus Torvalds wrote:
>
> > Can you try just writing to the thing as a raw device, ie simply doing
> > something like
> [...]
>
> Will do and report on what I find.
>
> >> I didn't see problems with using ide-scsi/sd for that drive in 2.5.7x,
> >> by the way, so I'm not so sure ide-scsi is really broken for that
> >> purpose.
> > It would be interesting to hear if ide-scsi works.
>
> I'll check on that, too.

I have not been using my writer lately, but ide-scsi works
fine for a flash disk (usb stick ?) and an a-drive (120mb
ide floppy drive).

Its just with the AS patches from -mm that I get issues.

Cheers,

--
Martin Schlemmer

2003-11-11 23:47:05

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 11 Nov 2003, Linus Torvalds wrote:

> Ok, that's just strange. You can't even _read_ from the raw device, but
> the mount works ok?

Exactly.

> And you got no IO errors anywhere? I don't see why the write would fail
> silently.

Nope, no errors anywhere.

> I wonder whether the disk capacity is set to zero. See
> drivers/ide/ide-cd.c, and in particular the
>
> /* Now try to get the total cdrom capacity. */
> stat = cdrom_get_last_written(cdi, (long *) &toc->capacity);
> if (stat || !toc->capacity)
> stat = cdrom_read_capacity(drive, &toc->capacity, sense);
> if (stat)
> toc->capacity = 0x1fffff;
>
> and see what that says.. I really think you should start sprinkling
> printk's around the thing to determine what goes on..

Did that. The code you quote from cdrom_read_toc is never even reached,
the first cdrom_read_tocentry in there just errors out because there
is no toc to read on an MO disk. This leaves the capacity64 member in
the associated ide_drive_t at 0 and also the capacity member in the
corresponding gendisk structure.

On mount, idecd_revalidate_disk gets called and also tries a
cdrom_read_toc, once again leaving the capacity at 0. Nevertheless,
the mount succeeds.

So, reading via dd seems to respect capacity, that explains the "no
space left on device" on writing and the read resulting in zero data
without error. Mounting doesn't even seem to look at the capacity.

My guess would be that an MO drive needs a different way to find out
the capacity than a CD-ROM. After all, when using ide-scsi, it is the
sd driver and not sr that handles the drive. The rest of the problems
could be due to the wrong capacity information?

--
Ciao,
Pascal

2003-11-12 00:09:55

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, 12 Nov 2003, Daniel Pittman wrote:

> The symptoms were exactly the same as above - I could mount and use the
> thing correctly, but the raw device was not readable at all.
>
> Maybe cdrom_read_capacity can also return zero for some broken
> situations?

I put a printk in cdrom_read_capacity also, and the thing is never
even called for the MO drive because we don't get that far in
cdrom_read_toc in my case.

--
Ciao,
Pascal

2003-11-12 00:04:40

by Daniel Pittman

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 11 Nov 2003, Linus Torvalds wrote:
> On Tue, 11 Nov 2003, Pascal Schmidt wrote:
>>
>> dd behaves strangly on the MO drive. I've tried with 2.6.0-test9 and
>> the patch appended to the end of this mail.
>>
>> # dd if=testfile of=/dev/hde bs=4096 count=1
>> dd: writing `/dev/hde': no space left on device
>> 1+0 records in
>> 0+0 records out
>>
>> # dd if=/dev/hde of=mofile bs=4096 count=1
>> 0+0 records in
>> 0+0 records out
>>
>> Mounting the disc read-only works, however, and I can read all the
>> data on it without problems.
>
> Ok, that's just strange. You can't even _read_ from the raw device,
> but the mount works ok?
>
> And you got no IO errors anywhere? I don't see why the write would
> fail silently.
>
> I wonder whether the disk capacity is set to zero. See
> drivers/ide/ide-cd.c, and in particular the
>
> /* Now try to get the total cdrom capacity. */
> stat = cdrom_get_last_written(cdi, (long *) &toc->capacity);
> if (stat || !toc->capacity)
> stat = cdrom_read_capacity(drive, &toc->capacity,
> sense);
> if (stat)
> toc->capacity = 0x1fffff;
>
> and see what that says.. I really think you should start sprinkling
> printk's around the thing to determine what goes on..

The '|| !toc->capacity' part of that code exists because I have a DVD
drive that got zero capacity from the cdrom_get_last_written call.

The symptoms were exactly the same as above - I could mount and use the
thing correctly, but the raw device was not readable at all.

Maybe cdrom_read_capacity can also return zero for some broken
situations?

Daniel

--
The youth gets together his materials to build a bridge to the moon, or,
perchance, a palace or temple on the earth, and, at length, the middle-aged
man concludes to build a woodshed with them.
-- Henry David Thoreau

2003-11-12 01:14:39

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, 12 Nov 2003, Pascal Schmidt wrote:
>
> My guess would be that an MO drive needs a different way to find out
> the capacity than a CD-ROM. After all, when using ide-scsi, it is the
> sd driver and not sr that handles the drive. The rest of the problems
> could be due to the wrong capacity information?

Yes. That would explain a lot.

The ide-scsi thing never uses "cdrom_get_last_written" crud. It just uses
the regular READ_CAPACITY command (0x25).

Which is what ide-cd.c will fall back to as well ("cdrom_read_capacity()")
but I think it should _start_ with that rather than fall back on it.
That's the simple case, after all.

Does it work if you change the order of those two things in ide-cd.c (or
just remove the call to "cdrom_get_last_written()" entirely, so that it
always just does the sane thing).

Linus

2003-11-12 17:32:53

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 11 Nov 2003, Linus Torvalds wrote:

> Which is what ide-cd.c will fall back to as well ("cdrom_read_capacity()")
> but I think it should _start_ with that rather than fall back on it.
> That's the simple case, after all.
>
> Does it work if you change the order of those two things in ide-cd.c (or
> just remove the call to "cdrom_get_last_written()" entirely, so that it
> always just does the sane thing).

In my case, we don't get as far as the cdrom_last_written() call in
cdrom_read_toc(). I will try putting the cdrom_read_capacity() stuff
on top and see if that works.

--
Ciao,
Pascal

2003-11-12 18:20:18

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 11 Nov 2003, Linus Torvalds wrote:

> Does it work if you change the order of those two things in ide-cd.c (or
> just remove the call to "cdrom_get_last_written()" entirely, so that it
> always just does the sane thing).

I've moved the cdrom_read_capacity() to the top of cdrom_read_toc and
now the capacity gets set correctly and everything seems to work just
fine.

dd to and from the raw device works, as do mke2fs and e2fsck. I could
also mount the disk read-write, write a 10MB file to it, and umount
again without problems. Then I rebooted into 2.4 and verified that the
filesystem is okay and the 10MB file made it to disk correctly.

Lookin' good so far.

Now, assuming there is a reason that the cdrom_read_capacity() function
is only used as a fallback for normal ide-cd devices, my change might
break non-MO devices. I also don't know what to do when read_capacity
fails - setting capacity to 0 obviously breaks as we've seen before,
so maybe setting it to the lowest possible MO size (128M) would be a
good way to handle that situation.

Jens, what do you think?

--
Ciao,
Pascal

2003-11-12 18:31:10

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, Nov 12 2003, Pascal Schmidt wrote:
> On Tue, 11 Nov 2003, Linus Torvalds wrote:
>
> > Does it work if you change the order of those two things in ide-cd.c (or
> > just remove the call to "cdrom_get_last_written()" entirely, so that it
> > always just does the sane thing).
>
> I've moved the cdrom_read_capacity() to the top of cdrom_read_toc and
> now the capacity gets set correctly and everything seems to work just
> fine.
>
> dd to and from the raw device works, as do mke2fs and e2fsck. I could
> also mount the disk read-write, write a 10MB file to it, and umount
> again without problems. Then I rebooted into 2.4 and verified that the
> filesystem is okay and the 10MB file made it to disk correctly.
>
> Lookin' good so far.

Great! Can you please send a diff for review? It speaks more clearly
than 1000 descriptions of what a patch does :)

> Now, assuming there is a reason that the cdrom_read_capacity() function
> is only used as a fallback for normal ide-cd devices, my change might

Fall back?

> break non-MO devices. I also don't know what to do when read_capacity
> fails - setting capacity to 0 obviously breaks as we've seen before,
> so maybe setting it to the lowest possible MO size (128M) would be a
> good way to handle that situation.
>
> Jens, what do you think?

Do what it currently does, set it to some high value? Then we'll just
rely on the drive properly failing read requests. Better than not being
able to reach the files.

--
Jens Axboe

2003-11-12 19:44:42

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, 12 Nov 2003, Jens Axboe wrote:

> Great! Can you please send a diff for review? It speaks more clearly
> than 1000 descriptions of what a patch does :)

Included at the end of the mail. I found one little problem. If I do

mke2fs -b 2048 /dev/hde
mount -t ext2 /dev/hde /mnt/mo
copy 10mbfile /mnt/mo/
umount /mnt/mo
e2fsck -f /dev/hde

I get complaints from e2fsck that the free blocks and free inodes counts
are wrong. However, if I do

eject -r /dev/hde

and then reinsert the disk before the e2fsck, there are no errors
reported. Checking on 2.4 confirms the filesystem on disk is okay. This
look to me like the data makes it to disk in any case, but in the first
case e2fsck is somehow getting stale data from somewhere.

> > Now, assuming there is a reason that the cdrom_read_capacity() function
> > is only used as a fallback for normal ide-cd devices, my change might
> Fall back?

Yes, the code in cdrom_read_toc does only use cdrom_read_capacity if the
cdrom_get_last_written call fails or returns a 0 capacity. For the MO,
we never get that far because cdrom_read_toc exits a lot earlier because
the first cdrom_get_tocentry it tries fails and causes the function to
exit, never setting the capacity.

>> Jens, what do you think?
> Do what it currently does, set it to some high value? Then we'll just
> rely on the drive properly failing read requests. Better than not being
> able to reach the files.

Sounds reasonable. I rearranged what I did a little so that non-MO
drives should be handled almost the same as before. The
cdrom_read_capacity is now attempted at the start of cdrom_read_toc and
the cdrom_get_last_written at the end can override the capacity if
needed. I don't fix up toc->capacity in that case, however, that
would need to be added, I think.

--- linux-2.6.0-test9/drivers/ide/ide-cd.c.orig Tue Nov 11 22:21:38 2003
+++ linux-2.6.0-test9/drivers/ide/ide-cd.c Wed Nov 12 20:12:31 2003
@@ -2257,6 +2257,13 @@
if (CDROM_STATE_FLAGS(drive)->toc_valid)
return 0;

+ /* Try to get the total cdrom capacity. */
+ stat = cdrom_read_capacity(drive, &toc->capacity, sense);
+ if (stat)
+ toc->capacity = 0x1fffff;
+
+ set_capacity(drive->disk, toc->capacity * SECTORS_PER_FRAME);
+
/* First read just the header, so we know how long the TOC is. */
stat = cdrom_read_tocentry(drive, 0, 1, 0, (char *) &toc->hdr,
sizeof(struct atapi_toc_header), sense);
@@ -2365,12 +2372,8 @@

/* Now try to get the total cdrom capacity. */
stat = cdrom_get_last_written(cdi, (long *) &toc->capacity);
- if (stat || !toc->capacity)
- stat = cdrom_read_capacity(drive, &toc->capacity, sense);
- if (stat)
- toc->capacity = 0x1fffff;
-
- set_capacity(drive->disk, toc->capacity * SECTORS_PER_FRAME);
+ if (!stat && toc->capacity)
+ set_capacity(drive->disk, toc->capacity * SECTORS_PER_FRAME);

/* Remember that we've read this stuff. */
CDROM_STATE_FLAGS(drive)->toc_valid = 1;
@@ -3211,7 +3214,8 @@

nslots = ide_cdrom_probe_capabilities (drive);

- if (CDROM_CONFIG_FLAGS(drive)->dvd_ram)
+ if (CDROM_CONFIG_FLAGS(drive)->dvd_ram ||
+ CDROM_CONFIG_FLAGS(drive)->mo_drive)
set_disk_ro(drive->disk, 0);

#if 0
--- linux-2.6.0-test9/drivers/cdrom/cdrom.c.orig Tue Nov 11 22:21:25 2003
+++ linux-2.6.0-test9/drivers/cdrom/cdrom.c Wed Nov 12 20:13:33 2003
@@ -426,7 +426,8 @@
if ((fp->f_flags & O_NONBLOCK) && (cdi->options & CDO_USE_FFLAGS))
ret = cdi->ops->open(cdi, 1);
else {
- if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
+ if ((fp->f_mode & FMODE_WRITE) &&
+ !(CDROM_CAN(CDC_DVD_RAM) || CDROM_CAN(CDC_MO_DRIVE)))
return -EROFS;

ret = open_for_data(cdi);

--
Ciao,
Pascal

2003-11-12 23:08:54

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

In article <[email protected]>,
Diego Calleja =?ISO-8859-15?Q?Garc=EDa?= <[email protected]> wrote:
| El Mon, 10 Nov 2003 21:40:58 -0800 (PST) Linus Torvalds <[email protected]>
| escribi?:
|
| > Now it's your turn. Instead of wasting my time complaining, how about you
| > put up or shut up? Show me the code. THEN post it. Until you do, there's
| > no point to your mails.
|
| Until then, I'd suggest this patch to avoid more complains about this:

The object is not to avoid complaints, the object is to get the
capability working again. I presume eventually one of the commercial
vendors will fix it, since it's easier than rewriting all the SCSI
applications in the world. oddly there are people writing useful things
using other operating systems, under 2.4 almost all of those work.

I hope to pick up another IDE tape drive so I can look at this problem,
the one I have is on a production system, which at the moment has no
reason to go to 2.6 even if it worked, which it doesn't. It also has
software to read ZIP drives in odd ways, and I'm not about to look for a
SCSI 100MB ZIP drive :-(

|
| diff -puN drivers/ide/Kconfig~idescsi-broken drivers/ide/Kconfig
| --- tim/drivers/ide/Kconfig~idescsi-broken 2003-11-11 18:35:23.000000000 +0100
| +++ tim-diego/drivers/ide/Kconfig 2003-11-11 18:36:07.000000000 +0100
| @@ -247,7 +247,7 @@ config BLK_DEV_IDEFLOPPY
|
| config BLK_DEV_IDESCSI
| tristate "SCSI emulation support"
| - depends on SCSI
| + depends on SCSI && BROKEN
| ---help---
| This will provide SCSI host adapter emulation for IDE ATAPI
| devices, and will allow you to use a SCSI device driver instead of
| a native
|
| _
|
| -
| 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/
|

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-12 23:48:02

by Bartlomiej Zolnierkiewicz

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wednesday 12 of November 2003 23:58, bill davidsen wrote:
> In article <[email protected]>,
>
> Diego Calleja =?ISO-8859-15?Q?Garc=EDa?= <[email protected]> wrote:
> | El Mon, 10 Nov 2003 21:40:58 -0800 (PST) Linus Torvalds
> | <[email protected]>
> |
> | escribi?:
> | > Now it's your turn. Instead of wasting my time complaining, how about
> | > you put up or shut up? Show me the code. THEN post it. Until you do,
> | > there's no point to your mails.
> |
> | Until then, I'd suggest this patch to avoid more complains about this:
>
> The object is not to avoid complaints, the object is to get the
> capability working again. I presume eventually one of the commercial
> vendors will fix it, since it's easier than rewriting all the SCSI

Since it is easier for commercial vendors to fix it.
They have necessary hardware and financial motivation
(you've already pointed that out in one of your previous mails).

> applications in the world. oddly there are people writing useful things
> using other operating systems, under 2.4 almost all of those work.

Therefore stop complaining and _do_ something.

> I hope to pick up another IDE tape drive so I can look at this problem,
> the one I have is on a production system, which at the moment has no
> reason to go to 2.6 even if it worked, which it doesn't. It also has
> software to read ZIP drives in odd ways, and I'm not about to look for a
> SCSI 100MB ZIP drive :-(

So you are about to look for a way to fix it... :P.
Please send patches to me and lkml.

--bartlomiej
IDE Maintainer

> | diff -puN drivers/ide/Kconfig~idescsi-broken drivers/ide/Kconfig
> | --- tim/drivers/ide/Kconfig~idescsi-broken 2003-11-11 18:35:23.000000000
> | +0100 +++ tim-diego/drivers/ide/Kconfig 2003-11-11 18:36:07.000000000
> | +0100 @@ -247,7 +247,7 @@ config BLK_DEV_IDEFLOPPY
> |
> | config BLK_DEV_IDESCSI
> | tristate "SCSI emulation support"
> | - depends on SCSI
> | + depends on SCSI && BROKEN
> | ---help---
> | This will provide SCSI host adapter emulation for IDE ATAPI
> | devices, and will allow you to use a SCSI device driver instead of
> | a native

2003-11-13 07:06:36

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Wed, Nov 12 2003, bill davidsen wrote:
> In article <[email protected]>,
> Diego Calleja =?ISO-8859-15?Q?Garc=EDa?= <[email protected]> wrote:
> | El Mon, 10 Nov 2003 21:40:58 -0800 (PST) Linus Torvalds <[email protected]>
> | escribi?:
> |
> | > Now it's your turn. Instead of wasting my time complaining, how about you
> | > put up or shut up? Show me the code. THEN post it. Until you do, there's
> | > no point to your mails.
> |
> | Until then, I'd suggest this patch to avoid more complains about this:
>
> The object is not to avoid complaints, the object is to get the

If it could avoid your non-stop whining...

> capability working again. I presume eventually one of the commercial
> vendors will fix it, since it's easier than rewriting all the SCSI
> applications in the world. oddly there are people writing useful things
> using other operating systems, under 2.4 almost all of those work.

It's not about applications, we can fix that differently. You still
don't seem to get that moving from ide-scsi is a _good_ thing, from the
application point of view. It's about hardware that doesn't work well
with atapi drivers yet, for whatever reason. ide-scsi is nice to have to
fill those holes.

> I hope to pick up another IDE tape drive so I can look at this problem,
> the one I have is on a production system, which at the moment has no
> reason to go to 2.6 even if it worked, which it doesn't. It also has
> software to read ZIP drives in odd ways, and I'm not about to look for a
> SCSI 100MB ZIP drive :-(

Until then please pipe down, your mails are getting pretty tedious. I
dunno why I even read this one.

--
Jens Axboe

2003-11-13 12:04:09

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Tue, 11 Nov 2003, Linus Torvalds wrote:

>
> On Wed, 12 Nov 2003, Pascal Schmidt wrote:
> >
> > My guess would be that an MO drive needs a different way to find out
> > the capacity than a CD-ROM. After all, when using ide-scsi, it is the
> > sd driver and not sr that handles the drive. The rest of the problems
> > could be due to the wrong capacity information?
>
> Yes. That would explain a lot.
>
> The ide-scsi thing never uses "cdrom_get_last_written" crud. It just uses
> the regular READ_CAPACITY command (0x25).
>
> Which is what ide-cd.c will fall back to as well ("cdrom_read_capacity()")
> but I think it should _start_ with that rather than fall back on it.
> That's the simple case, after all.

Are there any cases when the last_written size is really what's wanted,
rather than the capacity? Such as unclosed multi-session iso9660, ufs, or
whatever else I'm ignoring?
>
> Does it work if you change the order of those two things in ide-cd.c (or
> just remove the call to "cdrom_get_last_written()" entirely, so that it
> always just does the sane thing).

For a read-only access, I think the size is what's written, while for
writing it's the physical size, I think. Does it need to be as complex as
having the order depend on the access mode? It seems that a size of zero
is correct for a read access to an unwritten media.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-13 12:20:58

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 13 2003, Bill Davidsen wrote:
> On Tue, 11 Nov 2003, Linus Torvalds wrote:
>
> >
> > On Wed, 12 Nov 2003, Pascal Schmidt wrote:
> > >
> > > My guess would be that an MO drive needs a different way to find out
> > > the capacity than a CD-ROM. After all, when using ide-scsi, it is the
> > > sd driver and not sr that handles the drive. The rest of the problems
> > > could be due to the wrong capacity information?
> >
> > Yes. That would explain a lot.
> >
> > The ide-scsi thing never uses "cdrom_get_last_written" crud. It just uses
> > the regular READ_CAPACITY command (0x25).
> >
> > Which is what ide-cd.c will fall back to as well ("cdrom_read_capacity()")
> > but I think it should _start_ with that rather than fall back on it.
> > That's the simple case, after all.
>
> Are there any cases when the last_written size is really what's wanted,
> rather than the capacity? Such as unclosed multi-session iso9660, ufs, or
> whatever else I'm ignoring?

Yes, for packet written media.

--
Jens Axboe

2003-11-13 13:19:45

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 13 Nov 2003, Jens Axboe wrote:

>> Are there any cases when the last_written size is really what's wanted,
>> rather than the capacity? Such as unclosed multi-session iso9660, ufs, or
>> whatever else I'm ignoring?
> Yes, for packet written media.

My patch from yesterday should handle that situation.
cdrom_get_last_written is allowed to override the capacity from
cdrom_read_capacity.

--
Ciao,
Pascal

2003-11-13 13:18:10

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 13 Nov 2003, Bill Davidsen wrote:

> For a read-only access, I think the size is what's written, while for
> writing it's the physical size, I think. Does it need to be as complex as
> having the order depend on the access mode? It seems that a size of zero
> is correct for a read access to an unwritten media.

Well, there is only one capacity and we cannot tell at the time we
fetch the capacity from the drive whether the user will use the disk
read-only or read-write.

In any case, cdrom_read_capacity() is the only thing that works on my
MO drive, the other methods all fail. So my patch from yesterday changes
the order of things so that read_capacity is used first to get the
capacity, and the other methods are allowed to override it's findings
later on.

--
Ciao,
Pascal

2003-11-13 14:35:32

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 13 2003, Pascal Schmidt wrote:
> On Thu, 13 Nov 2003, Jens Axboe wrote:
>
> >> Are there any cases when the last_written size is really what's wanted,
> >> rather than the capacity? Such as unclosed multi-session iso9660, ufs, or
> >> whatever else I'm ignoring?
> > Yes, for packet written media.
>
> My patch from yesterday should handle that situation.
> cdrom_get_last_written is allowed to override the capacity from
> cdrom_read_capacity.

Yep, that is fine.

--
Jens Axboe

2003-11-13 15:22:43

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 13 Nov 2003, Jens Axboe wrote:

> On Thu, Nov 13 2003, Pascal Schmidt wrote:
> >
> > My patch from yesterday should handle that situation.
> > cdrom_get_last_written is allowed to override the capacity from
> > cdrom_read_capacity.
>
> Yep, that is fine.

Well, there is a good argument for not bothering with the
"cdrom_get_last_written" at all: the SCSI layer never does anything like
that as far as I can see, so arguably everybody who ever used ide-scsi
would only ever have seen the READ_CAPACITY command be used. And nobody
ever complained about bad capacitites as far as I can remember..

But I might have missed something in the SCSI driver. But I actually see a

if (cdrom_get_last_written(..)

in sr.c, and it's been #if 0'ed out since before the Bitkeeper tree
started. And that code definitely does the READ_CAPACITY first.

The "sd.c" code (which is what a MO device would use) obviously doesn't do
cdrom_get_last_written either - it just does a READ_CAPACITY. (Well, it
does a READ_CAPACITY_16 if it hits a really big disk, but that only hits
if the disk has more than 4G sectors, so we can ignore it for CD-ROM's for
a while.

So I'd argue for just dropping the cdrom_get_last_written() call entirely.

Linus

2003-11-13 15:28:02

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 13 2003, Linus Torvalds wrote:
>
> On Thu, 13 Nov 2003, Jens Axboe wrote:
>
> > On Thu, Nov 13 2003, Pascal Schmidt wrote:
> > >
> > > My patch from yesterday should handle that situation.
> > > cdrom_get_last_written is allowed to override the capacity from
> > > cdrom_read_capacity.
> >
> > Yep, that is fine.
>
> Well, there is a good argument for not bothering with the
> "cdrom_get_last_written" at all: the SCSI layer never does anything like
> that as far as I can see, so arguably everybody who ever used ide-scsi
> would only ever have seen the READ_CAPACITY command be used. And nobody
> ever complained about bad capacitites as far as I can remember..
>
> But I might have missed something in the SCSI driver. But I actually see a
>
> if (cdrom_get_last_written(..)
>
> in sr.c, and it's been #if 0'ed out since before the Bitkeeper tree
> started. And that code definitely does the READ_CAPACITY first.
>
> The "sd.c" code (which is what a MO device would use) obviously doesn't do
> cdrom_get_last_written either - it just does a READ_CAPACITY. (Well, it
> does a READ_CAPACITY_16 if it hits a really big disk, but that only hits
> if the disk has more than 4G sectors, so we can ignore it for CD-ROM's for
> a while.
>
> So I'd argue for just dropping the cdrom_get_last_written() call entirely.

Your argument isn't very good, imo. I was the one that added the
cdrom_get_last_written() calls, because with the pktcdvd written media
reading the toc or using READ_CAPACITY just didn't work.

For MO drives, DVD-RAM, and that sort of thing there's no argument -
read capacity is the way to go. For CDROMs it's not so clear.

--
Jens Axboe

2003-11-13 15:26:46

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 13 Nov 2003 15:40:20 +0100, you wrote in linux.kernel:

>> My patch from yesterday should handle that situation.
>> cdrom_get_last_written is allowed to override the capacity from
>> cdrom_read_capacity.

> Yep, that is fine.

Will you queue the patch or should I resend it after 2.6.0 gets released?

--
Ciao,
Pascal

2003-11-13 15:29:22

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, Nov 13 2003, Pascal Schmidt wrote:
> On Thu, 13 Nov 2003 15:40:20 +0100, you wrote in linux.kernel:
>
> >> My patch from yesterday should handle that situation.
> >> cdrom_get_last_written is allowed to override the capacity from
> >> cdrom_read_capacity.
>
> > Yep, that is fine.
>
> Will you queue the patch or should I resend it after 2.6.0 gets released?

If Linus doesn't want to take it now, send it later :)

--
Jens Axboe

2003-11-13 15:33:23

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 13 Nov 2003, Jens Axboe wrote:

>> Will you queue the patch or should I resend it after 2.6.0 gets released?
> If Linus doesn't want to take it now, send it later :)

Will do.

--
Ciao,
Pascal

2003-11-15 13:15:33

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 13 Nov 2003, Pascal Schmidt wrote:

> On Thu, 13 Nov 2003, Bill Davidsen wrote:
>
> > For a read-only access, I think the size is what's written, while for
> > writing it's the physical size, I think. Does it need to be as complex as
> > having the order depend on the access mode? It seems that a size of zero
> > is correct for a read access to an unwritten media.
>
> Well, there is only one capacity and we cannot tell at the time we
> fetch the capacity from the drive whether the user will use the disk
> read-only or read-write.
>
> In any case, cdrom_read_capacity() is the only thing that works on my
> MO drive, the other methods all fail. So my patch from yesterday changes
> the order of things so that read_capacity is used first to get the
> capacity, and the other methods are allowed to override it's findings
> later on.

And that sounds like the correct thing to do.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-15 13:23:53

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 13 Nov 2003, Jens Axboe wrote:

> On Wed, Nov 12 2003, bill davidsen wrote:

> > capability working again. I presume eventually one of the commercial
> > vendors will fix it, since it's easier than rewriting all the SCSI
> > applications in the world. oddly there are people writing useful things
> > using other operating systems, under 2.4 almost all of those work.
>
> It's not about applications, we can fix that differently. You still
> don't seem to get that moving from ide-scsi is a _good_ thing, from the
> application point of view. It's about hardware that doesn't work well
> with atapi drivers yet, for whatever reason. ide-scsi is nice to have to
> fill those holes.

Sorry, as far as I can tell it's just the wrong direction. Devices mounted
by USB look like... SCSI. And ZIP drives and tapes mounted on parallel
(ppa) look like... SCSI. If Linux had one fully functional ide-scsi driver
it would then present a consistant all-SCSI interface to the applications.
No more ide-floppy, ide-cd, ide-tape, just one driver. And that would
allow use of applications from BSD, Sun, and SysV.

Clearly the ide-scsi driver currently available isn't fully capable, and
as long as Linus doesn't agree that having a single application interface
is elegant and desirable, I can't see anyone doing the things needed.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-15 13:27:34

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Thu, 13 Nov 2003, Jens Axboe wrote:

> On Thu, Nov 13 2003, Bill Davidsen wrote:

> > Are there any cases when the last_written size is really what's wanted,
> > rather than the capacity? Such as unclosed multi-session iso9660, ufs, or
> > whatever else I'm ignoring?
>
> Yes, for packet written media.

Thanks, the recent patch addresses that, I think that covers the cases
which want the last_written size.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-11-15 13:43:33

[permalink] [raw]

Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

On Sat, Nov 15 2003, Bill Davidsen wrote:
> On Thu, 13 Nov 2003, Jens Axboe wrote:
>
> > On Wed, Nov 12 2003, bill davidsen wrote:
>
> > > capability working again. I presume eventually one of the commercial
> > > vendors will fix it, since it's easier than rewriting all the SCSI
> > > applications in the world. oddly there are people writing useful things
> > > using other operating systems, under 2.4 almost all of those work.
> >
> > It's not about applications, we can fix that differently. You still
> > don't seem to get that moving from ide-scsi is a _good_ thing, from the
> > application point of view. It's about hardware that doesn't work well
> > with atapi drivers yet, for whatever reason. ide-scsi is nice to have to
> > fill those holes.
>
> Sorry, as far as I can tell it's just the wrong direction. Devices mounted
> by USB look like... SCSI. And ZIP drives and tapes mounted on parallel
> (ppa) look like... SCSI. If Linux had one fully functional ide-scsi driver
> it would then present a consistant all-SCSI interface to the applications.

Crap. 2.6 block layer can pass "looks like SCSI" commands through the
plain queue just fine, why on earth would I need to go through two extra
layers to send a command to ide-cd? Presenting all-SCSI interface to
applications is bogus. The number of actual SCSI devices is going down
by the minute. Basically all storage-like devices talk some packetized
commands that looks like SCSI, but they are not.

What we do need is something that allows you to submit commands to a
device, no matter where it's attached. You still don't seem to grasp
that.

> No more ide-floppy, ide-cd, ide-tape, just one driver. And that would
> allow use of applications from BSD, Sun, and SysV.

One drive to manage different device types? What are you smoking.

> Clearly the ide-scsi driver currently available isn't fully capable, and
> as long as Linus doesn't agree that having a single application interface
> is elegant and desirable, I can't see anyone doing the things needed.

Once again you fail to understand the simplest of points. Linus doesn't
disagree that one single application interface is what we want, and I
don't disagree. What you don't understand is that sg (and having to
carry the full SCSI stack around) is anything but elegant and desired.

And if you can't see anyone doing the things needed, then you are blind
as well. I've mentioned bsg (block sg) many times on lkml.

Further mails from you go to /dev/null, you are wasting everybodies
time.

--
Jens Axboe

2003-11-17 13:34:31