Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: doixanh on July 13, 2010, 09:16:55 AM
-
My laptop doesn't have any floppy drives, but it still takes the kernel to detect it during start up
This is my dmesg :
...
Real Time Clock Driver v1.12b
Non-volatile memory driver v1.3
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
Floppy drive(s): fd0 is 1.44M
TC kernel stops loading here for around 3-4 secs, and then
floppy0: no floppy controllers found
brd: module loaded
input: Macintosh mouse button emulation as /devices/virtual/input/input3
Uniform Multi-Platform E-IDE driver
piix 0000:00:1f.1: IDE controller (0x8086:0x2850 rev 0x02)
....
I don't use the floppy drive, so is there anyway to prevent the kernel from detecting it at boot time?
Thanks.
-
Is there a bios setting about legacy emulation of floppy drives you could disable maybe?
-
There is no "floppy" related setting in my bios :-( Is there any other chance I could disable TC from detecting it ?
-
There might be a linux kernel parameter, otherwise you could recompile the kernel without it (seems to be built in).
-
This may help:
http://www.cyberciti.biz/tips/blade-server-disable-floppy-driver-module.html
-
I'm having the same issue. I'm losing 3 seconds during boot (out maybe 12 seconds total, a major chunk!) due to the check for a non-existant floppy drive.
The referenced link indicates I should modify /etc/modprobe.conf . Can I add this file to my /.filetool.lst file, or can I put it in a .tcz, or does it need to go into microcore.gz?
-
I tried adding "alias floppy off" to my modprobe.conf file, and then adding that to .filetool.lst, but that didn't work. I also remastered microcore.gz following the steps on the Wiki (though I skipped the depmod step), adding that line to the modprobe.conf file. That also didn't work.
Suggestions anyone?
I also tried "floppy.allowed_drive_mask=0" in my kernel parameters.
-
There is no kernel parameter to disable the floppy drive. The driver is compiled into
the kernel. I don't know if this would work but you could try lying to the kernel. Go to
www.mjmwired.net/kernel/, switch to the blockdev directory, and read the floppy.txt file.
Check out the "floppy=<drive>,<type>,cmos" parameter. Maybe the kernel will take
your word for it if you tell it you have a certain type of floppy and skip the probe for it.
-
I'm having the same issue. I'm losing 3 seconds during boot (out maybe 12 seconds total, a major chunk!) due to the check for a non-existant floppy drive.
First of all your claim of "losing 3 seconds" is not convincing - at least not to me - without any comparative reference.
It has been clearly stated in an earlier post that recompiling the kernel would be a systematical approach to remove hardware support.
But say as a working hypothesis it would be established that there would be a difference in boot time of 3 seconds, of what practical value could that be? How much could the possible expectable accumulated (from all future boots) gain be compared to the expectable loss of going through length to achieve it?
-
Oh freaking heck, it's just a feel-good "Look how fast my system boots!" measure. It's not going to end world hunger or prevent financial collapse. It just reduces the amount of time I spend staring at a (mostly) black screen with a blinking cursor waiting for something to happen.
As to the 3 seconds, using kernel parameters "syslog printk.time=1", I see in dmesg:
[ 0.762322] Floppy drive(s): fd0 is 1.44M
[ 3.783424] No floppy controller found
It's very real. On another machine that actually has a floppy controller, it passes through that step in about 0.01 second. If I use the kernel parameter "floppy=debug", I see that it's trying to lock fd0, which it times out on in 3 seconds (sorry, I don't have the messages withe me, it's on my home computer).
I'm sure that recompiling the kernel would solve it. I was just hoping to avoid that for now, though I may get to it soon.
As to the lost hours spent trying to get rid of three seconds of boot time, you're right. Logic would indicate I should just ignore it and move on with life. But then if I were logical, I would realize that it's way easier to just use windows like everyone else in the world, instead of trying to learn how to solve this massive puzzle called Linux.
-
Yes, I have received the memo. Everyone do check your bioses though, there is often a setting "disable floppy" "no floppy" etc.
-
I was able to reproduce your results. Adding the "floppy=0,irq" boot parameter will eliminate the delay. You cannot disable the driver, but you can make it fail by giving it bad data:
[ 0.000000] floppy0: irq=0
[ 3.150974] Floppy drive(s): fd0 is 1.44M
[ 3.150979] floppy0: Unable to grab IRQ0 for the floppy driver
there is often a setting "disable floppy" "no floppy" etc.
Yes, but on my system (choices: off, usb, internal, read-only) setting it to off does not affect the delay.
I also tried "floppy.allowed_drive_mask=0" in my kernel parameters.
The proper syntax is "floppy=0,allowed_drive_mask" but it does not eliminate the delay.
This may help:
http://www.cyberciti.biz/tips/blade-server-disable-floppy-driver-module.html
I tried blacklist=floppy, but that didn't seem to have any affect.
-
In 3.4.1 roberts added a fix to avoid searching for non-existent floppy.
-
In 3.4.1 roberts added a fix to avoid searching for non-existent floppy.
Changelog states "skip floppy label detection" ;)
-
I'm using 3.4.1, so I think that change doesn't skip loading the floppy module.
I also tried blacklist=floppy, with no effect.
I don't have any parameter in my BIOS regarding floppy drives.
I'll try floppy=0,irq tonight when I get home. If that skips the delay as it did for you, that'll be perfect.
-
I'm using 3.4.1, so I think that change doesn't skip loading the floppy module.
Correct, as the observed delay of 3 sec appears during the kernel boot phase and Robert's change was done AFAIK in '/usr/bin/mountables.sh' (a helper script for the Mount Tool if I'm not mistaken).
-
kernel parameter "floppy=0,irq" did the trick.
Thank you very much!
-
Oh freaking heck, it's just a feel-good "Look how fast my system boots!" measure.
Heh, ok, to each their own... :D
Personally I would rather adapt the more conventional/traditional Linux users approach of feel-good "Look how rarely my system needs to boot" and therefore put priority of stability over boot time.
After all 'uptime' is a most basic command to check with one glimpse - and its output directly comparable ;)
-
kernel parameter "floppy=0,irq" did the trick.
Thank you very much!
Really curious now if you could us provide us with a comparison of total boot time in each case. ;)
-
I personally don't like to leave my compters on when I'm not using them. My Windows machine often gets left on, simply because it's a drag waiting for it to boot (a couple minutes), though that's nothing compared to my computer at work, which I NEVER turn off, because it can take 15 minutes...
My last kernel message has a timestamp of 5.4 seconds. It takes about a second each to get through BIOS and bootloader. The rest of the time probably gets taken up with loading the kernel from disk, and starting various vital extensions (wireless drivers, xvesa, flwm, ...)
In total, it's about 12 seconds from pushing the ON button to looking at flwm.
-
It's somewhat funny how this can too be blamed on the bios writers :P
Nobody on the team has reported this, probably because all our hw either has a floppy drive or has a proper bios that doesn't poll when the floppy drive is set to none.
-
Really curious now if you could us provide us with a comparison of total boot time in each case.
My results are similar (about 20% savings):
BEFORE
[ 3.902644] Floppy drive(s): fd0 is 1.44M
[ 6.913368] floppy0: no floppy controllers found
[ 15.701130] EXT4-fs (loop0): mounted filesystem without journal
AFTER
[ 3.172265] Floppy drive(s): fd0 is 1.44M
[ 3.172374] floppy0: Unable to grab IRQ0 for the floppy driver
[ 11.994172] EXT4-fs (loop0): mounted filesystem without journal
-
I personally don't like to leave my compters on when I'm not using them.
Have you considered suspend?
In total, it's about 12 seconds from pushing the ON button to looking at flwm.
Is that with floppy disabled by boot param or without?
How much is the value in the other case?
-
Really curious now if you could us provide us with a comparison of total boot time in each case.
My results are similar (about 20% savings):
BEFORE
[ 3.902644] Floppy drive(s): fd0 is 1.44M
[ 6.913368] floppy0: no floppy controllers found
[ 15.701130] EXT4-fs (loop0): mounted filesystem without journal
AFTER
[ 3.172265] Floppy drive(s): fd0 is 1.44M
[ 3.172374] floppy0: Unable to grab IRQ0 for the floppy driver
[ 11.994172] EXT4-fs (loop0): mounted filesystem without journal
Not exactly what I meant by total boottime, but time until desktop has finished fully loading.
e.g. there could be a possibility that floppy probing would directly delay the mounting of that loop without excluding that other processes are running in parallel.
-
Is suspend easy to get working with TCL? It was pretty hit and miss with Windows.
It was 3 seconds longer with the floppy check, so I would guess about 15 seconds. I'm also using several flags that help speed it along:
noicons (though I don't think this matters for me)
noswap (that helps a bit, not having to mount swap)
nodhcp (though this gets done for my wifi in bootlocal.sh
noutc (probably no gain)
embed (doesn't have to move files, I'm guessing?)
nozswap (this was taking some time)
I also am using microcore, and converted Xvesa, Xlibs, Xprogs, and flwm_topside to .tcz's instead of .tg'z, which I think saves me a few milliseconds.
I'm only assuming it was 3 seconds longer until desktop. I'd have to check again to make sure.
-
It's somewhat funny how this can too be blamed on the bios writers :P
Nobody on the team has reported this, probably because all our hw either has a floppy drive or has a proper bios that doesn't poll when the floppy drive is set to none.
I happen to have a laptop with a broken floppy drive which results in a delay during POST but not during OS boot. :P