Hi,
This project has been sleeping for a while, so I thought it was about time
something happened. And now it has - I've put up version 0.0.2c of the
CD-RW packet writing module, aka the "happy birthday grandma" release 8)
A summary of some of the changes:
- inc usage count of buffer heads
- add internal buffer pool to avoid deadlock on oom
- gather data for as many buffers as we have, before initiating write. this
allows the laser to stay on longer, giving better performance.
- fix always busy when tray can't be locked
- remove request duplication nastiness, inject directly into the target
- adapted to devfs and elevator changes
- added proc interface
Not a whole lot, this is just to get the ball rolling again. However,
the addition of the internal buffer pool was something that should have
been added a long time ago. So this release should be significantly more
stable than 0.0.2b -- at least it is for me, your mileage may vary.
The patch is against 2.4.0-test7 and can be found at:
*.kernel.org/pub/linux/kernel/people/axboe/packet
or
http://sourceforge.net/projects/packet-cd/
--
* Jens Axboe
Hmm I have checked out 'ftp.us.kernel.org' and it is not there (can't connect to ftp.kernel.org). I have also checked out sourceforge and while it mentions '0.0.2c' it says there are no files for it. also, is there some TODO list? I would be interested to know what features are still missing. For example I heard there some talk that it does not deal correctly w/ bad blocks. is this still case? -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
I think it is missing this line [root@pepsi 24]# diff -u linux/drivers/block/Config.in{.old,} --- linux/drivers/block/Config.in.old Fri Sep 8 14:50:40 2000 +++ linux/drivers/block/Config.in Fri Sep 8 14:46:54 2000 @@ -38,6 +38,10 @@ tristate 'Packet writing on CD/DVD media' CONFIG_CDROM_PKTCDVD +if [ "$CONFIG_CDROM_PKTCDVD" = "y" -o "$CONFIG_CDROM_PKTCDVD" = "m" ]; then + tristate 'CD-RW support' CONFIG_CDROM_PKTCDVD_CDRW +fi + tristate 'Loopback device support' CONFIG_BLK_DEV_LOOP dep_tristate 'Network block device support' CONFIG_BLK_DEV_NBD $CONFIG_NET -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
On Fri, Sep 08 2000, adam@cfar.umd.edu wrote:
I think it is missing this line
[root@pepsi 24]# diff -u linux/drivers/block/Config.in{.old,} --- linux/drivers/block/Config.in.old Fri Sep 8 14:50:40 2000 +++ linux/drivers/block/Config.in Fri Sep 8 14:46:54 2000 @@ -38,6 +38,10 @@
tristate 'Packet writing on CD/DVD media' CONFIG_CDROM_PKTCDVD
+if [ "$CONFIG_CDROM_PKTCDVD" = "y" -o "$CONFIG_CDROM_PKTCDVD" = "m" ]; then + tristate 'CD-RW support' CONFIG_CDROM_PKTCDVD_CDRW +fi +
Not really, the Configure.help however should not have been in there.
The reason is that I plan to split packet writing into write type (cdrw first
naturally, then cd-r and "other" type devices).
--
* Jens Axboe
On Fri, Sep 08 2000, adam@cfar.umd.edu wrote:
Hmm I have checked out 'ftp.us.kernel.org' and it is not there (can't connect to ftp.kernel.org). I have also checked out sourceforge and while it mentions '0.0.2c' it says there are no files for it.
The sourceforge one was my mistake, I forgot to add the files. kernel.org mirrors can take some time to sync up thought, so if you don't find it at the first place try again.
also, is there some TODO list? I would be interested to know what features are still missing. For example I heard there some talk that it does not deal correctly w/ bad blocks. is this still case?
That is still true, currently that data will be lost. It will tell you
if this happens.
I'll post an "official" TODO list with the next release, coming next
week.
--
* Jens Axboe
it is no go for me. it panics kernel for me when I try to mount it. Panic below. (note this panic actually does not finish, it just print this msg but after this system is still running, but trying to unmount anything, sync or shutdown will just hang..) Linux version 2.4.0-test7-packet (root@pepsi) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #23 SMP Fri Sep 8 18:08:23 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable) BIOS-e820: 0000000000000400 @ 000000000009fc00 (usable) BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved) BIOS-e820: 0000000000001000 @ 00000000fec00000 (reserved) BIOS-e820: 0000000000001000 @ 00000000fee00000 (reserved) BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved) BIOS-e820: 000000000bef0000 @ 0000000000100000 (usable) BIOS-e820: 000000000000d000 @ 000000000bff3000 (ACPI data) BIOS-e820: 0000000000003000 @ 000000000bff0000 (ACPI NVS) Scan SMP from c0000000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f0000 for 65536 bytes. found SMP MP-table at 000f5ae0 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f1000 reserved twice. hm, page 000f2000 reserved twice. On node 0 totalpages: 49136 zone(0): 4096 pages. zone(1): 45040 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000 Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Bootup CPU Processor #1 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Bus #0 is PCI Bus #1 is PCI Bus #2 is ISA I/O APIC #2 Version 17 at 0xFEC00000. Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 0, trig 0, bus 2, IRQ 05, APIC ID 2, APIC INT 05 Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 1, trig 1, bus 2, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 2, IRQ 0d, APIC ID 2, APIC INT 0d Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 3, trig 3, bus 0, IRQ 1f, APIC ID 2, APIC INT 13 Int: type 0, pol 3, trig 3, bus 0, IRQ 24, APIC ID 2, APIC INT 13 Int: type 0, pol 3, trig 3, bus 0, IRQ 34, APIC ID 2, APIC INT 11 Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 0, IRQ 4c, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 4d, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10 Int: type 2, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 17 Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 2 mapped APIC to ffffe000 (fee00000) mapped IOAPIC to ffffd000 (fec00000) Kernel command line: BOOT_IMAGE=packet ro root=2103 ip=off video=matrox:off video=vga16:off hdc=ide-scsi console=ttyS0,9600 console=tty0 ide_setup: hdc=ide-scsi Initializing CPU#0 Detected 551262515 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1101.00 BogoMIPS Memory: 190908k/196544k available (1482k kernel code, 5248k reserved, 118k data, 216k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (20000221) Richard Gooch (rgooch@atnf.csiro.au) CPU0: Intel Celeron (Mendocino) stepping 05 per-CPU timeslice cutoff: 356.82 usecs. Getting VERSION: 40011 Getting VERSION: 40011 Getting ID: 0 Getting ID: f000000 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 CPU present map: 3 Booting processor 1/1 eip 2000 Setting warm reset code and vector. 1. 2. 3. Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1. After apic_write. Startup point 1. Initializing CPU#1 Waiting for send to finish... CPU#1 (phys ID: 1) waiting for CALLOUT +Sending STARTUP #2. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Before Callout 1. After Callout 1. CALLIN, before setup_local_APIC(). masked ExtINT on CPU#1 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 1101.00 BogoMIPS Stack at about cbfe7fbc OK. CPU1: Intel Celeron (Mendocino) stepping 05 CPU has booted. Before bogomips. Total of 2 processors activated (2202.01 BogoMIPS). Before bogocount - setting activated=1. Boot done. ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. Synchronizing Arb IDs. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-9, 2-10, 2-11, 2-12, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 activating NMI Watchdog ... done. number of MP IRQ sources: 20. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 .... register #01: 00170011 ....... : max redirection entries: 0017 ....... : IO APIC version: 0011 .... register #02: 00000000 ....... : arbitration: 00 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 003 03 0 0 0 0 0 1 1 39 02 003 03 0 0 0 0 0 1 1 31 03 003 03 0 0 0 0 0 1 1 41 04 003 03 0 0 0 0 0 1 1 49 05 003 03 0 0 0 0 0 1 1 51 06 003 03 0 0 0 0 0 1 1 59 07 003 03 0 0 0 0 0 1 1 61 08 003 03 0 0 0 0 0 1 1 69 09 000 00 1 0 0 0 0 0 0 00 0a 000 00 1 0 0 0 0 0 0 00 0b 000 00 1 0 0 0 0 0 0 00 0c 000 00 1 0 0 0 0 0 0 00 0d 000 00 1 0 0 0 0 0 0 00 0e 003 03 0 0 0 0 0 1 1 71 0f 003 03 0 0 0 0 0 1 1 79 10 003 03 1 1 0 1 0 1 1 81 11 003 03 1 1 0 1 0 1 1 89 12 003 03 1 1 0 1 0 1 1 91 13 003 03 1 1 0 1 0 1 1 99 14 000 00 1 0 0 0 0 0 0 00 15 000 00 1 0 0 0 0 0 0 00 16 000 00 1 0 0 0 0 0 0 00 17 000 00 1 0 0 0 0 0 0 00 IRQ to pin mappings: IRQ0 -> 2 IRQ1 -> 1 IRQ3 -> 3 IRQ4 -> 4 IRQ5 -> 5 IRQ6 -> 6 IRQ7 -> 7 IRQ8 -> 8 IRQ13 -> 13 IRQ14 -> 14 IRQ15 -> 15 IRQ16 -> 16 IRQ17 -> 17 IRQ18 -> 18 IRQ19 -> 19 .................................... done. calibrating APIC timer ... ..... CPU clock speed is 551.2621 MHz. ..... host bus clock speed is 100.2291 MHz. cpu: 0, clocks: 1002291, slice: 334097 CPU0T0:1002288,T1:668176,D:15,S:334097,C:1002291 cpu: 1, clocks: 1002291, slice: 334097 CPU1T0:1002288,T1:334080,D:14,S:334097,C:1002291 checking TSC synchronization across CPUs: passed. Setting commenced=1, go go go mtrr: your CPUs had inconsistent fixed MTRR settings mtrr: probably your BIOS does not setup all CPUs PCI: PCI BIOS revision 2.10 entry at 0xfb5c0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router PIIX [8086/7000] at 00:07.0 PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I9,P0) -> 19 PCI->APIC IRQ transform: (B0,I13,P0) -> 17 PCI->APIC IRQ transform: (B0,I15,P0) -> 16 PCI->APIC IRQ transform: (B0,I19,P0) -> 18 PCI->APIC IRQ transform: (B0,I19,P1) -> 18 PCI->APIC IRQ transform: (B1,I0,P0) -> 16 Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 IEEE 802.2 LLC for Linux 2.1 (c) 1996 Tim Alpaerts NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 16384 bind 16384) IPv4 over IPv4 tunneling driver early initialization of device tunl0 is deferred GRE over IPv4 tunneling driver early initialization of device gre0 is deferred Linux IP multicast router 0.06 plus PIM-SM Initializing RT netlink socket Starting kswapd v1.7 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA HPT366: onboard version of chipset, pin1=1 pin2=2 HPT366: IDE controller on PCI bus 00 dev 98 HPT366: chipset revision 1 HPT366: not 100% native mode: will probe irqs later ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:DMA, hdf:pio HPT366: IDE controller on PCI bus 00 dev 99 HPT366: chipset revision 1 HPT366: not 100% native mode: will probe irqs later ide3: BM-DMA at 0xe000-0xe007, BIOS settings: hdg:pio, hdh:pio hda: IBM-DHEA-38451, ATA DISK drive hdc: QPS CD-R PX-W8432T, ATAPI CDROM drive hdd: CD-532E, ATAPI CDROM drive hde: WDC WD272AA, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 ide2 at 0xcc00-0xcc07,0xd002 on irq 18 hda: 16514064 sectors (8455 MB) w/472KiB Cache, CHS=1027/255/63, UDMA(33) hde: 53128656 sectors (27202 MB) w/2048KiB Cache, CHS=52707/16/63, UDMA(66) Partition check: hda: hda1 hde: hde1 hde2 hde3 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ DETECT_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10c Non-volatile memory driver v1.1 Linux PCMCIA Card Services 3.1.11 options: [pci] [cardbus] [pm] ip_conntrack (1535 buckets, 12280 max) ACPI: support found ip_tables: (c)2000 Netfilter core team ACPI: namespace load failed ACPI: -0550: <7>ACPI: *** Success: Entire namespace and objects deleted ds: no socket drivers loaded! VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 216k freed NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Adding Swap: 131536k swap-space (priority -1) Linux Tulip driver version 0.9.9 (August 11, 2000) eth0: Lite-On 82c168 PNIC rev 32 at 0xc800, 00:A0:CC:62:2B:2A, IRQ 16. eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) lp0: using parport0 (interrupt-driven). lp0: console ready eth0: Setting full-duplex based on MII#1 link partner capability of 41e1. mice: PS/2 mouse device common for all mice usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.237 $ time 18:15:52 Sep 8 2000 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xc000, IRQ 19 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb.c: USB new device connect, assigned device number 1 hub.c: USB hub found hub.c: 2 ports detected usb.c: USB new device connect, assigned device number 2 usb.c: USB device 2 (prod/vend 0x45e/0x29) is not claimed by any active driver. Linux video capture interface: v1.00 i2c-core.o: i2c core module i2c-algo-bit.o: i2c bit algorithm module bttv: driver version 0.7.41 loaded bttv: using 2 buffers with 2080k (4160k total) for capture bttv: Bt8xx card found (0). bttv0: Bt848 (rev 18) at 00:0d.0, irq: 17, latency: 32, memory: 0xda001000 bttv0: model: BT848A(Phoebe Tv Master + FM) [insmod option] bttv0: gpio config override: mask=0xffffffff, mux=0x2,0xffffffff,0xffffffff,0xffffffff,0xffffffff i2c-algo-bit.o: Adapter: bt848 #0 scl: 1 sda: 1 -- testing... i2c-algo-bit.o:1 scl: 1 sda: 0 i2c-algo-bit.o:2 scl: 1 sda: 1 i2c-algo-bit.o:3 scl: 0 sda: 1 i2c-algo-bit.o:4 scl: 1 sda: 1 i2c-algo-bit.o: bt848 #0 passed test. i2c-core.o: adapter bt848 #0 registered as adapter 0. bttv0: i2c: checking for MSP34xx @ 0x80... not found tvaudio: TV audio decoder + audio/video mux driver tvaudio: known chips: tda9840,tda9873h,tda9850,tda9855,tea6300,tda8425,pic16c54 (PV951) i2c-core.o: driver generic i2c audio driver registered. bttv0: i2c: checking for TDA9875 @ 0xb0... not found i2c-core.o: driver i2c TV tuner driver registered. tuner: chip found @ 0x60 bttv0: i2c attach [Temic NTSC] i2c-core.o: client [Temic NTSC] registered to adapter [bt848 #0](pos. 0). usb.c: USB disconnect on device 1 usb.c: USB disconnect on device 2 usb.c: USB bus 1 deregistered usb.c: deregistering driver usbdevfs usb.c: deregistering driver hub mice: PS/2 mouse device common for all mice usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.237 $ time 18:15:52 Sep 8 2000 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xc000, IRQ 19 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb.c: USB new device connect, assigned device number 1 hub.c: USB hub found hub.c: 2 ports detected usb.c: USB new device connect, assigned device number 2 usb.c: USB device 2 (prod/vend 0x45e/0x29) is not claimed by any active driver. usb.c: registered new driver hid usb-uhci.c: interrupt, status 3, frame# 1433 mouse0: PS/2 mouse device for input0 input0: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse� Optical] on usb1:2.0 scsi0 : SCSI host adapter emulation for IDE ATAPI devices scsi : 1 host. Vendor: QPS Model: CD-R PX-W8432T Rev: 1.05 Type: CD-ROM ANSI SCSI revision: 02 Vendor: TEAC Model: CD-532E Rev: 3.0A Type: CD-ROM ANSI SCSI revision: 02 pktcdvd: v0.0.2c 08/09/2000 Jens Axboe (axboe@suse.de) udf: registering filesystem pktcdvd: open RDONLY to setup device pktcdvd: failed open Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 Detected scsi CD-ROM sr1 at scsi0, channel 0, id 1, lun 0 sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.11 sr1: scsi3-mmc drive: 32x/32x xa/form2 cdda tray VFS: Disk change detected on device sr(11,0) pktcdvd: writer sr0 sucessfully registered pktcdvd: 454208KB available on disc pktcdvd: inserted media is CD-RW pktcdvd: Fixed packets, 32 blocks / packet, Mode-1 disc pktcdvd: speed (R/W) 6/4 pktcdvd: 454208KB available on disc UDF-fs DEBUG (../linux-2.4/lowlevel.c, 65): udf_get_last_session: CDROMMULTISESSION not supported: rc=-22 UDF-fs DEBUG (../linux-2.4/super.c, 1355): udf_read_super: Multi-session=0 UDF-fs DEBUG (../linux-2.4/super.c, 1364): udf_read_super: Lastblock=227103 UDF-fs DEBUG (../linux-2.4/super.c, 392): udf_vrs: Starting at sector 16 (2048 byte sectors) UDF-fs DEBUG (../linux-2.4/super.c, 742): udf_load_pvoldesc: recording time 968452905/179539, 2000/09/08 17:41 (1ed4) UDF-fs DEBUG (../linux-2.4/super.c, 928): udf_load_logicalvol: Partition (0:0) type 2 on volume 1 UDF-fs DEBUG (../linux-2.4/super.c, 938): udf_load_logicalvol: FileSet found in LogicalVolDesc at block=32, partition=0 UDF-fs DEBUG (../linux-2.4/super.c, 789): udf_load_partdesc: Searching map: (0 == 0) UDF-fs DEBUG (../linux-2.4/super.c, 823): udf_load_partdesc: unallocatedSpaceBitmap (part 0) @ 0 UDF-fs DEBUG (../linux-2.4/super.c, 860): udf_load_partdesc: Partition (0:0 type 1522) starts at physical 2464, block length 224352 UDF-fs DEBUG (../linux-2.4/super.c, 1177): udf_load_partition: Using anchor in block 227103 UDF-fs DEBUG (../linux-2.4/super.c, 714): udf_find_fileset: Fileset at block=32, partition=0 UDF-fs DEBUG (../linux-2.4/super.c, 775): udf_load_fileset: Rootdir at block=64, partition=0 UDF-fs INFO UDF 0.9.3-cvs-rw (2000/06/17) Mounting volume '', timestamp 2000/09/08 17:41 (1ed4) Incorrect number of segments after building list nr_segments is 3 counted segments is 20 Flags 0 0 Segment 0xc59cf920, blocks 4, addr 0x59177ff Segment 0xc5932a40, blocks 4, addr 0x592c7ff Segment 0xc5932ac0, blocks 4, addr 0x592cfff Segment 0xc5932b40, blocks 4, addr 0x592d7ff Segment 0xc5932bc0, blocks 4, addr 0x592dfff Segment 0xc5932c40, blocks 4, addr 0x592e7ff Segment 0xc5932cc0, blocks 4, addr 0x592efff Segment 0xc5932d40, blocks 4, addr 0x592f7ff Segment 0xc5932dc0, blocks 4, addr 0x592ffff Segment 0xc5932e40, blocks 4, addr 0x59307ff Segment 0xc5932ec0, blocks 4, addr 0x5930fff Segment 0xc5932f40, blocks 4, addr 0x59317ff Segment 0xc59420a0, blocks 4, addr 0x5932fff Segment 0xc5942120, blocks 4, addr 0x59337ff Segment 0xc59421a0, blocks 4, addr 0x5933fff Segment 0xc5942220, blocks 4, addr 0x59347ff Segment 0xc59422a0, blocks 4, addr 0x5934fff Segment 0xc5942320, blocks 4, addr 0x59357ff Segment 0xc59423a0, blocks 4, addr 0x5935fff Segment 0xc5942420, blocks 4, addr 0x59367ff Segment 0xc59424a0, blocks 4, addr 0x5936fff Segment 0xc5942520, blocks 4, addr 0x59377ff Segment 0xc59425a0, blocks 4, addr 0x5937fff Segment 0xc5942620, blocks 4, addr 0x59387ff Segment 0xc59426a0, blocks 4, addr 0x5938fff Segment 0xc5942720, blocks 4, addr 0x59397ff Segment 0xc59427a0, blocks 4, addr 0x5939fff Segment 0xc5942820, blocks 4, addr 0x593a7ff Segment 0xc59428a0, blocks 4, addr 0x593afff Segment 0xc5942920, blocks 4, addr 0x593b7ff Segment 0xc59429a0, blocks 4, addr 0x593bfff Kernel panic: Ththththaats all folks. Too dangerous to continue. -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
On Fri, Sep 08 2000, adam@cfar.umd.edu wrote:
Incorrect number of segments after building list nr_segments is 3 counted segments is 20 Flags 0 0 Segment 0xc59cf920, blocks 4, addr 0x59177ff [snip]
Try attached patch, I hadn't noticed the segment counts were wrong
because I have implicit recounting.
--
* Jens Axboe
Try attached patch, I hadn't noticed the segment counts were wrong because I have implicit recounting.
Yes, this patch fixes the problem, thanks. Once I aplied I could mount the cd and write a file to it, so it seems to work. Three semi-related comments. The udf from cvs tree has annoying habbit to put udf.o in /fs/udf.o dir while new modutils put udf.o in kernel/fs/udf/udf.o so if you are not carefull you still will load old udf.o driver, evern after unning 'make install' from udf cvs tree. So when using packet mode with udf I get just 450mb out of 650mb cd? pktcdvd reports the read speed as 6x, shouldn't it be 8x as this is 8432 drive. Just for kicks I have attached output of dmesg while using the cd-rw to mount and write in block mode on udf filesystem. Thanks for great work! I finally should be able to use cd-rw in packet mode! -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
Jens Axboe wrote:
Hi,
This project has been sleeping for a while, so I thought it was about time something happened. And now it has - I've put up version 0.0.2c of the CD-RW packet writing module, aka the "happy birthday grandma" release 8)
A summary of some of the changes:
- inc usage count of buffer heads - add internal buffer pool to avoid deadlock on oom - gather data for as many buffers as we have, before initiating write. this allows the laser to stay on longer, giving better performance. - fix always busy when tray can't be locked - remove request duplication nastiness, inject directly into the target - adapted to devfs and elevator changes - added proc interface
Not a whole lot, this is just to get the ball rolling again. However, the addition of the internal buffer pool was something that should have been added a long time ago. So this release should be significantly more stable than 0.0.2b -- at least it is for me, your mileage may vary.
It's still blowing away the whole packet on write for me, at least on my IDE drive (I havn't tried the SCSI yet). After mounting/unmounting (so only 1 block gets written) trying to read back any block in the packet gives: hdc: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error } hdc: cdrom_decode_status: error=0x30 hdc: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error } hdc: cdrom_decode_status: error=0x30 hdc: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error } hdc: cdrom_decode_status: error=0x30 hdc: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error } hdc: cdrom_decode_status: error=0x30 hdc: DMA disabled hdc: ATAPI reset complete ATAPI device hdc: Error: Unit attention -- (Sense key=0x06) Power on, reset or hardware reset occurred -- (asc=0x29, ascq=0x00) Using cdrwtool, I can rewrite the packet, at which point I can re-read from it. Ben -- Linux UDF - http://linux-udf.sourceforge.net Latest Is - udf-0.9.2.1 (http://www.csc.calpoly.edu/~bfennema/udf.html)
more testings: - I was able to write over 90mb of data to the cdrw. it was without problems (ie maching blowing up as someone else reported). however the write would freeze machien for seconds (as long as 30 sec or even min at time) not even mouse would move then. - the data written onto cd is corrupted. for example [root@pepsi cd1]# tar ztvf ncd19r.tar.gz drwxr-xr-x mrbill/mrbill 0 2000-03-06 14:48:55 ./ -rw-r--r-- mrbill/mrbill 2435664 1999-10-31 14:58:00 Xncd19r gzip: stdin: invalid compressed data--format violated tar: Child returned status 1 tar: Error exit delayed from previous errors [root@pepsi cd1]# gunzip -t ~adam/ncd19r.tar.gz [root@pepsi cd1]# .. so unfortunatelly it is still useless for me for backups :-( -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
On Sat, Sep 09 2000, adam@cfar.umd.edu wrote:
more testings: - I was able to write over 90mb of data to the cdrw. it was without problems (ie maching blowing up as someone else reported).
however the write would freeze machien for seconds (as long as 30 sec or even min at time) not even mouse would move then.
Using SCSI or IDE? UP or SMP?
- the data written onto cd is corrupted. for example
[root@pepsi cd1]# tar ztvf ncd19r.tar.gz drwxr-xr-x mrbill/mrbill 0 2000-03-06 14:48:55 ./ -rw-r--r-- mrbill/mrbill 2435664 1999-10-31 14:58:00 Xncd19r
gzip: stdin: invalid compressed data--format violated tar: Child returned status 1 tar: Error exit delayed from previous errors
[root@pepsi cd1]# gunzip -t ~adam/ncd19r.tar.gz [root@pepsi cd1]#
All the data or some of it? Could I get you to find out where the corruption is taking place -- try doing a cmp of some corrupted files and the originals, to see where the offset is.
.. so unfortunatelly it is still useless for me for backups :-(
We'll get there 8)
--
* Jens Axboe
On Sat, Sep 09 2000, Jens Axboe wrote:
- the data written onto cd is corrupted. for example
[root@pepsi cd1]# tar ztvf ncd19r.tar.gz drwxr-xr-x mrbill/mrbill 0 2000-03-06 14:48:55 ./ -rw-r--r-- mrbill/mrbill 2435664 1999-10-31 14:58:00 Xncd19r
gzip: stdin: invalid compressed data--format violated tar: Child returned status 1 tar: Error exit delayed from previous errors
[root@pepsi cd1]# gunzip -t ~adam/ncd19r.tar.gz [root@pepsi cd1]#
All the data or some of it? Could I get you to find out where the corruption is taking place -- try doing a cmp of some corrupted files and the originals, to see where the offset is.
I can reproduce the corruption here. Ugh, but at least that means that
I can fix it locally as well. It seems to always start at an 2048
byte offset (+1), same for you?
--
* Jens Axboe
Using SCSI or IDE? UP or SMP?
SCSI-over-IDE (EIDE CDRW drive) SMP
All the data or some of it? Could I get you to find out where the corruption is taking place -- try doing a cmp of some corrupted files and the originals, to see where the offset is.
[root@pepsi cd2]# cmp ~adam/ncd19r.tar.gz ncd19r.tar.gz /home/adam/ncd19r.tar.gz ncd19r.tar.gz differ: char 956417, line 2467 -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
On Sat, Sep 09 2000, adam@cfar.umd.edu wrote:
SCSI-over-IDE (EIDE CDRW drive)
SMP
Ok, I test on raw atapi and scsi on my test machine. Also SMP.
All the data or some of it? Could I get you to find out where the corruption is taking place -- try doing a cmp of some corrupted files and the originals, to see where the offset is.
[root@pepsi cd2]# cmp ~adam/ncd19r.tar.gz ncd19r.tar.gz /home/adam/ncd19r.tar.gz ncd19r.tar.gz differ: char 956417, line 2467
Same deal, corruption starts at the beginning of a new 2k sized buffer.
Could you read the first 2048 bytes from the CD-ROM file and check that
this buffer is zero? It is here, which means that a gather-block wasn't
brought properly into memory before being written out.
--
* Jens Axboe
SCSI-over-IDE (EIDE CDRW drive) SMP Ok, I test on raw atapi and scsi on my test machine. Also SMP.
Hmm speaking of this, do I still need to use ide-scsi in order to use packet writing? AFAIK I do need to use it for cdrwite.
All the data or some of it? Could I get you to find out where the corruption is taking place -- try doing a cmp of some corrupted files and the originals, to see where the offset is.
[root@pepsi cd2]# cmp ~adam/ncd19r.tar.gz ncd19r.tar.gz /home/adam/ncd19r.tar.gz ncd19r.tar.gz differ: char 956417, line 2467
Same deal, corruption starts at the beginning of a new 2k sized buffer. Could you read the first 2048 bytes from the CD-ROM file and check that this buffer is zero? It is here, which means that a gather-block wasn't brought properly into memory before being written out.
I'm not sure I get it. This or other way here are bytes from beginning of file. [root@pepsi cd2]# od -t x1 ncd19r.tar.gz | head -75 0000000 1f 8b 08 08 b8 0b c4 38 00 03 6e 63 64 31 39 72 0000020 2e 74 61 72 00 e4 bd 7f 7c 5c c5 75 37 7c f6 ee 0000040 ae b4 b6 04 ba 92 d7 62 31 c2 ec 6a af 56 6b 23 [...] 0002000 f1 8e df fd fc 6d bf ad cb 50 d3 2d de d0 ec 13 0002020 bc ae 34 ed 76 ff d2 db f0 ef c3 a4 e4 5f 6f e0 0002040 6c 3b 4c 55 d4 13 8f b4 7a ce ca 71 ff e9 21 db 0002060 69 f5 66 d1 10 3b d2 ea fd ce f6 e6 8d 88 53 e9 And using tar shows that beginning of file is ok as well. [root@pepsi cd2]# tar ztvf ncd19r.tar.gz drwxr-xr-x mrbill/mrbill 0 2000-03-06 14:48:55 ./ -rw-r--r-- mrbill/mrbill 2435664 1999-10-31 14:58:00 Xncd19r gzip: stdin: invalid compressed data--format violated tar: Child returned status 1 tar: Error exit delayed from previous errors btw: is the 450mb of 650mb the penlaty I pay for using UDF over ISO9600 and for using RW instead of RO? -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
On Sat, Sep 09 2000, adam@cfar.umd.edu wrote:
(EIDE CDRW drive) SMP Ok, I test on raw atapi and scsi on my test machine. Also SMP.
Hmm speaking of this, do I still need to use ide-scsi in order to use packet writing? AFAIK I do need to use it for cdrwite.
No, the packet writing patch adds write support to ide-cd as well.
[root@pepsi cd2]# cmp ~adam/ncd19r.tar.gz ncd19r.tar.gz /home/adam/ncd19r.tar.gz ncd19r.tar.gz differ: char 956417, line 2467
Same deal, corruption starts at the beginning of a new 2k sized buffer. Could you read the first 2048 bytes from the CD-ROM file and check that this buffer is zero? It is here, which means that a gather-block wasn't brought properly into memory before being written out.
I'm not sure I get it. This or other way here are bytes from beginning of file.
[root@pepsi cd2]# od -t x1 ncd19r.tar.gz | head -75 0000000 1f 8b 08 08 b8 0b c4 38 00 03 6e 63 64 31 39 72
Sorry, I wasn't being very clear. The corruption starts at byte 956417 according to your cmp above. So if you could dump 2048 bytes from the cdrom input file starting at 956416 and dump that, it would help a lot.
btw: is the 450mb of 650mb the penlaty I pay for using UDF over ISO9600 and for using RW instead of RO?
No, this appears to be a bug in cdrwtool when setting up the
space. It does this on one of my drives too, I've noticed. You should
be able to get around 550MB space on the disc.
--
* Jens Axboe
Sorry, I wasn't being very clear. The corruption starts at byte 956417 according to your cmp above. So if you could dump 2048 bytes from the cdrom input file starting at 956416 and dump that, it would help a lot.
Ok, the command was : od -j 956000 -N 20000 -v -t x1 ncd19r.tar.gz > /tmp/dump the file is 76k and the dump is in : http://www.eax.com/other/dump I hope to have a more nice test case using special test file. -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
I hope to have a more nice test case using special test file.
and indeed. The file is 1.6mb and you can find it at http://www.eax.com/other/test.tgz [root@pepsi /tmp]# tar ztvf test.tgz -rw-rw-r-- adam/adam 12162502 2000-09-09 11:58:17 test.file.corr -rw-rw-r-- adam/adam 12162502 2000-09-09 11:51:00 test.file.orig -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
On Sat, Sep 09 2000, adam@cfar.umd.edu wrote:
I hope to have a more nice test case using special test file.
and indeed. The file is 1.6mb and you can find it at
http://www.eax.com/other/test.tgz
[root@pepsi /tmp]# tar ztvf test.tgz -rw-rw-r-- adam/adam 12162502 2000-09-09 11:58:17 test.file.corr -rw-rw-r-- adam/adam 12162502 2000-09-09 11:51:00 test.file.orig
Thanks, shows the exact same error I've reproduced here (a block
was zero-filled, when it shouldn't have been).
--
* Jens Axboe
Jens Axboe wrote:
btw: is the 450mb of 650mb the penlaty I pay for using UDF over ISO9600 and for using RW instead of RO?
No, this appears to be a bug in cdrwtool when setting up the space. It does this on one of my drives too, I've noticed. You should be able to get around 550MB space on the disc.
First, on the drive that gives 450mb could you stick in a blank cdrw and run cdrwtool -i on it and send me the output? Second, the (normal) ~550MB is due to packet writing overhead. So for every packet written there is 7 blocks lost do to lead-in/lead-out/link blocks. Ben -- Linux UDF - http://linux-udf.sourceforge.net Latest Is - udf-0.9.2.1 (http://www.csc.calpoly.edu/~bfennema/udf.html)
On Sat, Sep 09 2000, Ben Fennema wrote:
btw: is the 450mb of 650mb the penlaty I pay for using UDF over ISO9600 and for using RW instead of RO?
No, this appears to be a bug in cdrwtool when setting up the space. It does this on one of my drives too, I've noticed. You should be able to get around 550MB space on the disc.
First, on the drive that gives 450mb could you stick in a blank cdrw and run cdrwtool -i on it and send me the output?
bart:/tmp/udf/udf/tools # ./cdrwtool -d /dev/scd0 -i using device /dev/scd0 2317KB internal buffer setting write speed to 4x DISC INFO: erasable : Yes border = 0 Disc status = 0 number of first track = 1 number of sessions = 1 number of tracks = 1 status of last track = 1 uru = 0 did_v = 0 dbc_v = 0 disc type = 255 disc_id = 0 OPC entries = 0 TRACK INFO: Track 1 track_number = 1 session_number = 1 damage = 0 copy = 0 track_mode = 0 Rt = 0 blank = 1 packet = 0 fp = 0 data_mode = 15 lra_v = 0 nwa_v = 1 track_start = 0 next_writable = 0 last_recorded = 0 free_blocks = 336154 packet_size = 0 track_size = 336154 (672308KB) See, this looks ok. But doing cdrwtool -q only gives the reported 450MB. I noticed this some time ago, but it was low prio to me so I put off fixing cdrwtool.
Second, the (normal) ~550MB is due to packet writing overhead. So for every packet written there is 7 blocks lost do to lead-in/lead-out/link blocks.
Yup
--
* Jens Axboe
On Sat, Sep 09 2000, adam@cfar.umd.edu wrote:
however the write would freeze machien for seconds (as long as 30 sec or even min at time) not even mouse would move then.
Just a heads up on this bug, I've fixed it now. The problem was that cd-rw is a slow writer, as compared to a hard drive. I've maintained a patch on the side for the regular kernel, that batches freeing of requests once they are completed. That means once the request free list is empty, we wait until a certain fraction of the total requests are available before waking anyone up and handing them a free slot. This works well when a queue is under pressure because it provides some rudimentary flow control and allows the elevator to do a better job at merging new buffers. Back to the point -- for cd-rw, completing 16 requests can take a _lot_ of time. During this time, kflushd and kupdated would often be stuck for long periods of time waiting for a slot. No buffers could thus be flushed. Eek. For packet writing, we now wake for every free. There are still some stalls because it is slow (try using a dvd-ram, you'll see the same behaviour). But the stalls are much smaller now, around one second every once in a while. Hopefully I can fix this too.
- the data written onto cd is corrupted. for example
And a second heads up, I think I've nailed this one as well. I need
to do some more testing to be sure, though.
Unrelated info -- there's a rather severe bug in 0.0.2c that causes
buffers written to cd-rw not to be freed. Pretty stupid one too, the
folks on low memory machines will surely notice. A quick fix for that
is to move the atomic_inc(&bh->b_state) in the pkt_init_bh function
inside the if (bh->b_private == pd):
if (bh->b_private == pd) {
atomic_inc(&bh->b_count);
bh->b_end_io = pkt_end_io_write;
}
--
* Jens Axboe
bug #1 and bug #2 fixed.
cool, thanks.
Unrelated info -- there's a rather severe bug in 0.0.2c that causes buffers written to cd-rw not to be freed. Pretty stupid one too, the
I think I can feel it, especially if amount of taken memory is proportional to size of write. I have like 200mb ram, but machine feels slower than usuall.. .... so this makes me wonder, how about 0.0.2d against 2.4.0-test8 plus all known fixes ? -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
On Sat, Sep 09 2000, adam@cfar.umd.edu wrote:
Unrelated info -- there's a rather severe bug in 0.0.2c that causes buffers written to cd-rw not to be freed. Pretty stupid one too, the
I think I can feel it, especially if amount of taken memory is proportional to size of write. I have like 200mb ram, but machine feels slower than usuall..
The amount of memory eaten is the amount written to disc, minus the buffers from the internal pool. I first noticed it when doing low memory testing, I hit swap in no time.
.... so this makes me wonder, how about 0.0.2d against 2.4.0-test8 plus all known fixes ?
You betcha, coming later today or tomorrow.
--
* Jens Axboe
On Sat, Sep 09 2000, Ben Fennema wrote:
It's still blowing away the whole packet on write for me, at least on my IDE drive (I havn't tried the SCSI yet).
After mounting/unmounting (so only 1 block gets written) trying to read back any block in the packet gives:
hdc: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error } hdc: cdrom_decode_status: error=0x30 hdc: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error } hdc: cdrom_decode_status: error=0x30 hdc: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error } hdc: cdrom_decode_status: error=0x30 hdc: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error } hdc: cdrom_decode_status: error=0x30 hdc: DMA disabled hdc: ATAPI reset complete ATAPI device hdc: Error: Unit attention -- (Sense key=0x06) Power on, reset or hardware reset occurred -- (asc=0x29, ascq=0x00)
Using cdrwtool, I can rewrite the packet, at which point I can re-read from it.
Hmm, bad bad. Can I get you to check if pktcdvd sets up the write
parameters differently than cdrwtool?
--
* Jens Axboe
participants (3)
-
adam＠cfar.umd.edu -
Ben Fennema -
Jens Axboe