Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: jason.ritzke on January 22, 2011, 10:08:46 AM
-
Alright, I've tried this with every cheat code I know from other distros, in case there is one undocumented. No matter what I do, I cannot get TC to boot. Every time I get:
hde: timeout waiting for DMA
Now, I only have 4 hdd's in this box, so I'm assuming hde is the cd?
Also, before you ask, the system cannot boot from a USB stick as an alternative.
Compaq Proliant ML330 G2.
Any advice would be appreciated. I'm confident that once I get this booting I can move on fairly quickly.
-
Try ide=nodma.
-
Hi Jason
The fact that it's complaining about hde suggests that you have 5 drives in your rig. Are
you running SCSI, a mix of SCSI and ide, or an extra IDE controller card? A little more
information about your hardware might aid in solving your problem. You can also try
checking your BIOS setup to see if you can turn off DMA to your drives. If you can, do it
to all drives just to see if you can boot and to make sure none of the other drives are
causing a problem. If it boots you can start re-enabling DMA on the drives one by one.
-
Intelligent reply, unfortunately something I've already tried.
I have tried (from previous posts for tinycore here and elsewhere):
nodma ide-core=nodma ide=nodma dma=off
On to the second reply:
Unfortunately, the bios of this system does not allow me to deactivate the DMA on the system, In fact, it doesn't give me many options on the drives themselves at all. It is a compaq server from the early 2000's, which means proprietary and annoying as hell. If I could get it to even boot a *nix distro from the HDD I would, but the system won't boot a kernel from the HDD at all.
-
With regards to your actual QUESTION regarding my system configuration, this is what it is:
2 1.4 ghz p3's
768 MB of ECC Signed ram
Onboard ATI Rage XL
Onboard LSI MegaRAID host raid controller
Onboard 10/100 ethernet (don't remember the manufacturer off the top of my head.
Drives are like this
On the RAID card:CH1mas=40gb Maxtor,CH2slv=empty,CH2mas=40gb Maxtor,CH2slv=empty
NOTE the raid drives are configured as spare pool only in the host raid bios. I'd turn it off completely if I could, but then I lose the channels
IDE:CH1mas=CD drive,CH1slv=empty,CH2mas=60gb seagate,CH2slv=40gb maxtor
I don't see what HDE could be except for the CD....
And no, I don't have a usb drive plugged in to the back :-)
-
I thought I should mention that the LSI MegaRAID (which is built in on a full length daughtercard with the graphics and the lan) is IDE RAID, not SCSI. There are no SCSI drives in the system.
-
Wow, you've got a lot going on there. If it was me I would first try a different CD drive
if I had one sitting around. Next, I would unplug anything not essential to boot, meaning
you want to lose hard drives, maybe disable the second proccessor if you can, in other
words simplify the system as much as possible and see if anything changes. I also saw
someone wrote that there is a setup disk for this model that is required to access certain
bios settings required to boot linux.
-
Have you looked into booting over ethernet?
-
Have you tried the HP website? When you boot what rom version does it report?
According to HP the last revision is "4.04 (D10-11/01/2003) (9 Dec 2003)". One
of the fixes listed is "Issue where Linux could set the embedded IDE controller
to the wrong DMA speeds.". Also download Smartstart while you are there, it's
a CD iso for setting up the machine.
-
1. Bios is version D10 already.
2. System will run most livecd's (puppy, knoppix, etc.) incl. troublesome ones if you set acpi=off. I've only had boot problems with HDD installs (IE bios not liking my boot loader) and Tiny Core.
3. I did one better than unplugging things. I went into the bios and disabled every channel or controller other than the CD. Still no go. ALTHOUGH this time it was "hda: timeout waiting for DMA".
Long and short, the CD drive runs fine (diagnosis:runs other distros), this isn't the bios bug (diagnosis: version d10 installed) and this isn't the complexity of the system (I turned everything else off).
As for the HP website, they've yanked their debian netinst iso's. Aside from that, there is no real linux support. The disks in question are driver and kernel packs to help with install compatibility, but I think mostly they contain a driver for the MegaRAID when it's being used as a RAID controller instead of just a spare pool, as well as enterprise power management stuff.
I haven't really looked at netbooting tinycore. Any useful links? The only *nix I've ever PXE'd was CloneZilla Server.
-
'tc-terminal-server' script is included in TC base.
-
Since you are still getting dma errors when you add ide=nodma that suggests that
the kernel does not see it. Dumb questioin but, did you type "tinycore ide=nodma"?
Without the name tinycore it may ignore it.
-
Yes, I typed "tinycore" first :-)
Tinypoodle, I might consider that. I guess I'd like to check all other options first, because that means I'd have to use up another box (or at least start a VM) unless you have a better idea up your sleeve that you just aren't sharin.
If anybody has any ideas as to why the kernel isn't taking my nodma command, they'd be awesome to hear.
-
Hi jason
I found something, ide=nodma is obsolete. Now that you've disabled everything and the
CD is drive hda try "tinycore ide-core.dma=0.0 libdata.dma=0" and see if that helps.
[EDIT]: Corrected syntax from ide_core to ide-core
-
I'm not sure if your issue is similar to the one I described here (http://forum.tinycorelinux.net/index.php?topic=7942.msg42565#msg42565). But my fairly old notebook produces a lot of DMA related error messages (AFAIK during the "autoscanning" that TC does during it's startup process) and the only way I managed to get it to boot from CD-ROM was by ejecting the CD-ROM manually after the boot loader was done (I've written about this in another post (http://forum.tinycorelinux.net/index.php?topic=7825.msg41922;topicseen#msg41922) as well).
In the end that might not be a viable method for you. But if you could get at least to the point of having a 'dmesg' output you might be able to target your next steps a bit more precisely.
-
Tinypoodle, I might consider that. I guess I'd like to check all other options first, because that means I'd have to use up another box (or at least start a VM) unless you have a better idea up your sleeve that you just aren't sharin.
Booting over ethernet would indeed require another box as "mothership", but only until your client box has booted, then the connection can be terminated and you are free to do with the other box as you like, incl. shutdown.
For a better idea up my sleeve... hmm...
You mention bios not liking my boot loader
but without being more specific...
In case you could successfully boot to a (even very minimal) DOS system, then it might be relatively easy to use a DOS based Linux bootloader, in which case it could be avoided to have the BIOS handing control over directly to your desired bootloader.
-
Rich: Sorry, no joy with that bootcode either.
Maro: Part of the problem is that I don't even get booted. In fact, I get no part of the boot process. The system fails to begin reading from the drive properly because it times out waiting for dma. Therefore it doesn't boot at all.
Tinypoodle:
The netboot idea is kind of interesting, although I hope you can see how it would be a MAJOR hassle in many situations.
As for the bootloader issue, sorry I wasn't more specific, but I like to keep threads on track. No HDD based bootloader I've tried has worked. Even with the boot partition in fat 32 and under 256mb. The bios doesn't even appear to see them. It just hangs with a flashing cursor followed by an "invalid system disk". Is that specific enough?
-
Hi jason
I'm so sorry, I mistyped the cheatcode. With your CD drive still trying to boot as hda
try "tinycore ide-core.nodma=0.0".
-
(1) I was initially mildly confused when I read for the first time:
Part of the problem is that I don't even get booted. In fact, I get no part of the boot process. The system fails to begin reading from the drive properly because it times out waiting for dma. Therefore it doesn't boot at all.
I thought that the kernel does not even get to run (i.e. the boot loader already fails to read from the CD-ROM). But that is obviously contradicted by the reported "timeout waiting for DMA" message which most likely is generated by the 'drivers/ide/ide-dma.c' file of the kernel.
(2) As a side note I've now managed to boot from CD-ROM on my old Dell notebook after adjusting the suggestion of reply #17 to my case: using 'ide-core.nodma=1.0' as boot code to disallow DMA on '/dev/hdc'.
I was wondering how using this boot code compared to my earlier suggestion to eject the CD-ROM after the boot loader (i.e. ISOLINUX) has done it's job. In my view the right time would be when the screen performs a refresh and the cursor jumps to the top right corner (and preferably before TC goes through it's startup process as noticable by the "Booting tinycore_3.4.1" message). But the disadvantage of this "ejection method" is that the CD-ROM would still not be usable after TC is running. As I discovered the DMA issues would just "resurface" when a CD-ROM has been put back in the drive and a mount /mnt/hdc was done.
The 'ide-core.nodma=1.0' boot code eliminated for me all those problems, so it might be the way to go for other systems of a certain age.
-
Maro, since you seem confused and to be coming to wrong conclusions about what is happening on my system, I shall give you a step by step account of what I see.
Post completes.
Tinycore boot prompt comes up.
I enter "tinycore [add switches of your choice here]" and press enter.
Screen flashes once. The tinycore boot prompt reappears, with the words that I entered.
After about 10 seconds "hd_: Timeout waiting for DMA" appears in the upper left hand corner. NOTHING ELSE. Just that.
That is what occurs. Does that help you to understand better?
-
Rich, I tried both ways :-). I figured it might be a typo, so I tried:
ide-core.nodma=0.0
ide_core.nodma=0.0
ide-core.nodma=0
ide_core.nodma=0
No joy. I'll keep pluggin.
-
Tinypoodle:
The netboot idea is kind of interesting, although I hope you can see how it would be a MAJOR hassle in many situations.
As for the bootloader issue, sorry I wasn't more specific, but I like to keep threads on track. No HDD based bootloader I've tried has worked. Even with the boot partition in fat 32 and under 256mb. The bios doesn't even appear to see them. It just hangs with a flashing cursor followed by an "invalid system disk". Is that specific enough?
Sorry, no, I can't see how a netboot could be a major hassle in many situations for you; for me it has often proven to be a major convenience, while I would have had even more choices than you appear to have with given hardware.
Yes, the issue about not being able to boot with a hdd based bootloader appears more clear now (besides from also having had a chance to look up your hardware) :)
As you said you like to keep threads on track, feel free to open another thread about possible approaches of booting ;)
-
I'd have to shut down a system in order to serve netboot TC every time I wanted to reboot the server I wanted to run TC in the first place. That is the hassle.
Is there really no way to shut off DMA in this situation?
-
From kernel-parameters.txt (http://www.kernel.org/doc/Documentation/kernel-parameters.txt):
ide-core.nodma= [HW] (E)IDE subsystem
Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc
.vlb_clock .pci_clock .noflush .nohpa .noprobe .nowerr
.cdrom .chs .ignore_cable are additional options
See Documentation/ide/ide.txt.
Try this: "ide-core.nodma=2.0"
-
Hi jason
If your CD is still trying to boot as drive A then that should have worked, however, if you
re-enabled your other drives and pushed the CD back to drive E then you will have to
use the code from danielibarnes since the code targets a specific drive. When you pass
a boot code to the kernel it makes no distinction between _ and -, either one will have
the same effect.
[EDIT]: Struck out the last sentence, it was just plain wrong.
-
@jason.ritzke: Thanks for your more detailed description (in reply #19).
As it quite evident from your description that the kernel is booting up I wonder whether you have already tried to use the 'debug' boot code. This boot code overwrites the 'quiet' boot code contained in the ISOLINUX configuration on the TC CD-ROM, and would allow you to see all the kernel boot messages (and not just the "fatal" ones).
A problem might then appear in the fact that you initally dont't seem to be able to pause the screen content scrolling out of sight. In my experience one can hit 'Ctrl-s' when the kernel messages start appearing and the scrolling will stop at some stage. One could then use 'Shift-PgUp' and 'Shift-PgDn' to browse (most of) the output and continue the processing with 'Ctrl-q'.
-
If you use the 'debug' boot code you can slow down the scrolling with boot-delay=n
where n is the number of milliseconds between printed lines.
-
++--++SOLVED++--++
Okay, the debug idea got me pointed in the right direction. Here is what I do and the responses I get.
"tinycore [any parameter other than ide-core.nodma=whateverisappropriate]" yields a timeout (of course!)
"tinycore ide-core.nodma=[whateverisappropriate]" yields a timeout
"tinycore ide-core.nodma=[whateverisappropriate] [any other parameter]" yields a proper boot for every parameter I've tested.
"tinycore [any parameter] ide-core.nodma=[whateverisappropriate]" yields a proper boot with some parameters. It fails with "xsetup" at least.
That's what I've got as of now. Now for the second part. Why? If anybody is interested, that is.
-
Glad we finally made some progress. Sounds like it might be a timing problem, Xsetup
probably gets processed after the kernel finishes probing the hardware.
-
Right but why does it need a second parameter for ide-core.nodma=0.0 to work at all?
-
Indeed sounds like a timing issue.
For more debugging you could use following boot params:
debug printk.time=y earlyprintk=vga,keep syslog
If boot is successful you could then analyze syslog with
less /var/log/messages
This may sound unorthodox if not abusive, but if I were you I might just start to experiment what happens with generously yanking waitusb= in.
-
Hi jason
Try these 2 boot codes by themselves.
ide-core.nodma=0.0:0
ide-core.nodma=0.0:1
and see what each does.
tinypoodle: There are no USB ports involved yet.
[EDIT]: Also try irqpoll by itself.
-
tinypoodle: There are no USB ports involved yet.
Hence the "unorthodox if not abusive" ;)
-
Ok, but trying that would only make sense without the nodma code since adding any
other code after nodma seems to make it work
-
The 'xsetup' boot code is specific to TC and gets picked up by '/usr/init.d/tc-config'. It just sets a flag (i.e. '/tmp/xsetup_requested') which forces the execution of '/usr/bin/xsetup.sh' when 'startx' gets executed (as part of '~/.profile'). So IMHO there is a lot of other stuff happening between the kernel boot (which seems to be when the DMA issues are happening) and the start of the X server.
Still, I'm equally perplexed about this apparent connection of the number of boot codes and 'nodma' being ignored or not.
-
@TP
That does not work. If I don't turn off dma on the CD drive, the system simply does not boot. So no syslog to work with. And by yank waitusb to you mean remove or apply. I can't tell with your writing style.
@rich
I've reinstalled all of the HDDs, so I'm now using "ide-core.nodma=2.0". So you want me to give "ide-core.nodma=2.0:0" and "ide-core.nodma=2.0:1" a shot? Along with irqpoll?
@maro
especially considering that adding "xsetup" after "ide-core.nodma" has an effect. I wonder if the command isn't even getting passed to ide-core because the system doesn't parse it without an additional parameter. But with that hypothesis, the thing that doesn't make sense to me is that it is ordering sensitive.
-
Hi jason
tinypoodle was just suggesting trying something like waitusb=2 to alter the startup
timing. Regardless, you might want to pull off a copy of the output from dmesg to
use as a hardware reference.
[EDIT] Yes, if you have a chance please try those three by themselves and note
ANY changes in behaviour.
-
What I meant was for example to add waitusb= either before or after the nodma as the only additional boot parameter.
I suspect you might have overlooked the "if" in my statement about the debugging parameters: 'If boot is successful'
-
What I meant was for example to add waitusb= either before or after the nodma as the only additional boot parameter.
I suspect you might have overlooked the "if" in my statement about the debugging parameters: 'If boot is successful'
Your antecedents are still vague and unclear. Those debug parameters, do you want them with or without "ide-core.nodma=2.0". Without "ide-core.nodma=2.0", there is not boot. Also it is still unclear as to where exactly where waitusb fits in with all of this. do you want it with the other parameters?
I guess what I'm saying is that since this is a issue that is clearly dependent upon the place and order of the boot time parameters, I need you to be more clear and definite about what you are interested in me putting in to this system. Because the output will depend on the input a great deal.
EDIT: even used verbatim after "ide-core.nodma=2.0" that bootcode does not output to /var/log/messages. I don't know why.
EDIT: tried after another reboot and got an output. Must have typoed somewhere. I'll post below.
-
Hi jason
tinypoodle was just suggesting trying something like waitusb=2 to alter the startup
timing. Regardless, you might want to pull off a copy of the output from dmesg to
use as a hardware reference.
[EDIT] Yes, if you have a chance please try those three by themselves and note
ANY changes in behaviour.
I'll pull a dmesg and also see what I can do
Edit: about the other options, I mean.
-
Boot with
1. ide-core.nodma=2.0 waitusb=1
2. waitusb=1 ide-core.nodma=2.0
without any other additional params and see what happens in either case.
If you don't get any output to /var/log/messages after booting with 'syslog', check if daemons are running:
ps |grep logd
-
waitusb=1 in conjunction with ide-core.nodma=2.0 boots fine, either way.
irqpoll in conjunction with ide-core.nodma=2.0 boots fine, either way.
ide=core.nodma=2.0:0 with or without an additional parameter does not boot.
ide=core.nodma=2.0:1 with an additional parameter boots. Without does not boot.
All of the boot failures are "waiting for dma" timeouts.
First three are dmesg outputs, last one is output of "less /var/log/messages"
Edit : sorry, the first two are duplicates. Other than that my previous statment was true.
-
From all those errors I'd guess that either the medium is faulty or the reader.
-
Which explains why it runs flawlessly?
EDIT:
I guess to be more precise and less terse, I've seen errors like this during boots on a number of systems with livcds. Do you really think that these I/O errors have to do with an actual deficiency of the drive (used a new medium, same errors). Could you explain how, if you were certain? Or point me in the direction of some documentation?
-
Which explains all the randomess, look at your own logs how "flawlessly" it runs...
-
TP, no reason to get snippy. I looked at the logs. I see the I/O errors. But, as I said, I've seen errors like that before, and those are the only real errors I see. Well, that, and the fact that the system isn't finding my second CPU. But I'm still researching that.
Feel free to point out any errors that aren't i/o errors on hde. But those errors don't seem to affect functionality.
EDIT: plugged in another known working disc drive. dmesg output looks the same.
-
Hi jason
You did not mention but I take it irqpoll by itself also did not work.
cat /proc/cpuinfo should tell you how many CPUs Linux thinks you have.
cat /proc/interrupts should let you check that wour interrupts are assigned correctly.
Dmesg mentions a acpi_pm_good boot code you can try.
-
cat /proc/interrupts should let you check that your interrupts are assigned correctly.
It's always a good idea to know what resources your devices are using in an old system like that. It is possible that there is an IRQ conflict with the third IDE channel.
-
2 observations about the logs on the side:
You appear to have multiple filesystems which are overdue for a fsck.
You could possibly skip part of all that mounting going on at boot time by using boot codes, either to point to specific partitions (*=<dev>) or to exclude scanning (no*).
-
@TP, yes it does appear that way. I had an issue last week when I made those partitions, I didn't realize that the system thought it was 1998. The partitions are clean, I just haven't bothered to fsck them. It's on the todo list. As regards the mounting, I'd rather do it with scripts than boot codes, as it is easier to back up my work, and requires fewer seconds typing at boot.
@rich, yes, irqpoll by itself does not work. cat /proc/cpuinfo shows only one 1400 mhz pentium 3. With no lapic flag. Which I gather (from other sources) is a problem, since lapic is the subsystem that governs the multiple processors? Also, cat /proc/interrupts shows that ide 0 and 1 (the ide raid controller with drives set to spare pool) is irq 10, and that ide 3 and 4 are irqs 14 and 15 respectively. Doesn't seem to be any problem there.
I'll try acpi_pm_good
EDIT:
acpi_pm_good doesn't appear to have any effect. Neither does manually invoking lapic. I was pretty sure it was already on, and that wasn't the reason, but I had to make sure.
-
Sounds like a plausible explanation then, and I guess slightly less bad than an error message that the last write to filesystem is in the future...
You might want to look at tune2fs:
http://www.netadmintools.com/html/8tune2fs.man.html
option -T time-last-checked
-
Hi jason
According to the docs I found online you can enable lapic in the bios. I think it was listed
under MPT. There should also be a setting called something like Clear CPU which tells
the system a CPU is functional. The ACPI: messages in dmseg look suspicious.
ACPI: RSDP 000f4f70 00014 (v00 COMPAQ)
ACPI: RSDT 2fffc000 00030 (v01 COMPAQ D10 00000002 Ò? 0000162E)
ACPI: FACP 2fffc040 00074 (v01 COMPAQ D10 00000002 Ò? 0000162E)
ACPI: DSDT 2fffc200 0320E (v01 COMPAQ DSDT 00000001 MSFT 0100000B)
ACPI: FACS 2fffc0c0 00040
ACPI: APIC 2fffc100 00074 (v01 COMPAQ 00000083 00000002 00000000)
ACPI: SPCR 2fffc180 00050 (v01 COMPAQ SPCRRBSU 00000001 Ò? 0000162E)
The column where it says MSFT (can I use that word in this forum?) is the creator id
which in every example I've seen is in clear text. No surprises from the cat /proc/
commands. Dmesg comes right out and says it's not multi-processor.
SMP motherboard not detected.
SMP disabled
There is a boot code to tell the kernel how many CPU you have but I doubt it will work,
I'd look it up but I have to run.
-
Alllllllrrrrriiiiiiiiiiiggggggggggghhhhhht..... :(
So I found the MPS table settings (am I blind or something)... and I turned on apic. And then X wouldn't start. So I switched it to mapped. And X wouldn't start. So I disabled it...and X wouldn't start. So I set it to auto. Looks like this is going to be annoying. I'm going to start a new thread for this, as soon as get me some decent logs.
Right now, I REALLY have to finish my Thesis. XDD
-
This is certainly not your run of the mill PC. Depending on when your G2 was built there
may be setup functions on F8, F9, and F10 keys when you boot. The F10 key relies
on the Smartstart utilities being installed on a hidden partition. Looking foward to the
new thread when you have time to start it.
-
As for the bootloader issue, sorry I wasn't more specific, but I like to keep threads on track. No HDD based bootloader I've tried has worked. Even with the boot partition in fat 32 and under 256mb. The bios doesn't even appear to see them. It just hangs with a flashing cursor followed by an "invalid system disk". Is that specific enough?
Just a thought:
Have you tried by marking the boot partition - and only that one - as active?