James Bottomley wrote on 23/09/15 08:15: > On Wed, 2015-09-23 at 07:55 +0930, Arthur Marsh wrote: >> >> Jiang Liu wrote on 22/09/15 17:00: >>> Previously the eata driver just grabs and accesses eata PCI devices >>> without implementing a PCI device driver, that causes troubles with >>> latest IRQ related >>> >>> Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and >>> pcibios_free_irq()") changes the way to allocate PCI legacy IRQ >>> for PCI devices on x86 platforms. Instead of allocating PCI legacy >>> IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq() >>> will be called by pci_device_probe() to allocate PCI legacy IRQs >>> when binding PCI drivers to PCI devices. >>> >>> But the eata driver directly accesses PCI devices without implementing >>> corresponding PCI drivers, so pcibios_alloc_irq() won't be called for >>> those PCI devices and wrong IRQ number may be used to manage the PCI >>> device. >>> >>> This patch implements a PCI device driver to manage eata PCI devices, >>> so eata driver could properly cooperate with the PCI core. It also >>> provides headroom for PCI hotplug with eata driver. >>> >>> It also represents non-PCI eata devices as platform devices, so it could >>> be managed as normal devices. >>> >>> Signed-off-by: Jiang Liu >>> Cc: Hannes Reinecke >>> Cc: Ballabio, Dario >>> Cc: Christoph Hellwig >>> --- >> >> Not really any change with this driver: >> >> previously >> >> http://www.users.on.net/~arthur.marsh/20150915547.jpg >> >> now >> >> http://www.users.on.net/~arthur.marsh/20150922553.jpg >> >> If there was any way of capturing any more debug output I'd be happy to >> do it. > > It looks to be some problem in shut down. Can you simply remove and > re-insert the driver successfully? If it's your root disk driver, > you'll have to do this from an initrd so as not to have root mounted > from the eata controller. > > If the remove and reinsert fails, it means we have a problem in the > driver shut down. If not, it's likely something kexec related. > > James OK, it looks like there was a problem with unloading the driver. After un-mounting file systems on the disk attached to the SCSI controller using the eata driver I could do a: modprobe -r eata but received the output of the attached dmesg log. Attempting to do modprobe eata after the previous modprobe -r eata resulted in a complete lock-up. Arthur.