Re: Debian/SPARC[64]
On 14/01/15 06:34, Karel Gardas wrote:
> 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.
Okay so now I am really confused. The ne2k/rt8029 networking here works
out of the box, definitely for both a NetBSD 6.1.x SPARC64 guest and my
Debian wheezy SPARC64 guest. I've also had reports of this working from
other people with and without virtio, with both NetBSD and Debian Linux
guests.
Can you clarify your host setup and the exact command-line used to
launch QEMU 2.2? Here I'm using Debian wheezy amd64 host OS with a 3.15
kernel. The command line is based upon booting from the netinst ISO
image like this:
qemu-system-sparc64 -cdrom debian-7.7.0-sparc-netinst.iso -boot d -nographic
If you continue through the installer then requesting a DHCP lease as
part of the installation works as normal. And also please double-check
that you are definitely running your new 2.2 installation and not
another version supplied with your OS.
>>> 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.
Hmmm. With the remote system I was given temporary access to, the lockup
would persist for days (or at least I could re-visit a screen session a
day or two later and it would still be frozen). So I'm not sure this is
the same problem yet.
> 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?
I agree we haven't ruled out this as a possibility, but there's
definitely something else going on here if the networking is already
broken for you.
ATB,
Mark.
Reply to: