r have I missed something which has this effect ?)
2) If so, would patches be accepted ?
The same problem also appears to exist in 2.4...
Thanks
-- Jim
James Cownie<[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
-
To unsubscribe from this list: send the li
py(maddr + (addr & ~PAGE_MASK), buf, len);
flush_page_to_ram(page);
flush_icache_page(vma, page);
kunmap(page);
}
which looks ideal to me...
That still leaves 2.2 broken, though :-(
-- Jim
James Cownie<[EMAIL PROTECTED]>
Etnus
age)) || PageReserved(page))
return 0;
flush_cache_page(vma, addr);
p.s. Please CC me on any replies since I am not currently subscribed
to the linux-kernel list, and I'm out all next week so don't want to
subscribe right now :-(
Thanks.
-- Jim
James Cownie<[EMAIL PROT
& DR_STEP) {
/*
%
-- Jim
James Cownie<[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
-
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/
rap_no = 1;
%
-- Jim
James Cownie<[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
-
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/
m kernel mode ?
Since the debug trap handler can (potentially) be entered as a result
of _any_ store instruction in the kernel, it's certainly not clear to me
that I wouldn't be violating locking assumptions by calling
force_sig_info from here...
-- Jim
James Cownie<[EMAI
debugger point at the right place, i.e. the system
call inside which the watchpoint triggered.
-- Jim
James Cownie<[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
jcownie@pc2: diff -u signal.c-test7 signal.c
--- signal.c-test7 Mon Sep 25 11:52:35 200
Please let me know (by mail) otherwise I may take a look, since it
doesn't appear to be a _huge_ problem any longer, and it's one of the
things users keep bitching at us about when using our debugger :-(
Thanks
-- Jim
James Cownie<[EMAIL PROTECTED]>
Etnus, LLC. +44
'm simply aiming to catch up with
existing practice on many other operating systems.
-- Jim
James Cownie<[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
-
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/
ehow...) waited for them all to
stop before writing the core file would suffice. (Of course, I may be
wrong !)
-- Jim
James Cownie<[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
rnel gurus could point out any problems with the Villarreal
approach ?
-- Jim
James Cownie<[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
-
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/
.
Such an approach might be nice, (the kernel would get smaller, and
embedded folks could just leave out the code dumping daemon) but it's
a much more major change than anyone would want to do now for 2.4.
It's also hard to summon much enthusiasm to do it, since it's deep
into the &
ch is the complaints we get from our
customers saying that our debugger doesn't work because it won't
provide them with any useful information from the core files they get
from their pthreaded codes when running on Linux. I don't like having
to explain that it's a kernel "fea
13 matches
Mail list logo
