December 28, 20169 yr This appeared to happen after upgrading from 6.1.x (something) to 6.2.4. First happened at about 3am last night, as best as I can tell. I had to hard reboot the server as it was completely unresponsive (both over the network, and physically), and then the same thing happened about half an hour later, after successfully starting the array. I tried swapping to another usb stick, where there was no difference. The server is used just as a server running a few dockers and storing data. Currently it's hung at the mounting disks part of starting the array, but I can still ssh into it. ls /mnt gives me disks 2-5 present (there should be 5), 1 isn't there. I've attached the syslog, and the result of diagnostics. There are a whole bunch of other errors in the log, not just the irq one. totoro.zip syslog.txt
December 28, 20169 yr Community Expert What's hanging the array start is disk1, you need to run xfs_repair on it: https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS For the IRQ issue, you'll need to try bios update and/or moving to other slots or removing hardware, like NICs, HBAs, etc.
December 28, 20169 yr Author Thanks. root@Totoro:~# xfs_repair -v /dev/md1 Phase 1 - find and verify superblock... - block cache size set to 687664 entries Phase 2 - using internal log - zero log... zero_log: head block 1285877 tail block 1265285 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Presumably I just wanna run with -L here? Since I can't mount.
December 28, 20169 yr Author Is this needing repairs then the likely cause of unraid's death last night? If this works and repairs, I should be able to start the array normally, right? What's next if it doesn't fix it?
December 28, 20169 yr Author And it's started, thanks. Everything seems to be as normal. Will have to see if that's solved the initial problem though, it crashing and dying, as this may well have been a result of having to power off the system.
December 28, 20169 yr Community Expert If IRQ16 keeps getting disable it can cause issues, mostly depending on what's using it.
December 28, 20169 yr Author Seems stable for now, I'll update this topic if it turns out not to be. Thanks for your help
January 2, 20179 yr Author Just had another crash, in an absolutely identical way to before. System was idle (for the most part), I came back after half an hour or so and it's completely non-responsive, had to hard reset. Logs were lost obviously, so I'm tailing syslog from another pc in the hope that I can see what's happening.
January 2, 20179 yr Author Jan 2 13:56:07 Totoro kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Jan 2 13:56:07 Totoro kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.30-unRAID #2 Jan 2 13:56:07 Totoro kernel: Hardware name: Gigabyte Technology Co., Ltd. Z97P-D3/Z97P-D3, BIOS F8 09/18/2015 Jan 2 13:56:07 Totoro kernel: 0000000000000000 ffff88021fa03e70 ffffffff8136f79f ffff880213425c00 Jan 2 13:56:07 Totoro kernel: 0000000000000000 ffff88021fa03e98 ffffffff8107f8ce ffff880213425c00 Jan 2 13:56:07 Totoro kernel: 0000000000000000 0000000000000010 ffff88021fa03ed0 ffffffff8107fb9b Jan 2 13:56:07 Totoro kernel: Call Trace: Jan 2 13:56:07 Totoro kernel: <IRQ> [<ffffffff8136f79f>] dump_stack+0x61/0x7e Jan 2 13:56:07 Totoro kernel: [<ffffffff8107f8ce>] __report_bad_irq+0x2b/0xb4 Jan 2 13:56:07 Totoro kernel: [<ffffffff8107fb9b>] note_interrupt+0x1a0/0x22e Jan 2 13:56:07 Totoro kernel: [<ffffffff8107d8d1>] handle_irq_event_percpu+0xe2/0xf0 Jan 2 13:56:07 Totoro kernel: [<ffffffff8107d915>] handle_irq_event+0x36/0x54 Jan 2 13:56:07 Totoro kernel: [<ffffffff810803c5>] handle_fasteoi_irq+0x8c/0xf4 Jan 2 13:56:07 Totoro kernel: [<ffffffff8100e0e8>] handle_irq+0x17/0x1b Jan 2 13:56:07 Totoro kernel: [<ffffffff8100db3e>] do_IRQ+0x46/0xc2 Jan 2 13:56:07 Totoro kernel: [<ffffffff8162a6c2>] common_interrupt+0x82/0x82 Jan 2 13:56:07 Totoro kernel: <EOI> [<ffffffff81508581>] ? cpuidle_enter_state+0xf0/0x148 Jan 2 13:56:07 Totoro kernel: [<ffffffff8150853a>] ? cpuidle_enter_state+0xa9/0x148 Jan 2 13:56:07 Totoro kernel: [<ffffffff815085fb>] cpuidle_enter+0x12/0x14 Jan 2 13:56:07 Totoro kernel: [<ffffffff810765ca>] call_cpuidle+0x4e/0x50 Jan 2 13:56:07 Totoro kernel: [<ffffffff81076752>] cpu_startup_entry+0x186/0x1fd Jan 2 13:56:07 Totoro kernel: [<ffffffff8161f6ed>] rest_init+0x84/0x87 Jan 2 13:56:07 Totoro kernel: [<ffffffff81900ec0>] start_kernel+0x3f7/0x404 Jan 2 13:56:07 Totoro kernel: [<ffffffff81900120>] ? early_idt_handler_array+0x120/0x120 Jan 2 13:56:07 Totoro kernel: [<ffffffff81900339>] x86_64_start_reservations+0x2a/0x2c Jan 2 13:56:07 Totoro kernel: [<ffffffff81900421>] x86_64_start_kernel+0xe6/0xf3 Message from syslogd@Totoro at Jan 2 13:56:07 ... kernel:Disabling IRQ #16 Jan 2 13:56:07 Totoro kernel: handlers: Jan 2 13:56:07 Totoro kernel: [<ffffffff814b1e61>] usb_hcd_irq Jan 2 13:56:07 Totoro kernel: Disabling IRQ #16 Still responsive, so that's probably not the issue.
Archived
This topic is now archived and is closed to further replies.