LTC Owner is: csiddali.com LTC Originator is: marksmit.com Problem description: kernel crash on fistboot after new install, while configuring firewall ip_tables. Hardware Environment Machine type: OpenPower 710 Cpu type Power5, Is the system sitting in a debugger right now? yes. Additional information: Applied workaround of switching eth3 config back to default dhcp, and installation completed. Upon reboot after install (firstboot), blue (kudzu?) screen appeared allowing the setting of the security (passwords). accepted defaults offered. next offered to configure the firewall. accepted the defaults offered. system then crashed into xmon: iptables: loop hook 1 pos 0 00000022. iptables: loop hook 1 pos 0 00000022. Unable to handle kernel paging request for data at address 0xd00000000004f008 Faulting instruction address: 0xd000000000389bbc cpu 0x1: Vector: 300 (Data Access) at [c0000001e2b034a0] pc: d000000000389bbc: .do_add_counters+0x14c/0x240 [ip_tables] lr: d000000000389b8c: .do_add_counters+0x11c/0x240 [ip_tables] sp: c0000001e2b03720 msr: 8000000000009032 dar: d00000000004f008 dsisr: 40000000 current = 0xc0000001e49677f0 paca = 0xc00000000045e300 pid = 1970, comm = iptables enter ? for help 1:mon> found this same crash while trying to modify the firewall settings, same type of hardware and OS level. to recreate (this might take a couple of iterations) 1)run system-config-securitylevel either enable or disable the firewall 2)run command again enable firewall, and select ssh. 3)if no crash repeate above steps adding ssh as a trusted protocol and removing it you will eventually get a kernel crash when you try to exit the program to commit the changes to the firewall. ========================= R00 = 000000000000014c R16 = 0000000010107870 R01 = c000000075573720 R17 = 000000001000d920 R02 = d00000000035c378 R18 = 0000000000000004 R03 = c00000007ea7d508 R19 = 0000000000000002 R04 = 0000000000000101 R20 = 0000000000000070 R05 = 000000000000009c R21 = 000000001001f00c R06 = c000000076c25678 R22 = 00000000ff8fabd8 R07 = c00000007ea7d5a4 R23 = 0000000000000002 R08 = 0000000000000000 R24 = 0000000000000000 R09 = 0000000000001000 R25 = 000000001001f640 R10 = 0000000000000000 R26 = d0000000002c7048 R11 = d00000000004f000 R27 = d00000000004e000 R12 = d00000000034cfa8 R28 = 0000000000000002 R13 = c00000000045e100 R29 = ffffffffffffffea R14 = 00000000100e0000 R30 = d00000000035c180 R15 = 0000000000000000 R31 = d0000000002c7010 pc = d000000000349bbc .do_add_counters+0x14c/0x240 [ip_tables] lr = d000000000349b8c .do_add_counters+0x11c/0x240 [ip_tables] msr = 8000000000009032 cr = 22000484 ctr = c00000000036f7d8 xer = 0000000000000007 trap = 300 dar = d00000000004f008 dsisr = 40000000 0:mon> e cpu 0x0: Vector: 300 (Data Access) at [c0000000755734a0] pc: d000000000349bbc: .do_add_counters+0x14c/0x240 [ip_tables] lr: d000000000349b8c: .do_add_counters+0x11c/0x240 [ip_tables] sp: c000000075573720 msr: 8000000000009032 dar: d00000000004f008 dsisr: 40000000 current = 0xc0000000766367f0 paca = 0xc00000000045e100 pid = 2161, comm = iptables d000000000349b94 80060004 lwz r0,4(r6) d000000000349b98 7f80e000 cmpw cr7,r0,r28 d000000000349b9c 409e0070 bne cr7,d000000000349c0c # .do_add_counters+0x19c/0x240 [ip_tables] d000000000349ba0 a12d000a lhz r9,10(r13) d000000000349ba4 38a00000 li r5,0 d000000000349ba8 38800000 li r4,0 d000000000349bac 79291f24 rldicr r9,r9,3,60 d000000000349bb0 7d293214 add r9,r9,r6 d000000000349bb4 e8690038 ld r3,56(r9) d000000000349bb8 48000030 b d000000000349be8 # .do_add_counters+0x178/0x240 [ip_tables] d000000000349bbc e94b0008 ld r10,8(r11) <--- pc here 0:mon> d000000000349bc0 7d1b482a ldx r8,r27,r9 d000000000349bc4 e8070068 ld r0,104(r7) d000000000349bc8 e9270060 ld r9,96(r7) d000000000349bcc a167005a lhz r11,90(r7) d000000000349bd0 7c005214 add r0,r0,r10 d000000000349bd4 7d294214 add r9,r9,r8 From the dis-assembly the problem seems to be in the following source line... static inline int add_counter_to_entry(struct ipt_entry *e,.....) { .... ADD_COUNTER(e->counters, addme[*i].bcnt, addme[*i].pcnt); <<<<---- here ... }
changed: What |Removed |Added ---------------------------------------------------------------------------- Version|FC5 |Other ------- Additional Comments From marksmit.com 2006-05-26 22:26 EDT ------- I am changing the version on the LTC Bugzilla from FC5 to "other" to reflect that this is found on Fedora-devel (rawhide). Retesting with the May26 snapshot of rawhide, this appears to fixed. It no longer recreates.
changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Other |devel ------- Additional Comments From marksmit.com 2006-06-05 23:56 EDT ------- I am changing the version to 'devel' to properly reflect that this recreates on rawhide. The status remains unchanged. This no longer recreates as of the May26 rawhide snapshot.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
----- Additional Comments From marksmit.com 2006-10-18 18:41 EDT ------- This bug was never recreated on FC5, only FC6 during May 2006 rawhide builds. This bug does not recreate on FC6-test3, nor on the requested FC5 fresh install, followed by a yum update to Version: 2.6.18-1.2200.fc5 kernel.