From: Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Bus errors and /dev/shm -- was: KQEMU bus errors
Date: Mon, 14 Feb 2005 09:19:19 +1300 [thread overview]
Message-ID: <1108325959.14612.5.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.61.0502131549220.25275@alpha.polcom.net>
[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]
I'm not quite clear on why /dev/shm should affect the 2005-02-11 version
and not the 2005-02-09 version of the code, but I took you at your word
and tried first with qemu guest mem == size of /dev/shm, and once again
received 'Bus error'. I then set qemu guest mem == 3/4 of /dev/shm and
it seems to be working OK.
So, can anyone explain why the apparent regression, and why /dev/shm is
used at all? I would be happier if I understood :)
Incidentally, the 'Protection Error' received by Win9x guest appears to
be orthogonal to this problem and isn't fixed by the above like WinXP
is.
Cheers,
D
On Sun, 2005-02-13 at 15:51 +0100, Grzegorz Kulewski wrote:
> On Sun, 13 Feb 2005, Julian Seward wrote:
>
> > On Sunday 13 February 2005 11:13, Jonas Maebe wrote:
> >> On 13 feb 2005, at 10:42, Darryl Dixon wrote:
> >>> Most of the references that I can find for a Linux 'Bus error' talk
> >>> about unaligned memory accesses.
> >>
> >> Indeed. The only way I know of to get a bus error under Linux/x86 from
> >> a user space program, is to turn on the alignment check flag in the
> >> eflags register, followed by an unaligned memory access.
> >
> > I have a very vague and possibly wrong memory that the another way
> > to get a bus error is to mmap a file into an area which is too big
> > for the file, then read/write the area beyond the end of the file.
> > Or perhaps that was on Solaris. In any case, it might be worth
> > checking this isn't somehow related to mmap or use of mmap.
>
> >From man mmap(2):
>
> "SIGBUS Attempted access to a portion of the buffer that does not
> correspond to the file (for example,
> beyond the end of the file, including the case where
> another process has truncated the file)."
>
> So this is very probable that the errors are caused by too small
> limit of tmpfs mounted on /dev/shm.
>
>
> Grzegorz Kulewski
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>
[-- Attachment #2: Type: text/html, Size: 3487 bytes --]
next prev parent reply other threads:[~2005-02-13 21:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-11 1:48 [Qemu-devel] KQEMU bus errors Darryl Dixon
2005-02-13 1:49 ` Julian Chesterfield
2005-02-13 2:17 ` Hetz Ben Hamo
2005-02-13 5:14 ` Brad Campbell
2005-02-13 9:42 ` Darryl Dixon
2005-02-13 11:13 ` Jonas Maebe
2005-02-13 14:10 ` Julian Seward
2005-02-13 14:51 ` Grzegorz Kulewski
2005-02-13 20:19 ` Darryl Dixon [this message]
2005-02-13 22:00 ` [Qemu-devel] Bus errors and /dev/shm -- was: " Filip Navara
2005-02-13 12:24 ` [Qemu-devel] " Phil Krylov
2005-02-13 2:37 ` Darryl Dixon
2005-02-13 2:44 ` Grzegorz Kulewski
2005-02-21 22:24 ` [Qemu-devel] " bri3d
2005-02-21 23:04 ` Hetz Ben Hamo
2005-02-21 23:30 ` Darryl Dixon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1108325959.14612.5.camel@localhost.localdomain \
--to=esrever_otua@pythonhacker.is-a-geek.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).