Hi,
I'm currently looking into fixing: http://bugzilla.redhat.com/show_bug.cgi?id=565693
The easiest way to do this would be to remove the always modprobe floppy code from anaconda and rely on udev for floppy driver loading.
But that cannot be done as for some reason the fedora kernel caries this "beauty" of a patch called die-floppy-die.patch:
###
Kill the floppy.ko pnp modalias. We were surviving just fine without autoloading floppy drivers, tyvm.
Please feel free to register all complaints in the wastepaper bin.
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c index 91b7530..2ea84a6 100644 --- a/drivers/block/floppy.c +++ b/drivers/block/floppy.c @@ -4631,7 +4631,7 @@ static const struct pnp_device_id floppy_pnpids[] = { { "PNP0700", 0 }, { } }; -MODULE_DEVICE_TABLE(pnp, floppy_pnpids); +/* MODULE_DEVICE_TABLE(pnp, floppy_pnpids); */
#else
###
Which although it says "to register all complaints in the wastepaper bin", I beg to differ. We can certainly do some kludge in anaconda to restore the autoload behavior there, but I wonder why as many people seem to think that the removal of the autoloading is a bad idea, see: http://bugzilla.redhat.com/show_bug.cgi?id=537741
And also, this thread was which supposed to be about an anaconda specific solution but turned into a why is floppy driver autoloading disabled thread: http://www.redhat.com/archives/anaconda-devel-list/2010-March/msg00332.html
So even though the auto loading may cause some issues (mostly for people who have congfigured there is a floppy in the BIOS while there isn't one), disabling it also causes issues, and we're deviating from upstream here.
So I wonder why are we deviating from upstream here, with a patch that clearly has no intention of ever going upstream ? That seems to contradict most of our policies.
And if those who are in favor of the patch believe it is a good patch, why are they not taking this discussion upstream, and let it be fixed there ?
Regards,
Hans
On Mon, 2010-04-12 at 17:36 +0200, Hans de Goede wrote:
I'm currently looking into fixing: http://bugzilla.redhat.com/show_bug.cgi?id=565693
The easiest way to do this would be to remove the always modprobe floppy code from anaconda and rely on udev for floppy driver loading.
Sigh, and you're probably trying to modprobe floppy because someone somewhere thinks driver disks are a good idea.
- ajax
On Mon, Apr 12, 2010 at 12:04:09 -0400, Adam Jackson ajax@redhat.com wrote:
On Mon, 2010-04-12 at 17:36 +0200, Hans de Goede wrote:
I'm currently looking into fixing: http://bugzilla.redhat.com/show_bug.cgi?id=565693
The easiest way to do this would be to remove the always modprobe floppy code from anaconda and rely on udev for floppy driver loading.
Sigh, and you're probably trying to modprobe floppy because someone somewhere thinks driver disks are a good idea.
I occasionally use them for transferring data between some old laptops and machines running Fedora. Occasionally I have also used them for driver disks, though all of my computers currently are on the last bios version they are ever likely to get.
As things went in the other discussion, it isn't hard to get floppies to work, it's hard finding out what the issue is and how to fix it. Now that I know I need to run modprobe it isn't a big deal for me. But this information is not readily available to people and can cause significant problems for people who stumble accross it.
On Mon, Apr 12, 2010 at 11:51:10AM -0500, Bruno Wolff III wrote:
I occasionally use them for transferring data between some old laptops and machines running Fedora. Occasionally I have also used them for driver disks, though all of my computers currently are on the last bios version they are ever likely to get.
As things went in the other discussion, it isn't hard to get floppies to work, it's hard finding out what the issue is and how to fix it. Now that I know I need to run modprobe it isn't a big deal for me. But this information is not readily available to people and can cause significant problems for people who stumble accross it.
The problem is, EVERYONE has a floppy controller and NOBODY(*) has a floppy disk drive. PNP only reports the presence of the controller, not the drive.
Ergo: FAIL for everyone, for the sake of some ancient crap that nobody except for a vocal minority of approximately three people cares about.
--Kyle
On Mon, Apr 12, 2010 at 12:58:35 -0400, Kyle McMartin kyle@mcmartin.ca wrote:
The problem is, EVERYONE has a floppy controller and NOBODY(*) has a floppy disk drive. PNP only reports the presence of the controller, not the drive.
Ergo: FAIL for everyone, for the sake of some ancient crap that nobody except for a vocal minority of approximately three people cares about.
I am not an expert on the tradeoffs on the kernel side and don't have a real strong opinion there. But I do think if floppy drives aren't available by default, there should be some documentation somewhere that tells people how to enable their floppy drives. That isn't necessarily the job of the kernel maintainers.
Maybe at first boot people could get asked.
Maybe a drive could be looked for once and the result remembered. (I expect that a lot less people move floppy drives around than use them.)
Maybe it could be on an FAQ.
Maybe it could be mentioned in the release notes. (Though I think this change first affected f12, I don't remember running accross any notice before I first ran into the problem.)
On Mon, Apr 12, 2010 at 12:18:37PM -0500, Bruno Wolff III wrote:
I am not an expert on the tradeoffs on the kernel side and don't have a real strong opinion there. But I do think if floppy drives aren't available by default, there should be some documentation somewhere that tells people how to enable their floppy drives. That isn't necessarily the job of the kernel maintainers.
You're asking for a non-trivial amount of work for an ever (and I mean rapidly) diminishing set of users. That is why this is unreasonable.
--Kyle
Maybe at first boot people could get asked.
Maybe a drive could be looked for once and the result remembered. (I expect that a lot less people move floppy drives around than use them.)
Maybe it could be on an FAQ.
Maybe it could be mentioned in the release notes. (Though I think this change first affected f12, I don't remember running accross any notice before I first ran into the problem.)
On Mon, Apr 12, 2010 at 01:25:36PM -0400, Kyle McMartin wrote:
On Mon, Apr 12, 2010 at 12:18:37PM -0500, Bruno Wolff III wrote:
I am not an expert on the tradeoffs on the kernel side and don't have a real strong opinion there. But I do think if floppy drives aren't available by default, there should be some documentation somewhere that tells people how to enable their floppy drives. That isn't necessarily the job of the kernel maintainers.
You're asking for a non-trivial amount of work for an ever (and I mean rapidly) diminishing set of users. That is why this is unreasonable.
Ok, the latter two aren't, but still. :) (Yes, I agree, it should be release noted or something.)
On Mon, Apr 12, 2010 at 13:27:22 -0400, Kyle McMartin kyle@mcmartin.ca wrote:
On Mon, Apr 12, 2010 at 01:25:36PM -0400, Kyle McMartin wrote:
On Mon, Apr 12, 2010 at 12:18:37PM -0500, Bruno Wolff III wrote:
I am not an expert on the tradeoffs on the kernel side and don't have a real strong opinion there. But I do think if floppy drives aren't available by default, there should be some documentation somewhere that tells people how to enable their floppy drives. That isn't necessarily the job of the kernel maintainers.
You're asking for a non-trivial amount of work for an ever (and I mean rapidly) diminishing set of users. That is why this is unreasonable.
Ok, the latter two aren't, but still. :) (Yes, I agree, it should be release noted or something.)
I mentioned the issue on the docs list and suggested a release notes entry and perhaps FAQ inclusion.
A one time user space solution isn't going to happen in time for f13 in any case and it seems very unlikely the kernel is going to change before f13 (related to floppy support), so that seems like a good idea for f13.
I went and searched the f12 and f11 release notes and didn't see a reference to the change there. (I think the change first affected f12. I don't have an f11 instance to test the current situation there, but that is pretty much moot now.)
On Mon, 2010-04-12 at 12:18 -0500, Bruno Wolff III wrote:
On Mon, Apr 12, 2010 at 12:58:35 -0400, Kyle McMartin kyle@mcmartin.ca wrote:
The problem is, EVERYONE has a floppy controller and NOBODY(*) has a floppy disk drive. PNP only reports the presence of the controller, not the drive.
Ergo: FAIL for everyone, for the sake of some ancient crap that nobody except for a vocal minority of approximately three people cares about.
I am not an expert on the tradeoffs on the kernel side and don't have a real strong opinion there. But I do think if floppy drives aren't available by default, there should be some documentation somewhere that tells people how to enable their floppy drives. That isn't necessarily the job of the kernel maintainers.
Maybe at first boot people could get asked.
Maybe a drive could be looked for once and the result remembered. (I expect that a lot less people move floppy drives around than use them.)
Maybe it could be on an FAQ.
Maybe it could be mentioned in the release notes. (Though I think this change first affected f12, I don't remember running accross any notice before I first ran into the problem.)
The thing was the window where this patch applied was about 3-4 weeks in rawhide, it went in upstream, it slowed boot down on lots of my machines, I nuked it.
So Fedora behaviour should not have changed across this patch.
Dave.
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Tue, Apr 13, 2010 at 06:38:59 +1000, Dave Airlie airlied@redhat.com wrote:
The thing was the window where this patch applied was about 3-4 weeks in rawhide, it went in upstream, it slowed boot down on lots of my machines, I nuked it.
So Fedora behaviour should not have changed across this patch.
I think a related change was made to the Fedora udev scripts at about the same time.
I definitely noticed a change. One day I went to copy some stuff to floppy and I couldn't mount the floppy drive. I eventually found out what needed to be done, so it isn't a big deal for me anymore. But my machines with floppy drives still don't get /dev/floppy created unless I run modprobe floppy.
On 12 April 2010 21:50, Bruno Wolff III bruno@wolff.to wrote:
On Tue, Apr 13, 2010 at 06:38:59 +1000, Â Dave Airlie airlied@redhat.com wrote:
The thing was the window where this patch applied was about 3-4 weeks in rawhide, it went in upstream, it slowed boot down on lots of my machines, I nuked it.
So Fedora behaviour should not have changed across this patch.
I think a related change was made to the Fedora udev scripts at about the same time.
I definitely noticed a change. One day I went to copy some stuff to floppy and I couldn't mount the floppy drive. I eventually found out what needed to be done, so it isn't a big deal for me anymore. But my machines with floppy drives still don't get /dev/floppy created unless I run modprobe floppy.
Which is what people who still use floppies (for some reason only known to themselves) can do if they need the functionality.
By all means stick it in release notes but I distinctly remember reading somewhere about Fedora being "bleeding edge" or something and to be discussing how best to enable legacy magnetic storage devices which hold less than 2MB of data in 2010 is a bit ... embarassing.
The argument about this being required for places where they cannot afford flash drives or CD-RW doesn't hold much weight either as flash storage is so cheap and floppy disks so scarce and have such small capacity that floppy drives are all but useless.
On Mon, 12 Apr 2010, Christopher Brown wrote:
On 12 April 2010 21:50, Bruno Wolff III bruno@wolff.to wrote:
On Tue, Apr 13, 2010 at 06:38:59 +1000, Â Dave Airlie airlied@redhat.com wrote:
The thing was the window where this patch applied was about 3-4 weeks in rawhide, it went in upstream, it slowed boot down on lots of my machines, I nuked it.
So Fedora behaviour should not have changed across this patch.
I think a related change was made to the Fedora udev scripts at about the same time.
I definitely noticed a change. One day I went to copy some stuff to floppy and I couldn't mount the floppy drive. I eventually found out what needed to be done, so it isn't a big deal for me anymore. But my machines with floppy drives still don't get /dev/floppy created unless I run modprobe floppy.
Which is what people who still use floppies (for some reason only known to themselves) can do if they need the functionality.
One good reason: there are tons of oscilloscopes and other industrial equipement that do their jobs pretty well, but the only way to transfer images is to use floppy.
Another one: Do you own or code for any "obscure" old 8bit computer? No. Your fault - this is a big fan. They also use floppy drives. Then the PC drive you can use for emulators, transfers of your code etc.
The argument about this being required for places where they cannot afford flash drives or CD-RW doesn't hold much weight either as flash storage is so cheap and floppy disks so scarce and have such small capacity that floppy drives are all but useless.
And what about dropping CDROM support? This would definitely solve this https://bugzilla.redhat.com/show_bug.cgi?id=453095 stupid bug which is bothering people for almost two years. And is also related to anaconda.
-- Christopher Brown
Adam Pribyl
2010/4/14 Adam Pribyl pribyl@lowlevel.cz:
[...] And what about dropping CDROM support? This would definitely solve this https://bugzilla.redhat.com/show_bug.cgi?id=453095 stupid bug which is bothering people for almost two years. And is also related to anaconda.
I fail to see how this is related to this at all "there is a random bug using hw $foo so lets drop support for $foo" isn't the main point here ... it is about not loading a module for _ancient_ hardware.
2010/4/14 Adam Pribyl pribyl@lowlevel.cz:
On Mon, 12 Apr 2010, Christopher Brown wrote:
On 12 April 2010 21:50, Bruno Wolff III bruno@wolff.to wrote:
On Tue, Apr 13, 2010 at 06:38:59 +1000, Â Dave Airlie airlied@redhat.com wrote:
The thing was the window where this patch applied was about 3-4 weeks in rawhide, it went in upstream, it slowed boot down on lots of my machines, I nuked it.
So Fedora behaviour should not have changed across this patch.
I think a related change was made to the Fedora udev scripts at about the same time.
I definitely noticed a change. One day I went to copy some stuff to floppy and I couldn't mount the floppy drive. I eventually found out what needed to be done, so it isn't a big deal for me anymore. But my machines with floppy drives still don't get /dev/floppy created unless I run modprobe floppy.
Which is what people who still use floppies (for some reason only known to themselves) can do if they need the functionality.
One good reason: there are tons of oscilloscopes and other industrial equipement that do their jobs pretty well, but the only way to transfer images is to use floppy.
So they can manually load the driver then...
Another one: Do you own or code for any "obscure" old 8bit computer? No. Your fault - this is a big fan. They also use floppy drives. Then the PC drive you can use for emulators, transfers of your code etc.
I'm not sure where you are going here...
The argument about this being required for places where they cannot afford flash drives or CD-RW doesn't hold much weight either as flash storage is so cheap and floppy disks so scarce and have such small capacity that floppy drives are all but useless.
And what about dropping CDROM support? This would definitely solve this https://bugzilla.redhat.com/show_bug.cgi?id=453095 stupid bug which is bothering people for almost two years. And is also related to anaconda.
Now you've completely lost me.
Hi,
On 04/12/2010 10:38 PM, Dave Airlie wrote:
On Mon, 2010-04-12 at 12:18 -0500, Bruno Wolff III wrote:
On Mon, Apr 12, 2010 at 12:58:35 -0400, Kyle McMartinkyle@mcmartin.ca wrote:
The problem is, EVERYONE has a floppy controller and NOBODY(*) has a floppy disk drive. PNP only reports the presence of the controller, not the drive.
Ergo: FAIL for everyone, for the sake of some ancient crap that nobody except for a vocal minority of approximately three people cares about.
I am not an expert on the tradeoffs on the kernel side and don't have a real strong opinion there. But I do think if floppy drives aren't available by default, there should be some documentation somewhere that tells people how to enable their floppy drives. That isn't necessarily the job of the kernel maintainers.
Maybe at first boot people could get asked.
Maybe a drive could be looked for once and the result remembered. (I expect that a lot less people move floppy drives around than use them.)
Maybe it could be on an FAQ.
Maybe it could be mentioned in the release notes. (Though I think this change first affected f12, I don't remember running accross any notice before I first ran into the problem.)
The thing was the window where this patch applied was about 3-4 weeks in rawhide, it went in upstream, it slowed boot down on lots of my machines, I nuked it.
So Fedora behaviour should not have changed across this patch.
Yet it did (change), as udev used to carry a modprobe.conf file which contained the same alias, and that was dropped when the alias was added to the kernel.
If you look at this F-10 udev build: http://koji.fedoraproject.org/koji/buildinfo?buildID=105370
You will see the udev package contains a file called: /etc/modprobe.d/floppy-pnp
With as content: alias pnp:dPNP0700 floppy
So we do have a change being caused by this patch, as this patch removes the kernel alias which was to replace the removed udev floppy-pnp modprobe.conf file.
More interesting though is the question if we can somehow fix this for people who have a floppy drive without causing the boot delay for people who don't.
When you hit this issue, did you check that your BIOS was configured for you not having a floppy drive ? In my experience on several machines, the PNP0700 id will go away if you tell the BIOS that there is no floppy drive attached (in the good old plain CMOS screen, where you can usually also set date / time).
Regards,
Hans
Hi,
On 04/12/2010 06:58 PM, Kyle McMartin wrote:
On Mon, Apr 12, 2010 at 11:51:10AM -0500, Bruno Wolff III wrote:
I occasionally use them for transferring data between some old laptops and machines running Fedora. Occasionally I have also used them for driver disks, though all of my computers currently are on the last bios version they are ever likely to get.
As things went in the other discussion, it isn't hard to get floppies to work, it's hard finding out what the issue is and how to fix it. Now that I know I need to run modprobe it isn't a big deal for me. But this information is not readily available to people and can cause significant problems for people who stumble accross it.
The problem is, EVERYONE has a floppy controller and NOBODY(*) has a floppy disk drive.
Wrong, except for laptops until very recently every single standard machine sold came with a floppy drive. In the university where I used to work all new machines came with a ... floppy. That is all 2000 of them.
Where are your numbers, statements like EVERYONE and NOBODY really are quite meaningless without some solid numbers to back them up.
PNP only reports the presence of the controller, not the drive.
Wrong again, on most machines the presence of the PNP0700 id in the PNP data depends on the setting of the floppy drive type in the BIOS, set it to None and PNP0700 id goes away.
Ergo: FAIL for everyone, for the sake of some ancient crap that nobody except for a vocal minority of approximately three people cares about.
Erm, you *completely* failed to respond to my upstream argument, if this is as clear cut a decision as you make it, why don't you take it upstream ?
This whole discussion really is quite simply, there are 3 options here:
1) floppy driver autoloading on pnp info is a bad idea -> take it upstream
2) this is a gray area -> let not deviate from upstream, discuss upstream
3) floppy driver autoloading is fine, people with problems need to be educated to properly configure their BIOS
Also note that anaconda is autoloading the floppy driver on every install, so if it would really be the cause of a lot of problems, we (the anaconda team) would have been overwhelmed by bug reports about this by now, which surprise, surprise we are not.
Regards,
Hans
On Mon, Apr 12, 2010 at 09:51:20PM +0200, Hans de Goede wrote:
Wrong, except for laptops until very recently every single standard machine sold came with a floppy drive. In the university where I used to work all new machines came with a ... floppy. That is all 2000 of them.
Where are your numbers, statements like EVERYONE and NOBODY really are quite meaningless without some solid numbers to back them up.
Alright, whatever. I have no interest in arguing this.
PNP only reports the presence of the controller, not the drive.
Wrong again, on most machines the presence of the PNP0700 id in the PNP data depends on the setting of the floppy drive type in the BIOS, set it to None and PNP0700 id goes away.
No, it's just like everything else. This is how the BIOS /should/ work, theory and practice are seldom similar. This bit Dave, and it bit me on all my machines, across a variety of vendors.
Erm, you *completely* failed to respond to my upstream argument, if this is as clear cut a decision as you make it, why don't you take it upstream ?
This whole discussion really is quite simply, there are 3 options here:
floppy driver autoloading on pnp info is a bad idea -> take it upstream
this is a gray area -> let not deviate from upstream, discuss upstream
Upstream is irrelevant. They don't make an OS, we do.
- floppy driver autoloading is fine, people with problems need to be educated to properly configure their BIOS
This is ridiculous.
Also note that anaconda is autoloading the floppy driver on every install, so if it would really be the cause of a lot of problems, we (the anaconda team) would have been overwhelmed by bug reports about this by now, which surprise, surprise we are not.
The issue is that probing the controller with no drives attached causes extremely long boot delays. That's why we removed the module aliases.
regards, Kyle
Hi,
On 04/12/2010 11:06 PM, Kyle McMartin wrote:
<snip>
PNP only reports the presence of the controller, not the drive.
Wrong again, on most machines the presence of the PNP0700 id in the PNP data depends on the setting of the floppy drive type in the BIOS, set it to None and PNP0700 id goes away.
No, it's just like everything else. This is how the BIOS /should/ work, theory and practice are seldom similar. This bit Dave, and it bit me on all my machines, across a variety of vendors.
This is how the BIOS actually works in my experience across quite a large number of machines. Did you actually verify the floppy was listed as not being present in the CMOS setup on all those machines? One reset to defaults will put it back at 1.44 MB.
Note that AFAIK windows relies on this working properly too, so I would be surprised if a lot of machines got this wrong (sure some will have gotten it wrong).
Also I find it a bit strange that we now default to making properly working hardware not work out of the box (and yes people still use floppies), so as to avoid a boot delay on buggy hardware ?
That very much seems like the other way around then how things should be.
Erm, you *completely* failed to respond to my upstream argument, if this is as clear cut a decision as you make it, why don't you take it upstream ?
This whole discussion really is quite simply, there are 3 options here:
floppy driver autoloading on pnp info is a bad idea -> take it upstream
this is a gray area -> let not deviate from upstream, discuss upstream
Upstream is irrelevant. They don't make an OS, we do.
Yes, so that is why we always say that any patches going into the Fedora kernel should either already be upstream, or have a clear path of being included upstream. I don't see how this patch is so special that that rule all of a sudden does not apply. Esp. as this is not as clear a case as you seem to think it is (and again if it is as clear a case, take it upstream).
- floppy driver autoloading is fine, people with problems need to be educated to properly configure their BIOS
This is ridiculous.
Really statements like "ridiculous" and "irrelevant" (nor the "extremely" below), do not help in having a constructive discussion about this.
Again lets talk numbers here. Having a discussion like this on anything but numbers is really rather meaningless.
I'm sure we all have access to a wide variety of machines, so lets actually see what happens to the PNP0700 id when the floppy gets marked as disabled in the BIOS, you can easily find this out, by making sure the floppy is disabled in the BIOs and then doing: cat /sys/bus/pnp/devices/*/id
If PNP0700 is not listed, the BIOS is behaving properly and dropping the die-floppy-die patch won't affect the machine.
Here are my numbers: Asus M2N SLI deluxe: PNP0700 disappears Abit KV8 Pro: PNP0700 disappears (*) Asrock AM2NF3-VSTA: PNP0700 disappears Compaq Evo N600C: PNP0700 disappears Dell Latitude E6400: no floppy config possible, laptop, no PNP0700 MSI Wind u100: no floppy config possible, laptop, no PNP0700
*) After setting floppy controller to disabled in a separate config screen, simply setting the attached floppy type to None does not work.
Also note that anaconda is autoloading the floppy driver on every install, so if it would really be the cause of a lot of problems, we (the anaconda team) would have been overwhelmed by bug reports about this by now, which surprise, surprise we are not.
The issue is that probing the controller with no drives attached causes extremely long boot delays. That's why we removed the module aliases.
Again numbers please. I just did "modprobe floppy" on my floppy less main workstation, and it took 2 seconds. Also aren't we loading modules in parallel now a days ?
Regards,
Hans
On Tue, Apr 13, 2010 at 10:27:53AM +0200, Hans de Goede wrote:
Here are my numbers: Asus M2N SLI deluxe: PNP0700 disappears Abit KV8 Pro: PNP0700 disappears (*) Asrock AM2NF3-VSTA: PNP0700 disappears Compaq Evo N600C: PNP0700 disappears Dell Latitude E6400: no floppy config possible, laptop, no PNP0700 MSI Wind u100: no floppy config possible, laptop, no PNP0700
*) After setting floppy controller to disabled in a separate config screen, simply setting the attached floppy type to None does not work.
So of the machines you tested that have a floppy controller, 25% are buggy in the way that Kyle described. That's a pretty compelling argument against assuming that PNP0700 indicates the presence of a floppy drive. If you're interested in improving this, perhaps you could try adding a check for the CMOS bytes that indicate floppy configuration and make that check conditional on the machine being a PC? That might fix enough of these cases that we could turn the module loading back on by default.
Alternatively, on ACPI machines, call the _FDE method and parse the results of that if it's present. Falling back to CMOS after that seems reasonable.
Hi,
On 04/13/2010 03:59 PM, Matthew Garrett wrote:
On Tue, Apr 13, 2010 at 10:27:53AM +0200, Hans de Goede wrote:
Here are my numbers: Asus M2N SLI deluxe: PNP0700 disappears Abit KV8 Pro: PNP0700 disappears (*) Asrock AM2NF3-VSTA: PNP0700 disappears Compaq Evo N600C: PNP0700 disappears Dell Latitude E6400: no floppy config possible, laptop, no PNP0700 MSI Wind u100: no floppy config possible, laptop, no PNP0700
*) After setting floppy controller to disabled in a separate config screen, simply setting the attached floppy type to None does not work.
So of the machines you tested that have a floppy controller, 25% are buggy in the way that Kyle described.
Erm, no, they are not buggy the BIOS authors have simply chosen to add a separate config option for disabling the floppy controller, rather then automatically doing so when the floppy type is set to None.
One more data point: Fujitsu S26361-D2831: PNP0700 disappears (*)
Yes (*), same thing as with the Abit board.
Anyways as I see it 100% of the 7 machines I've tested allow the user to disable the auto loading of the floppy driver by properly configuring the BIOS.
I must say I'm a bit disappointed that everyone else who seems to have an opinion on this has not taken the 5 minutes / machine to provide us with more data points :|
That's a pretty compelling argument against assuming that PNP0700 indicates the presence of a floppy drive.
It indicates the presence of a floppy drive controller. And if that is present we should load the driver for it, at least that would be the consistent thing to do as that is how we handle all other hardware.
I still don't understand this whole discussion it seems pretty clear cut to me:
1) We are currently shipping a non upstream patch, with no intention of taking it upstream (clear violation of Fedora kernel policies last time I checked).
2) This causes peoples hardware to not work out of the box (regression!)
3) This is done so that people who have not configured their system properly do not suffer a boot delay (nothing more).
Note I don't care much personally as I very seldom use floppies and I'm technically capable of fixing this. But this does not make us look good wrt userfriendlyness, ie this is certainly not something I can explain to my mother in law who is using Fedora and still uses floppies.
Regards,
Hans
On Wed, Apr 14, 2010 at 09:49:13AM +0200, Hans de Goede wrote:
Hi,
So of the machines you tested that have a floppy controller, 25% are buggy in the way that Kyle described.
Erm, no, they are not buggy the BIOS authors have simply chosen to add a separate config option for disabling the floppy controller, rather then automatically doing so when the floppy type is set to None.
The point is that we do not wish to probe the floppy controller if there are no floppy drives attached. Therefore autoloading on PNP0700 is not acceptable.
- We are currently shipping a non upstream patch, with no intention of taking it upstream (clear violation of Fedora kernel policies last time I checked).
This is a policy decision, not a functionality decision. We ship several such patches.
- This causes peoples hardware to not work out of the box (regression!)
It causes most people's hardware to work better.
- This is done so that people who have not configured their system properly do not suffer a boot delay (nothing more).
This is done so that people who have a common hardware configuration do not suffer a boot delay.
Note I don't care much personally as I very seldom use floppies and I'm technically capable of fixing this. But this does not make us look good wrt userfriendlyness, ie this is certainly not something I can explain to my mother in law who is using Fedora and still uses floppies.
Solutions have been proposed. Like most things, if it's something that itches you then feel free to scratch it.
Hi,
Ok, I think I just had an idea which might solve this in a way that makes everyone happy, without depending on people getting their BIOS settings right.
How about we drop die-floppy-die.patch, so that the driver will autoload again, and then add a script to initscripts that checks if any floppy drives were detected, and if not, then it blacklists the floppy driver ?
This way we only get the boot delay caused by the floppy driver probing (in case of no floppy) once (on the first boot), and we make the floppy drive work out of the box for people who still have and use one.
Regards,
Hans
On 14 April 2010 09:01, Hans de Goede hdegoede@redhat.com wrote:
Hi,
Ok, I think I just had an idea which might solve this in a way that makes everyone happy, without depending on people getting their BIOS settings right.
How about we drop die-floppy-die.patch, so that the driver will autoload again, and then add a script to initscripts that checks if any floppy drives were detected, and if not, then it blacklists the floppy driver ?
Sounds sane but would suggest this is something done for F14 Alpha rather than F13.
This way we only get the boot delay caused by the floppy driver probing (in case of no floppy) once (on the first boot), and we make the floppy drive work out of the box for people who still have and use one.
Are you also offering to be point man for kernel bug reports? :)
On Wed, Apr 14, 2010 at 21:02:01 -0400, Kyle McMartin kyle@mcmartin.ca wrote:
On Wed, Apr 14, 2010 at 10:01:51AM +0200, Hans de Goede wrote:
i've written support for acpi enumeration which seems to be working; i'll commit it tomorrow after one of my final exams, and drop the pnp neutering.
Thanks!
Hi,
On 04/15/2010 03:02 AM, Kyle McMartin wrote:
On Wed, Apr 14, 2010 at 10:01:51AM +0200, Hans de Goede wrote:
i've written support for acpi enumeration which seems to be working; i'll commit it tomorrow after one of my final exams, and drop the pnp neutering.
Great! Many many thanks!
Regards,
Hans
On Tue, Apr 13, 2010 at 7:23 PM, drago01 drago01@gmail.com wrote:
On Tue, Apr 13, 2010 at 10:27 AM, Hans de Goede hdegoede@redhat.com wrote:
[...] Again numbers please. I just did "modprobe floppy" on my floppy less main workstation, and it took 2 seconds.
2 seconds sounds like a very long time for just loading a module.
Also aren't we loading modules in parallel now a days ?
No.
(resend with list CCed)
kernel@lists.fedoraproject.org
-
Adam Jackson -
Adam Pribyl -
Bruno Wolff III -
Christopher Brown -
David Airlie -
drago01 -
Hans de Goede -
Kyle McMartin -
Matthew Garrett -
Matthew Garrett