Am 08.06.2012 00:42, schrieb Martin Pärtel:
> Oh, darn, indeed. Well, getting si_code right fixed my immediate problem, but
> I might look at this again some time next week unless you've fixed it
> yourself by then. Thanks!
>
I can wait for your patch.
No need to hurry. :)
Thanks,
//richard
On 06/08/2012 01:07 AM, Richard Weinberger wrote:
> Am 07.06.2012 23:39, schrieb Martin Pärtel:
>> On 06/08/2012 12:26 AM, Richard Weinberger wrote:
>>
>>> Am 07.06.2012 22:59, schrieb Martin Pärtel:
Signal handlers in UML guest processes now get correct siginfo_t fields
for SIGTRAP, SIG
Am 07.06.2012 23:39, schrieb Martin Pärtel:
> On 06/08/2012 12:26 AM, Richard Weinberger wrote:
>
>> Am 07.06.2012 22:59, schrieb Martin Pärtel:
>>> Signal handlers in UML guest processes now get correct siginfo_t fields
>>> for SIGTRAP, SIGFPE, SIGILL and SIGBUS. Specifically, si_addr and si_code
(ack, forgot to reply to list)
On 06/08/2012 12:26 AM, Richard Weinberger wrote:
> Am 07.06.2012 22:59, schrieb Martin Pärtel:
>> Signal handlers in UML guest processes now get correct siginfo_t fields
>> for SIGTRAP, SIGFPE, SIGILL and SIGBUS. Specifically, si_addr and si_code
>> are now correct
Am 07.06.2012 22:59, schrieb Martin Pärtel:
> Signal handlers in UML guest processes now get correct siginfo_t fields
> for SIGTRAP, SIGFPE, SIGILL and SIGBUS. Specifically, si_addr and si_code
> are now correct where previously they were si_addr = NULL and si_code = 128.
What exactly is broken?
I
Signal handlers in UML guest processes now get correct siginfo_t fields
for SIGTRAP, SIGFPE, SIGILL and SIGBUS. Specifically, si_addr and si_code
are now correct where previously they were si_addr = NULL and si_code = 128.
Signed-off-by: Martin Pärtel
---
diff -uprN -X linux-3.4.1/Documentation/d
