Using the kernel 4.19.0-rc2 it works now, so With the fix for not
calling fput when memfd == NULL the patch is
Reviewed-By: Gert Wollny
best,
Gert
Am Montag, den 10.09.2018, 15:30 +0200 schrieb Gerd Hoffmann:
> On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote:
> > Am Mo
Using the kernel 4.19.0-rc2 it works now, so With the fix for not
calling fput when memfd == NULL the patch is
Reviewed-By: Gert Wollny
best,
Gert
Am Montag, den 10.09.2018, 15:30 +0200 schrieb Gerd Hoffmann:
> On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote:
> > Am Mo
Am Montag, den 10.09.2018, 15:30 +0200 schrieb Gerd Hoffmann:
> On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote:
> > Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann:
> > >
> > > By default qemu doesn't use memfd for backing storage, you hav
Am Montag, den 10.09.2018, 15:30 +0200 schrieb Gerd Hoffmann:
> On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote:
> > Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann:
> > >
> > > By default qemu doesn't use memfd for backing storage, you hav
Am Montag, den 10.09.2018, 15:30 +0200 schrieb Gerd Hoffmann:
> On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote:
> > Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann:
> > >
> > > By default qemu doesn't use memfd for backing storage, you hav
Am Montag, den 10.09.2018, 15:30 +0200 schrieb Gerd Hoffmann:
> On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote:
> > Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann:
> > >
> > > By default qemu doesn't use memfd for backing storage, you hav
Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann:
>
> By default qemu doesn't use memfd for backing storage, you have to
> explicitly configure qemu that way (see qemu commit log of the test
> branch):
>
> qemu-system-x86_64 -m 2G
> -object
Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann:
>
> By default qemu doesn't use memfd for backing storage, you have to
> explicitly configure qemu that way (see qemu commit log of the test
> branch):
>
> qemu-system-x86_64 -m 2G
> -object
Am Montag, den 10.09.2018, 10:37 +0200 schrieb Gerd Hoffmann:
...
> > The other question is of course, why did dma_buf_export fail for me
> > ...
>
> What exactly did you try?
I ran
qemu-system-x86_64 -enable-kvm -smp 5 -M q35 -m 8G \
-drive format=raw,file=ubuntu.raw,if=virtio \
Am Montag, den 10.09.2018, 10:37 +0200 schrieb Gerd Hoffmann:
...
> > The other question is of course, why did dma_buf_export fail for me
> > ...
>
> What exactly did you try?
I ran
qemu-system-x86_64 -enable-kvm -smp 5 -M q35 -m 8G \
-drive format=raw,file=ubuntu.raw,if=virtio \
I am by no means a kernel expert, but Tomeu asked whether I could
review this. Generally the patch looks okay, it applied (on top of
4.18.5-gentoo), and compiled without problems.
However, running the experimental qemu branch I get a kernel bug:
BUG: unable to handle kernel NULL pointer
I am by no means a kernel expert, but Tomeu asked whether I could
review this. Generally the patch looks okay, it applied (on top of
4.18.5-gentoo), and compiled without problems.
However, running the experimental qemu branch I get a kernel bug:
BUG: unable to handle kernel NULL pointer
Hello,
I've hit a Kernel BUG with the combination of nonstandart kernel
modules. So dear linux-kernel readers, this bug report may or may not
apply to the standart kernel. But if you have any comments, please CC
me.
We use the dolphinics psb66 clustering card and a GForce 256 graphics
card.
Hello,
I've hit a Kernel BUG with the combination of nonstandart kernel
modules. So dear linux-kernel readers, this bug report may or may not
apply to the standart kernel. But if you have any comments, please CC
me.
We use the dolphinics psb66 clustering card and a GForce 256 graphics
card.
ert
>From - Thu Nov 16 12:10:09 2000
>From wollny Thu Nov 16 11:32:26 2000
Received: from mout1.freenet.de ([EMAIL PROTECTED] [194.97.50.132])
by topaz.cns.mpg.de (8.9.3/8.9.3/Debian/GNU) with ESMTP id LAA31905
for <[EMAIL PROTECTED]>; Thu, 16 Nov 2000 11:32:26 +0100
Receive
From - Thu Nov 16 12:10:09 2000
From wollny Thu Nov 16 11:32:26 2000
Received: from mout1.freenet.de ([EMAIL PROTECTED] [194.97.50.132])
by topaz.cns.mpg.de (8.9.3/8.9.3/Debian/GNU) with ESMTP id LAA31905
for [EMAIL PROTECTED]; Thu, 16 Nov 2000 11:32:26 +0100
Received: from [194
Hello,
i think it got it nailed, please try the attached patch (it is against
11-pre4, but it should work against all test11).
Explanation:
with test7-pre6 in the imm-module the new scsi - code was enabled (see
imm.h).
This causes the locking of the io_request_lock in scsi_register_host
James M wrote:
>
> Dunno what time it is over there
Just add seven hours to your time.
> but could you give this a try when you get a chance?
yeah, and the other thing i will do, is to go through the test7-pre
series, to see where the bug came to light.
-
To unsubscribe from this list: send
James M wrote:
Dunno what time it is over there
Just add seven hours to your time.
but could you give this a try when you get a chance?
yeah, and the other thing i will do, is to go through the test7-pre
series, to see where the bug came to light.
-
To unsubscribe from this list: send the
Hello,
i think it got it nailed, please try the attached patch (it is against
11-pre4, but it should work against all test11).
Explanation:
with test7-pre6 in the imm-module the new scsi - code was enabled (see
imm.h).
This causes the locking of the io_request_lock in scsi_register_host
On Tue, 14 Nov 2000, James M wrote:
>Was just trying to find out why I can mount in 11pre1 and 11pre2 when
> Gert can't mount at all, so I removed my VFAT factory formatted zipdisk
> and put in an Ext2 formatted one.**BOOM**
Actually i never tried to mount in my testings, just did
A bug i had with kernel version 2.4.0-test9 is still there, but there are
additional information:
When parport_pc is compiled as module, and not already loaded
"modprobe imm" yields the LOCKUP message (subject).
The iomega-drive is usable after the modprobe and despite of
the lockup.
If
A bug i had with kernel version 2.4.0-test9 is still there, but there are
additional information:
When parport_pc is compiled as module, and not already loaded
"modprobe imm" yields the LOCKUP message (subject).
The iomega-drive is usable after the modprobe and despite of
the lockup.
If
compiling usb as module i get:
drivers/usb/usb.c 723: hotplug_path unknown ...
bye
Gert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
compiling usb as module i get:
drivers/usb/usb.c 723: hotplug_path unknown ...
bye
Gert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Hello,
I was told that I should see if the bug is repeatable with a vanilla gcc
(and not pgcc).
/proc/version is now:
Linux version 2.4.0-test9-my-fb ([EMAIL PROTECTED])
(gcc version 2.7.2.3) #26 SMP Son Okt 15 18:50:40 CEST 2000
The other information stays the same.
bye
Gert
PS: Pleas
Hello,
Here is the bug report
When doing "modprobe imm" I get message LOCKUP detected
the trace looks like this:
0: ?? (assume spin_lock_irqsave in blk_get_queue but printed EIP seems to
be sensless - area with no code according to the map file)
1: ll_rw_blk.c: 874
Hello,
Here is the bug report
When doing "modprobe imm" I get message LOCKUP detected
the trace looks like this:
0: ?? (assume spin_lock_irqsave in blk_get_queue but printed EIP seems to
be sensless - area with no code according to the map file)
1: ll_rw_blk.c: 874
Hello,
using ramfs with highmem enabled (and ehough RAM ;) yields a possible
:Unable to handle kernel NULL pointer dereference at virtual address
:printing eip:
:c0166f88
[snip]
This is in asm/string.h: 518
called by fs/ramfs/inode.c:68
here page_address used to access the
Hello,
using ramfs with highmem enabled (and ehough RAM ;) yields a possible
:Unable to handle kernel NULL pointer dereference at virtual address
:printing eip:
:c0166f88
[snip]
This is in asm/string.h: 518
called by fs/ramfs/inode.c:68
here page_address used to access the
30 matches
Mail list logo
