[BUG] 2.6.24-mm1 and 2.6.24-git13 kernel panic's while bootup at ide_device_add_all
Hi,
The kernel bootup panics with the 2.6.24-mm1 and 2.6.24-git13 kernel
while defconfig compiled in for x86_64 (Intel(R) Xeon) box
BUG: unable to handle kernel paging request at ffb0
IP: [80413642] init_irq+0x188/0x444
PGD 203067 PUD 204067 PMD 0
Oops: [1] SMP
CPU 2
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.24 #1
RIP: 0010:[80413642] [80413642] init_irq+0x188/0x444
RSP: 0018:81022f093e00 EFLAGS: 00010287
RAX: ff90 RBX: 808a9100 RCX:
RDX: RSI: 81022fc039c0 RDI: 8074dd00
RBP: 81022f093e30 R08: 808af880 R09: 0002
R10: 0001 R11: 810bed60 R12: 808b0400
R13: 808b0410 R14: R15:
FS: () GS:81022f0883c0() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: ffb0 CR3: 00201000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process swapper (pid: 1, threadinfo 81022f092000, task 81022f0797d0)
Stack: 81022f093e30 808a9100 808a9120
ffed 81022f093eb0 80414425
81022f093ec0 8074e920 0246
Call Trace:
[80414425] ide_device_add_all+0xb27/0xe1b
[807d2884] ide_generic_init+0x3a/0x3e
[807b473b] kernel_init+0x175/0x2e7
[8020bff8] child_rip+0xa/0x12
[80372350] ? acpi_ds_init_one_object+0x0/0x88
[807b45c6] ? kernel_init+0x0/0x2e7
[8020bfee] ? child_rip+0x0/0x12
Code: 89 03 49 8b 45 18 48 89 18 48 39 1b 75 04 0f 0b eb fe fe 05 51 51 38 00
fb eb 5b 48 8b 83 28 07 00 00 83 ca ff 48 83 e8 70 74 0e 48 8b 40 20 48 8b 80
88 00 00 00 8b 50 04 48 8b 3d 79 ff 2f 00
RIP [80413642] init_irq+0x188/0x444
RSP 81022f093e00
CR2: ffb0
---[ end trace 9010a4c8c4ba608a ]---
(gdb) p init_irq
$1 = {int (ide_hwif_t *)} 0x804134ba init_irq
(gdb) p/x 0x804134ba+0x188
$2 = 0x80413642
(gdb) l *0x80413642
0x80413642 is in init_irq (include/linux/ide.h:1311).
1306print_hex_dump(KERN_INFO, , DUMP_PREFIX_NONE, 16, 2, id, 512,
0);
1307}
1308
1309static inline int hwif_to_node(ide_hwif_t *hwif)
1310{
1311struct pci_dev *dev = to_pci_dev(hwif-dev);
1312return dev ? pcibus_to_node(dev-bus) : -1;
1313}
1314
1315static inline ide_drive_t *ide_get_paired_drive(ide_drive_t *drive)
(gdb)
(gdb) p ide_device_add_all
$1 = {int (u8 *, const struct ide_port_info *)} 0x804138fe
ide_device_add_all
(gdb) p/x 0x804138fe
$2 = 0x804138fe
(gdb) l *0x804138fe
0x804138fe is in ide_device_add_all (drivers/ide/ide-probe.c:1372).
1367hwif-cbl = hwif-cable_detect(hwif);
1368}
1369}
1370
1371int ide_device_add_all(u8 *idx, const struct ide_port_info *d)
1372{
1373ide_hwif_t *hwif, *mate = NULL;
1374int i, rc = 0;
1375
1376for (i = 0; i MAX_HWIFS; i++) {
(gdb)
--
Thanks Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] blk_end_request: full I/O completion handler
On Tue, Feb 05 2008, S, Chandrakala (STSD) wrote: Hello, We would like to know in which kernel version these patches are available. They were merged after 2.6.24 was released, so they will show up in the 2.6.25 kernel. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/7] blk_end_request: full I/O completion handler
Hello,
We would like to know in which kernel version these patches are
available.
Thanks,
Chandrakala
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jens Axboe
Sent: Monday, September 03, 2007 1:16 PM
To: Kiyoshi Ueda
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-ide@vger.kernel.org; Miller, Mike (OS Dev);
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PATCH 0/7] blk_end_request: full I/O completion handler
On Fri, Aug 31 2007, Kiyoshi Ueda wrote:
Hello,
This set of patches changes request completion interface between
device drivers and block layer to 1 step procedure from current 2 step
procedures using end_that_request_{first/chunk} and
end_that_request_last().
This change allows request-based multipath to hook in before
completing each chunk of request, check errors for it and retry it
using another path if error is detected.
Summaries of each patch are below:
1/7: add new request completion interface, blk_end_request()
2/7: add some macros to get the size of request in bytes
3/7: convert normal drivers to use blk_end_request()
4/7: convert odd drivers like cciss/cpqarray/xsysace to use
blk_end_request()
5/7: convert ide-cd (cdrom_newpc_intr) to use blk_end_request()
6/7: remove/unexport no longer needed end_that_request_*
7/7: change rq-end_io to cover request completion as a whole
I have tested the patch on two machines, ia64+QLA1280+QLA2200 and
x86_64+SATA+IDE-CDROM.
I can't test other device drivers for which I don't have hardware.
So testing help and any comments would be very much appreciated.
The interface change causes code modifications of *ALL DEVICE DRIVERS*
which are using end_that_request_{first/chunk/last} to complete
request.
But it should not affect the behavior.
Please review and apply if no problem.
This patch-set should be applied on top of 2.6.23-rc3-mm1.
BACKGROUND
==
The patch is necessary to allow device stacking at request level, that
is request-based device-mapper multipath.
Currently, device-mapper is implemented as a stacking block device at
BIO level. OTOH, request-based DM will stack at request level to
allow better multipathing decision.
To allow device stacking at request level, the completion procedure
need to provide a hook for it.
For example, dm-multipath has to check errors and retry with other
paths if necessary before returning the I/O result to upper layer.
struct request has 'end_io' hook currently. But it's called at the
very late stage of completion handling where the I/O result is already
returned to the upper layer.
So we need something here.
The first approach to hook in completion of each chunk of request was
adding a new rq-end_io_first() hook and calling it on the top of
__end_that_request_first().
- http://marc.theaimsgroup.com/?l=linux-scsim=115520444515914w=2
- http://marc.theaimsgroup.com/?l=linux-kernelm=116656637425880w=2
However, Jens pointed out that redesigning rq-end_io() as a full
completion handler would be better:
On Thu, 21 Dec 2006 08:49:47 +0100, Jens Axboe [EMAIL PROTECTED]
wrote:
Ok, I see what you are getting at. The current -end_io() is called
when the request has fully completed, you want notification for each
chunk potentially completed.
I think a better design here would be to use -end_io() as the full
completion handler, similar to how bio-bi_end_io() works. A request
originating from __make_request() would set something ala:
.
instead of calling the functions manually. That would allow you to
get notification right at the beginning and do what you need,
without adding a special hook for this.
I thought his comment was reasonable.
So I modified the patches based on his suggestion.
WHAT IS CHANGED
===
The change is basically illustlated by the following pseudo code:
[Before]
if (end_that_request_{first/chunk} succeeds) { -- completes bios
do something driver specific
end_that_request_last() -- calls end_io()
the request is free from the driver
} else {
the request was incomplete, retry for leftover or ignoring
}
[After]
if (blk_end_request() succeeds) { -- calls end_io(), completes bios
the request is free from the driver
} else {
the request was incomplete, retry for leftover or ignoring
}
In detail, request completion procedures are changed like below.
[Before]
o 2 steps completion using end_that_request_{first/chunk}
and end_that_request_last().
o Device drivers have ownership of a request until they
call end_that_request_last().
o rq-end_io() is called at the last stage of
end_that_request_last() for some block layer codes need
specific request handling when completing it.
[After]
o 1 step completion using blk_end_request().
(end_that_request_* are no longer used from device
slow resume from s2ram
Hello, I can't get my otherwise lovely debian/sid Vaio TX17 to resume promptly from suspend-to-ram. Until recently it resumed at all maybe 1 in 4 times from 's2ram -f -p' in X, always taking several minutes, apparently due to the hard disk (1.8 Toshiba HDD1544/MK6006GAH). Last week I tried 2 things: * added /etc/modprobe.d/libata with options libata noacpi=0 * built a kernel + initrd from debian linux-source-2.6.24 with CONFIG_BLK_DEV_IDEACPI=y This boots OK, with ... $ cat /sys/module/libata/parameters/noacpi 0 But the only improvement is that, from X, it resumes every time (maybe 10 times so far). It still takes about 90 seconds (the disc light is on for the 1st 30 seconds, then after another 60 seconds it comes on again the display comes back). This is with the s2ram from debian/sid current uswsusp. Oddly, s2ram has always worked best from X. dmesg below ... presumably the delay is connected to the lines ... hda: lost interrupt hda: dma_timer_expiry: dma status == 0x21 Any ideas? Thanks, Brian Keck -- Linux version 2.6.24 (2.6.24-1) ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-5)) #2 SMP Fri Feb 1 20:28:43 EST 2008 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 3f69 (usable) BIOS-e820: 3f69 - 3f69d000 (ACPI data) BIOS-e820: 3f69d000 - 3f70 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: e000 - f0006000 (reserved) BIOS-e820: f0008000 - f000c000 (reserved) BIOS-e820: fed2 - fed9 (reserved) BIOS-e820: ff00 - 0001 (reserved) 118MB HIGHMEM available. 896MB LOWMEM available. Entering add_active_range(0, 0, 259728) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 HighMem229376 - 259728 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 259728 On node 0 totalpages: 259728 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 237 pages used for memmap HighMem zone: 30115 pages, LIFO batch:7 Movable zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000F6790, 0014 (r0 PTLTD ) ACPI: RSDT 3F697E7C, 0044 (r1 Sony V1 20050805 PTL 0) ACPI: FACP 3F69CE78, 0084 (r2 Sony V1 20050805 PTL50) ACPI: DSDT 3F69896F, 4509 (r1 Sony V1 20050805 PTL 10E) ACPI: FACS 3F6ADFC0, 0040 ACPI: APIC 3F69CEFC, 0068 (r1 Sony V1 20050805 PTL50) ACPI: BOOT 3F69CFD8, 0028 (r1 Sony V1 20050805 PTL 1) ACPI: MCFG 3F69CF9C, 003C (r1 Sony V1 20050805 PTL5F) ACPI: SSDT 3F69873D, 022E (r1 Sony V1 20050805 PTL 20030224) ACPI: SSDT 3F6982F8, 0235 (r1 Sony V1 20050805 PTL 20030224) ACPI: SSDT 3F6980D9, 021F (r1 Sony V1 20050805 PTL 20030224) ACPI: SSDT 3F697EC0, 0219 (r1 Sony V1 20050805 PTL 20030224) ACPI: DMI detected: Sony ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:13 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 5000 (gap: 4000:a000) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 257699 Kernel command line: root=/dev/hda2 ro mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 1197.028 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1020860k/1038912k available (1692k kernel code, 17256k reserved, 671k data, 216k init, 121408k highmem) virtual kernel memory layout: fixmap : 0xfff4d000 - 0xf000 ( 712 kB) pkmap : 0xff80 -
Re: AHCI driver preferring nr_ports over port map
Does the following patch fix the problem?
Yes, it does - thanks!
Jan
*
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index e75966b..39627c7 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -679,24 +679,20 @@ static void ahci_save_initial_config(struct pci_dev *pdev,
/* cross check port_map and cap.n_ports */
if (port_map) {
- u32 tmp_port_map = port_map;
- int n_ports = ahci_nr_ports(cap);
+ int map_ports = 0;
- for (i = 0; i AHCI_MAX_PORTS n_ports; i++) {
- if (tmp_port_map (1 i)) {
- n_ports--;
- tmp_port_map = ~(1 i);
- }
- }
+ for (i = 0; i AHCI_MAX_PORTS; i++)
+ if (port_map (1 i))
+ map_ports++;
- /* If n_ports and port_map are inconsistent, whine and
-* clear port_map and let it be generated from n_ports.
+ /* If PI has more ports than n_ports, whine and clear
+* port_map and let it be generated from n_ports.
*/
- if (n_ports || tmp_port_map) {
+ if (map_ports ahci_nr_ports(cap)) {
dev_printk(KERN_WARNING, pdev-dev,
- nr_ports (%u) and implemented port map
- (0x%x) don't match, using nr_ports\n,
- ahci_nr_ports(cap), port_map);
+ implemented port map (0x%x) contains more
+ ports than nr_ports (%u), using nr_ports\n,
+ port_map, ahci_nr_ports(cap));
port_map = 0;
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Mon, 2008-02-04 at 21:35 -0800, Luben Tuikov wrote: I guess the same could be said for STGT and SCST, right? You mean both of their kernel pieces are modular? That's correct. No, you know very well what I mean. By the same logic you're preaching to include your solution part of the kernel, you can also apply to SCST. Ah, but it's not ... the current patch is merely exporting an interface. The debate in STGT vs SCST is not whether to export an interface but where to draw the line. You could also argue in the same vein that sd is redundant because a filesystem could talk directly to the device via /dev/sgX (in fact OSD based filesystems already do this). The argument is true, but misses the bigger picture that the interfaces exported by sd are more portable (apply to non-SCSI block devices) and easier to use. Yes, for which the transport layer, implements the scsi device node for the SES device. It doesn't really matter if the SCSI commands sent to the SES device go over SGPIO or FC or SAS or Bluetooth or I2C, etc, the transport layer can implement that and present the /dev/sgX node. But it does matter if the enclosure device doesn't speak SCSI. Enclosure management isn't as simple as you're portraying it here. The enclosure management device speaks either SES or SAF-TE. The transport protocol to access it could be SGPIO or I2C or... Look, just read the spec; SGPIO is a bus for driving enclosures ... it doesn't require SES or SAF-TE or even any SCSI protocol. SGPIO isn't a SCSI protocol ... it's a general purpose serial bus protocol. It's pretty simple and register based, but it might (or might not) be accessible via a SCSI bridge. I see. You've just discovered SGPIO -- good for you. At any rate, I told you already that what is needed is not what you've provided but a _device node_ exported by the kernel, either a processor or enclosure type. Wrong ... we don't export non-SCSI devices as SCSI (with the single and rather annoying exception of ATA via SAT). James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (fwd) Bug#11922: I/O error on blank tapes
On Mon, 4 Feb 2008, James Bottomley wrote: On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote: On Mon, Feb 04, 2008 at 03:22:06PM +0100, maximilian attems wrote: (Added Bart to CC) hello borislav, may i forward you that *old* Debian kernel bug, have seen you working on ide-tape: http://bugs.debian.org/11922 no we don't carry any ide patches anymore. maybe you've already fixed it in latest? thanks -- maks - Forwarded message from Stephen Kitt [EMAIL PROTECTED] - Subject: Bug#11922: I/O error on blank tapes Date: Sat, 1 Dec 2007 19:06:18 +0100 From: Stephen Kitt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi, This does still occur with 2.6.22; with a blank tape in my HP DDS-4 drive: $ tar tzvf /dev/nst0 tar: /dev/nst0: Cannot read: Input/output error That's a SCSI tape, not an IDE one. I cc'd the SCSI list This is not a bug, it is a feature. There is _nothing_ on the tape and if you try to read something, you get an error. The same thing applies to reading after the last filemark. Note that after writing a filemark at the beginning of the tape, the situation is different. Now there is a file and the normal EOF semantics apply although there still is no data. I admit that the error return could be more descriptive but the st driver tries to be compatible with other Unices. The behavior can be changed if Linux does not match other Unices. I don't remember if I have tested just this with other Unices. I will try to test this with Tru64 tomorrow. If anyone has data on other Unices, it would be helpful. -- Kai - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata pm
Hi everybody,
it looks like this will be a never ending story...
After I got the new PSU and the raid was in full sync without any
error for 48h, I thought all problems were gone. Today the sata errors
reappeared and whenever the load is high enough I get the following:
I exchanged two (probably failing) of the eight harddrives with new ones.
All remaining disks have a good smart state and are fully readable when
the raid is not active. As long as I mount the filesystem on the raid
readonly there wont happen any error, but the moment I mount it rw and try
to copy something to the fs on the raid I get the already known timeout.
At least I get a little bit desperate now...
ata10.00: failed to read SCR 1 (Emask=0x40)
ata10.01: failed to read SCR 1 (Emask=0x40)
ata10.02: failed to read SCR 1 (Emask=0x40)
ata10.03: failed to read SCR 1 (Emask=0x40)
ata10.04: failed to read SCR 1 (Emask=0x40)
ata10.05: failed to read SCR 1 (Emask=0x40)
ata10.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.01: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.01: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 1 cdb 0x0 data 0
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata10.01: status: { DRDY }
ata10.02: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.03: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.04: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.05: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.15: hard resetting link
ata10.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
ata10.00: hard resetting link
ata10.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.01: hard resetting link
ata10.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.02: hard resetting link
ata10.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.03: hard resetting link
ata10.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.04: hard resetting link
ata10.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.05: hard resetting link
ata10.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata10.00: configured for UDMA/100
ata10.01: configured for UDMA/100
ata10.03: configured for UDMA/100
ata10.04: configured for UDMA/100
ata10: EH complete
sd 9:0:0:0: [sdl] 976773168 512-byte hardware sectors (500108 MB)
sd 9:0:0:0: [sdl] Write Protect is off
sd 9:0:0:0: [sdl] Mode Sense: 00 3a 00 00
sd 9:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:1:0:0: [sdm] 976773168 512-byte hardware sectors (500108 MB)
sd 9:1:0:0: [sdm] Write Protect is off
sd 9:1:0:0: [sdm] Mode Sense: 00 3a 00 00
sd 9:1:0:0: [sdm] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:2:0:0: [sdn] 976773168 512-byte hardware sectors (500108 MB)
sd 9:2:0:0: [sdn] Write Protect is off
sd 9:2:0:0: [sdn] Mode Sense: 00 3a 00 00
sd 9:2:0:0: [sdn] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:3:0:0: [sdo] 976773168 512-byte hardware sectors (500108 MB)
sd 9:3:0:0: [sdo] Write Protect is off
sd 9:3:0:0: [sdo] Mode Sense: 00 3a 00 00
sd 9:3:0:0: [sdo] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:4:0:0: [sdp] 976773168 512-byte hardware sectors (500108 MB)
sd 9:4:0:0: [sdp] Write Protect is off
sd 9:4:0:0: [sdp] Mode Sense: 00 3a 00 00
sd 9:4:0:0: [sdp] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] IDE updates part #4
On Sat, 2 Feb 2008, Bartlomiej Zolnierkiewicz wrote: * next part of IDE probing code re-organization saga (that would be me) This seems to cause very irritating and bogus messages for me: Probing IDE interface ide0... Probing IDE interface ide1... ide2: I/O resource 0x0-0x7 not free. ide2: ports already in use, skipping probe ide3: I/O resource 0x0-0x7 not free. ide3: ports already in use, skipping probe ide4: I/O resource 0x0-0x7 not free. ide4: ports already in use, skipping probe ide5: I/O resource 0x0-0x7 not free. ide5: ports already in use, skipping probe ide6: I/O resource 0x0-0x7 not free. ide6: ports already in use, skipping probe ide7: I/O resource 0x0-0x7 not free. ide7: ports already in use, skipping probe ide8: I/O resource 0x0-0x7 not free. ide8: ports already in use, skipping probe ide9: I/O resource 0x0-0x7 not free. ide9: ports already in use, skipping probe and that's just totally bogus. It shouldn't even request that region, since it's not been allocated! So that ide_device_add_all() is missing some checks. Should it check the probe[] array like ideprobe_init() used to, or what? Linus - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 2.6.24-git] ARM/RPC: Use HAVE_PATA_PLATFORM to select pata platform driver
On Sat, Feb 02, 2008 at 04:21:35PM +, Ben Dooks wrote: Use HAVE_PATA_PLATFORM for ARCH_RPC Cc: Linux ARM Kernel [EMAIL PROTECTED] Cc: Russell King [EMAIL PROTECTED] Signed-off-by: Ben Dooks [EMAIL PROTECTED] Patch is fine. Acked-by: Russell King [EMAIL PROTECTED] Thanks. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
--- On Tue, 2/5/08, James Bottomley [EMAIL PROTECTED] wrote: I guess the same could be said for STGT and SCST, right? You mean both of their kernel pieces are modular? That's correct. No, you know very well what I mean. By the same logic you're preaching to include your solution part of the kernel, you can also apply to SCST. Ah, but it's not ... the current patch is merely exporting an interface. The debate in STGT vs SCST is not whether to export an interface but where to draw the line. draw the line -- I see. BTW, what is wrong with exporting the interface? What is wrong if both implementations are in the kernel and then let the users and distros decide which one they like best and use more? It'll not be the fist time this has happened in the kernel. Both are actively maintained. It seems highly arbitrary to say: X is in the kernel, Y is not. If you want Y, just forget about it and fix X. Give people choice at config time. This is off topic anyway. You could also argue in the same vein that sd is redundant because a filesystem could talk directly to the device via /dev/sgX (in fact OSD based filesystems already do this). Yes, I've mentioned this thing before on this list. Oh, maybe 3 years ago. This is why I had wanted for transport protocols to export ... (oh, let's not get this off topic). (Apparently it takes 3 years...) The argument is true, but misses the bigger picture that the interfaces exported by sd are more portable (apply to non-SCSI block devices) and easier to use. It isn't quite the same thing. It's like comparing apples to oranges. Yes, for which the transport layer, implements the scsi device node for the SES device. It doesn't really matter if the SCSI commands sent to the SES device go over SGPIO or FC or SAS or Bluetooth or I2C, etc, the transport layer can implement that and present the /dev/sgX node. But it does matter if the enclosure device doesn't speak SCSI. Enclosure management isn't as simple as you're portraying it here. The enclosure management device speaks either SES or SAF-TE. The transport protocol to access it could be SGPIO or I2C or... Look, just read the spec; SGPIO is a bus for driving enclosures ... I thought Serial General Purpose Input Output (SGPIO) was a method to serialize general purpose IO signals. it doesn't require SES or SAF-TE or even any SCSI protocol. That's true. And this is why I mentioned a couple of emails ago to simply export a sgpio device node *IF* this is what is needed. Of course devices that use SGPIO abstract it away for their functional purpose, e.g. enclosures, LED, etc, and provide a more general way to control it -- highly hardware specific on one side. Your abstraction currently deals with SES devices and I'd rather leave that to user-space. Alternatively, which I presume is what you're thinking, a HW specific core would be using your abstraction to provide some unified access to raw features, and that unified access isn't defined anywhere, and would likely not be. Alternatively that unified access is things like SES and SAF-TE, which is what vendors prefer to export, or they prefer to drive this directly via other means. That is, I fail to see the kernel bloat, for things that aren't necessary in the kernel. If you want your abstraction to fly, it first needs a common usage model to abstract, and the latter is missing _from the kernel_. Unless I don't know the details and you've been asked to implement this for a single vendor's HW solution. SGPIO isn't a SCSI protocol ... it's a general purpose serial bus protocol. It's pretty simple and register based, but it might (or might not) be accessible via a SCSI bridge. I see. You've just discovered SGPIO -- good for you. At any rate, I told you already that what is needed is not what you've provided but a _device node_ exported by the kernel, either a processor or enclosure type. Wrong ... we don't export non-SCSI devices as SCSI (with the single and rather annoying exception of ATA via SAT). I didn't say you should do that. I had already mentioned that vendors export such controls as either enclosure or processor type devices, and this is why I told you that that is what needs to be exported, which incidentally is a device node of that type. Without a common usage model already in the kernel to abstract (e.g. sd for block device, since you brought that up) your abstraction seems redundant and arbitrary. Your kernel code already uses READ DIAGNOSTIC, etc, and I'd rather leave that to user-space. Luben - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide: another possible ide panic fix for blk-end-request
Hi Boris,
On Tue, 5 Feb 2008 07:01:57 +0100, Borislav Petkov wrote:
On Mon, Feb 04, 2008 at 02:53:12PM -0500, Kiyoshi Ueda wrote:
Hi Jens, Bart, Boris,
I have reviewed all blk-end-request patches again to confirm whether
there are any similar problems with the last week's ide-cd panic:
http://lkml.org/lkml/2008/1/29/140
And I found a possible similar bug in ide-io change:
ide_end_drive_cmd() could be called for blk_pc_request() which could
have bios.
You mean ide_abort() and ide_error(), right?
Because ide{-tape,-floppy,-scsi} do call already ide_end_request()
for non-special rq's (!blk_special_request()), except ide-scsi
filters also on !blk_sense_request().
That's right.
Thanks,
Kiyoshi Ueda
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Tue, 2008-02-05 at 11:33 -0800, Luben Tuikov wrote: Wrong ... we don't export non-SCSI devices as SCSI (with the single and rather annoying exception of ATA via SAT). I didn't say you should do that. I had already mentioned that vendors export such controls as either enclosure or processor type devices, and this is why I told you that that is what needs to be exported, which incidentally is a device node of that type. Without a common usage model already in the kernel to abstract (e.g. sd for block device, since you brought that up) your abstraction seems redundant and arbitrary. Exactly, so the first patch in this series (a while ago now) was a common usage model abstraction of enclosures, and the second was an implementation in terms of SES. I will do one in terms of SGPIO as well ... assuming I ever find a SGPIO enclosure ... Your kernel code already uses READ DIAGNOSTIC, etc, and I'd rather leave that to user-space. You can do it in user space as well. It's just a bit difficult to get information out of a SES enclosure without using it, and getting some of the information is a requirement of the abstraction. James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
--- On Tue, 2/5/08, James Bottomley [EMAIL PROTECTED] wrote: Wrong ... we don't export non-SCSI devices as SCSI (with the single and rather annoying exception of ATA via SAT). I didn't say you should do that. I had already mentioned that vendors export such controls as either enclosure or processor type devices, and this is why I told you that that is what needs to be exported, which incidentally is a device node of that type. Without a common usage model already in the kernel to abstract (e.g. sd for block device, since you brought that up) your abstraction seems redundant and arbitrary. Exactly, so the first patch in this series (a while ago ^^^ See last paragraph. now) was a common usage model abstraction of enclosures, and the second was an implementation in terms of SES. I will do one in terms of SGPIO as well ... assuming I ever find a SGPIO enclosure ... The vendor would've abstracted that away most commonly using SES. Your kernel code already uses READ DIAGNOSTIC, etc, and I'd rather leave that to user-space. You can do it in user space as well. It's just a bit difficult to get information out of a SES enclosure without using it, and getting some of the information is a requirement of the abstraction. You missed my point. Your abstraction is redundant and arbitrary -- it is not based on any known, in-practice, usage model, already in place that needs a better, common way of doing XYZ, and therefore needs an abstraction. Luben - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem burning DVDs with Marvell 88SE6121 on pata_marvell
(added linux-ide) On Sat, 2 Feb 2008 16:30:04 -0600 Mike Hokenson [EMAIL PROTECTED] wrote: I recently put together a new system with a MSI P35 PLATINUM and although reading from data CDs, DVDs, and watching DVD movies is working fine, DVD burning isn't. MSI's manual says 1 IDE port by Marvell 88SE6111, but lspci says it's a 88SE6121. I have two DVD burners, a SONY DRU-510A and a DRU-820A. They were both working fine with TDK DVD+R media on my ASUS K8V SE DELUXE (VIA IDE controller) prior to the upgrade. Here's what I see with dvd+rw-tools version 7.0-9: sh# dvd+rw-mediainfo /dev/dvd /dev/null # this is blank media :-[ GET CURRENT PERFORMACE failed with SK=5h/ASC=24h/ACQ=00h]: Input/output error :-[ READ TOC failed with SK=5h/ASC=24h/ACQ=00h]: Input/output error sh# growisofs -dvd-compat -speed=2.4 -Z /dev/dvd -rJ -joliet-long -quiet burn Executing 'genisoimage -rJ -joliet-long -quiet burn | builtin_dd of=/dev/dvd obs=32k seek=0' /dev/dvd: Current Write Speed is 2.5x1352KBps. :-[ [EMAIL PROTECTED] failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error :-( write failed: Input/output error /dev/dvd: flushing cache /dev/dvd: closing track :-[ CLOSE TRACK failed with SK=5h/ASC=30h/ACQ=05h]: Wrong medium type /dev/dvd: closing disc :-[ CLOSE DISC failed with SK=5h/ASC=30h/ACQ=05h]: Wrong medium type sh# dvd+rw-mediainfo /dev/dvd /dev/null :-[ READ TRACK INFORMATION failed with SK=3h/ASC=11h/ACQ=05h]: Input/output error (this is 2.6.24) If nothing happens with this report in the next few days, please create an entry at bugzilla.kernel.org so we can keep an eye on it, thanks. Trying older kernels might be interesting, find out if it's a regression or if it was always this way. And from cdrecord version 1.1.6-1: sh# mkisofs -rJ -joliet-long -quiet burn | cdrecord -v dev=/dev/dvd - wodim: No write mode specified. wodim: Asuming -tao mode. wodim: Future versions of wodim may have different drive dependent defaults. TOC Type: 1 = CD-ROM scsidev: '/dev/dvd' devname: '/dev/dvd' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.5.27 Wodim version: 1.1.6 SCSI buffer size: 64512 Device type: Removable CD-ROM Version: 5 Response Format: 2 Capabilities : Vendor_info: 'SONY' Identification : 'DVD RW DRU-820A ' Revision : '1.0c' Device seems to be: Generic mmc2 DVD-R/DVD-RW. Current: 0x0009 (CD-R) Profile: 0x002B (DVD+R/DL) Profile: 0x001B (DVD+R) Profile: 0x001A (DVD+RW) Profile: 0x0016 (DVD-R/DL layer jump recording) Profile: 0x0015 (DVD-R/DL sequential recording) Profile: 0x0014 (DVD-RW sequential recording) Profile: 0x0013 (DVD-RW restricted overwrite) Profile: 0x0012 (DVD-RAM) Profile: 0x0011 (DVD-R sequential recording) Profile: 0x0010 (DVD-ROM) Profile: 0x000A (CD-RW) Profile: 0x0009 (CD-R) (current) Profile: 0x0008 (CD-ROM) Profile: 0x0002 (Removable disk) Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 1114112 = 1088 KB Beginning DMA speed test. Set CDR_NODMATEST environment variable if device communication breaks or freezes immediately after that. FIFO size : 12582912 = 12288 KB Track 01: data unknown length Total size:0 MB (00:00.00) = 0 sectors Lout start:0 MB (00:02/00) = 0 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 4 Is not unrestricted Is not erasable Disk sub type: Medium Type A, high Beta category (A+) (3) ATIP start of lead in: -11849 (97:24/01) ATIP start of lead out: 359847 (79:59/72) Disk type:Long strategy type (Cyanine, AZO or similar) Manuf. index: 25 Manufacturer: Taiyo Yuden Company Limited wodim: WARNING: Total disk size unknown. Data may not fit on disk. Speed set to 7056 KB/s Starting to write CD/DVD at speed 40.0 in real TAO mode for single session. Last chance to quit, starting real write i 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... Starting new track at sector: 0 Track 01:1 MB written (fifo 100%) [buf 97%] 5.4x.Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error CDB: 2A 00 00 00 03 64 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 04 00 00 00 00 0A CF DC 00 00 08 03 00 00 Sense Key: 0x4 Hardware Error, Segment 0 Sense Code: 0x08 Qual 0x03 (logical unit communication crc error (ultra-dma/32)) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 30.186s timeout 40s write track data: error after 1777664 bytes wodim: A write error occured. wodim: Please properly read the error message above. Writing time: 46.572s Fixating... Errno: 5 (Input/output error), close track/session scsi sendcmd: no error CDB: 5B 00 02 00 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00
Re: [PATCH] enclosure: add support for enclosure services
On Sun, 03 Feb 2008 18:16:51 -0600
James Bottomley [EMAIL PROTECTED] wrote:
From: James Bottomley [EMAIL PROTECTED]
Date: Sun, 3 Feb 2008 15:40:56 -0600
Subject: [SCSI] enclosure: add support for enclosure services
The enclosure misc device is really just a library providing sysfs
support for physical enclosure devices and their components.
Thanks for sending it out for review.
+struct enclosure_device *enclosure_find(struct device *dev)
+{
+ struct enclosure_device *edev = NULL;
+
+ mutex_lock(container_list_lock);
+ list_for_each_entry(edev, container_list, node) {
+ if (edev-cdev.dev == dev) {
+ mutex_unlock(container_list_lock);
+ return edev;
+ }
+ }
+ mutex_unlock(container_list_lock);
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(enclosure_find);
This looks a little odd. We don't take a ref on the object after looking
it up, so what prevents some other thread of control from freeing or
otherwise altering the returned object while the caller is playing with it?
+/**
+ * enclosure_for_each_device - calls a function for each enclosure
+ * @fn: the function to call
+ * @data:the data to pass to each call
+ *
+ * Loops over all the enclosures calling the function.
+ *
+ * Note, this function uses a mutex which will be held across calls to
+ * @fn, so it must have user context, and @fn should not sleep or
Probably non atomic context would be more accurate.
fn() actually _can_ sleep.
+ * otherwise cause the mutex to be held for indefinite periods
+ */
+int enclosure_for_each_device(int (*fn)(struct enclosure_device *, void *),
+ void *data)
+{
+ int error = 0;
+ struct enclosure_device *edev;
+
+ mutex_lock(container_list_lock);
+ list_for_each_entry(edev, container_list, node) {
+ error = fn(edev, data);
+ if (error)
+ break;
+ }
+ mutex_unlock(container_list_lock);
+
+ return error;
+}
+EXPORT_SYMBOL_GPL(enclosure_for_each_device);
+
+/**
+ * enclosure_register - register device as an enclosure
+ *
+ * @dev: device containing the enclosure
+ * @components: number of components in the enclosure
+ *
+ * This sets up the device for being an enclosure. Note that @dev does
+ * not have to be a dedicated enclosure device. It may be some other type
+ * of device that additionally responds to enclosure services
+ */
+struct enclosure_device *
+enclosure_register(struct device *dev, const char *name, int components,
+struct enclosure_component_callbacks *cb)
+{
+ struct enclosure_device *edev =
+ kzalloc(sizeof(struct enclosure_device) +
+ sizeof(struct enclosure_component)*components,
+ GFP_KERNEL);
+ int err, i;
+
+ if (!edev)
+ return ERR_PTR(-ENOMEM);
+
+ if (!cb) {
+ kfree(edev);
+ return ERR_PTR(-EINVAL);
+ }
It would be less fuss if this were to test cb before doing the kzalloc().
Can cb==NULL actually and legitimately happen?
+ edev-components = components;
+
+ edev-cdev.class = enclosure_class;
+ edev-cdev.dev = get_device(dev);
+ edev-cb = cb;
+ snprintf(edev-cdev.class_id, BUS_ID_SIZE, %s, name);
+ err = class_device_register(edev-cdev);
+ if (err)
+ goto err;
+
+ for (i = 0; i components; i++)
+ edev-component[i].number = -1;
+
+ mutex_lock(container_list_lock);
+ list_add_tail(edev-node, container_list);
+ mutex_unlock(container_list_lock);
+
+ return edev;
+
+ err:
+ put_device(edev-cdev.dev);
+ kfree(edev);
+ return ERR_PTR(err);
+}
+EXPORT_SYMBOL_GPL(enclosure_register);
+
+static struct enclosure_component_callbacks enclosure_null_callbacks;
+
+/**
+ * enclosure_unregister - remove an enclosure
+ *
+ * @edev:the registered enclosure to remove;
+ */
+void enclosure_unregister(struct enclosure_device *edev)
+{
+ int i;
+
+ if (!edev)
+ return;
Is this legal?
+ mutex_lock(container_list_lock);
+ list_del(edev-node);
+ mutex_unlock(container_list_lock);
See, right now, someone who found this enclosure_device via
enclosure_find() could still be playing with it?
+ for (i = 0; i edev-components; i++)
+ if (edev-component[i].number != -1)
+ class_device_unregister(edev-component[i].cdev);
+
+ /* prevent any callbacks into service user */
+ edev-cb = enclosure_null_callbacks;
+ class_device_unregister(edev-cdev);
+}
+EXPORT_SYMBOL_GPL(enclosure_unregister);
+
+/**
+ * enclosure_component_register - add a particular component to an enclosure
+ * @edev:the enclosure to add the component
+ * @num: the device number
+ * @type:the type of component
Re: [git patches] IDE updates part #4
Hi Linus,
On Tuesday 05 February 2008, Linus Torvalds wrote:
On Sat, 2 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
* next part of IDE probing code re-organization saga
(that would be me)
This seems to cause very irritating and bogus messages for me:
Probing IDE interface ide0...
Probing IDE interface ide1...
ide2: I/O resource 0x0-0x7 not free.
ide2: ports already in use, skipping probe
ide3: I/O resource 0x0-0x7 not free.
ide3: ports already in use, skipping probe
ide4: I/O resource 0x0-0x7 not free.
ide4: ports already in use, skipping probe
ide5: I/O resource 0x0-0x7 not free.
ide5: ports already in use, skipping probe
ide6: I/O resource 0x0-0x7 not free.
ide6: ports already in use, skipping probe
ide7: I/O resource 0x0-0x7 not free.
ide7: ports already in use, skipping probe
ide8: I/O resource 0x0-0x7 not free.
ide8: ports already in use, skipping probe
ide9: I/O resource 0x0-0x7 not free.
ide9: ports already in use, skipping probe
and that's just totally bogus. It shouldn't even request that region,
since it's not been allocated!
So that ide_device_add_all() is missing some checks. Should it check the
probe[] array like ideprobe_init() used to, or what?
This is ide-generic problem exhibited by recent ide_device_add_all() changes.
Fix below (it works for me) - you may merge the patch as it is or wait an hour
or so for the next IDE tree pull request.
Also sorry for the issue in the first place (it turned out that it slipped
my testing because I has been running with IDE_MAX_HWIFS=2 for some time :).
From: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Subject: [PATCH] ide-generic: probing bugfix
On Tuesday 05 February 2008, Linus Torvalds wrote:
On Sat, 2 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
* next part of IDE probing code re-organization saga
(that would be me)
This seems to cause very irritating and bogus messages for me:
Probing IDE interface ide0...
Probing IDE interface ide1...
ide2: I/O resource 0x0-0x7 not free.
ide2: ports already in use, skipping probe
ide3: I/O resource 0x0-0x7 not free.
ide3: ports already in use, skipping probe
ide4: I/O resource 0x0-0x7 not free.
ide4: ports already in use, skipping probe
ide5: I/O resource 0x0-0x7 not free.
ide5: ports already in use, skipping probe
ide6: I/O resource 0x0-0x7 not free.
ide6: ports already in use, skipping probe
ide7: I/O resource 0x0-0x7 not free.
ide7: ports already in use, skipping probe
ide8: I/O resource 0x0-0x7 not free.
ide8: ports already in use, skipping probe
ide9: I/O resource 0x0-0x7 not free.
ide9: ports already in use, skipping probe
and that's just totally bogus. It shouldn't even request that region,
since it's not been allocated!
The commit 139ddfcab50e5eabcc88341c8743a990ac1be6a2 (ide: move handling of
I/O resources out of ide_probe_port()) changed the ordering of hwif-noprobe
check vs ide_hwif_request_regions() call (so that we now reserve I/O regions
before checking for hwif-noprobe). However ide-generic host driver depended
on hwif-noprobe to be set for skipping probing of empty ide_hwifs[] slots.
Fix it by passing only indexes of non-empty slots to ide_device_add_all()
from ide_generic_init().
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-generic.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
Index: b/drivers/ide/ide-generic.c
===
--- a/drivers/ide/ide-generic.c
+++ b/drivers/ide/ide-generic.c
@@ -20,8 +20,14 @@ static int __init ide_generic_init(void)
if (ide_hwifs[0].io_ports[IDE_DATA_OFFSET])
ide_get_lock(NULL, NULL); /* for atari only */
- for (i = 0; i MAX_HWIFS; i++)
- idx[i] = ide_hwifs[i].present ? 0xff : i;
+ for (i = 0; i MAX_HWIFS; i++) {
+ ide_hwif_t *hwif = ide_hwifs[i];
+
+ if (hwif-io_ports[IDE_DATA_OFFSET] !hwif-present)
+ idx[i] = i;
+ else
+ idx[i] = 0xff;
+ }
ide_device_add_all(idx, NULL);
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide-pci-generic: kill the unused ifdef/endif/MODULE code
On Saturday 02 February 2008, Denis Cheng wrote: with module_param macro, the __setup code can be killed now: const __setup(all-generic-ide, ide_generic_all_on); and the module name generic.ko is not descriptive to its functionality, can be changed in Makefile, the ide-pci-generic.ko is better. the ide-pci-generic.all-generic-ide parameter also documented in Documentation/kernel-parameters.txt Signed-off-by: Denis Cheng [EMAIL PROTECTED] applied, thanks PS the other patch will take same more time to review - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Palmchip BK3710 IDE driver
On Tuesday 05 February 2008, Anton Salnikov wrote:
I've tested the driver on 2.6.24.
I've made the changes you asked for. But when I tested them on
arm/mach-davinci
Thanks!
architecture on the current Linus' git there was link error undefined
reference
to symbol ide_hwif_setup_dma().
However on x86_64 architecture it compiles well without any warnings with
respect to link error of undefined clk_get() clk_enable() clk_get_rate(),
which
are not present in this architecture.
ide_hwif_setup_dma() comes from setup-pci.c which depends on BLK_DEV_IDEPCI.
palm_bk3710 host driver selects BLK_DEV_IDEDMA_PCI which should also select
BLK_DEV_IDEPCI but PCI doesn't even seem to be supported by this ARM platform.
I (hopefully) workarounded the issue by adding an additional #ifdef to
linux/ide.h but it is a unmaintanable and ugly hack:
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1014,7 +1014,8 @@ extern int __ide_pci_register_driver(str
void ide_pci_setup_ports(struct pci_dev *, const struct ide_port_info *, int,
u8 *);
void ide_setup_pci_noise(struct pci_dev *, const struct ide_port_info *);
-#ifdef CONFIG_BLK_DEV_IDEDMA_PCI
+/* FIXME: palm_bk3710 uses BLK_DEV_IDEDMA_PCI without BLK_DEV_IDEPCI! */
+#if defined(CONFIG_BLK_DEV_IDEPCI) defined(CONFIG_BLK_DEV_IDEDMA_PCI)
void ide_hwif_setup_dma(ide_hwif_t *, const struct ide_port_info *);
#else
static inline void ide_hwif_setup_dma(ide_hwif_t *hwif,
Anton/Sergei: please look into fixing it properly - we probably just need to
to have a new config option (CONFIG_IDE_SFF_DMA sounds neat) to be selected by
both BLK_DEV_{IDEDMA_PCI,PALMCHIP_BK3710} and to replace BLK_DEV_IDEDMA_PCI
#ifdefs in ide-dma.c.
I've just noticed that there is no cable detection for UDMA modes UDMA2?
For the present controller in documentation: Cable Select (CSEL) -
unsupported
IDE controller signal. This signal is not necessary because an 80-conductor
cable must be used with the DM644x.
Signed-off-by: Anton Salnikov [EMAIL PROTECTED]
Minor issue: the original patch description got lost somehow so I just used
the one from the previous version.
---
drivers/ide/Kconfig |9
drivers/ide/arm/Makefile |1
drivers/ide/arm/palm_bk3710.c | 420
++
drivers/ide/ide-proc.c|1
include/linux/ide.h |2
5 files changed, 432 insertions(+), 1 deletion(-)
Index: 2.6.25.ide/drivers/ide/Kconfig
===
--- 2.6.25.ide.orig/drivers/ide/Kconfig
+++ 2.6.25.ide/drivers/ide/Kconfig
@@ -1009,6 +1009,15 @@ config BLK_DEV_Q40IDE
normally be on; disable it only if you are running a custom hard
drive subsystem through an expansion card.
+config BLK_DEV_PALMCHIP_BK3710
+ tristate Palmchip bk3710 IDE controller support
+ depends on ARCH_DAVINCI
+ select BLK_DEV_IDEDMA_PCI
+ help
+ Say Y here if you want to support the onchip IDE controller on the
+ TI DaVinci SoC
+
+
config BLK_DEV_MPC8xx_IDE
tristate MPC8xx IDE support
depends on 8xx (LWMON || IVMS8 || IVML24 || TQM8xxL) IDE=y
BLK_DEV_IDE=y !PPC_MERGE
Index: 2.6.25.ide/drivers/ide/arm/Makefile
===
--- 2.6.25.ide.orig/drivers/ide/arm/Makefile
+++ 2.6.25.ide/drivers/ide/arm/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_BLK_DEV_IDE_ICSIDE) += icside.o
obj-$(CONFIG_BLK_DEV_IDE_RAPIDE) += rapide.o
obj-$(CONFIG_BLK_DEV_IDE_BAST) += bast-ide.o
+obj-$(CONFIG_BLK_DEV_PALMCHIP_BK3710)+= palm_bk3710.o
ifeq ($(CONFIG_IDE_ARM), m)
obj-m += ide_arm.o
Index: 2.6.25.ide/drivers/ide/arm/palm_bk3710.c
===
--- /dev/null
+++ 2.6.25.ide/drivers/ide/arm/palm_bk3710.c
[...]
+/*static inline u8 hwif_read8(u32 base, u32 reg)
+{
+ return readb(base + reg);
+}
+
+static inline u16 hwif_read16(u32 base, u32 reg)
+{
+ return readw(base + reg);
+}
+
+static inline void hwif_write16(u32 base, u16 val, u32 reg)
+{
+ writew(val, base + reg);
+}
+
+static inline u32 hwif_read32(u32 base, u32 reg)
+{
+ return readl(base + reg);
+}
+
+static inline void hwif_write32(u32 base, u32 val, u32 reg)
+{
+ writel(val, base + reg);
+}*/
I removed this chunk while merging the patch (no need for a dead code)
also added Reviewed-by: tags crediting Alan Sergei
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem burning DVDs with Marvell 88SE6121 on pata_marvell
On Tuesday, February 05, 2008 at 03:21PM, Andrew Morton wrote: (added linux-ide) thanks On Sat, 2 Feb 2008 16:30:04 -0600 Mike Hokenson [EMAIL PROTECTED] wrote: I recently put together a new system with a MSI P35 PLATINUM and although reading from data CDs, DVDs, and watching DVD movies is working fine, DVD burning isn't. MSI's manual says 1 IDE port by Marvell 88SE6111, but lspci says it's a 88SE6121. I have two DVD burners, a SONY DRU-510A and a DRU-820A. They were both working fine with TDK DVD+R media on my ASUS K8V SE DELUXE (VIA IDE controller) prior to the upgrade. Here's what I see with dvd+rw-tools version 7.0-9: sh# dvd+rw-mediainfo /dev/dvd /dev/null # this is blank media :-[ GET CURRENT PERFORMACE failed with SK=5h/ASC=24h/ACQ=00h]: Input/output error :-[ READ TOC failed with SK=5h/ASC=24h/ACQ=00h]: Input/output error sh# growisofs -dvd-compat -speed=2.4 -Z /dev/dvd -rJ -joliet-long -quiet burn Executing 'genisoimage -rJ -joliet-long -quiet burn | builtin_dd of=/dev/dvd obs=32k seek=0' /dev/dvd: Current Write Speed is 2.5x1352KBps. :-[ [EMAIL PROTECTED] failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error :-( write failed: Input/output error /dev/dvd: flushing cache /dev/dvd: closing track :-[ CLOSE TRACK failed with SK=5h/ASC=30h/ACQ=05h]: Wrong medium type /dev/dvd: closing disc :-[ CLOSE DISC failed with SK=5h/ASC=30h/ACQ=05h]: Wrong medium type sh# dvd+rw-mediainfo /dev/dvd /dev/null :-[ READ TRACK INFORMATION failed with SK=3h/ASC=11h/ACQ=05h]: Input/output error (this is 2.6.24) If nothing happens with this report in the next few days, please create an entry at bugzilla.kernel.org so we can keep an eye on it, thanks. Trying older kernels might be interesting, find out if it's a regression or if it was always this way. 2.6.13.14 shows the same problems and 2.6.22 doesn't see the controller. It looks like most of the changes happened betwen it's introduction in 2.6.20 (v0.1.1) and 2.6.22 (v0.1.4), with some minor updates for internal changes after that... Mike - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Tue, 2008-02-05 at 16:12 -0800, Andrew Morton wrote:
On Sun, 03 Feb 2008 18:16:51 -0600
James Bottomley [EMAIL PROTECTED] wrote:
From: James Bottomley [EMAIL PROTECTED]
Date: Sun, 3 Feb 2008 15:40:56 -0600
Subject: [SCSI] enclosure: add support for enclosure services
The enclosure misc device is really just a library providing sysfs
support for physical enclosure devices and their components.
Thanks for sending it out for review.
+struct enclosure_device *enclosure_find(struct device *dev)
+{
+ struct enclosure_device *edev = NULL;
+
+ mutex_lock(container_list_lock);
+ list_for_each_entry(edev, container_list, node) {
+ if (edev-cdev.dev == dev) {
+ mutex_unlock(container_list_lock);
+ return edev;
+ }
+ }
+ mutex_unlock(container_list_lock);
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(enclosure_find);
This looks a little odd. We don't take a ref on the object after looking
it up, so what prevents some other thread of control from freeing or
otherwise altering the returned object while the caller is playing with it?
The use case is for enclosure destruction, so the free should never
happen, but I take the point; I've added a class_device_get().
+/**
+ * enclosure_for_each_device - calls a function for each enclosure
+ * @fn:the function to call
+ * @data: the data to pass to each call
+ *
+ * Loops over all the enclosures calling the function.
+ *
+ * Note, this function uses a mutex which will be held across calls to
+ * @fn, so it must have user context, and @fn should not sleep or
Probably non atomic context would be more accurate.
fn() actually _can_ sleep.
should to me means you don't have to do this but ought to. I'll add a
may (but should not).
+ if (!cb) {
+ kfree(edev);
+ return ERR_PTR(-EINVAL);
+ }
It would be less fuss if this were to test cb before doing the kzalloc().
Can cb==NULL actually and legitimately happen?
Not really ... I'll make it a BUG_ON.
+void enclosure_unregister(struct enclosure_device *edev)
+{
+ int i;
+
+ if (!edev)
+ return;
Is this legal?
No ... it'll oops on the null deref later ... I'll remove this.
+ mutex_lock(container_list_lock);
+ list_del(edev-node);
+ mutex_unlock(container_list_lock);
See, right now, someone who found this enclosure_device via
enclosure_find() could still be playing with it?
Yes, fixed.
+ if (!edev || number = edev-components)
+ return ERR_PTR(-EINVAL);
Is !edev possible and legitimate?
It shouldn't be, no ... I can remove it.
+ snprintf(cdev-class_id, BUS_ID_SIZE, %d, number);
%u :)
Nitpicker!
+ return snprintf(buf, 40, %d\n, edev-components);
+}
40?
I just followed precedence ;-P
There doesn't seem to be a define for this maximum length, so 40 is the
most commonly picked constant.
+static char *enclosure_type [] = {
+ [ENCLOSURE_COMPONENT_DEVICE] = device,
+ [ENCLOSURE_COMPONENT_ARRAY_DEVICE] = array device,
+};
One could play with const here, if sufficiently keen.
One will try to summon up the enthusiasm.
+static ssize_t set_component_fault(struct class_device *cdev, const char
*buf,
+ size_t count)
+{
+ struct enclosure_device *edev = to_enclosure_device(cdev-parent);
+ struct enclosure_component *ecomp = to_enclosure_component(cdev);
+ int val = simple_strtoul(buf, NULL, 0);
hrm, we do this conversion about 1e99 times in the kernel and we have to go
and pass three args where only one was needed. katoi()?
Yes ... I'll add it to the todo list.
+ for (i = 0; enclosure_status[i]; i++) {
+ if (strncmp(buf, enclosure_status[i],
+ strlen(enclosure_status[i])) == 0
+ buf[strlen(enclosure_status[i])] == '\n')
+ break;
+ }
So if an application does
write(fd, foo, 3)
it won't work? Thye have to do
write(fd, foo\n, 4)
?
No ... it's designed for echo; however, I'll add a check for '\0' which
will catch the write case.
+#define to_enclosure_device(x) container_of((x), struct enclosure_device,
cdev)
+#define to_enclosure_component(x) container_of((x), struct
enclosure_component, cdev)
These could be C functions...
OK ... I was just following precedence again, but I can make them
inlines.
Nice looking driver.
Thanks,
James
---
Here's the incremental diff.
diff --git a/drivers/misc/enclosure.c b/drivers/misc/enclosure.c
index 42e6e43..6fcb0e9 100644
--- a/drivers/misc/enclosure.c
+++ b/drivers/misc/enclosure.c
@@ -39,7 +39,8 @@ static struct class enclosure_component_class;
*
* Looks through the list of registered enclosures to see
* if it can find a match for a device. Returns NULL if no
- * enclosure is found.
+ * enclosure is found.
Re: ide-tape redux (was: Re:)
On Tue, Feb 05, 2008 at 02:20:22AM +0100, Bartlomiej Zolnierkiewicz wrote:
[...]
w.r.t. #11 ide-tape uses char devices and supports DSC so it is not as obvious
as in ide-floppy case that all atomic bitops can be just removed (extra audit
and some time -mm are required) so please resync/resubmit
Ok, here's what i think we should do here: There are two flags that handle DSC:
PC_FL_WAIT_FOR_DSC and IDETAPE_FL_IGNORE_DSC. The first one is per pc and is
set in
all the packet command init functions ..create_bla_cmd() after their callers
have
created a pc on the stack and reached its ptr down for initialization. This case
is carefree since the bit will be tested first in the interrupt handler and this
happens only after the pc is queued (ide_do_drive_cmd()) into the request
buffer.
The other flag, IDETAPE_FL_IGNORE_DSC, is polled for in the request handler and
can be set when a pc is being retried and we should leave only those atomic
tests intact, imho, but i'm definitely gonna need a second opinion here.
---
commit 1ed8ae92249d5dff7af4ee88710ea08ff3f3356f
Author: Borislav Petkov [EMAIL PROTECTED]
Date: Tue Feb 5 08:05:35 2008 +0100
ide-tape: remove atomic test/set macros
Also, since the driver supports DSC, leave the atomic tests
for the IDETAPE_FL_IGNORE_DSC bit untouched because this is polled
for in the request handler and can be set in the interrupt
handler through idetape_retry_pc() after enabling interrupts.
Finally, remove flag IDETAPE_READ_ERROR since it is unused.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index e59e49e..9455ce4 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -206,24 +206,24 @@ typedef struct idetape_packet_command_s {
/* Temporary buffer */
u8 pc_buffer[IDETAPE_PC_BUFFER_SIZE];
/* Status/Action bit flags: long for set_bit */
- unsigned long flags;
+ unsigned int flags;
} idetape_pc_t;
-/*
- * Packet command flag bits.
- */
-/* Set when an error is considered normal - We won't retry */
-#definePC_ABORT0
-/* 1 When polling for DSC on a media access command */
-#define PC_WAIT_FOR_DSC1
-/* 1 when we prefer to use DMA if possible */
-#define PC_DMA_RECOMMENDED 2
-/* 1 while DMA in progress */
-#definePC_DMA_IN_PROGRESS 3
-/* 1 when encountered problem during DMA */
-#definePC_DMA_ERROR4
-/* Data direction */
-#definePC_WRITING 5
+/* Packet command flag bits. */
+enum {
+ /* Set when an error is considered normal - We won't retry */
+ PC_FL_ABORT = (1 0),
+ /* 1 When polling for DSC on a media access command */
+ PC_FL_WAIT_FOR_DSC = (1 1),
+ /* 1 when we prefer to use DMA if possible */
+ PC_FL_DMA_RECOMMENDED = (1 2),
+ /* 1 while DMA in progress */
+ PC_FL_DMA_IN_PROGRESS = (1 3),
+ /* 1 when encountered problem during DMA */
+ PC_FL_DMA_ERROR = (1 4),
+ /* Data direction */
+ PC_FL_WRITING = (1 5),
+};
/* A pipeline stage. */
typedef struct idetape_stage_s {
@@ -357,8 +357,7 @@ typedef struct ide_tape_obj {
/* Wasted space in each stage */
int excess_bh_size;
- /* Status/Action flags: long for set_bit */
- unsigned long flags;
+ unsigned int flags;
/* protects the ide-tape queue */
spinlock_t lock;
@@ -451,20 +450,26 @@ static void ide_tape_put(struct ide_tape_obj *tape)
#define DOOR_LOCKED1
#define DOOR_EXPLICITLY_LOCKED 2
-/*
- * Tape flag bits values.
- */
-#define IDETAPE_IGNORE_DSC 0
-#define IDETAPE_ADDRESS_VALID 1 /* 0 When the tape position is
unknown */
-#define IDETAPE_BUSY 2 /* Device already opened */
-#define IDETAPE_PIPELINE_ERROR 3 /* Error detected in a pipeline
stage */
-#define IDETAPE_DETECT_BS 4 /* Attempt to auto-detect the
current user block size */
-#define IDETAPE_FILEMARK 5 /* Currently on a filemark */
-#define IDETAPE_DRQ_INTERRUPT 6 /* DRQ interrupt device */
-#define IDETAPE_READ_ERROR 7
-#define IDETAPE_PIPELINE_ACTIVE8 /* pipeline active */
-/* 0 = no tape is loaded, so we don't rewind after ejecting */
-#define IDETAPE_MEDIUM_PRESENT 9
+/* Tape flag bits values. */
+enum {
+ IDETAPE_FL_IGNORE_DSC = (1 0),
+ /* 0 When the tape position is unknown */
+ IDETAPE_FL_ADDRESS_VALID= (1 1),
+ /* Device already opened */
+ IDETAPE_FL_BUSY = (1 2),
+ /* Error detected in a pipeline stage */
+ IDETAPE_FL_PIPELINE_ERR = (1 3),
+ /* Attempt to auto-detect the current user block size */
Re: ide-tape redux (was: Re:)
... and while we're at it ...
commit c824f79fe4040f7541d7e35c546bb57a22d2fe11
Author: Borislav Petkov [EMAIL PROTECTED]
Date: Wed Feb 6 06:23:10 2008 +0100
ide-tape: move all struct and other defs to the top
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index 9455ce4..398aea8 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -225,6 +225,69 @@ enum {
PC_FL_WRITING = (1 5),
};
+/* Tape door status */
+#define DOOR_UNLOCKED 0
+#define DOOR_LOCKED1
+#define DOOR_EXPLICITLY_LOCKED 2
+
+/* Tape flag bits values. */
+enum {
+ IDETAPE_FL_IGNORE_DSC = (1 0),
+ /* 0 When the tape position is unknown */
+ IDETAPE_FL_ADDRESS_VALID= (1 1),
+ /* Device already opened */
+ IDETAPE_FL_BUSY = (1 2),
+ /* Error detected in a pipeline stage */
+ IDETAPE_FL_PIPELINE_ERR = (1 3),
+ /* Attempt to auto-detect the current user block size */
+ IDETAPE_FL_DETECT_BS= (1 4),
+ /* Currently on a filemark */
+ IDETAPE_FL_FILEMARK = (1 5),
+ /* DRQ interrupt device */
+ IDETAPE_FL_DRQ_INTERRUPT= (1 6),
+ /* pipeline active */
+ IDETAPE_FL_PIPELINE_ACTIVE = (1 7),
+ /* 0 = no tape is loaded, so we don't rewind after ejecting */
+ IDETAPE_FL_MEDIUM_PRESENT = (1 8),
+};
+
+/* A define for the READ BUFFER command */
+#define IDETAPE_RETRIEVE_FAULTY_BLOCK 6
+
+/* Some defines for the SPACE command */
+#define IDETAPE_SPACE_OVER_FILEMARK1
+#define IDETAPE_SPACE_TO_EOD 3
+
+/* Some defines for the LOAD UNLOAD command */
+#define IDETAPE_LU_LOAD_MASK 1
+#define IDETAPE_LU_RETENSION_MASK 2
+#define IDETAPE_LU_EOT_MASK4
+
+/*
+ * Special requests for our block device strategy routine.
+ *
+ * In order to service a character device command, we add special requests to
+ * the tail of our block device request queue and wait for their completion.
+ */
+
+enum {
+ REQ_IDETAPE_PC1 = (1 0), /* packet command (first stage) */
+ REQ_IDETAPE_PC2 = (1 1), /* packet command (second stage) */
+ REQ_IDETAPE_READ= (1 2),
+ REQ_IDETAPE_WRITE = (1 3),
+ REQ_IDETAPE_READ_BUFFER = (1 4),
+};
+
+/* Error codes returned in rq-errors to the higher part of the driver. */
+#defineIDETAPE_ERROR_GENERAL 101
+#defineIDETAPE_ERROR_FILEMARK 102
+#defineIDETAPE_ERROR_EOD 103
+
+/* Structures related to the SELECT SENSE / MODE SENSE packet commands. */
+#define IDETAPE_BLOCK_DESCRIPTOR 0
+#defineIDETAPE_CAPABILITIES_PAGE 0x2a
+
+
/* A pipeline stage. */
typedef struct idetape_stage_s {
struct request rq; /* The corresponding request */
@@ -445,68 +508,6 @@ static void ide_tape_put(struct ide_tape_obj *tape)
mutex_unlock(idetape_ref_mutex);
}
-/* Tape door status */
-#define DOOR_UNLOCKED 0
-#define DOOR_LOCKED1
-#define DOOR_EXPLICITLY_LOCKED 2
-
-/* Tape flag bits values. */
-enum {
- IDETAPE_FL_IGNORE_DSC = (1 0),
- /* 0 When the tape position is unknown */
- IDETAPE_FL_ADDRESS_VALID= (1 1),
- /* Device already opened */
- IDETAPE_FL_BUSY = (1 2),
- /* Error detected in a pipeline stage */
- IDETAPE_FL_PIPELINE_ERR = (1 3),
- /* Attempt to auto-detect the current user block size */
- IDETAPE_FL_DETECT_BS= (1 4),
- /* Currently on a filemark */
- IDETAPE_FL_FILEMARK = (1 5),
- /* DRQ interrupt device */
- IDETAPE_FL_DRQ_INTERRUPT= (1 6),
- /* pipeline active */
- IDETAPE_FL_PIPELINE_ACTIVE = (1 7),
- /* 0 = no tape is loaded, so we don't rewind after ejecting */
- IDETAPE_FL_MEDIUM_PRESENT = (1 8),
-};
-
-/* A define for the READ BUFFER command */
-#define IDETAPE_RETRIEVE_FAULTY_BLOCK 6
-
-/* Some defines for the SPACE command */
-#define IDETAPE_SPACE_OVER_FILEMARK1
-#define IDETAPE_SPACE_TO_EOD 3
-
-/* Some defines for the LOAD UNLOAD command */
-#define IDETAPE_LU_LOAD_MASK 1
-#define IDETAPE_LU_RETENSION_MASK 2
-#define IDETAPE_LU_EOT_MASK4
-
-/*
- * Special requests for our block device strategy routine.
- *
- * In order to service a character device command, we add special requests to
- * the tail of our block device request queue and wait for their completion.
- */
-
-enum {
- REQ_IDETAPE_PC1 = (1 0), /* packet command (first stage) */
- REQ_IDETAPE_PC2 = (1 1), /* packet command (second stage) */
- REQ_IDETAPE_READ= (1 2),
- REQ_IDETAPE_WRITE = (1 3),
-
