linux-2.6 deller (ioremap-changes) and more
Quoted 10 lines · John David Anglin
Quoted 2 lines
But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it
worked fine, so I assume you shouldn't see any problems either...
I tried the default 2.6.16-pa5 from www.parisc-linux.org this afternoon. I still get a lot of
ip_tablesmessages on the console which unfortunately aren't captured in any log file. I've attached the diff between 2.6.15-rc7-pa
and 2.6.16-pa5 dmesg files. Is the eth0 difference significant? There's also a segv in dirmngr that occurs late in both boots.
I had a similar problem (regarding iptables). It seems they are implementing a new unified interface (NFNETLINK) which might break the userspace netfilter tools (aka. iptables/ip6tables), unless you use the CVS version of them. This is was introduced somewhere between 2.6.15 and 2.6.16. IIRC after disabling CONFIG_NETFILTER_NETLINK (or at least set it to compile it as a module) and enabling CONFIG_NETFILTER_XTABLES I didn't have any problems anymore.
Regarding the segfault, I can't help you there ... although I have seen many applications not longer working on my Debian/testing system lately (segfault, 'unresolvable relocation error 0x42' most of the time). The affected applications/debian packages are:
- aide
- samba (libsmbclient, samba, samba-common, smbclient, smbfs etc.)
- autofs
Recompiling those applications via 'apt-get build-dep <package>' and 'apt-get -b source <package>' with gcc-3.4 produces working executables. At least for samba I also tried recompiling with gcc-4.0, with also worked. It seems that there is something wrong with the setup Debian's buildd uses ... ... I think I should rather report this bug to the debian-hppa m-l ...
Max
Quoted 3 lines
Regarding the segfault, I can't help you there ... although I have seen many applications not longer working on my Debian/testing system lately (segfault, 'unresolvable relocation error
0x42' most of the time).
This should be fixed in libc6 2.3.6-3 which has support for the above relocation. If it's still occurring, there needs to be a new bug report. In the situations that I've seen the relocations are coming from /usr/lib/Scrt1.o when pie code is being used.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 8 lines · John David Anglin
Quoted 3 lines
Regarding the segfault, I can't help you there ... although I have seen many applications not longer working on my Debian/testing system lately (segfault, 'unresolvable relocation error
0x42' most of the time).This should be fixed in libc6 2.3.6-3 which has support for the above relocation. If it's still occurring, there needs to be a new bug report. In the situations that I've seen the relocations are coming from
/usr/lib/Scrt1.owhen pie code is being used.
Hi Dave,
I'm running libc6-2.3.6-4 and see some strange crashes. Might it be related, or does 2.3.6-4 doesn't includes your fix ?
Regards,
Helge
root@c3000:~# dpkg -l | grep libc ii libc6 2.3.6-4 GNU C Library: Shared libraries and Timezone data ii libc6-dev 2.3.6-4 GNU C Library: Development Libraries and Header Files ii libc6-pic 2.3.6-4 GNU C Library: PIC archive library
dbus-0.61-5.deb
nscd-2.3.6-4.deb
do_page_fault() pid=1854 command='dbus-daemon' type=15 address=0x41493520 vm_start = 0x4095d000, vm_end = 0x4095f000
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111110100001111 Not tainted
r00-03 00000000 0062c6c3 409148df 40493818 r04-07 4095b714 404933b8 00000005 40493000 r08-11 0000000f 0007a960 00000005 fb556648 r12-15 fb55664c 4095c714 4095c714 fb55674c r16-19 4095ed9c 00000001 00000000 4095b714 r20-23 01000168 00000000 000196a8 0007a960 r24-27 00000005 000000d3 a2d3a6be 00070eec r28-31 00000000 404931e4 fb556880 409148f3 sr0-3 00000000 00000000 00000000 00001765 sr4-7 00001765 00001765 00001765 00001765
VZOUICununcqcqcqcqcqcrmunTDVZOUI
FPSR: 00000000000000000000000000000000
FPER1: 00000000
fr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 fr04-07 11bb69e08f41d7fc 000000001017b2f8 1051e2201051e220 11ba1b0810436960 fr08-11 0000000300000000 11bb69e00098963a 0000000000000002 11ba1b0810436960 fr12-15 0007a8a810517010 0000000010125938 0007a8c81054d6a0 0000000000030000 fr16-19 0000000b1051e810 11ba409c11ba4148 1051e220103af867 00002000103d15a0 fr20-23 11b9400000000000 0000000010166ef8 0000000000000000 0000000010514010 fr24-27 0000000110436810 10125a9800000000 232aaf8049c5f780 0098963a11b94000 fr28-31 ffffff9c11ba1b08 11ba414810167050 000000001051e010 00000000f0400004
IASQ: 00001765 00001765 IAOQ: 40914917 4091491b
IIR: 0e85001c ISR: 00001765 IOR: 41493520
CPU: 0 CR30: 8eb90000 CR31: 104bc000
ORIG_R28: 00000000
IAOQ[0]: 0x40914917
IAOQ[1]: 0x4091491b
RP(r2): 0x409148df
do_page_fault() pid=1830 command='nscd' type=15 address=0x41493534 vm_start = 0x41425000, vm_end = 0x41428000
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111 Not tainted
r00-03 00000000 410d0fdc 410b80cf 404c8c80 r04-07 410d0ca0 00000000 4426c56b 404937e8 r08-11 41493520 00000079 404933b8 00000079 r12-15 404c8e89 000000d3 000000d2 410d0df0 r16-19 4426c56b 00000059 410d0fdc 410d0ca0 r20-23 00000000 01000168 00000000 00000008 r24-27 404c8cb8 404c8e48 404c8cb8 410d0ca0 r28-31 00000001 00000803 404c8f40 00000000 sr0-3 00001701 00000000 00000000 00001701 sr4-7 00001701 00001701 00001701 00001701
VZOUICununcqcqcqcqcqcrmunTDVZOUI
FPSR: 00000000000000000000000000000000
FPER1: 00000000
fr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 fr04-07 11bb69e08f41d7fc 000000001017b2f8 1051e2201051e220 11ba1b0810436960 fr08-11 0000000300000000 11bb69e00098963a 0000000000000002 11ba1b0810436960 fr12-15 0000100010517010 404c8e4010125938 402ac4b41054d6a0 0000000000030000 fr16-19 0000000b1051e810 11ba409c11ba4148 1051e220103af867 00002000103d15a0 fr20-23 11b9400000000000 0000000010166ef8 40095a2bcccccccd 404c8cb810514010 fr24-27 0000000a10436810 10125a9800000000 232aaf8049c5f780 0098963a11b94000 fr28-31 ffffff9c11ba1b08 11ba414810167050 000000001051e010 00000000f0400004
IASQ: 00001701 00001701 IAOQ: 410b7f43 410b7f47
IIR: 491c0028 ISR: 00001701 IOR: 41493534
CPU: 0 CR30: 8e9cc000 CR31: 104bc000
ORIG_R28: 00000001
IAOQ[0]: 0x410b7f43
IAOQ[1]: 0x410b7f47
RP(r2): 0x410b80cf
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Hello Matthias,
Quoted 12 lines · Helge Deller
Quoted 8 lines · John David Anglin
Quoted 3 lines
Regarding the segfault, I can't help you there ... although I have seen many applications not longer working on my Debian/testing system lately (segfault, 'unresolvable relocation error
0x42' most of the time).This should be fixed in libc6 2.3.6-3 which has support for the above relocation. If it's still occurring, there needs to be a new bug report. In the situations that I've seen the relocations are coming from
/usr/lib/Scrt1.owhen pie code is being used.
Quoted 4 lines
Hi Dave,
I'm running libc6-2.3.6-4 and see some strange crashes. Might it be related, or does 2.3.6-4 doesn't includes your fix ?
Do you know in which gcc-4.0 dpkg release the jda patch (<http://lists.parisc-linux.org/pipermail/parisc-linux/2006-March/028548.html>) was in? I can so check in buildd with which compiler this new glibc-2.3.6-4 was build ;-)
TIA,
Joel
Quoted 1 line
Quoted 1 line
I'm running libc6-2.3.6-4 and see some strange crashes. Might it be related, or does 2.3.6-4 doesn't includes your fix ?
2.3.6-4 should have the glibc fix...
Quoted 3 lines
Do you know in which gcc-4.0 dpkg release the jda patch
(<http://lists.parisc-linux.org/pipermail/parisc-linux/2006-March/028548.html>) was in? I can so check in buildd with which compiler this new glibc-2.3.6-4 was build ;-)
As far as GCC goes, the fix is now in all 4.x branches but not in 3.4. I'm not sure about the debian status. I believe that Matthias integrated the change but there was a regression due to a missing glibc patch needed to prevent a SIGSEGV in the unwind code. Matthias said this problem was fixed on March 20.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 4 lines
I'm not sure about the debian status. I believe that Matthias integrated the change but there was a regression due to a missing glibc patch needed to prevent a SIGSEGV in the unwind code. Matthias said this problem was fixed on March 20.
2.3.6-3 does't have the fix:
dave@hiauly6:~$ objdump -d /lib/libpthread.so.0 /lib/libpthread.so.0: file format elf32-hppa-linux
Disassembly of section .init:
000041ac <_init>:
41ac: 6b c2 3f d9 stw rp,-14(sp)
41b0: 6f c4 00 80 stw,ma r4,40(sp)
41b4: 6b d3 3f c1 stw r19,-20(sp)
41b8: e8 42 02 a0 b,l 8310 <__pthread_initialize_minimal>,rp
41bc: 08 13 02 44 copy r19,r4
41c0: 08 04 02 53 copy r4,r19
41c4: e8 40 0c 70 b,l 4804 <frame_dummy>,rp
41c8: 08 00 02 40 nop
41cc: e8 44 1d 2c b,l e068 <__do_global_ctors_aux>,rp
41d0: 08 00 02 40 nop
41d4: 4b c2 3f 59 ldw -54(sp),rp
41d8: 08 04 02 53 copy r4,r19
41dc: e8 40 c0 00 bv r0(rp)000041e0 <_end_init>:
41e0: 4f c4 3f 81 ldw,mb -40(sp),r4
This .init section isn't built correctly in shared libraries. The PIC register r19 needs to be retored after every call if it is subsequently used. As can be seen above, there is no restore after the call to frame_dummy and r19 is needed for the call to __do_global_ctors_aux.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 10 lines · John David Anglin
Quoted 1 line
Quoted 1 line
I'm running libc6-2.3.6-4 and see some strange crashes. Might it be related, or does 2.3.6-4 doesn't includes your fix ?
2.3.6-4 should have the glibc fix...
Quoted 2 lines
Do you know in which gcc-4.0 dpkg release the jda patch (<http://lists.parisc-linux.org/pipermail/parisc-linux/2006-March/028548.html>) was in? I can so check in buildd with which compiler this new glibc-2.3.6-4 was build ;-)
Quoted 5 lines
As far as GCC goes, the fix is now in all 4.x branches but not in 3.4. I'm not sure about the debian status. I believe that Matthias integrated the change but there was a regression due to a missing glibc patch needed to prevent a SIGSEGV in the unwind code. Matthias said this problem was fixed on March 20.
Sorry for delay but I come back to you with this stuff because I finaly take some time today to make some free space to check:
* this patch is included into gcc-snapshot dpkg (namely ref to 2006 03 25 ;-) )
* but neither gcc-4.0 nor gcc-4.1 dpkg contained this patch ;-(
(should I ask to Matthias, aka doko, lol?)
Thanks,
Joel
Quoted 1 line
I'm running libc6-2.3.6-4 and see some strange crashes. Might it be related, or does 2.3.6-4 doesn't includes your fix ?
Don't know. Note the r19 bug and the dynamic loader relocation bug are completely different bugs. It's easy to see the r19 bug by looking at the .init section of shared libraries as shown in my previous message. A backtrace would also help to see where the SEGV is occuring.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)