Hi,
I've written the basic kernel and user space code to support the "new"
mt rainier cd-rw drives (hence forth known as cd-mrw in this mail).
What are these drives? They are basically CD-RW drives with a twist. The
twist, to put it shortly:
- back ground formatting support is a requirement
- read-modify-write cycle support is in firmware, not software
- bad block management is in firmware, not file system
The drives use regular CD-RW media. The media needs to be initialized
before use, the supplied mtr tool can help you do that. Basically you
just need to start a back ground format:
# ./mtr -d /dev/hdc -f full
This will take ~10 seconds or so, after which the media can be used for
writing. No more waiting for format completion. Should you wish to enjoy
the silence and watch the media format, there's a -p poll switch for
that:
# ./mtr -d /dev/hdc -p
(can of course also be used while starting the format). If you want to
remove the media before the format has completed, you need to suspend
it.
# ./mtr -d /dev/hdc -s
ide-cd will do this automagically if you remove the driver while a
format is in progress, btw (from dmesg).
cdrom: issuing MRW bgformat suspend
The mtr tool can restart a format for you as well:
# ./mtr -d /dev/hdc -f restart
ide-cd will also do this automagically if you mount a media rw which is
partially formatted, if you didn't disable the bgformat restart option
when loading cdrom.o (new options, mrw_format_restart, defaults to 1):
cdrom: mount opening for WRITE
cdrom open: mrw_status 'bgformat inactive'
cdrom: Restarting format
I dunno which drives have cd-mrw support yet, I've got some Philips
samples here. I have heard that there are at least TEAC drives with a
firmware upgrade option to support cd-mrw, and I'm sure that pretty soon
all new burners are going to have this feature. Running the mtr tool
will tell you if your drive supports cd-mrw or not.
Any file system will work, but using UDF is recommended. Make sure to
remember to include UDF rw support :-). Incidentally, 2.4.19-pre4 has a
bug that prevents UDF from being built with read-write support. Patch is
included for that and sent to Marcelo separately. Recommended format
options:
# mkudffs --media-type=cdrw -b 2048 /dev/hdc
start=0, blocks=16, type=RESERVED
start=16, blocks=3, type=VRS
start=19, blocks=237, type=USPACE
start=256, blocks=1, type=ANCHOR
start=257, blocks=31, type=USPACE
start=288, blocks=32, type=PVDS
start=320, blocks=32, type=LVID
start=352, blocks=32, type=STABLE
start=384, blocks=1024, type=SSPACE
start=1408, blocks=256608, type=PSPACE
start=258016, blocks=31, type=USPACE
start=258047, blocks=1, type=ANCHOR
start=258048, blocks=160, type=USPACE
start=258208, blocks=32, type=STABLE
start=258240, blocks=32, type=RVDS
start=258272, blocks=31, type=USPACE
start=258303, blocks=1, type=ANCHOR
This is the first release. Works for me, YMMV.
Patch your 2.4.19-pre4 kernel and give it a spin. Note that only ide-cd
supports Mt Rainier right now. The bulk of the support is in the uniform
layer, so adding SCSI CD-ROM support is going to be a breeze. I'm not
quite done shoving code around between ide-cd and cdrom, so that's why I
didn't bother adding the SCSI bits just yet.
--
Jens Axboe
Hello Jens,
> diff -ur -X /usr/src/exclude /opt/kernel/linux-2.4.19-pre4/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
> --- /opt/kernel/linux-2.4.19-pre4/drivers/ide/ide-cd.c Thu Mar 21 12:53:28 2002
> +++ linux/drivers/ide/ide-cd.c Thu Mar 21 13:38:34 2002
> @@ -292,9 +292,13 @@
> * correctly reporting tray status -- from
> * Michael D Johnson <[email protected]>
> *
> + * 4.60 Mar 21, 2002 - Add mt rainier support
> + * - Bump timeout value for packet commands
> + * - Odd stuff
Do you think you've fixed that oops too? I can reproduce this on
2.4.19-pre2-ac3 kernel by setting 'append = "hdb=noprobe hdb=cdrom"'
in lilo.conf and after booting doing a 'cat /dev/hdb | od' without
having a medium in the DVD drive. BTW 2.5.x crashes horribly when I
enable this append line in /etc/lilo.conf. I haven't had time to track
this down yet, so you might as well give it a whirl. I've got
CONFIG_BLK_DEV_PIIX=y and CONFIG_PIIX_TUNING=y. More of the .config upon
request.
Unable to handle kernel NULL pointer dereference at virtual address 00000063
c01a9300
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c01a9300>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: c02a86ac ebx: 00000000 ecx: 00000006 edx: 00000004
esi: 00000005 edi: c02a86ac ebp: 00000001 esp: df1f5edc
ds: 0018 es: 0018 ss: 0018
Process modprobe (pid: 584, stackpage=df1f5000)
Stack: c02a86ac 00000286 e285a820 c01a9347 c02a86ac c01a5e03 00000004
c02a86ac
00000007 c02a86ac df975e00 c02a86ac 00000001 e285799d c02a86ac
e285a820
00000001 e2854000 00000001 00000001 000068a0 c0115c1d df1f4000
08053c1b
Call Trace: [<e285a820>] [<c01a9347>] [<c01a5e03>] [<e285799d>]
[<e285a820>]
[<c0115c1d>] [<e2854060>] [<c0106bb3>] [<c020002b>]
Code: f6 43 63 08 75 06 f6 43 6a 02 74 0e be 07 00 00 00 57 e8 15
>>EIP; c01a9300 <config_drive_xfer_rate+b0/e4> <=====
Trace; e285a820 <[ide-cd]ide_cdrom_driver+0/50>
Trace; c01a9346 <piix_dmaproc+12/2c>
Trace; c01a5e02 <ide_register_subdriver+9e/fc>
Trace; e285799c <[ide-cd]init_module+94/196>
Trace; e285a820 <[ide-cd]ide_cdrom_driver+0/50>
Trace; c0115c1c <sys_init_module+504/5a8>
Trace; e2854060 <[ide-cd]__module_license+0/0>
Trace; c0106bb2 <system_call+32/38>
Trace; c020002a <number+12a/43c>
Code; c01a9300 <config_drive_xfer_rate+b0/e4>
00000000 <_EIP>:
Code; c01a9300 <config_drive_xfer_rate+b0/e4> <=====
0: f6 43 63 08 testb $0x8,0x63(%ebx) <=====
Code; c01a9304 <config_drive_xfer_rate+b4/e4>
4: 75 06 jne c <_EIP+0xc> c01a930c
<config_drive_xfer_rate+bc/e4>
Code; c01a9306 <config_drive_xfer_rate+b6/e4>
6: f6 43 6a 02 testb $0x2,0x6a(%ebx)
Code; c01a930a <config_drive_xfer_rate+ba/e4>
a: 74 0e je 1a <_EIP+0x1a> c01a931a
<config_drive_xfer_rate+ca/e4>
Code; c01a930c <config_drive_xfer_rate+bc/e4>
c: be 07 00 00 00 mov $0x7,%esi
Code; c01a9310 <config_drive_xfer_rate+c0/e4>
11: 57 push %edi
Code; c01a9312 <config_drive_xfer_rate+c2/e4>
12: e8 15 00 00 00 call 2c <_EIP+0x2c> c01a932c
<config_drive_xfer_rate+dc/e4>
<1>Unable to handle kernel NULL pointer dereference at virtual address
0000000ce2857543
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<e2857543>] Not tainted
EFLAGS: 00010206
eax: e2857524 ebx: 00000000 ecx: df2a8000 edx: e285a820
esi: c02a86ac edi: fffffff4 ebp: 00000340 esp: df2a9ef4
ds: 0018 es: 0018 ss: 0018
Process cat (pid: 582, stackpage=df2a9000)
Stack: c02a86ac df2164c0 dfe512bc c01a3b55 df2164c0 df3adbe0 c02a86ac
dfe512a0
00000340 c0136ea5 df2164c0 df3adbe0 df2164c0 df3adbe0 ffffffe9
dffe7320
00000000 c0136ff6 dfe512a0 df2164c0 df3adbe0 df2164c0 df3adbe0
df2164c0
Call Trace: [<c01a3b55>] [<c0136ea5>] [<c0136ff6>] [<c0130f15>]
[<c0130e2a>]
[<c013115a>] [<c0106bb3>]
Code: 83 7b 0c 00 75 19 68 f0 01 00 00 68 00 00 01 00 e8 38 18 8d
>>EIP; e2857542 <[ide-cd]ide_cdrom_open+1e/70> <=====
Trace; c01a3b54 <ide_open+cc/fc>
Trace; c0136ea4 <do_open+94/14c>
Trace; c0136ff6 <blkdev_open+22/28>
Trace; c0130f14 <dentry_open+e0/188>
Trace; c0130e2a <filp_open+52/5c>
Trace; c013115a <sys_open+36/98>
Trace; c0106bb2 <system_call+32/38>
Code; e2857542 <[ide-cd]ide_cdrom_open+1e/70>
00000000 <_EIP>:
Code; e2857542 <[ide-cd]ide_cdrom_open+1e/70> <=====
0: 83 7b 0c 00 cmpl $0x0,0xc(%ebx) <=====
Code; e2857546 <[ide-cd]ide_cdrom_open+22/70>
4: 75 19 jne 1f <_EIP+0x1f> e2857560
<[ide-cd]ide_cdrom_open+3c/70>
Code; e2857548 <[ide-cd]ide_cdrom_open+24/70>
6: 68 f0 01 00 00 push $0x1f0
Code; e285754c <[ide-cd]ide_cdrom_open+28/70>
b: 68 00 00 01 00 push $0x10000
Code; e2857552 <[ide-cd]ide_cdrom_open+2e/70>
10: e8 38 18 8d 00 call 8d184d <_EIP+0x8d184d>
e3128d8e <END_OF_CODE+8ce4f0/????>
Cheers,
Roberto Nibali, ratz
On Thu, Mar 21, 2002 at 02:12:01PM +0100, Jens Axboe wrote:
> # ./mtr -d /dev/hdc -f full
You may need to rename this biary since I think some other tools use this
name also...
> On Thu, Mar 21, 2002 at 02:12:01PM +0100, Jens Axboe wrote:
> > # ./mtr -d /dev/hdc -f full
>
> You may need to rename this biary since I think some other tools use this
> name also...
Yes - mtr is a graphical/text mode trace route/ping/etc tool
On Thu, Mar 21 2002, Alan Cox wrote:
> > On Thu, Mar 21, 2002 at 02:12:01PM +0100, Jens Axboe wrote:
> > > # ./mtr -d /dev/hdc -f full
> >
> > You may need to rename this biary since I think some other tools use this
> > name also...
>
> Yes - mtr is a graphical/text mode trace route/ping/etc tool
Ok for the record, I've gotten 10 of these now. Does anyone have
constructive comments besides the name (which I have changed now)? :-)
--
Jens Axboe