similar to: Reproducible kernel BUG while using VirtualBox:

This problem is found in meego testing: http://bugs.meego.com/show_bug.cgi?id=6672 A file in btrfs is mmaped and the mmaped buffer is passed to pwrite to write to the same page of the same file. In btrfs_file_aio_write(), the pages is locked by prepare_pages(). So when btrfs_copy_from_user() is called, page fault happens and the same page needs to be locked again in filemap_fault(). The fix is to

Hi, While updating my fedora rawhide installation, I got the Ooops listed at the end of the Email. Is this a known bug (I didn''t find anything specific), or should I file a bug? Thank you in advance, Clemens Feb 10 10:59:45 testbox kernel: [ 524.495751] BUG: unable to handle kernel NULL pointer dereference at (null) Feb 10 10:59:45 testbox kernel: [ 524.496006] IP:

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 6 Jan 2011 20:59:08 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=26242 > > Summary: BUG: unable to handle kernel NULL pointer dereference > at (null) > Product: Memory Management >

On Nov 22, 2005, at 17:18, Reid Spencer wrote: > Your patch uses an operating system call that is not portable. All > non-portable code needs to be located in the lib/System library. Yep! I know. That is why I posted it for discussion. I'm not sure if this is the "right" way to fix the problem, or if there is a different fix that should be applied (like perhaps copying the

Hello, We're having a problem in Dovecot 1.1.8 with a failed assertion on certain mbox format mailboxes. It happens both with deliver when it attempts to delier to the mailbox, and with IMAP connections for the affected box (though I'm not sure what they're doing at the time). Mar 3 12:55:26 <snip> dovecot: Panic: IMAP(<snip>): file istream.c: line 81 (i_stream_read):

On 1 Mar 2014 at 5:42, Ady wrote: From: Ady <ady-sf at hotmail.com> To: syslinux at zytor.com Date sent: Sat, 1 Mar 2014 05:42:25 +0200 Priority: normal Subject: Re: [syslinux] VirtualBox 4.1.x can reproduce bug 45 Send reply to: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com> > > > > > Short summary:

> Short summary: > I think bug #45 > http://bugzilla.syslinux.org/show_bug.cgi?id=45 > "Regression in Syslinux 6.xx. Doesn't 'hand over' to linux kernel" > can be reproduced using VirtualBox 4.1.x while trying to boot a > relatively-newish Linux kernel. > > Now, for more details... > > Under VBox 4.1.x and using ISOLINUX 4.xx, a newish Linux

Hi, I was wondering about the ARC and its interaction with the VM pagecache... When a file on a ZFS filesystem is mmaped, does the ARC cache get mapped to the process'' virtual memory? Or is there another copy? -Manoj

Alan Coopersmith (5): configure: Drop AM_MAINTAINER_MODE autogen.sh: Honor NOCONFIGURE=1 Print which option was in error along with usage message Use strcasecmp instead of a tolower loop & strcmp xkill 1.0.5 Emil Velikov (1): autogen.sh: use quoted string variables Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1):

> > > Short summary: > > I think bug #45 > > http://bugzilla.syslinux.org/show_bug.cgi?id=45 > > "Regression in Syslinux 6.xx. Doesn't 'hand over' to linux kernel" > > can be reproduced using VirtualBox 4.1.x while trying to boot a > > relatively-newish Linux kernel. > > Just to report an update... After confirming that the

Short summary: I think bug #45 http://bugzilla.syslinux.org/show_bug.cgi?id=45 "Regression in Syslinux 6.xx. Doesn't 'hand over' to linux kernel" can be reproduced using VirtualBox 4.1.x while trying to boot a relatively-newish Linux kernel. Now, for more details... Under VBox 4.1.x and using ISOLINUX 4.xx, a newish Linux kernel boots correctly. Under VBox 4.1.x and

Hi all, ive been playing with squat indexes. Up to about 300.000 emails in a single mailbox this was working flawlessly. The search index file is about 500MB at that time. Ive now added some more emails, and at 450.000 or so emails im seeing a serious problem with squat index creation. It takes...f o r e v e r . The .tmp file is being so slowly, it will probably take 2-3 hours to create. Upto

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 xkill is a utility for forcing the X server to close connections to clients. This program is very dangerous, but is useful for aborting programs that have displayed undesired windows on a user's screen. This minor maintenance release provides some hopefully very non-dangerous build configuration improvements and janitorial cleanups. Alan

Jack, can you please upload this test somewhere? On Thu, Nov 29, 2012 at 10:09 AM, Kostya Serebryany <kcc at google.com> wrote: > +glider > The compiler hardly matters here, I would expect the same failures with > clang. > Alex, could you please take a look? > > --kcc > > > On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >

We're currently on dovecot 0.99.10 with a few modifications (including one very nasty hack for the blank line at the beginning of the mailbox bug). We're using mbox all around. Everything works smoothly but we still ocasionally get corrupt mailboxes and indexes that need to be wiped out. I setup 1.0-test45 on one of our mailservers to start testing it and ran into a few issues. The

I debugged this a bit and it seems the mach_override patching of __cxa_throw is bogus. The start of that function is patched to jump to garbage. Breakpoint 1, 0x0000000100001c19 in main () (gdb) display/i $pc 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 <dyld_stub___cxa_throw> (gdb) si 0x0000000100016386 in dyld_stub___cxa_throw () 2: x/i $pc 0x100016386

I''m encountering premature ENOSPC issues recently where my Btrfs testing partition will either prematurely return an ENOSPC, or lock up the operations trying to access the partition. I have bisected the problem to this commit: http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commit;h=914ee295af418e936ec20a08c1663eaabe4cd07a (Btrfs: pwrite blocked when writing from the

This is with last night''s Xen snapshot (apr 24th), on kernel 2.6.12-rc3 - but the mess is so horrid that I''m not quite sure how to fix it... This oops prevents xen from starting xenU domains. Basically xend does the following: 1) mmap /proc/xen/privcmd 2) call an ioctl to populate the mmap 3) munmap the mapping created in (1) During the munmap, the dom0 kernel oopses, as

I've tried to stress test dovecot 1.1.4 with imaptest for days without any assertion failure or crash. Just some "got too little data" messages. So far it's the most stable 1.1.x version. Today a user got this imap segfault with vanilla 1.1.4 (I don't know if it's something you have already fixed in current tree). The user didn't complain of anything, I've just

Looks like this happens on x86_64 because the position of __cxa_throw is too far from the allocated branch island (should be <2G). This can be solved by allocating the branch islands somewhere near the text segment (look for kIslandEnd in asan_mac.cc, this is currently 0x7fffffdf0000) or by patching the function with a longer instruction sequence that stores the jump target in a register and