On Thursday 25 March 2010 18:25:41 Aurelien Jarno wrote: > On Thu, Mar 25, 2010 at 12:33:33PM -0500, Rob Landley wrote: > > On Thursday 25 March 2010 04:20:26 Artyom Tarasenko wrote: > > > 2010/3/24 Rob Landley <r...@landley.net>: > > > > I have a native build under qemu that gets killed if it doesn't > > > > produce a line of output for 60 seconds (hang detection enforced by > > > > the host monitoring qemu's stdout with --nographic, not from within > > > > qemu). > > > > > > > > In the most recent release version, it never came close to triggering > > > > on mips with a 30 second timeout. In the current -git version (well, > > > > as of Thursday anyway), it triggers frequently (about 90% of the > > > > time) even with a 60 second timeout. > > > > > > Are other platforms affected as well? Do your automated tests run > > > against qemu-sparc meanwhile? > > > > That was the only platform I hit this particular regression on. It > > affects mips, mipsel, and mips64. > > > > The arm, x86, and x86-64 targets built to the end just fine. > > > > Sparc works fine from a performance perspective (the timeout doesn't > > trigger), it just dies building strace with: > > > > In file included from file.c:88:^M > > /usr/bin/../include/asm/stat.h:56: error: expected > > specifier-qualifier-list before 'uid16_t'^ > > > > Which is either an strace bug or something wrong with the kernel headers, > > either way I need too track that down and fix it. > > > > Powerpc got broken by the 2.6.32->2.6.33 kernel upgrade (the hard drives > > don't work because something broke in DMA interrupt handling, I'm > > bisecting it), so I can't comment on its performance at the moment. I'll > > get back to you on that one. > > This has been broken in r680 of openbios. I haven't found time to find > the real problem though.
According to the boot messages, it looks like it moved the IRQ of the IDE controller from 19 to 16, thus making it shared with the serial controller. This boots: ttyS0 at MMIO 0x80893020 (irq = 16) is a Z85c30 ESCC - Serial port ttyS1 at MMIO 0x80893000 (irq = 17) is a Z85c30 ESCC - Serial port ide-pmac: Found Apple Heathrow ATA controller (macio), bus ID 0, irq 19 ide0 at 0xd1010000-0xd1010070,0xd1010160 on irq 19 This does not: ttyS0 at MMIO 0x80893020 (irq = 16) is a Z85c30 ESCC - Serial port ttyS1 at MMIO 0x80893000 (irq = 17) is a Z85c30 ESCC - Serial port ide-pmac: Found Apple Heathrow ATA controller (macio), bus ID 0, irq 16 ide0 at 0xd1010000-0xd1010070,0xd1010160 on irq 16 > > As far as I can tell the sh4 linux-kernel maintainer officially doesn't > > care about anybody who isn't employed by his company, so I'm not sure I > > still care about supporting that platform. It's not real hardware, it's > > a one-company toy: > > > > http://permalink.gmane.org/gmane.linux.ports.sh.devel/7233 > > http://permalink.gmane.org/gmane.linux.ports.sh.devel/7237 > > If you continue to attack people like that, not sure I'll continue to > care about your emails. I'm not asking anyone to care about me personally, I'm asking them to care about specific technical issues. If those issues don't interest you, they don't interest you. Speaking of ppc, last month I sent this patch: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00917.html And I was under the impression people agreed with it: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01044.html http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01714.html But today's -git is still having that same issue, and the same patch still applies cleanly and fixes it for me. > Your emails on this mailing list are always > complaining, and it really starts to be annoying. I tend to email when something isn't working for me, and not email when things are working for me, yes. In this case, I was listing the platforms I have existing .configs to build system images for, and explaining why I've currently lost interest in one of them (sh4), despite still being interested in even older things like the alpha and m68k (neither of which qemu has in-tree system emulations for yet). I was unaware of attacking anyone personally. I've never met the sh4 maintainer, that I'm aware of. I disagree with his judgement call in this instance. Of course I respect his right to take any position he likes, since he _is_ maintainer, but his position removes any motivation to put more of my own time into his platform just now. (I feel similarly disinterested in itanium and pa-risc.) > Aurelien Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds
