Date: Thu, 29 Aug 2013 11:25:28 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Ronald Klop <ronald-freebsd8@klop.yi.org> Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI Message-ID: <6046B66D-5F4C-4E8D-923A-3E26DED5DD8F@bsdimp.com> In-Reply-To: <CAJ-VmomABwx=hd7nKVc1KbiZbnFmkgtsY9=DQuxF0xgqtN2wSA@mail.gmail.com> References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <op.w2k0j5i08527sy@212-182-167-131.ip.telfort.nl> <CAJ-VmokTrMDJtw0OwjMamW-T=ZAx_6%2BhLxq=mxUbfLLA84ecPA@mail.gmail.com> <op.w2k1r5sc8527sy@212-182-167-131.ip.telfort.nl> <CAJ-Vmo=eWwRvKRFADvakTMWo17NrJf665sEQSYkay%2BK-ayBmbg@mail.gmail.com> <op.w2k6dutz8527sy@212-182-167-131.ip.telfort.nl> <CAJ-Vmo=0s95gSvct5dSkP8D9rpL92_cy76T6F7cYSWNJbdSN2Q@mail.gmail.com> <CAJ-Vmo=b4zZx=bY=3h10aL7gZxh=J1m%2Be5LpqozpwcGLC5zHNA@mail.gmail.com> <op.w2k7ng158527sy@212-182-167-131.ip.telfort.nl> <CAJ-Vmomy8dfhC89nOmHE=hpm3cQOV4pW_iCVL5HAOyFsqHTiKg@mail.gmail.com> <op.w2k8jvbq8527sy@212-182-167-131.ip.telfort.nl> <CAJ-VmomABwx=hd7nKVc1KbiZbnFmkgtsY9=DQuxF0xgqtN2wSA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 29, 2013, at 11:17 AM, Adrian Chadd wrote: > (top posting so one doesn't have to scroll down to the bottom to read > this..) >=20 > ARM people - is this useful? This looks to me like the serial console = IO > path to enter ddb. I guess uart_bus_attach() is the wrong function = name and > the real function is something inside the uart RX path This stack trace is poo. These routines long ago finished running, and = certainly wouldn't be running in the context of df. > When this userland process hangs, are other processes able to run? are = you > able to do something like df &, have it hang in the background, then = enter > kdb (from the shell pid?) >=20 > I wonder if this is a userland hang rather than a kernel hang.. Not being able to ^C suggests that the process is in a "disk" wait or = other uninterruptible wait (or it has tripped an infinite loop in the = kernel). That needs to be tracked down. why does df show up as having = no wchan and no wmesg, yet is hung and not responding to ^C? Warner >=20 > -adrian >=20 >=20 >=20 > On 29 August 2013 10:08, Ronald Klop <ronald-freebsd8@klop.yi.org> = wrote: >=20 >> On Thu, 29 Aug 2013 19:02:48 +0200, Adrian Chadd <adrian@freebsd.org> >> wrote: >>=20 >> ok, next, try 'bt 47'. It should get a stack trace of the df pid. >>>=20 >>> It shows its running, so.. >>>=20 >>>=20 >>>=20 >>> -adrian >>> ______________________________**_________________ >>> freebsd-arm@freebsd.org mailing list >>> = http://lists.freebsd.org/**mailman/listinfo/freebsd-arm<http://lists.freeb= sd.org/mailman/listinfo/freebsd-arm> >>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@**freebsd.org<freebsd-arm-unsubscribe@freebsd.org= > >>> " >>>=20 >>>=20 >> That gives me this. I have to go now, but I will leave it in the = debugger >> so I can test more when I'm back. >>=20 >> db> bt 47 >> Tracing pid 47 tid 100040 td 0xc4047320 >> db_trace_self() at db_trace_self >> pc =3D 0xc0bb9b4c lr =3D 0xc093277c (db_hex2dec+0x494) >> sp =3D 0xdce8dab0 fp =3D 0xdce8dac8 >> r10 =3D 0xc0c9d4e0 >> db_hex2dec() at db_hex2dec+0x494 >> pc =3D 0xc093277c lr =3D 0xc0932130 (db_command_loop+0x2f4) >> sp =3D 0xdce8dad0 fp =3D 0xdce8db70 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0xc0c31c57 >> db_command_loop() at db_command_loop+0x2f4 >> pc =3D 0xc0932130 lr =3D 0xc0931e8c (db_command_loop+0x50) >> sp =3D 0xdce8db78 fp =3D 0xdce8db88 >> r4 =3D 0xc0c02fb7 r5 =3D 0xc0c19c4d >> r6 =3D 0xc0e4575c r7 =3D 0xdce8dd58 >> r8 =3D 0xc4047320 r9 =3D 0xc0ce1094 >> r10 =3D 0xc0c9d750 >> db_command_loop() at db_command_loop+0x50 >> pc =3D 0xc0931e8c lr =3D 0xc09347fc = (X_db_symbol_values+0x254) >> sp =3D 0xdce8db90 fp =3D 0xdce8dcb0 >> r4 =3D 0x00000000 r5 =3D 0xdce8db98 >> r6 =3D 0xc0ce10c0 >> X_db_symbol_values() at X_db_symbol_values+0x254 >> pc =3D 0xc09347fc lr =3D 0xc0a7d034 (kdb_trap+0xd4) >> sp =3D 0xdce8dcb8 fp =3D 0xdce8dcd8 >> r4 =3D 0x00000000 r5 =3D 0x00000001 >> r6 =3D 0xc0ce10c0 r7 =3D 0xdce8dd58 >> kdb_trap() at kdb_trap+0xd4 >> pc =3D 0xc0a7d034 lr =3D 0xc0bca7ac = (undefinedinstruction+0x204) >> sp =3D 0xdce8dce0 fp =3D 0xdce8dd50 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0xc0bca4f8 r7 =3D 0xe7ffffff >> r8 =3D 0xc4047320 r9 =3D 0xc0a7cad4 >> r10 =3D 0xdce8dd58 >> undefinedinstruction() at undefinedinstruction+0x204 >> pc =3D 0xc0bca7ac lr =3D 0xc0bbb400 (exception_exit) >> sp =3D 0xdce8dd58 fp =3D 0xdce8ddb8 >> r4 =3D 0xffffffff r5 =3D 0xffff1004 >> r6 =3D 0x00000002 r7 =3D 0x00000000 >> r8 =3D 0x00000001 r9 =3D 0xc4047320 >> r10 =3D 0x27be4eaf >> exception_exit() at exception_exit >> pc =3D 0xc0bbb400 lr =3D 0xc0a7cac4 (kdb_alt_break+0x184) >> sp =3D 0xdce8ddac fp =3D 0xdce8ddb8 >> r0 =3D 0xc0ce10a4 r1 =3D 0xc0c030ab >> r2 =3D 0x00000000 r3 =3D 0x60000093 >> r4 =3D 0xc3d45200 r5 =3D 0xc3d45288 >> r6 =3D 0x00000002 r7 =3D 0x00000000 >> r8 =3D 0x00000001 r9 =3D 0xc4047320 >> r10 =3D 0x27be4eaf r12 =3D 0x000000c0 >> kdb_alt_break() at kdb_alt_break+0x198 >> pc =3D 0xc0a7cad8 lr =3D 0xc0a7c950 (kdb_alt_break+0x10) >> sp =3D 0xdce8ddc0 fp =3D 0xdce8ddc0 >> r4 =3D 0xc3d45200 r5 =3D 0xc3d45288 >> r6 =3D 0x00000002 r7 =3D 0x00000000 >> kdb_alt_break() at kdb_alt_break+0x10 >> pc =3D 0xc0a7c950 lr =3D 0xc094c5d8 (uart_bus_ihand+0x2fc) >> sp =3D 0xdce8ddc8 fp =3D 0xdce8dde0 >> uart_bus_ihand() at uart_bus_ihand+0x2fc >> pc =3D 0xc094c5d8 lr =3D 0xc094d19c (uart_bus_attach+0x690) >> sp =3D 0xdce8dde8 fp =3D 0xdce8de20 >> r4 =3D 0x0000ff7f r5 =3D 0xc3d45200 >> r6 =3D 0x00040000 >> uart_bus_attach() at uart_bus_attach+0x690 >> pc =3D 0xc094d19c lr =3D 0xc0a27f7c (intr_event_handle+0x78) >> sp =3D 0xdce8de28 fp =3D 0xdce8de40 >> r4 =3D 0xc34c3700 r5 =3D 0xdce8de60 >> r6 =3D 0x00000000 r7 =3D 0xc3e3b340 >> r8 =3D 0x00000000 >> intr_event_handle() at intr_event_handle+0x78 >> pc =3D 0xc0a27f7c lr =3D 0xc0bbc68c = (arm_handler_execute+0x54) >> sp =3D 0xdce8de48 fp =3D 0xdce8de58 >> r4 =3D 0xdce8de60 r5 =3D 0x00000021 >> r6 =3D 0xc0cc29e0 r7 =3D 0xc0e42ad8 >> r8 =3D 0x12a2532a r9 =3D 0xc6d47a95 >> arm_handler_execute() at arm_handler_execute+0x54 >> pc =3D 0xc0bbc68c lr =3D 0xc0bcef24 (irq_entry+0x9c) >> sp =3D 0xdce8de60 fp =3D 0xbfffe528 >> r4 =3D 0xffffffff r5 =3D 0xffff1004 >> r6 =3D 0x208dc014 r7 =3D 0x2f5b177e >> irq_entry() at irq_entry+0x9c >> pc =3D 0xc0bcef24 lr =3D 0x200eba44 (0x200eba44) >> sp =3D 0xdce8deb4 fp =3D 0xbfffe528 >> r0 =3D 0xa5581795 r1 =3D 0x209707a0 >> r2 =3D 0x0000ec90 r3 =3D 0x20901280 >> r4 =3D 0x27be4eaf r5 =3D 0x00000000 >> r6 =3D 0x208dc014 r7 =3D 0x2f5b177e >> r8 =3D 0x12a2532a r9 =3D 0xc6d47a95 >> r10 =3D 0x27be4eaf r12 =3D 0xc849eabc >> Unable to unwind into user mode >>=20 >>=20 >>=20 >> Ronald. >> ______________________________**_________________ >> freebsd-arm@freebsd.org mailing list >> = http://lists.freebsd.org/**mailman/listinfo/freebsd-arm<http://lists.freeb= sd.org/mailman/listinfo/freebsd-arm> >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@**freebsd.org<freebsd-arm-unsubscribe@freebsd.org= > >> " >>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6046B66D-5F4C-4E8D-923A-3E26DED5DD8F>