Re: [Cooker] ZIP devfs
On Friday 30 November 2001 21:04, you wrote: On ðÔÎ, 2001-11-30 at 19:16, RA wrote: Your mentioned patch is probably linux-2.4.10-ac10-ide-floppy-devfs.patch, isn't it? I'm not a C programmer or kernel expert, but after boot devfs only knows, that there is a drive (without partitioning info). The problem is, that mount does not trigger a new lookup for the drive partitioning. When new device is registered, it is marked as removable and directory (/dev/ide/.../lun0/) holds removables count registered under it. In this case it is .../disc. When you lookup .../part4 and it is not found and directory has non-zero removables count it initiates rescan for parition information. That is theory :-) The bug in ide-floppy was that with empty drive *nothing* ever was registered, and for this reason lookup of .../part4 never triggered partition revalidation. The person who reported this bug also reported that it was fixed by above mentioned patch. I do not have any ide-floppy devices to test it now. You may want to look on lkml (about two days ago) for a ide-floppy patch from driver maintainer. It does it slightly differently. May be it works better. Or I can send it to you (I guess I have not yet deleted it :-) I found the patch and will give it a try. Thanx! -andrej In theory praxis and theory are the same. In praxis they are different.
Re: [Cooker] ZIP devfs
Borsenkow Andrej [EMAIL PROTECTED] writes: I tried to reanimate (once again) my zip drive when booting with 'devfs=mount'. The problem with the current configuration is the missing of part4 dev node. It is only automatically generated when a ZIP media is inserted during boot. It must be working in current cooker kernel (old ide-floppy bug) and is being corrected in public driver in slightly different way (Chmouel, it probably will obsolete my patch). yes i noticed that to juan, juan ? -- http://www.linux-mandrake.com/en/club/
[Fwd: Re: [Cooker] ZIP devfs]
For some reasons it never was sent it seems. On ðÔÎ, 2001-11-30 at 19:16, RA wrote: Your mentioned patch is probably linux-2.4.10-ac10-ide-floppy-devfs.patch, isn't it? I'm not a C programmer or kernel expert, but after boot devfs only knows, that there is a drive (without partitioning info). The problem is, that mount does not trigger a new lookup for the drive partitioning. When new device is registered, it is marked as removable and directory (/dev/ide/.../lun0/) holds removables count registered under it. In this case it is .../disc. When you lookup .../part4 and it is not found and directory has non-zero removables count it initiates rescan for parition information. That is theory :-) The bug in ide-floppy was that with empty drive *nothing* ever was registered, and for this reason lookup of .../part4 never triggered partition revalidation. The person who reported this bug also reported that it was fixed by above mentioned patch. I do not have any ide-floppy devices to test it now. You may want to look on lkml (about two days ago) for a ide-floppy patch from driver maintainer. It does it slightly differently. May be it works better. Or I can send it to you (I guess I have not yet deleted it :-) -andrej In theory praxis and theory are the same. In praxis they are different.
RE: [Cooker] ZIP devfs
I tried to reanimate (once again) my zip drive when booting with 'devfs=mount'. The problem with the current configuration is the missing of part4 dev node. It is only automatically generated when a ZIP media is inserted during boot. It must be working in current cooker kernel (old ide-floppy bug) and is being corrected in public driver in slightly different way (Chmouel, it probably will obsolete my patch). Are you using cooker kernel? If not what is the point of posting it here? -andrej
Re: [Cooker] ZIP devfs
On Fri, 30 Nov 2001 15:36:49 +0300 Borsenkow Andrej [EMAIL PROTECTED] wrote: I tried to reanimate (once again) my zip drive when booting with 'devfs=mount'. The problem with the current configuration is the missing of part4 dev node. It is only automatically generated when a ZIP media is inserted during boot. It must be working in current cooker kernel (old ide-floppy bug) and is being corrected in public driver in slightly different way (Chmouel, it probably will obsolete my patch). I can atest to that I just upgraded a system to cooker yesterday and the Zip performs without problem. Charles
Re: [Cooker] ZIP devfs
On Friday 30 November 2001 13:44, you wrote: On Fri, 30 Nov 2001 15:36:49 +0300 Borsenkow Andrej [EMAIL PROTECTED] wrote: I tried to reanimate (once again) my zip drive when booting with 'devfs=mount'. The problem with the current configuration is the missing of part4 dev node. It is only automatically generated when a ZIP media is inserted during boot. It must be working in current cooker kernel (old ide-floppy bug) and is being corrected in public driver in slightly different way (Chmouel, it probably will obsolete my patch). I can atest to that I just upgraded a system to cooker yesterday and the Zip performs without problem. Charles I upgraded to current cooker (from a mixed mdk8.1/cooker system) two days ago - running kernel-2.4.13-12mdk. And I can atest that I have to touch disc node first when disc is inserted, then part4 is generated. I.e. 'mount -t vfat /dev/host0.../part4 /mnt/zip' is otherwise not working. Or maybe it's a upgrade problem.
RE: [Cooker] ZIP devfs
Borsenkow Andrej [EMAIL PROTECTED] wrote: I tried to reanimate (once again) my zip drive when booting with 'devfs=mount'. The problem with the current configuration is the missing of part4 dev node. It is only automatically generated when a ZIP media is inserted during boot. It must be working in current cooker kernel (old ide-floppy bug) and is being corrected in public driver in slightly different way (Chmouel, it probably will obsolete my patch). I can atest to that I just upgraded a system to cooker yesterday and the Zip performs without problem. Charles I upgraded to current cooker (from a mixed mdk8.1/cooker system) two days ago - running kernel-2.4.13-12mdk. And I can atest that I have to touch disc node first when disc is inserted, then part4 is generated. That is correct. It is first created when you try to access it, *not* when you insert disk. I.e. 'mount -t vfat /dev/host0.../part4 /mnt/zip' is otherwise not working. It is pretty strange. Dmesg, anything else that shows what's going on? -andrej
Re: [Cooker] ZIP devfs
On Friday 30 November 2001 13:44, you wrote: On Fri, 30 Nov 2001 15:36:49 +0300 Borsenkow Andrej [EMAIL PROTECTED] wrote: I tried to reanimate (once again) my zip drive when booting with 'devfs=mount'. The problem with the current configuration is the missing of part4 dev node. It is only automatically generated when a ZIP media is inserted during boot. It must be working in current cooker kernel (old ide-floppy bug) and is being corrected in public driver in slightly different way (Chmouel, it probably will obsolete my patch). I can atest to that I just upgraded a system to cooker yesterday and the Zip performs without problem. Charles Are you using any kernel parameter for ide-floppy?
Re: [Cooker] ZIP devfs
On Fri, 30 Nov 2001 14:28:26 +0100 RA [EMAIL PROTECTED] wrote: On Friday 30 November 2001 13:44, you wrote: On Fri, 30 Nov 2001 15:36:49 +0300 It must be working in current cooker kernel (old ide-floppy bug) and is being corrected in public driver in slightly different way (Chmouel, it probably will obsolete my patch). I can atest to that I just upgraded a system to cooker yesterday and the Zip performs without problem. Charles I upgraded to current cooker (from a mixed mdk8.1/cooker system) two days ago - running kernel-2.4.13-12mdk. And I can atest that I have to touch disc node first when disc is inserted, then part4 is generated. I.e. 'mount -t vfat /dev/host0.../part4 /mnt/zip' is otherwise not working. Or maybe it's a upgrade problem. More than likely it is caused by changes you made prior upgrading to the full cooker. Any such changes would not have been overwritten by the upgrade. Such changes, while allowing the drive to function in 8.1 would prevent the now properly functioning devfs from operating unless the same hack is used or unless all configs are returned to their default. As I said my USB Zip is functioning without problem and no changes were necessary. FWIW here is the fstab listings for my zip: /dev/sda /mnt/zip auto user,iocharset=iso8859-1,umask=0,sync,exec,codepage=850,noauto 0 0 /dev/sda4 /mnt/zip2 auto user,iocharset=iso8859-1,umask=0,sync,exec,codepage=850,noauto 0 0 Charles
Re: [Cooker] ZIP devfs
On Friday 30 November 2001 15:04, you wrote: Borsenkow Andrej [EMAIL PROTECTED] wrote: I tried to reanimate (once again) my zip drive when booting with 'devfs=mount'. The problem with the current configuration is the missing of part4 dev node. It is only automatically generated when a ZIP media is inserted during boot. It must be working in current cooker kernel (old ide-floppy bug) and is being corrected in public driver in slightly different way (Chmouel, it probably will obsolete my patch). I can atest to that I just upgraded a system to cooker yesterday and the Zip performs without problem. Charles I upgraded to current cooker (from a mixed mdk8.1/cooker system) two days ago - running kernel-2.4.13-12mdk. And I can atest that I have to touch disc node first when disc is inserted, then part4 is generated. That is correct. It is first created when you try to access it, *not* when you insert disk. I.e. 'mount -t vfat /dev/host0.../part4 /mnt/zip' is otherwise not working. It is pretty strange. Dmesg, anything else that shows what's going on? -andrej After reboot (with virgin devfsd.conf, no disc in drive): $grep ide-floppy /var/log/dmesg ide-floppy driver 0.98a /dev/ide/host0/bus1/target0/lun0:3ide-floppy: hdc: I/O error, pc = 28, key = 2, asc = 3a, ascq = 0 ide-floppy driver 0.98a $ls -l /dev/ide/host0/bus1/target0/lun0 total 0 brw---1 root root 22, 0 Jan 1 1970 disc $ $mount -t vfat /dev/ide/host0/bus1/target0/lun0/part4 /mnt/disk mount: special device /dev/ide/host0/bus1/target0/lun0/part4 does not exist Nothing changed after inserting of a disc. No log output (messages,dmesg,kernel/*). part4 creation triggered by fdisk -l or touching disc. Ralf.
Re: [Cooker] ZIP devfs
On Friday 30 November 2001 15:20, you wrote: ... Or maybe it's a upgrade problem. More than likely it is caused by changes you made prior upgrading to the full cooker. Any such changes would not have been overwritten by the upgrade. Such changes, while allowing the drive to function in 8.1 would prevent the now properly functioning devfs from operating unless the same hack is used or unless all configs are returned to their default. As I said my USB Zip is functioning without problem and no changes were necessary. FWIW here is the fstab listings for my zip: /dev/sda /mnt/zip auto user,iocharset=iso8859-1,umask=0,sync,exec,codepage=850,noauto 0 0 /dev/sda4 /mnt/zip2 auto user,iocharset=iso8859-1,umask=0,sync,exec,codepage=850,noauto 0 0 Charles Ohh, you are using USB zip and ide-scsi. I'm using ide-floppy.
RE: [Cooker] ZIP devfs
After reboot (with virgin devfsd.conf, no disc in drive): $grep ide-floppy /var/log/dmesg ide-floppy driver 0.98a /dev/ide/host0/bus1/target0/lun0:3ide-floppy: hdc: I/O error, pc = 28, key = 2, asc = 3a, ascq = 0 ide-floppy driver 0.98a $ls -l /dev/ide/host0/bus1/target0/lun0 total 0 brw---1 root root 22, 0 Jan 1 1970 disc $ $mount -t vfat /dev/ide/host0/bus1/target0/lun0/part4 /mnt/disk mount: special device /dev/ide/host0/bus1/target0/lun0/part4 does not exist Nothing changed after inserting of a disc. No log output (messages,dmesg,kernel/*). part4 creation triggered by fdisk -l or touching disc. Does it help if you comment out these last three lines in rc.sysinit and reboot (already commented out by me)? if [ -c /dev/.devfsd ]; then if [ -x /sbin/devfsd ]; then # copy /lib/dev-state before starting devfsd to avoid accidentally # triggering devfsd actions (like module loading) #if [ -d /lib/dev-state ]; then # cp -af /lib/dev-state/* /dev /dev/null 21 #fi -andrej
Re: [Cooker] ZIP devfs
On Friday 30 November 2001 16:01, you wrote: Does it help if you comment out these last three lines in rc.sysinit and reboot (already commented out by me)? if [ -c /dev/.devfsd ]; then if [ -x /sbin/devfsd ]; then # copy /lib/dev-state before starting devfsd to avoid accidentally # triggering devfsd actions (like module loading) #if [ -d /lib/dev-state ]; then # cp -af /lib/dev-state/* /dev /dev/null 21 #fi -andrej No, only disc entry, mount fails.
Re: [Cooker] ZIP devfs
On Friday 30 November 2001 13:36, you wrote: I tried to reanimate (once again) my zip drive when booting with 'devfs=mount'. The problem with the current configuration is the missing of part4 dev node. It is only automatically generated when a ZIP media is inserted during boot. It must be working in current cooker kernel (old ide-floppy bug) and is being corrected in public driver in slightly different way (Chmouel, it probably will obsolete my patch). Your mentioned patch is probably linux-2.4.10-ac10-ide-floppy-devfs.patch, isn't it? I'm not a C programmer or kernel expert, but after boot devfs only knows, that there is a drive (without partitioning info). The problem is, that mount does not trigger a new lookup for the drive partitioning. Are you using cooker kernel? If not what is the point of posting it here? -andrej
Re: [Cooker] ZIP devfs
On ðÔÎ, 2001-11-30 at 19:16, RA wrote: Your mentioned patch is probably linux-2.4.10-ac10-ide-floppy-devfs.patch, isn't it? I'm not a C programmer or kernel expert, but after boot devfs only knows, that there is a drive (without partitioning info). The problem is, that mount does not trigger a new lookup for the drive partitioning. When new device is registered, it is marked as removable and directory (/dev/ide/.../lun0/) holds removables count registered under it. In this case it is .../disc. When you lookup .../part4 and it is not found and directory has non-zero removables count it initiates rescan for parition information. That is theory :-) The bug in ide-floppy was that with empty drive *nothing* ever was registered, and for this reason lookup of .../part4 never triggered partition revalidation. The person who reported this bug also reported that it was fixed by above mentioned patch. I do not have any ide-floppy devices to test it now. You may want to look on lkml (about two days ago) for a ide-floppy patch from driver maintainer. It does it slightly differently. May be it works better. Or I can send it to you (I guess I have not yet deleted it :-) -andrej In theory praxis and theory are the same. In praxis they are different.
