I guess that I see something that is 'normal', because I observerd the same
thing without my program running. As you can see, I setted a breackpoint on
ds_device_write and letted the kernel continue. After some time the
breakpoint was hit with the result: kmsg != kmsg->ikm_next->ikm_prev.
wagi
Daniel Wagner <[EMAIL PROTECTED]> writes:
> I have a question about the kmsg. Is the datastructer holding all kmsg is
> double linked circular list? I'm asking this, because I can't see it
> with gdb. For example following ikm_next and then comparing with
> the value of ikm_prev seems never to ma
> You may have to slowly track down what pages got
> used for what and how things got the way they are.
I have a question about the kmsg. Is the datastructer holding all kmsg is
double linked circular list? I'm asking this, because I can't see it
with gdb. For example following ikm_next and then
On Thu, 22 Nov 2001, Roland McGrath wrote:
> Does your program use device_write or device_write_inband? Try making both
Yes, it used device_write. I have changed it to use device_write_inband
with the result that my programm crashes:
gauss:/mnt/newton/cache/hurd/oskit-mach-debug# ./xmit -r et
> (gdb) p/x *kmsg
> $1 = {ikm_next = 0x4081700, ikm_prev = 0xff10, ikm_size = 0x100,
> ikm_marequest = 0x0, ikm_header = {msgh_bits = 0x80001200, msgh_size = 0xa0,
> msgh_remote_port = 0x0, msgh_local_port = 0x4, msgh_seqno = 0x5,
> msgh_id = 0x7788}}
If this is right (and it loo
On Tue, 20 Nov 2001, Roland McGrath wrote:
> I take it your second program uses device_set_filter on its own to select
> some of the packets.
Yes, that's right.
> First, by
> program should both be sending and receiving packets. We need to figure
> looking in the mach_msg_trap frame, you can s
I take it your second program uses device_set_filter on its own to select
some of the packets. That should be perfectly valid and both your program
and pfinet should get copies of each packet.
I'd like to understand better exactly what is happening when the kernel
crashes, and I don't think it s
On Sun, 28 Oct 2001, Roland McGrath wrote:
> It seems likely that this crash is due to improper reentrance. I am
> suspicious of your other patch, because the situation it disables the check
> for is just the kind of situation I would suspect in this kind of lossage.
As you have foreseen, attac
The patch removes the not needed assertion.
wagi
2001-11-15 Daniel Wagner <[EMAIL PROTECTED]>
* oskit/osenv_mem.c (free_for_oskit): Don't test for the
OSENV_NONBLOCKING flag. Instead decide on the address which flavor
of memory is to be freed.
Index: osenv_mem.
> The question was: How do I allocate memory? I'm asking this, because
> there might be a difficulty at this point. We can not use kfree to free
> some memory, so kalloc would fail also, right?
It's the context that's not clear. There are numerous kinds of memory
allocation. The only kinds that
> I'm not really following your question. If you are not hitting this panic
> now, then let's not worry about it until you do.
The question was: How do I allocate memory? I'm asking this, because
there might be a difficulty at this point. We can not use kfree to free
some memory, so kalloc would
I'm not really following your question. If you are not hitting this panic
now, then let's not worry about it until you do.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
> panic ("free_for_oskit of virtual memory from interrupt level");
>
> If that happens, we'll have to come up with some hairy solution. That's
> because you can't call kfree at interrupt level, so we'd need to maintain a
> to-be-freed list at interrupt level and process it later and it w
On Tue, 06 Nov 2001, Roland McGrath wrote:
> No, that doesn't quite make sense. The mflags argument to
Of course :)
> Try changing that kmalloc call to use __GFP_HIGH instead (that's what
> GFP_ATOMIC is defined to in oskit/linux/src/include/linux/mm.h).
Using __GFP_HIGH helped. So it seems d
No, that doesn't quite make sense. The mflags argument to
oskit_skbufio_mem_alloc uses OSENV_* flag bits, not GFP_* flag bits.
kmalloc needs GFP_* flag bits. However, note the assert early in
oskit_skbufio_mem_alloc, so you know mflags is always just OSENV_NONBLOCKING.
So just calling it with G
On Mon, 05 Nov 2001, Roland McGrath wrote:
> You said "fixing kmalloc was easy", but I didn't see you post any change to
> the oskit code. I'm not at all sure that kmalloc should change.
Ok, here is what I fixed. mflags is passed to oskit_skufio_mem_alloc but
it is not passed to kamlloc. If it
You said "fixing kmalloc was easy", but I didn't see you post any change to
the oskit code. I'm not at all sure that kmalloc should change.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
> On Mon, 29 Oct 2001, Daniel Wagner wrote:
>
> > oskit and not for oskit-mach. So I will write a patch for oskit and then
> > I'll see what happends.
>
> It seems that the oskit wrappers for kmalloc and kfree don't pass the
> right flags to oskit_linux_mem_alloc and oskit_linux_mem_free.
I w
On Mon, 05 Nov 2001, Daniel Wagner wrote:
> On Mon, 29 Oct 2001, Daniel Wagner wrote:
>
>
> Fixing kmalloc was easy, but I've some problems with kfree. kfree takes
Oops, it should be oskit_skbufio_mem_alloc and not kmalloc. Here is the
bt for freeing memory:
#0 panic (
fmt=0x209960 "../.
On Mon, 29 Oct 2001, Daniel Wagner wrote:
> oskit and not for oskit-mach. So I will write a patch for oskit and then
> I'll see what happends.
It seems that the oskit wrappers for kmalloc and kfree don't pass the
right flags to oskit_linux_mem_alloc and oskit_linux_mem_free.
Fixing kmalloc was
Hi Roland!
On Sun, 28 Oct 2001, Roland McGrath wrote:
> It seems likely that this crash is due to improper reentrance. I am
> suspicious of your other patch, because the situation it disables the check
> for is just the kind of situation I would suspect in this kind of lossage.
Hmm, but the ke
It seems likely that this crash is due to improper reentrance. I am
suspicious of your other patch, because the situation it disables the check
for is just the kind of situation I would suspect in this kind of lossage.
I am not going to be comfortable with any tweak-around-the-edges approach
to
Hi
I found an easy way to crash oskit-mach reproducable. The attached
buggy program does it. Be warned: the crash leaves your system in
horrible condition (as always).
This is what I get from the gdb (remote debugging):
Breakpoint 1, panic (fmt=0x21f7ca "vm_map_copyout: wiring 0x%x")
at ../
23 matches
Mail list logo
