Borsenkow Andrej writes:
> >
> > Borsenkow Andrej writes:
> > > Mandrake 2.4.17-18mdk based on 2.4.18-rc1
> > >
> > > On first (?) bootup after install the following interesting message
> > > (error -17):
> > >
> > > PIIX4: chipset revision 1
> > > PIIX4: not 100% native mode: will probe irqs later
> > > ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:pio, hdb:pio
> > > ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:DMA, hdd:pio
> > > hda: LS-120 CSMO 05 UHD Floppy, ATAPI FLOPPY drive
> > > hdc: IBM-DTTA-371440, ATA DISK drive
> > > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > > ide1 at 0x170-0x177,0x376 on irq 15
> > > hdc: 28229040 sectors (14453 MB) w/462KiB Cache, CHS=28005/16/63,
> > > UDMA(33)
> > > hda: No disk in drive
> > > hda: 123264kB, 963/8/32 CHS, 533 kBps, 512 sector size, 720 rpm
> > > devfs_register(disc): could not append to parent, err: -17
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Odd. This should never happen. If you look at the code for
> > devfs_register_disc(), you will see the very first line:
> > if (dev->part[minor].de) return;
> >
> > which prevents duplicate registrations.
>
> I am sorry. Mandrake is using patch from Paul (that has been announced
> here as well, see another thread "Removeable Media, partitions and
> devfs?", patch is quite old actually.
>
> idefloppy_setup registers "disc" itself:
>
> /*
> * Driver initialization.
> */
> static void idefloppy_setup (ide_drive_t *drive, idefloppy_floppy_t
> *floppy)
> {
> ...
> /* Always register drive with devfs */
> floppy->de = devfs_register (drive->de, "disc",
> DEVFS_FL_REMOVABLE,
> major, minor,
> S_IFBLK | S_IRUGO | S_IWUGO,
> ide_fops, NULL);
FUCK, FUCK, FUCK!!! No wonder I couldn't figure out what was going
on. That's a hack that should never have gone into a released kernel!
I even posted the correct fix to the devfs list sometime last year
when this was being discussed, and eventually made it's way into
2.4.18-rc1.
> /* Create ide/fd entry in devfs */
> idefloppy_devfs_handle =
> devfs_mk_dir(ide_devfs_handle,"fd",NULL);
>
> sprintf (fname, "c%db%dt%du%d",
> ^^^^^^^^^^^^^
> Is not this a devfsd task?
YES! No driver should ever do something like this.
> It looks like handle for ..../disc never makes it way into gendisk at
> this point.
>
> Is there newer patch? Paul, you probably should not create compat
> links in driver.
Indeed. Or any other driver.
<rant>
I don't care what private patches people write, and they're free to
publish them (provided ugly hacks are marked as such). But
distribution vendors shouldn't release such patches to unsuspecting
users. It doesn't look good. Better management of patches is required,
which includes co-ordinating with developers if something hasn't yet
reached the mainline kernel. Don't just throw in a hack.
</rant>
> Robert, sorry, had to do closer look but really had no time :(
To address Robert's immediate problem (the error message he sees): he
can ignore it. The problem is not fatal and will not cause data
corruption. The only problem is that /proc/partitions will not have a
devfs name for his removable media. And he will get an error message
at bootup, to remind him of the evils of random hacks.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|