April 6, 200818 yr ...well I just built my new unRAID, based on hardware I already had (and have already "semi-tested", read below) but I stumble on problems that do not allow to even start the thing. Data: - Mobo: Asus P4C800-E Deluxe - CPU: P4 640 @ 3.2GHz (478) - RAM: 4 DIMMs x 512MB = 2GB - Stick: Corsair something, 2GB - Initial disks: 2 SATA disks mounted on on-board Promise, one 750 and one 500 Problem: System boots ok from Corsair (and much faster than I remember, for some reason) BUT system doesn't seem to detect my LAN at all. Pinging anywhere outside the box, tells me "network unreachable". More data: - Tried both with b6 and latest stable (different reaction, read below) - Tried with DHCP and with editing network.cfg for static IP - Tried with different LAN cable (even one taken from one of my computers that actually DOES work on that LAN) - Tried different Switch ports - Tried different Switch (because before setting up unRAID this is the Switch I used to use)... this had interesting results (bad again) depending on unRAID version - System is CMOS cleared and BIOS reset to the best possible settings (for this setup) Even more data (that makes this really weird): - Before really setting up unRAID, I HAVE tried unRAID on this same machine and it worked (also worked fine as a Windows machine), only differences with that day are that now LESS cards are on-board (not needed), different case used (duh unrelated) and of course different disks installed (but haven't reached the point of actually using them). I probably tried the same latest stable and some older 4.3 beta (something I cannot do now as I don't have any older beta). - Now that I have this problem, I tested both with b6 and latest stable as I mention above. DIFFERENT things happen depending on version. I was only able to see the differences with my old Gigabit Switch (NetGear 5 port, my new one is a 3COM 8 port). With b6 (newer kernel and NIC driver possibly), I see the LAN port on the switch switching off at some point (sometime when DHCP is queried). With latest stable, port doesn't seem to switch off, but seems to "start and reset" continously (but first seems to pass some traffic and then a collision is detected - all those from the Switch LEDs not from any unRAID feedback). ...weird. So the least I need now, is a way to copy whatever log contents to my boot USB stick (as it is my only connection to the world) so that I can post it here. Thank you in advance.
April 6, 200818 yr Do you have the LAN controller disabled in the BIOS? Both of your syslogs say the same thing: Apr 6 12:05:21 Tower dhcpcd[1381]: broadcasting DHCP_DISCOVER Apr 6 12:05:31 Tower dhcpcd[1381]: timed out waiting for a valid DHCP server response Apr 6 12:05:31 Tower ifplugd(eth0)[1474]: ifplugd 0.28 initializing. Apr 6 12:05:31 Tower ifplugd(eth0)[1474]: Using interface eth0/00:0E:A6:2E:8C:94 with driver <e1000> (version: 7.6.15.4-NAPI) Apr 6 12:05:31 Tower ifplugd(eth0)[1474]: Using detection mode: SIOCETHTOOL Apr 6 12:05:31 Tower ifplugd(eth0)[1474]: Initialization complete, link beat not detected. If your LAN controller is not toasted (read defective), and is enabled in the BIOS, I would try yet another LAN cable. (I know you said you used one from another machine, but the "link beat not detected" is troubling. Joe L.
April 6, 200818 yr Apr 6 12:05:27 Tower kernel: [ 74.211256] irq 11: nobody cared (try booting with the "irqpoll" option) Apr 6 12:05:27 Tower kernel: [ 74.211329] [<c012d568>] __report_bad_irq+0x36/0x75 Apr 6 12:05:27 Tower kernel: [ 74.211436] [<c012d637>] note_interrupt+0x74/0xa7 Apr 6 12:05:27 Tower kernel: [ 74.211540] [<c012dada>] handle_level_irq+0x70/0x91 Apr 6 12:05:27 Tower kernel: [ 74.211642] [<c01051cb>] do_IRQ+0x4e/0x65 Apr 6 12:05:27 Tower kernel: [ 74.211746] [<c0103c0b>] common_interrupt+0x23/0x28 Apr 6 12:05:27 Tower kernel: [ 74.211848] [<c0120000>] param_set_ulong+0x15/0x32 Apr 6 12:05:27 Tower kernel: [ 74.211955] [<c01174c7>] __do_softirq+0x2c/0x73 Apr 6 12:05:27 Tower kernel: [ 74.212058] [<c0117530>] do_softirq+0x22/0x26 Apr 6 12:05:27 Tower kernel: [ 74.212160] [<c01051d0>] do_IRQ+0x53/0x65 Apr 6 12:05:27 Tower kernel: [ 74.212262] [<c0265fe8>] pci_write+0x2a/0x2f Apr 6 12:05:27 Tower kernel: [ 74.212368] [<c0103c0b>] common_interrupt+0x23/0x28 Apr 6 12:05:27 Tower kernel: [ 74.212472] [<c012d2dd>] setup_irq+0x12f/0x15c Apr 6 12:05:27 Tower kernel: [ 74.212575] [<c02419ed>] usb_hcd_irq+0x0/0x4c Apr 6 12:05:27 Tower kernel: [ 74.212681] [<c012d447>] request_irq+0x7b/0x94 Apr 6 12:05:27 Tower kernel: [ 74.212784] [<c0241cab>] usb_add_hcd+0x150/0x30a Apr 6 12:05:27 Tower kernel: [ 74.212887] [<c0249592>] usb_hcd_pci_probe+0x1f6/0x280 Apr 6 12:05:27 Tower kernel: [ 74.212991] [<c01752d9>] sysfs_add_link+0x7d/0xa6 Apr 6 12:05:27 Tower kernel: [ 74.213099] [<c0220fb5>] __driver_attach+0x0/0x75 Apr 6 12:05:27 Tower kernel: [ 74.213204] [<c01c6817>] pci_call_probe+0xa/0xc Apr 6 12:05:27 Tower kernel: [ 74.213308] [<c01c6847>] __pci_device_probe+0x2e/0x3f Apr 6 12:05:27 Tower kernel: [ 74.213415] [<c01c6876>] pci_device_probe+0x1e/0x30 Apr 6 12:05:27 Tower kernel: [ 74.213517] [<c0220e69>] really_probe+0x95/0x11f Apr 6 12:05:27 Tower kernel: [ 74.213621] [<c0220f39>] driver_probe_device+0x37/0x3f Apr 6 12:05:27 Tower kernel: [ 74.213726] [<c0220ff9>] __driver_attach+0x44/0x75 Apr 6 12:05:27 Tower kernel: [ 74.213831] [<c02203ba>] bus_for_each_dev+0x35/0x59 Apr 6 12:05:27 Tower kernel: [ 74.213935] [<c022103e>] driver_attach+0x14/0x16 Apr 6 12:05:27 Tower kernel: [ 74.214039] [<c0220fb5>] __driver_attach+0x0/0x75 Apr 6 12:05:27 Tower kernel: [ 74.214142] [<c02208fe>] bus_add_driver+0x6d/0xf3 Apr 6 12:05:27 Tower kernel: [ 74.214244] [<c01c6a75>] __pci_register_driver+0x41/0x64 Apr 6 12:05:27 Tower kernel: [ 74.214347] [<c037708d>] uhci_hcd_init+0x7d/0xac Apr 6 12:05:27 Tower kernel: [ 74.214451] [<c0364a18>] kernel_init+0x0/0x8a Apr 6 12:05:27 Tower kernel: [ 74.214556] [<c03648cc>] do_initcalls+0x73/0x1a1 Apr 6 12:05:27 Tower kernel: [ 74.214659] [<c016f18a>] get_inode_number+0x26/0x43 Apr 6 12:05:27 Tower kernel: [ 74.214764] [<c016f3db>] proc_register+0xb/0x8f Apr 6 12:05:27 Tower kernel: [ 74.214867] [<c016f663>] proc_mkdir_mode+0x3e/0x51 Apr 6 12:05:27 Tower kernel: [ 74.214972] [<c012e13f>] register_irq_proc+0x61/0x6b Apr 6 12:05:27 Tower kernel: [ 74.215076] [<c016f663>] proc_mkdir_mode+0x3e/0x51 Apr 6 12:05:27 Tower kernel: [ 74.215179] [<c0364a18>] kernel_init+0x0/0x8a Apr 6 12:05:27 Tower kernel: [ 74.215283] [<c0364a5f>] kernel_init+0x47/0x8a Apr 6 12:05:27 Tower kernel: [ 74.215386] [<c0103cfb>] kernel_thread_helper+0x7/0x10 Apr 6 12:05:27 Tower kernel: [ 74.215489] ======================= Apr 6 12:05:27 Tower kernel: [ 74.215559] handlers: Apr 6 12:05:27 Tower kernel: [ 74.215628] [<c02419ed>] (usb_hcd_irq+0x0/0x4c) Apr 6 12:05:27 Tower kernel: [ 74.215762] Disabling IRQ #11 Apr 6 12:05:27 Tower kernel: [ 74.215851] uhci_hcd 0000:00:1d.2: irq 11, io base 0x0000ef20 Apr 6 12:05:27 Tower kernel: [ 74.216002] usb 1-1: new high speed USB device using ehci_hcd and address 2 Apr 6 12:05:27 Tower kernel: [ 74.216147] usb usb4: configuration #1 chosen from 1 choice I had something similiar on my MSI board, although it happened on my ethernet port. I think I used NOIRQPOLL and/or NOAPIC or something like that. Perhaps it is how the IRQ's are being allocated I would try those options in the syslinkx.cfg file and/or disabling some internal hardware on the board to see what happens. However, I would first check the ethernet cable.
April 6, 200818 yr Author The on-board NIC was working until yesterday (when I dismantled and re-installed the hardware). I don't know if I killed it somehow. I think I will also try some live CD to see what happens. I tried 4 different cables. The NIC is enabled in BIOS (I will try to disable/save/enable/save it too). I removed all my cards (so there is nothing to remove), except this detail: I now use a PCI VGA card (removed the power hungry AGP that was installed). Maybe I will move the card to another slot. Will get back with more data. Weebotech: NOIRQPOLL, NOAPIC = ?
April 6, 200818 yr Author OK, news... It ain't hardware. I have my original hard disk (that used to run on this mobo) and booted it. It managed to boot, regardless of all the hardware I have removed. The NIC works, locks at 1Gbit fine and in fact I WRITE FROM THIS MACHINE right now! So nothing to change in BIOS, switch, cable areas. It is definitely something with software. Weird since this mobo uses a pretty standard NIC *AND* I have already used it (last week) to test uNRAID and worked fine... REALLY weird. PS. Unrelated: The VGA card is still AGP... how did it come to me that it was PCI I dunno (maybe because I tried 4 different VGA cards from my closet). Heeeeeeeeeeeeelp!?
April 6, 200818 yr Author ...ah, the only thing new on the stick, from last week's test is Pro.key... does it make ANY sense to try without this?
April 6, 200818 yr Author ...even newer news! IT WORKED! I copied everything back to the stick and it worked! What could possibly mess this up?
April 6, 200818 yr I would try to disable any unused controllers on the motherboard. Here is my syslinux.cfg (I'im not saying it will totally work for you, but it worked for me) Notice the unRAID modified block. Try one option at a time. first irqpoll then pci=routeirq then both. I'm grasping for straws here. default menu.c32 menu title Lime Technology LLC prompt 0 timeout 50 label unRAID OS Modified menu default kernel bzimage append initrd=bzroot irqpoll pci=routeirq rootdelay=10 label unRAID OS kernel bzimage append initrd=bzroot rootdelay=10 label Memtest86+ kernel memtest
April 6, 200818 yr Author thanks for the help man turns out it was something simpler (but dunno what)
April 6, 200818 yr What could possibly mess this up? The stick going bad.. Bad spot on the disk. I would reboot a few times to see. I would also run the memtest to make sure there isn't something odd in ram. Did you put it in a different usb port perhaps. I've had issues where one USB port caused a conflict and another didn't.
April 6, 200818 yr Author Well the problem is still here. :( I tried again both with clean b6 and stable. The first saw "no carrier" (!), while the second did see the line but never got a DHCP address. I will try all my USB ports. The stick is brand new. This RAM worked for years with Win 2003 Server on same machine (utilized all of it, no problems). I suspect that it worked just after I rebooted after windows, means something (i.e. somehow Windows "woke up" NIC and then worked for unRAID). Is there any base in that? I cannot verify this tonight (very late in Greece right now). Will get back tomorrow. In the meantime keep posting ideas...
April 6, 200818 yr Try adding nolapic noapic to the syslinux.cfg file ... something like this: label unRAID OS menu default kernel bzimage append initrd=bzroot rootdelay=10 nolapic noapic It has helped others, perhaps you too.. Joe L.
April 6, 200818 yr Author OK I have some more news... I tried booting the disk again, rebooting to the stick (had 4.3b6, decided not to touch it so that the stick is not written at all)... no go... "no carrier" (I suspect b6 has a problem with my NIC anyway). Anyway, run MC, renamed the stable bzroot and bzimage, exited MC and run "shutdown -r 0" ...in time to see that my "NIC is up, 1000MBps, full duplex"!!! (this was probably coming from b6 still!) Unsurprisingly, after the restart (now in stable 4.2.4), I DID get DHCP address! Pinged fine and I see http://tower right now. So my suspisions: - b6 NIC driver is messed up AND/OR - NIC takes time to wake up AND/OR - something else random takes place my next experiment before going to sleep will be: - reboot this as it is now and see if it still works - power down and boot it again
April 6, 200818 yr Author tested: - reboot (without shutting down) and still NIC works edit... - power down, count 10", boot again... NIC still works (!?!?) ...this is getting weird. Definitely cannot describe this as "stable operation" (with 4.2.4) and definitely never seen the system work with b6 (so Tom we see a potential problem coming up with 4.3 here!)... I'll shut it down and see how it goes in a few hours. If it is just a "slow to wake NIC" issue, some timer could fix this.
April 6, 200818 yr Author ...oh come on! I even changed to static (through the web interface), system still worked with the new static IP and new host name. Then I rebooted to again NOT have a live NIC (cannot ping to or from it)... Help?
April 7, 200818 yr Any NIC that misbehaved that much on my computer gets fired! Try another... It's not worth the bother. If you do try another, don't forget to disable the onboard NIC in the BIOS. Your syslogs show troubling IRQ problems. You may actually have a flaky motherboard, although it is too early to decide that yet. Both kernels had essentially the same problems, although a different IRQ was involved. On the 4.3 beta version, IRQ 19 is disabled, although it is used with some of the USB support, then is involved with your network driver e1000, then is also used by the ICH5 IDE controller, which you aren't using. On the 4.2 version, it is IRQ 11 that is involved, with the very same drivers. The syslog suggests adding the irqpoll parameter, and that is probably a good idea. Parameters like this can be considered (as a generalization) as workarounds for faulty motherboard implementations. Just find the append line in your syslinux.cfg file on the flash drive, and add a space and the word irqpoll, and reboot. Can't hurt, might help... The others above have given similar advice to try.
April 7, 200818 yr As I mentioned earlier, disable anything and everything that is not used. Any serial, parallel, sound and/or controllers that are not being used. I did have to use the parms I posted earlier to get my MSI board and the e1000 driver to play nice.
April 7, 200818 yr Author RobJ the thing is that EVERY time I boot windows with this machine, NIC works. Not some times, every time. This problem only happens when booting unRAID. I'll try the parameters mentioned. WeeboTech, I have already disabled what you mention from the start. I'll get back to you with feedback in a couple of hours.
April 7, 200818 yr Author OK back to you guys. Just tested. First I tried irqpoll parameter with 4.2.4. WORKED! Thinking it might be what happens from time to time that makes it work, I went for the hard test right away. Booted with b6... WORKED!!! (first time ever) Sorry WeeboTech didn't get to try your parameters. So what did I do with irqpoll (I mean some more details than what I deduct from the parameter name)? What do the other two parameters do? Thank you guys both for the support (hello Tom?)... Hope it still works tomorrow.
April 8, 200818 yr IRQPOLL was a parameter I suggested, only I mistakenly put NO infront of it. Whoops. I know I had to use it for the MSI board. However, I think you may want to try another parameter first just in case. This is the chunk I read concerning IRQPOLL. "if noapic works go with that. irqpoll makes the kernel ask every interrupt handler if they want to handle the interrupt in question whenever one fires." From what I read, IRQPOLL wastes CPU cycles. So give it a shot with NOAPIC and see what happens. At the very least, you can become the poster child for others with the same mobo. Smile Big
Archived
This topic is now archived and is closed to further replies.