Re: Debian/SPARC[64]
On 01/13/15 10:24 AM, Mark Cave-Ayland wrote:
On 12/01/15 15:12, Karel Gardas wrote:
Hi Mark,
it's great that you mention this. Indeed, for Solaris 11 I'm using
T2000, for sparc/sparc64-linux (Debian 7.x) I've decided to give a try
to Qemu 2.2 SPARC64 emulation. First time I've not been lucky with
network (ne2k-pci not working) but later after some googling I've found
that virtio is working.
Hmmm I've previously run through the entire Debian installer using the
in-built QEMU userspace network stack and have successfully managed to
detect an rtl8029 network card and get a valid DHCP lease? What appears
to be the problem?
The network was not working at all. For debian I've solved that by using
virtio. For OpenBSD 5.6 I've solved that by using i82551.
Now, when I've run some GHC/cabal tasks I indeed observed some lockups
but I've thought his is Qemu issue and not kernel issue that time.
Anyway, it looks like Linux is really not well supported on SPARC
anymore. Where are those times when Jakub Jelinek done his first
UltraLinux in 90s.... Anyway, if I observe anything suspicious I'll let
you know.
Please do. Given that you seem to be able to reproduce this, the most
interesting part would be to try an older kernel (2.6.32 as mentioned
elsewhere in this thread) and/or try building a kernel without
performance counters in order to determine whether this really is the
cause of the lockup even under emulation.
Hmm, I've been maybe mistaken. What I see now is a long (minute or few
minutes?) hang which is then "resolved" by printing debug message to the
console claiming ata lost interupt:
[ 1833.686598] ata1: lost interrupt (Status 0x50)
[ 1833.697721] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[ 1833.698559] ata1.00: failed command: WRITE DMA
[ 1833.699180] ata1.00: cmd ca/00:08:84:28:07/00:00:00:00:00/e0 tag 0
dma 4096 out
[ 1833.699196] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask
0x4 (timeout)
[ 1833.700706] ata1.00: status: { DRDY }
[ 1833.703433] ata1: soft resetting link
[ 1833.873829] ata1.00: configured for UDMA/33
[ 1833.875106] ata1.00: device reported invalid CHS sector 0
[ 1833.877169] ata1: EH complete
then everything works again. If I get hard lock up I'll let you know.
Also this symptom of losing interrupts may be also presented on openbsd,
while using i82551 I've seen quite some messages about fxp01: time out.
-- perhaps Qemu does have problem in SPARC64 with delivering interrupts?
Karel
Reply to: