10:36 a.m.
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
11:04 a.m.
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
11:51 a.m.
On Mon, Apr 12, 2010 at 12:04:09 -0400,
Adam Jackson <ajax(a)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.
11:58 a.m.
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
12:18 p.m.
On Mon, Apr 12, 2010 at 12:58:35 -0400,
Kyle McMartin <kyle(a)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.)
12:25 p.m.
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.)
12:27 p.m.
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.)
1:03 p.m.
On Mon, Apr 12, 2010 at 13:27:22 -0400,
Kyle McMartin <kyle(a)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.)
3:38 p.m.
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
3:50 p.m.
On Tue, Apr 13, 2010 at 06:38:59 +1000,
Dave Airlie <airlied(a)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.
4:05 p.m.
New subject: RFC: re-enable auto loading of floppy driver when the PNP info says there is a floppy
On 12 April 2010 21:50, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Tue, Apr 13, 2010 at 06:38:59 +1000,
 Dave Airlie <airlied(a)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.
--
Christopher Brown
12:38 p.m.
On Mon, 12 Apr 2010, Christopher Brown wrote:
On 12 April 2010 21:50, Bruno Wolff III <bruno(a)wolff.to>
wrote:
> On Tue, Apr 13, 2010 at 06:38:59 +1000,
> Â Dave Airlie <airlied(a)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
12:50 p.m.
New subject: RFC: re-enable auto loading of floppy driver when the PNP info says there is a floppy
2010/4/14 Adam Pribyl <pribyl(a)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.
3:56 p.m.
New subject: RFC: re-enable auto loading of floppy driver when the PNP info says there is a floppy
2010/4/14 Adam Pribyl <pribyl(a)lowlevel.cz>:
On Mon, 12 Apr 2010, Christopher Brown wrote:
> On 12 April 2010 21:50, Bruno Wolff III <bruno(a)wolff.to> wrote:
>>
>> On Tue, Apr 13, 2010 at 06:38:59 +1000,
>> Â Dave Airlie <airlied(a)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.
--
Christopher Brown
2:17 a.m.
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 McMartin<kyle(a)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
2:51 p.m.
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
4:06 p.m.
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:
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
Upstream is irrelevant. They don't make an OS, we do.
3) 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
3:27 a.m.
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:
>
> 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
>
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).
> 3) 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
8:59 a.m.
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.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:17 a.m.
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.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:49 a.m.
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
7:43 a.m.
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.
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).
This is a policy decision, not a functionality decision. We ship several
such patches.
2) This causes peoples hardware to not work out of the box
(regression!)
It causes most people's hardware to work better.
3) 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.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
3:01 a.m.
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
11:56 a.m.
New subject: RFC: re-enable auto loading of floppy driver when the PNP info says there is a floppy
On 14 April 2010 09:01, Hans de Goede <hdegoede(a)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? :)
--
Christopher Brown
8:33 p.m.
On Wed, Apr 14, 2010 at 21:02:01 -0400,
Kyle McMartin <kyle(a)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!
1:36 a.m.
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
12:24 p.m.
New subject: RFC: re-enable auto loading of floppy driver when the PNP info says there is a floppy
On Tue, Apr 13, 2010 at 7:23 PM, drago01 <drago01(a)gmail.com> wrote:
On Tue, Apr 13, 2010 at 10:27 AM, Hans de Goede
<hdegoede(a)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)
5122
days inactive
5125
days old
kernel@lists.fedoraproject.org
28 comments
10 participants
participants (10)
-
Adam Jackson -
Adam Pribyl -
Bruno Wolff III -
Christopher Brown -
David Airlie -
drago01 -
Hans de Goede -
Kyle McMartin -
Matthew Garrett -
Matthew Garrett