Frans Pop wrote:
Hello Mark,
Martin forwarded your mail to me as I'm seeing the same/similar issue on
my QNAP TS-109 running arm 2.6.26-rc6 (old ABI).
On Friday 13 June 2008, Mark Lord wrote:
Mmm.. I don't know how this can happen, even if it does happen.
Unless perhaps the plaform code doesn't do a (driver).remove() call,
which is where we disable the interrupt you see above.
This *is* a "platform" (non-PCI) device, right?
With your debug patch included, I get on boot:
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0xf1012100 (irq = 4) is a 16550A
brd: module loaded
Driver 'sd' needs updating - please use bus_type methods
mv_platform_probe(c02ec910)
sata_mv sata_mv.0: version 1.24
sata_mv sata_mv.0: slots 32 ports 2
scsi0 : sata_mv
scsi1 : sata_mv
ata1: SATA max UDMA/133 irq 29
ata2: SATA max UDMA/133 irq 29
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: HDT722516DLA380, V43OA91A, max UDMA/133
ata1.00: 321672960 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
ata2: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access ATA HDT722516DLA380 V43O PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 321672960 512-byte hardware sectors (164697 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 321672960 512-byte hardware sectors (164697 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
Which has your 'mv_platform_probe(c02ec910)'
That being the case, can you stick a printk() into mv_platform_remove()
so we can see whether or not it gets called before "power down" ?
But on poweroff:
Will now halt.
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Stopping disk
Power down.
qnap_ts209_power_off: triggering power-off...
ata1: exception Emask 0�
So no sign of anything getting called here.
..
Mmm.. I suppose .remove() is not supposed to be called, then.
What does happen, is sd_shutdown() runs ("Stopping disk"),
and that's that.
Weird. I'd have thought there'd be a call somewhere to .port_stop()
or even .host_stop() on shutdown, but I don't see one anywhere.
Tejun?
Don't we try and turn off the hardware (IRQs) after stopping the drives?
Because these guys are seeing interrupts afterwards (loss of PHY, it seems),
and that looks somewhat risky -- such an interrupt might kill the shutdown sequence,
leaving a machine in limbo. Or not (?).
-ml
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
