Hi Al,
it is nice that blkdev_ioctl calls blk_ioctl itself, but unfortunately
it does that only if driver's ioctl returns -EINVAL - and IDE returns -EIO :-(
Patch below is tested for disks - I do not have IDE floppy nor IDE tape.
I have couple of additional questions:
(1) should not we use -ENOTTY for unimplemented ioctl, like other subsystems do?
(2) IDE returns -EIO also for default_open. -ENXIO/-ENODEV?
(3) if drive->driver == NULL, ioctl returns -EPERM. I believe that this check
is not needed because of ide_open checks for drive->driver != NULL. And
if we can invoke ide's ioctl without previous open, should not we return
-ENODEV?
Thanks,
Petr Vandrovec
[email protected]
diff -urN linux-2.5.33-c615.dist/drivers/ide/ide-floppy.c linux-2.5.33-c615/drivers/ide/ide-floppy.c
--- linux-2.5.33-c615.dist/drivers/ide/ide-floppy.c 2002-09-05 14:40:47.000000000 +0200
+++ linux-2.5.33-c615/drivers/ide/ide-floppy.c 2002-09-05 20:06:24.000000000 +0200
@@ -1817,7 +1817,7 @@
return (idefloppy_get_format_progress(drive, inode, file,
(int *)arg));
}
- return -EIO;
+ return -EINVAL;
}
/*
diff -urN linux-2.5.33-c615.dist/drivers/ide/ide-tape.c linux-2.5.33-c615/drivers/ide/ide-tape.c
--- linux-2.5.33-c615.dist/drivers/ide/ide-tape.c 2002-09-05 14:40:43.000000000 +0200
+++ linux-2.5.33-c615/drivers/ide/ide-tape.c 2002-09-05 20:06:11.000000000 +0200
@@ -4365,7 +4365,7 @@
return -EFAULT;
break;
default:
- return -EIO;
+ return -EINVAL;
}
return 0;
}
diff -urN linux-2.5.33-c615.dist/drivers/ide/ide.c linux-2.5.33-c615/drivers/ide/ide.c
--- linux-2.5.33-c615.dist/drivers/ide/ide.c 2002-09-05 14:40:42.000000000 +0200
+++ linux-2.5.33-c615/drivers/ide/ide.c 2002-09-05 19:58:15.000000000 +0200
@@ -3347,7 +3347,7 @@
static int default_ioctl (ide_drive_t *drive, struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
- return -EIO;
+ return -EINVAL;
}
static int default_open (struct inode *inode, struct file *filp, ide_drive_t *drive)
Petr,
I know you are active in 2.5, and I would like to tap your resouces and
ideas. Would it be possible to put things behind and move forward, as
Halloween is near? TIA!
Cheers,
Andre
On Thu, 5 Sep 2002, Petr Vandrovec wrote:
> Hi Al,
> it is nice that blkdev_ioctl calls blk_ioctl itself, but unfortunately
> it does that only if driver's ioctl returns -EINVAL - and IDE returns -EIO :-(
>
> Patch below is tested for disks - I do not have IDE floppy nor IDE tape.
For ide-disk.c, ide-floppy.c and ide-cd.c patch is OK. For ide-tape.c...
Not needed.
Keep in mind that current setup (some ioctls are unconditionally done
in fs/block_dev.c, for some we only call driver, for some - give
driver a chance and do our thing if it doesn't recongnize the ioctl)
will change. Most of the 3rd group actually belong to the 1st one -
the only reason why they are not there is handling of unpartitioned
devices that don't have gendisks. When that gets fixed, the kludge
with calling driver and handling -EINVAL will disappear...
On 5 Sep 02 at 15:53, Andre Hedrick wrote:
>
> I know you are active in 2.5, and I would like to tap your resouces and
> ideas. Would it be possible to put things behind and move forward, as
> Halloween is near? TIA!
I have no problem, I did not CC-ed you because of it looked to me like
pure 2.5.x problem. And besides that, my interest in IDE is currently
limited to get working system so I can continue in ncpfs and matroxfb
hacking ;-)
If you are interested in long story, then here it comes...
On Sunday afternoon my primary channel (Promise 20265) started magically
dying while starting Netware6 as a guest in VMware. After poking here
and there I found that simple 'cat Netware6.vmdk > /dev/null' kills the
system: cat in D state, IDE doing nothing.
So I tried 2.5.32, 2.5.31, 2.5.29-c476 and 2.4.19-pre7, and behavior was
all same - cat-ting Netware6.vmdk killed system, regardles of your/Martins
IDE, or kernel version.
Then an Idea appeared: I did "hdparm -d 0 /dev/hde", and then I did
"cat Netware6.vmdk > /dev/null" - and, voila, Unrecoverable error
reading sector XXXXXX appeared.
Well, so disk died, and there are missing some timeouts or error recovery
in the pdc driver while using UDMA on 20265. I hoped that I'll look into
that, but...
... I booted Windows, and started Windows Data Lifeguard tools. They told
me that disk has really problem, so I run extended test and let it
reallocate bad sector. It told me that everything was fine, so I rerun
it again, and it again found (same) bad sector, and told me that something
went wrong. So I concluded that disk is really dead, rebooted windows and...
... my MBR was full of crap. Then I brought disk to the work, downloaded
Western's DOS based tool, and it repaired disk without a glitch. So
my current idea is that WDL version I have relocated sector 0 instead
of bad sector :-( Grr... Now back to the my problems ;-) gpart recovered
partitions, and everything was nice.
Yesterday new disks arrived, and I found that I cannot partition that,
as cfdisk reports unreadable disk although I specified -h/-s/-c on
the command line. fdisk worked, though, after using extended options
to set c/h/s params, but fixed kernel and simple cfdisk UI is better
(although cfdisk does not allow to set extended partition as bootable
one, so I had to do that in fdisk anyway).
So now when I have working system back, I can actually look at promise
driver what's wrong there. Unfortunately, as DOS diag tool repaired
my drive, it looks like that even if I'll find where bug lives, it
will not be easy to verify it...
And because of I now have my HDD in the removable bay internally connected
using 40w cable (it is about 2 inches of 40w cable, but apparently
it is enough to get some echos or bad impendance or...) to the 80w one,
kernel found 80w cable and decided to use 88.8MB/s on my i845. It was
unreliable, so I did 'hdparm -X 66 /dev/hdc', and now disk works OK, but
atapci reports cycle time 7ns, transfer rate 266.6MB/s. But it looks more
like atapci problem than IDE driver problem, as disk really works fine.
I'll look at all problems reported here (except WDL... I do not have
their sources, maybe they fixed it already in newer versions, and I have
no way to test it again until new bad sector appears), but I cannot say
in what timeframe... Probably this year ;-)
Best regards,
Petr Vandrovec
[email protected]