On Wed, May 22, 2013 at 11:35 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, May 22, 2013 at 01:12:15PM +0200, Paolo Bonzini wrote:
Il 22/05/2013 13:09, Michael S. Tsirkin ha scritto:
Usually I do the same---I just do slightly more thorough testing for
configure patches.
I've no
On Fri, May 24, 2013 at 7:24 PM, Lior Vernia liorv...@gmail.com wrote:
Hello,
I am running x86 applications on an ARM device using QEMU, and found
it too slow for my needs. This is to be expected, of course, this is
not a complaint. However, I was wondering whether this could be helped
by
I get this on i386 chroot for make check:
GTESTER tests/test-qmp-output-visitor
**
ERROR:/src/qemu/tests/test-qmp-output-visitor.c:595:check_native_list:
assertion failed: (tmp)
GTester: last random seed: R02S559792e7c8d0762d9a2ee153fba8896c
**
On Thu, May 23, 2013 at 11:59 AM, Peter Maydell
peter.mayd...@linaro.org wrote:
This patch series is preparatory cleanup for the impending
AArch64 support.
Thanks, applied 1 to 9.
Patch 1 replaces all the uses of TCGv, tcg_temp_new(), etc in the
current 32 bit ARM decoder with the
On Fri, May 24, 2013 at 11:01 PM, Brad Smith b...@comstyle.com wrote:
Remove the OSS support for OpenBSD. The OSS API has not been usable
for quite some time.
Signed-off-by: Brad Smith b...@comstyle.com
Thanks, applied.
diff --git a/audio/ossaudio.c b/audio/ossaudio.c
index
On Sun, May 26, 2013 at 1:40 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote:
On 26 May 2013 13:31, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote:
I definitely think
On Sun, May 26, 2013 at 6:24 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, May 26, 2013 at 06:20:17PM +, Blue Swirl wrote:
On Sun, May 26, 2013 at 1:40 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote:
On 26 May 2013 13
On Sun, May 26, 2013 at 8:15 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, May 26, 2013 at 07:28:40PM +, Blue Swirl wrote:
On Sun, May 26, 2013 at 6:24 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, May 26, 2013 at 06:20:17PM +, Blue Swirl wrote:
On Sun, May 26, 2013
On Thu, May 30, 2013 at 9:03 PM, Paolo Bonzini pbonz...@redhat.com wrote:
This provides the basics for detecting accesses to unassigned memory
as soon as they happen, and also for a simple implementation of
address_space_access_valid.
Reviewed-by: Richard Henderson r...@twiddle.net
On Sat, Jun 1, 2013 at 11:41 AM, Mark Cave-Ayland
mark.cave-ayl...@ilande.co.uk wrote:
Commit d08151bf (conversion of tcx to the memory API) broke the 24-bit mode of
the tcx display adapter by accidentally passing in the final address of the
dirty region to memory_region_reset_dirty() instead
Thanks, applied.
On Sun, Jun 2, 2013 at 4:23 PM, Mark Cave-Ayland
mark.cave-ayl...@ilande.co.uk wrote:
Commit d08151bf (conversion of tcx to the memory API) broke the 24-bit mode of
the tcx display adapter by accidentally passing in the final address of the
dirty region to
On Fri, Sep 20, 2013 at 12:24 AM, Richard Henderson r...@twiddle.net wrote:
This is an attempt to improve performance of target-sparc
by exposing the windowed registers as TCG globals, and all
the optimization that we can do there.
This is done via allowing tcg_global_mem_new to be used
On Fri, Aug 9, 2013 at 7:19 PM, Richard Henderson r...@twiddle.net wrote:
We have one host platform (aarch64), and three target platforms
(openrisc, unicore32, xtensa) with no built-in disassembly support,
thanks largely to gplv3 silliness.
Here's a first-cut at handling these cases with an
: Blue Swirl blauwir...@gmail.com
Cc: Aurélien Jarno aurel...@aurel32.net
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: malc av1...@comtv.ru
Cc: Hu Tao hu...@cn.fujitsu.com
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Peter C. Crosthwaite peter.crosthwa...@xilinx.com
Andreas Färber (12):
gus
On Tue, May 28, 2013 at 8:19 AM, li guang lig.f...@cn.fujitsu.com wrote:
remove macros EAX, EBX, ECX, EDX, EBP, ESP, ESI, EDI, EIP, DF
as suggested by Richard Henderson r...@twiddle.net
Thanks, applied all.
v4: fix alignment issue in patch 6.
Li Guang (12)
target-i386/helper:
On Sun, Jun 16, 2013 at 3:57 PM, Andreas Färber afaer...@suse.de wrote:
Move it to qom/cpu.h.
While renaming, perhaps a more descriptive name could be used instead
of 'cpu_single_cpu', something like cpu_loop_current_cpu?
Signed-off-by: Andreas Färber afaer...@suse.de
---
cpu-exec.c
Hi,
You are probably using 2.4 or older target kernel? They don't work yet, for
example prom tree reading often goes to infinite loop. Please try 2.6
series, 2.6.11+tcx kernel in the Qemu downloads section should work.
_
Express
Hi,
The architecture used in sparc target (sun4m) supports SMP up to a maximum
of 16 CPUs. At hardware emulation level (hw/*, target-sparc/*), it would be
easy to add the missing interprocessor interrupts, per-CPU counters and
atomic instructions. It would also be simple to add the prom
SMP est definitely possible in QEMU - a few days of work are necessary to
add the missing generic support and an x86 implementation... but currently
I prefer to work an other topics.
Just for your information, some choices need to be made:
1) Do the CPUs share the same translation cache ?
This
I guess you'd really want to simulate multiple CPUs with multiple host
threads. One of the additional problems could then be memory/cache
coherency.
I'm not sure how much of a problem this would be in practice. If both host
and guest require the same (or no) explicit SMP memory barriert it's not
Hi,
Funny, here's a third version of the 64-bit support (among other
Sparc-related things). With it, Sparc64 system emulator can execute code in
high memory (4G) and loads/stores also work.
Fabrice, could you merge the best of all three?
well, just to let you know ... I'm interested in the emulator
(is there some howto available, regarding openprom and such?)
http://www.openfirmware.org/
I've learned most things by reading the sources (Proll, Linux
arch/sparc/prom, silo). Luckily, the code base is not large.
A nice way of
Hi,
That (confusing) message wasn't updated after CD/HDD boot was added. It just
shows the pre-loaded kernel size, 0K is OK for CD/HDD boot.
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
obp_devopen(sd(0,2,0))
obp_devseek: fd 2, hi 0, lo 8192
obp_devread: fd 2, nbytes 8192
Thanks for the report.
Here's a translation: Boot sector bootblk gets loaded. It reads 8k from
disk sd(0,2,0) (without partition code, mmh) at offset 8k. The contents is
not what is expected, so it prints
Hi,
Here's a new version of Proll. Now that I've fixed a bug with ESP, Proll
can boot from the following CDs:
Aurora 1.0
Debian 3.0r2
Debian 3.0r4
Debian-3.1r0 mini
Debian sarge mini
NetBSD_1.6
NetBSD_1.6.1
Debian sarge businesscard
Suse 7.3
Red Hat 4.0 'Zoot'
Kernels hang/crash very soon.
why isn't it possible to use some Sun-provided flash PROM-Update binary for
SS5 or so?
Now that would be interesting. Running it could reveal some bugs in Qemu's
HW implementation and especially where we have made some bogus shortcuts.
For example, the boot sequence is not what a real Prom
sparc-elf-ld: section .rodata [ffd08000 - ffd0a129]
overlaps section .text [ffd0 - ffd08077]
This means that the space reserved for code is full. You can adjust it like
this:
diff -ru proll-patch-16/qemu/Makefile proll-patch-16b/qemu/Makefile
---
Hi,
Sparc32 graphics cards are just frame buffers without a text mode. Sparc64
uses PCI cards, including VGA, so any text mode enhancements could be useful
there.
If you have a VGA test program, I could try to port it to Sparc64.
I only have no way to see whether everything works because I didn't
even find a working BIOS image for Sparc 64, but it should be fine.
Do the video adapters used in Sparc 32 machines really have nothing
like a text mode?
No, they are just frame buffers converting pixel data to RGB. For
Hi,
This version adds SMP support to Proll for Qemu. It's probably not very
useful for real hardware, probing for CPUs is not realistic.
Using latest Qemu from CVS and for example vmlinuz-2.2.17-14smp from Red
Hat, 4-way SMP shows some promise:
POSIX conformance testing by UNIFIX
Entering
Why not just use Oprofile (oprofile.sf.net) or standard readprofile
tool for this?
I didn't know about that, but after a quick look I'd say Oprofile is doing
performance profiling (which could be done using Qemu as well), not test
coverage analysis. Also, the kernel in question needs to be
Sorry, I am not familiar with qemu internals enough to understand that. It
currently fails the build in the sanity check implemented in dyngen.c. We
figured out so far that there might be two valid cases:
save;...ret;restore;
and ;retl;nop;. Are you saying that the function ending in
I'm trying to get the sparc system emulator going... I'm booting it
Good, new developers are most welcome!
After experimenting with some writes using dd, I noticed that blocks
were only getting to the disk image after a 1 write delay. With some
observation of the ESP debug trace, I
figured
Looks like there is no cpu_get_real_ticks() function implementation for
sparc. There is an old message on qemu-devel discussing this issue [0].
It looks like this function is fairly easy to implement by reading the
%tick register in machines compliant with SPARC v9 architecture (Ultra1
or
Hi,
This patch fixes the write logic. Now woody can write partition tables, make
swap and create a file system. Setup fails at kernel installation for some
reason.
I found another bug that the simple transfer buffer was too small for the
largest reads and writes. The fix is ugly, better
To find this problem, I enabled debugging in the esp.c file and printed
the
mapped address (after iommu mapping). In some cases the mapped address
is
zero:
ESP: DMA address 0beb8000
ESP: DMA address
I didn't find a manual of the SBUS IOMMU. But if I understand the contents
of
Thank you for the excellent analysis of the problem! Looks like Qemu doesn't
handle the case where DMA length and SCSI length are not equal.
Until here, the addresses are subsequent. Then the next address is much
lower:
So Linux splits the transfer into two parts to use two separate pieces
I send a patch that should fix a bug in the update of carry flag for addxcc
and subxcc instructions when the carry flag is set before the evaluation of
the instruction.
(the fix is identical to what is done in the similar instruction
op_adcl_T0_T1_cc for arm target)
Looks good, but what about V
Doesn't this condition in addx and the corresponding line in subx need
similar
treatment?
They don't change the flags.
_
FREE pop-up blocking with the new MSN Toolbar - get it now!
The attached patch is an updated version of my previous patch. Now it
applies
cleanly to cvs head and the read and write performance is increased.
Great work! Now the Debian 3.0r4 installer with 2.6.11+tcx kernel almost
finishes. Performance is also much better.
There is some problem with
Then I tried to track down this problem with gdb and strace. But
unfortunately, both are segfaulting, too. This makes debugging somewhat
harder... Now, I'll try to analyze the core files of the crashing programs
to
get an idea what's going wrong. Or do you have any idea? What's the
difference
swapper(1): Oops [#1]
Which initrd did you use?
It's the file
/dists/stable/main/disks-sparc/current/images-1.44/root.bin
as specified by /boot/silo.conf, from debian-30r4-sparc-binary-1.iso.
_
Express yourself instantly with MSN
I've checked and changed a lot of code inside the kernel and in qemu and
added
debbugging output. The crash is more or less reproducible and the program
crashes after 2-3 FPU disabled traps somewhere inside the libc init
routines.
The FPU instructions cannot be the problem, because I disabled
I should test NeXTStep/Sparc (sun4m required).
Is OpenBIOS made to work also on PowerPC?
OHW currently has so bugs that doesnt boot anything.
There is some support in OpenBIOS for PPC machines named briq, mol and
pearpc, but I don't know if they are related to Qemu machine types.
Could you elaborate a bit more please? I've no idea what you mean by
partial
transfers.
Actually the problem was that Qemu block devices use fixed sector size 512,
not variable 2048/512 like scsi layer. This meant that the bdrv_read
transferred too little data. Fix attached.
For some reason, bash and strace didn't work inside Sparc32 system emulator.
I finally found the reason by observing strange Linux behaviour relating to
MMU no-fault mode. No fault mode seems to apply only to supervisor accesses,
not user ones. The logic was not described like this in the
emulator. I finally found the reason by observing strange Linux
behaviour
relating to MMU no-fault mode. No fault mode seems to apply only to
supervisor accesses, not user ones. The logic was not described like
this
in the manual, thank you very much.
How did you find it?
I looked at
I added some new SCSI commands, which are used by Linux.
I found the reason for boot problems, where disk size was zero. Linux ESP
driver uses (very rarely) the ESP command Set ATN and Stop, which is in fact
not similar to Set ATN command. The way of sending the command seems to be
very
I got the ESP Set ATN Stop command working. Linux uses it only for probing
disk sizes, but of course if that fails, the zero sized disks will not be
very useful. Now all distro installers I tried detected the disks correctly.
Some distros didn't detect ESP or Lance automatically when using
Hmm, this sounds like a partially a Linux bug. The qemu devices only report
SCSI-3 rev 1, which doesn't define some of these commands.
If I remember correctly, Linux uses the commands even if the device claims
conformance to SCSI-1 (like it was before the SCSI reorg).
However implementing
Hardware clock in Sparc32 is based on the year 1968, not from the start of
century. Currently hwclock reads year 2006 as year 1974, fix attached.
I included also the MMU fix required for correct no-fault mode handling for
userland faults, please apply.
I installed Debian 3.1r1 from scratch
Did you apply the attached FPU patch I posted one week ago as well? With
this
patch and your patches all programs I tested did not segfault any longer.
I forgot it, indeed the segfaulting has gone.
_
Express yourself instantly
I'd like to replace Proll with OpenBIOS as the Qemu/Sparc32 boot prom and
then develop a Sparc64 port that would finally make the Sparc64 system
emulator usable.
OpenBIOS/Sparc32 has reached or exceeded the level of functionality that
Proll provides:
* boot from HDD and CD (several Linux
Sounds like a good idea to me, and the sooner the better.
Even if we find some things that work with proll but not openbios I guess
there's a good chance of getting openbios fixed.
So I'll send you a patch that changes the name 'proll.elf' to
'openbios-builtin.elf' (or maybe it's better to use
Is there any functionality, existing or planned or patched, to save Sparc
NVRAM contents between QEMU sessions and reload it when QEMU starts up ?
Currently nvram is used to pass some information from Qemu to BIOS. Some
other mechanism would need to be implemented instead, if nvram contents
So I'll send you a patch that changes the name 'proll.elf' to
'openbios-builtin.elf' (or maybe it's better to use something like
'openbios-sparc32', simplifies the code) and a sample OpenBIOS file and
that's it?
Yes. Plus documentation bits.
Bonus points if you include a README describing
Hi,
I finally learnt how to use Quilt to manage patches. The previous patch is
now in several parts, which should be easier to handle.
The order of applying should be:
gdb-sparc64.diff
sparc64-insn-fixes.diff
sun4u-fixes.diff
_
1) Include the bit 'psref' in the static translation state (in tb-flags).
Then psref can be tested at translation time and there is no run time cost.
This approach is used on the x86 target. The downside is that two TBs may
be generated for a given block of code depending on the psref value.
Change all uses of float/double and related functions in Sparc32/64 to
soft float replacements.
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
This patch makes sparc32 user emulator work again.
Programs using vfork still don't work. I'm not sure if the vfork case can be
made to work correctly with qemu blindly using vfork. Can Qemu obey the
vfork use rules (no system calls except exec family or _exit etc.)?
I found out why cc1 and also GDB had a segfault after I fixed the user
emulator. Branch distances over 1MB were not calculated correctly, shift
operation was done before sign extension. That made the 1MB branches
negative, and probably corrupted 2MB branches.
Now I can compile some programs
Last time I missed a lot of the functions, this version should be complete.
I see no difference in operation with or without the patch. Comments?
Description:
Change all uses of float/double and related functions in Sparc32/64 to
soft float replacements.
Other than it didn't apply against the current CVS? Was there a
requirement
for a previous patch you posted which hasn't been applied to CVS?
Fabrice applied it yesterday.
_
Express yourself instantly with MSN Messenger!
Fix the BPr instruction branch target calculation.
Index: qemu/target-sparc/translate.c
===
--- qemu.orig/target-sparc/translate.c 2006-06-22 14:50:51.0 +
+++ qemu/target-sparc/translate.c 2006-06-22
I got the i386-user to build by moving the troublesome SSE ops to helper
(only for Sparc32/64, no effect at least to x86 host). The emulator crashes
when executing the first TB, code generation and register use could be
suspected. The patch makes ops_sse.h more confusing to read. Any comments?
I converted PPC to use soft float instead of native FPU. I don't have much
PPC software available, but at least some qemu-tests files work on an x86
host.
As I also fixed the bug with system emulators not passing final link (in
sparc64.ld), now all default user and softmmu targets can be
Requiring that ops don't use a stack frame doesn't seem like a realistic
constraint.
It can be done, see my latest patch. Of course there's no point doing it if
there is no real need.
The remaining target specific problem with PPC FPU ops could be solved
by
changing PPC to soft float.
I made a simpler version of the Sparc64 patch which doesn't attempt to avoid
the stack use. All targets build on Sparc64 host. I copied the relevant
parts of the fixes to Sparc32 also.
The PPC patch is also updated, but I have no interest in maintaining this
patch in the future.
I got a statically linked trivial program (hello, world) execute on a x86
host. More complex programs expose bugs in the Sparc64 emulation, even the
dynamic linker uses currently unimplemented VIS instructions.
_
Express yourself
Hi,
I updated the patches for Sparc64 host support, Sparc64 user emulator fixes,
and Sparc64 CPU emulation fixes.
I'd be happy to fix any problems you might see.
_
Express yourself instantly with MSN Messenger! Download today
IN:
0x40002bac: rd %psr, %l3
##
This last instruction seems to be completely legal, so I don't really
know what's happening...
User mode emulator does not allow supervisor mode instructions at all. Try
the system emulator
I ran into this myself yesterday. I couldn't figure out a definitive
answer, because I am no expert on the SPARC architecture, but it appears
that at least on an UltraSparc IIi machine from a few years ago, the
sparc V9 instructions are supported. However, the gcc by default
doesn't define
After openbios-sparc32 is introduced for sparc-softmmu, I can see a Linux
penguin but can't see booting texts.
This happens because OpenBIOS didn't understand Qemu's nographic flag and
therefore the Linux console was not changed to the correct device. Adding
'console=/dev/tty0' to command
I get this error when running linux-test without any emulation on
Sparc32/64:
linux-test.c:477: itimer
Strace output:
setitimer(ITIMER_REAL, {it_interval={0, 1}, it_value={0, 1}}, NULL)
= 0
getitimer(ITIMER_REAL, {it_interval={0, 10998}, it_value={0, 10998}}) = 0
write(2,
I failed to compile qemu-0.8.2 under Solaris on SPARC Sun-Blade-100 box.
Does this patch help?
It looks like Solaris gcc by default compiles in V8plus (or V8plusa?) mode,
not V8 or V9 as I assumed. V8 would be wrong.
_
Express
Fix Sparc64 host build failing because the ld script referenced from
Makefile.target does not exist.
_
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Add
Without this patch I had ~500 byte/second transfers with qemu-system-sparc,
now it network speed is much better :)
Good work!
Looking at 7990 chip docs (main chip on lance card) it seems like there are
more features
not implemented; e.g. 1.6ms timer is needed to implement normal
transmission.
This patch adds serial mouse support for sun4m slavio emulation.
Funky, I had made almost the same changes some time ago, but I didn't know
about the extra two bytes in the protocol. I merged your changes with mine,
result attached.
It could be worthwhile to check if lance (Am7990) and pcnet (Am79C970A)
drivers could be merged. This was discussed briefly some years ago:
http://lists.gnu.org/archive/html/qemu-devel/2004-10/msg00364.html
Yes, a quick look shows 79c970a has one rx/tx buffer management mode which
is
If there is no CD in drive, sparc system emulator fails to boot. This
happens because error handling is a bit broken in scsi-disk.c. The older
OpenBIOS just didn't care.
_
Express yourself instantly with MSN Messenger! Download
Why are we getting reads when no data is available? The command should
already
have completed.
I don't know. Should all SCSI commands return something with the transfer
mechanism? Or is it a bug in OpenBIOS, should it get the SCSI error status
somehow without transferring data?
The
Hi,
Here's my first attempt to merge Lance to PCNet, doesn't work yet.
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.com/
Merge Lance and PCNet drivers.
Index: qemu/hw/pcnet.c
Hi,
I got PCNet working in Sun4m architecture by fixing endianness problems and
adding IOMMU hooks. There are still some endianness issues, that's why I
disabled the address matching code.
The original code could benefit from some touchup and performance tuning.
Any comments?
- A general remark : instead of using SPARC_IOMMU_TRANSLATE, you should use
new memory helpers to read or write bytes such as
pcnet_physical_memory_read() and pcnet_physical_memory_write(). The
rationale is that ultimately pci memory accesses will also use PCI specific
I/Os to handle the case
- A general remark : instead of using SPARC_IOMMU_TRANSLATE, you should use
new memory helpers to read or write bytes such as
pcnet_physical_memory_read() and pcnet_physical_memory_write(). The
rationale is that ultimately pci memory accesses will also use PCI specific
I/Os to handle the case
Hi,
These patches merge PCNet and Lance, implement the new IOMMU access method
and convert ESP and PCNet to use the new method.
At least Sparc works as before. I think the changes should not change PC use
of PCNet.
Please apply.
For the DMA controller I think it would be worth creating a separate object
for the sparc DMA controller, and having that forward to the individual
devices.
That's a good idea, then ESP/NCR53C9x could be used more easily elsewhere.
In Linux there are ESP derived SCSI drivers for at least
I have some problems (Linux and OS X) trying to run the spart-test-0.2.
When I
run the following command. I just get a blank screen.
That's because openbios-sparc32 image is not updated yet to the latest
version (svn r79) which fixes the bug. As a workaround, please add -cdrom
/some/file.
I tried to boot using a 2.4 (debian) kernel that it is SMP ready. It goes
ahead quite a bit, but still fails.
It never finish the Initializing RT netlink socket step.
I tried the non-smp kernel (debian distributionn), and works fine. Any
hints?
SMP-Linux detects the CPUs but can't start
Hi,
I added the context to the DMA controller.
The recent SCSI/AIO changes have broken something, Debian 3.1r1 no longer
installs.
_
Don't just search. Find. Check out the new MSN Search!
This may be useful for the openbios/qemu SPARC64 project.
On the latest release (1.3), SUN has included the source code
for the OpenBios for the Niagara (sunv)
http://opensparc-t1.sunsource.net/download_hw.html
That is very good news! OpenBIOS is very nice, but there are some 64-bit
issues
Hi,
I don't think savevm works reliably together with current AIO. At least some
kind of AIO flushing or completion waiting should happen and then this
should be done before any devices have started saving their state. Is this
correct?
Implementing it this way does mean savevm can effect the guest VM state (it
causes all pending IO to complete immediately). However this should be
safe,
ie. it could occur be chance anyway, and qemu isn't deterministic to start
with.
What would be the right place for the AIO flush, how about
When savevm is issued, you need to halt the guest CPUs, and wait for all IO
to
complete. While doing this you need to allow device AIO completion routines
to run, which may trigger additional IO. Once all IO has been completed you
should then be able to safely save state.
How's this patch?
qemu_aio_poll doesn't wait. It returns immediately if IO has not completed
yet.
You're right, sorry. How's this version then? Though there is a race
condition where the AIO signal is received between checking for AIO and
waiting for it.
Hi,
This patch changes most Sun4m uses of pic_set_irq to pic_set_irq_new. I
didn't change floppy or nvram. I can do that as well if it's OK for their
other users.
Comments?
_
FREE pop-up blocking with the new MSN Toolbar - get
Change pic_set_irq to pic_set_irq_new, adjust callers. Make floppy size
tables
const. Remove TARGET_SPARC dependant code.
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
Hi,
The first patch by Igor Kovalenko implements the mouse protocol.
The second one fixes an annoying bug when there is serial output and input
at the same time, serial may hang. It's easy to demonstrate: Boot Debian
3.1r1 CD in nographic mode, at the language selection menu press and hold
Digging old bugs, I found this problem.
Maybe this patch helps? I can't test it here (can't get display to 16 bit
somehow).
On 8/9/06, Anthony Liguori [EMAIL PROTECTED] wrote:
On Thu, 10 Aug 2006 00:32:20 +0200, Juergen Lock wrote:
Hi!
I was made aware of this by a FreeBSD user, but i
Seems like it works, booting aurora-2.0-sparc-disc1.iso gives me the
penguin at least. Then it hangs and burns CPU as usual.
So early? I get to 'Running anaconda..' etc. Before AIO, install almost
finished.
_
Express yourself
1 - 100 of 4848 matches
Mail list logo
