From owner-freebsd-sparc64@FreeBSD.ORG Sun Mar 29 16:06:13 2009 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B213A1065691 for ; Sun, 29 Mar 2009 16:06:13 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from sakima.Ivy.NET (sakima.Ivy.NET [IPv6:2610:1f8:dc:41:220:edff:fe27:e764]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8088FC1A for ; Sun, 29 Mar 2009 16:06:06 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [IPv6:2610:1f8:dc:c0::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id 8EF49A8093 for ; Sun, 29 Mar 2009 12:05:55 -0400 (EDT) Received: by castrovalva.Ivy.NET (Postfix, from userid 405) id 346E212FD0D; Sun, 29 Mar 2009 12:05:55 -0400 (EDT) To: freebsd-sparc64@freebsd.org References: <49CD39B7.3050500@nexus-ag.com> <20090328214138.GA93149@alchemy.franken.de> From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Sun_Mar_29_12:05:54_2009-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 29 Mar 2009 12:05:55 -0400 In-Reply-To: <20090328214138.GA93149@alchemy.franken.de> (Marius Strobl's message of "Sat, 28 Mar 2009 22:41:38 +0100") Message-ID: User-Agent: T-gnus/6.17.2 (based on No Gnus v0.2) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (alpha--netbsd) MULE/5.0 (SAKAKI) Subject: Re: kernel panic with firewire PCI card X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 16:06:14 -0000 --pgp-sign-Multipart_Sun_Mar_29_12:05:54_2009-1 Content-Type: text/plain; charset=US-ASCII >>>>> "ms" == Marius Strobl writes: ms> In theory there are some ways one can make them ms> work anyway but that would be quite some work to do if at all ms> feasible. see uvesafb in linux for possible starting point --pgp-sign-Multipart_Sun_Mar_29_12:05:54_2009-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUASc+cYonCBbTaW/4dAQIL1wP/YAIi3zncTI9D8EHffpbAu5qdfEtRoM1J aArHMbkDZcHm8KT98OvPXE6S5o4FNTXhzxUSLUx7JD2CgUpBjIp3yEr/hhXZeOVK ED/xlRAkffT+VeKd3h43lNfdpfI9+lgK+5RGxaqC1G0aWNKh9gKHYpY5cy3YVvO6 MYOc5B5yOHY= =OiHz -----END PGP SIGNATURE----- --pgp-sign-Multipart_Sun_Mar_29_12:05:54_2009-1-- From owner-freebsd-sparc64@FreeBSD.ORG Sun Mar 29 18:15:39 2009 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1750D106568F for ; Sun, 29 Mar 2009 18:15:39 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 9FBBA8FC15 for ; Sun, 29 Mar 2009 18:15:38 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n2TIFZ2w015421; Sun, 29 Mar 2009 20:15:35 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <49CFBAC6.5030809@fgznet.ch> Date: Sun, 29 Mar 2009 20:15:34 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Marius Strobl References: <49CD39B7.3050500@nexus-ag.com> <20090328214138.GA93149@alchemy.franken.de> In-Reply-To: <20090328214138.GA93149@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-sparc64@freebsd.org Subject: Re: kernel panic with firewire PCI card X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 18:15:39 -0000 Marius Strobl wrote: > On Fri, Mar 27, 2009 at 09:40:23PM +0100, Andreas Tobler wrote: >> Hello, >> >> I get the below panic while having plugged in a firewire PCI card. The >> card itself is not 'sun' compliant. Means, it is a custom fw card made >> for PC's I guess. But as far as I understand, fbsd can handle non sun >> PCI cards, can't it? > > If the driver is well-written, i.e. correctly uses bus_dma(9) > and bus_space(9), is LP64- and endian-clean and deals with > strict alignment requirements, and the chip plays nice > with Sun's interpretation of the PCI specifications they > should work. Drivers that rely on firmware on cards to do > some of the initialization still won't work though if it's > "PC firmware". Typical examples of the latter are ATA and > graphics controllers. In theory there are some ways one > can make them work anyway but that would be quite some > work to do if at all feasible. Aha. Good to know. >> fwohci0: mem >> 0x4008000-0x40087ff,0x400c000-0x400ff >> ff at device 4.0 on pci0 >> fwohci0: [ITHREAD] >> fwohci0: OHCI version 1.0 (ROM=1) >> fwohci0: No. of Isochronous channels is 4. >> fwohci0: EUI64 00:10:74:60:00:00:ee:a9 >> panic: pcib: PCI bus B error AFAR 0x1ff840080ec AFSR 0x4000f00000000000 >> cpuid = 0 >> KDB: enter: panic >> [thread pid 0 tid 100000 ] >> Stopped at kdb_enter+0x80: ta %xcc, 1 >> db> bt >> Tracing pid 0 tid 100000 td 0xc08ad870 >> panic() at panic+0x20c >> psycho_pci_bus() at psycho_pci_bus+0x88 >> intr_event_handle() at intr_event_handle+0x5c >> intr_execute_handlers() at intr_execute_handlers+0x14 >> intr_fast() at intr_fast+0x68 >> -- interrupt level=0xd pil=0 %o7=0xc0659be4 -- >> -- data access error %o7=0x32a -- >> fwphy_rddata() at fwphy_rddata+0xe8 >> fwohci_reset() at fwohci_reset+0x298 >> fwohci_init() at fwohci_init+0x9f8 >> fwohci_pci_attach() at fwohci_pci_attach+0x278 >> device_attach() at device_attach+0x4a4 > > PCI AFSR 0x4000000000000000 indicates that the primary error > was a target abort. Given that no DMA is involved at this stage > this means it actually was the OHCI chip which complained > about the PIO access. If this is the first access after the > reset (check with "l *(0xc0659be4)", "l *(fwphy_rddata+0xe8)" > and "l *(fwohci_reset+0x298)" in gdb on the corresponding > kernel.debug what code is actually involved) I'd suspect > the problem to be a combination of a sloppy driver with a > chip that takes some more time than the other contenders > to get ready again after a reset, i.e. fwohci_reset() only > tries 100 times with waiting one millisecond between tries > for OHCI_HCC_RESET to clear after the reset (the latter part > is in line with the OHCI specification). Increasing to f.e. > 1000 tries should solve the panic then, if this is actually > the cause. Generally fwohci(4) should be changed to fail if > the chip doesn't become ready again after a reset instead > of just ignoring that problem though. At least fwohci_reset() > (there are probably more such functions in fwohci(4)) also > seems to miss some bus space barriers, which also could be > the cause of this panic. I increased the for counter to 1000 in fwohci_reset(). while(OREAD(sc, OHCI_HCCCTL) & OHCI_HCC_RESET) { - if (i++ > 100) break; + if (i++ > 1000) break; DELAY(1000); } This did not help so far. I also tried to check the addresses you mentioned with l *(0xXXXX) But here I miss some things. I guess I need to invoke gdb somehow? Thanks so far, I continue playing :) Andreas Having the firewire debug on (hardcoded) Gives the below. You see that the rest loop terminates: fwohci0: resetting OHCI...done (loop=0) u60# kldload firewire fwohci0: mem 0x4008000-0x40087ff,0x400c000-0x400ff ff at device 4.0 on pci0 fwohci0: latency timer 24 -> 32. fwohci0: cache size 16 -> 16. fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:10:74:60:00:00:ee:a9 fwohci0: resetting OHCI...done (loop=0) panic: pcib: PCI bus B error AFAR 0x1ff840080ec AFSR 0x4000f00000000000 cpuid = 0 KDB: stack backtrace: panic() at 0xc03361a8 = panic+0x1c8 psycho_pci_bus() at 0xc0628848 = psycho_pci_bus+0x88 intr_event_handle() at 0xc030be7c = intr_event_handle+0x5c intr_execute_handlers() at 0xc0638fb4 = intr_execute_handlers+0x14 intr_fast() at 0xc0081328 = intr_fast+0x68 -- interrupt level=0xd pil=0 %o7=0xc0372920 -- -- data access error %o7=0xc0895000 -- fwphy_rddata() at 0xc0ef8b60 = fwphy_rddata+0x120 fwohci_reset() at 0xc0efb9d8 = fwohci_reset+0x1d8 fwohci_init() at 0xc0efcb54 = fwohci_init+0x9d4 fwohci_pci_attach() at 0xc0eff0f8 = fwohci_pci_attach+0x278 device_attach() at 0xc0366544 = device_attach+0x4a4 device_probe_and_attach() at 0xc03674a4 = device_probe_and_attach+0x64 pci_driver_added() at 0xc021c054 = pci_driver_added+0x154 devclass_driver_added() at 0xc0363bb4 = devclass_driver_added+0x74 devclass_add_driver() at 0xc03648a8 = devclass_add_driver+0xa8 driver_module_handler() at 0xc0365fd8 = driver_module_handler+0x58 module_register_init() at 0xc032223c = module_register_init+0xdc linker_load_module() at 0xc0317994 = linker_load_module+0xbd4 kern_kldload() at 0xc0317f58 = kern_kldload+0xb8 kldload() at 0xc03180e0 = kldload+0x60 syscall() at 0xc064a2f0 = syscall+0x2f0 -- syscall (304, FreeBSD ELF64, kldload) %o7=0x1008e0 -- userland() at 0x4045b708 user trace: trap %o7=0x1008e0 pc 0x4045b708, sp 0x7fdffffe1e1 pc 0x1006f0, sp 0x7fdffffe2a1 pc 0x40206934, sp 0x7fdffffe361 done KDB: enter: panic [thread pid 1305 tid 100066 ] Stopped at 0xc036dd20 = kdb_enter+0x80: ta %xcc, 1 From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 30 11:07:00 2009 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8D841065674 for ; Mon, 30 Mar 2009 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B417D8FC22 for ; Mon, 30 Mar 2009 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2UB70Gf054908 for ; Mon, 30 Mar 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2UB707j054904 for freebsd-sparc64@FreeBSD.org; Mon, 30 Mar 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Mar 2009 11:07:00 GMT Message-Id: <200903301107.n2UB707j054904@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 11:07:01 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f sparc/127051 sparc64 [hme] hme interfaces "pause" with the message "device o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg o sparc/119240 sparc64 top has WCPU over 100% on UP system s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/119017 sparc64 [install] 7.0 Beta won't install on U60 o sparc/113556 sparc64 [panic] trap: memory address not aligned; Rebooting... f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 [hang] system is hung during boot from CD f sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations f sparc/105157 sparc64 No reply to ping on Sparc64 o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 15 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 30 19:12:55 2009 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B184B1065670 for ; Mon, 30 Mar 2009 19:12:55 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 594308FC16 for ; Mon, 30 Mar 2009 19:12:55 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n2UJCdBG002093; Mon, 30 Mar 2009 21:12:40 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n2UJCdXu002092; Mon, 30 Mar 2009 21:12:39 +0200 (CEST) (envelope-from marius) Date: Mon, 30 Mar 2009 21:12:39 +0200 From: Marius Strobl To: Andreas Tobler Message-ID: <20090330191239.GA74661@alchemy.franken.de> References: <49CD39B7.3050500@nexus-ag.com> <20090328214138.GA93149@alchemy.franken.de> <49CFBAC6.5030809@fgznet.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49CFBAC6.5030809@fgznet.ch> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: kernel panic with firewire PCI card X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 19:12:56 -0000 On Sun, Mar 29, 2009 at 08:15:34PM +0200, Andreas Tobler wrote: > Marius Strobl wrote: > > > >PCI AFSR 0x4000000000000000 indicates that the primary error > >was a target abort. Given that no DMA is involved at this stage > >this means it actually was the OHCI chip which complained > >about the PIO access. If this is the first access after the > >reset (check with "l *(0xc0659be4)", "l *(fwphy_rddata+0xe8)" > >and "l *(fwohci_reset+0x298)" in gdb on the corresponding > >kernel.debug what code is actually involved) I'd suspect > >the problem to be a combination of a sloppy driver with a > >chip that takes some more time than the other contenders > >to get ready again after a reset, i.e. fwohci_reset() only > >tries 100 times with waiting one millisecond between tries > >for OHCI_HCC_RESET to clear after the reset (the latter part > >is in line with the OHCI specification). Increasing to f.e. > >1000 tries should solve the panic then, if this is actually > >the cause. Generally fwohci(4) should be changed to fail if > >the chip doesn't become ready again after a reset instead > >of just ignoring that problem though. At least fwohci_reset() > >(there are probably more such functions in fwohci(4)) also > >seems to miss some bus space barriers, which also could be > >the cause of this panic. > > I increased the for counter to 1000 in fwohci_reset(). > > while(OREAD(sc, OHCI_HCCCTL) & OHCI_HCC_RESET) { > - if (i++ > 100) break; > + if (i++ > 1000) break; > DELAY(1000); > } > > This did not help so far. Okay, this was my best guess based on the information available, sorry. > > I also tried to check the addresses you mentioned with l *(0xXXXX) > But here I miss some things. I guess I need to invoke gdb somehow? Yes, simply `gdb /path/to/kernel.debug` You might also want to bug firewire@ and simokawa@ regarding this. > > > Thanks so far, I continue playing :) > > Andreas > > > Having the firewire debug on (hardcoded) Gives the below. > > You see that the rest loop terminates: > fwohci0: resetting OHCI...done (loop=0) > > u60# kldload firewire > fwohci0: mem > 0x4008000-0x40087ff,0x400c000-0x400ff > ff at device 4.0 on pci0 > fwohci0: latency timer 24 -> 32. > fwohci0: cache size 16 -> 16. > fwohci0: [ITHREAD] > fwohci0: OHCI version 1.0 (ROM=1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:10:74:60:00:00:ee:a9 > fwohci0: resetting OHCI...done (loop=0) > panic: pcib: PCI bus B error AFAR 0x1ff840080ec AFSR 0x4000f00000000000 > cpuid = 0 > KDB: stack backtrace: > panic() at 0xc03361a8 = panic+0x1c8 > psycho_pci_bus() at 0xc0628848 = psycho_pci_bus+0x88 > intr_event_handle() at 0xc030be7c = intr_event_handle+0x5c > intr_execute_handlers() at 0xc0638fb4 = intr_execute_handlers+0x14 > intr_fast() at 0xc0081328 = intr_fast+0x68 > -- interrupt level=0xd pil=0 %o7=0xc0372920 -- > -- data access error %o7=0xc0895000 -- > fwphy_rddata() at 0xc0ef8b60 = fwphy_rddata+0x120 > fwohci_reset() at 0xc0efb9d8 = fwohci_reset+0x1d8 > fwohci_init() at 0xc0efcb54 = fwohci_init+0x9d4 > fwohci_pci_attach() at 0xc0eff0f8 = fwohci_pci_attach+0x278 > device_attach() at 0xc0366544 = device_attach+0x4a4 > device_probe_and_attach() at 0xc03674a4 = device_probe_and_attach+0x64 > pci_driver_added() at 0xc021c054 = pci_driver_added+0x154 > devclass_driver_added() at 0xc0363bb4 = devclass_driver_added+0x74 > devclass_add_driver() at 0xc03648a8 = devclass_add_driver+0xa8 > driver_module_handler() at 0xc0365fd8 = driver_module_handler+0x58 > module_register_init() at 0xc032223c = module_register_init+0xdc > linker_load_module() at 0xc0317994 = linker_load_module+0xbd4 > kern_kldload() at 0xc0317f58 = kern_kldload+0xb8 > kldload() at 0xc03180e0 = kldload+0x60 > syscall() at 0xc064a2f0 = syscall+0x2f0 > -- syscall (304, FreeBSD ELF64, kldload) %o7=0x1008e0 -- > userland() at 0x4045b708 > user trace: trap %o7=0x1008e0 > pc 0x4045b708, sp 0x7fdffffe1e1 > pc 0x1006f0, sp 0x7fdffffe2a1 > pc 0x40206934, sp 0x7fdffffe361 > done > KDB: enter: panic > [thread pid 1305 tid 100066 ] > Stopped at 0xc036dd20 = kdb_enter+0x80: ta %xcc, 1 Marius From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 30 19:43:53 2009 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B067A106564A for ; Mon, 30 Mar 2009 19:43:53 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 455928FC17 for ; Mon, 30 Mar 2009 19:43:52 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n2UJhplW062144; Mon, 30 Mar 2009 21:43:51 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n2UJhpdO062143; Mon, 30 Mar 2009 21:43:51 +0200 (CEST) (envelope-from marius) Date: Mon, 30 Mar 2009 21:43:51 +0200 From: Marius Strobl To: Miles Nordin Message-ID: <20090330194350.GA2097@alchemy.franken.de> References: <49CD39B7.3050500@nexus-ag.com> <20090328214138.GA93149@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: kernel panic with firewire PCI card X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 19:43:53 -0000 On Sun, Mar 29, 2009 at 12:05:55PM -0400, Miles Nordin wrote: > >>>>> "ms" == Marius Strobl writes: > > ms> In theory there are some ways one can make them > ms> work anyway but that would be quite some work to do if at all > ms> feasible. > > see uvesafb in linux for possible starting point This is one of the approaches I meant, with the XFree86/X.Org int10 module being a similar one but with a way less problematic license. Anyway, getting non-FCode/Sun graphics cards to work would be lots of work IMO better spent on improving the support for the "native" cards. Marius From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 30 19:49:31 2009 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 160CD1065745 for ; Mon, 30 Mar 2009 19:49:31 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 9F50B8FC0C for ; Mon, 30 Mar 2009 19:49:30 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n2UJnQtA049478; Mon, 30 Mar 2009 21:49:27 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <49D12246.3080905@fgznet.ch> Date: Mon, 30 Mar 2009 21:49:26 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Marius Strobl References: <49CD39B7.3050500@nexus-ag.com> <20090328214138.GA93149@alchemy.franken.de> <49CFBAC6.5030809@fgznet.ch> <20090330191239.GA74661@alchemy.franken.de> In-Reply-To: <20090330191239.GA74661@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-sparc64@freebsd.org Subject: Re: kernel panic with firewire PCI card X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 19:49:31 -0000 Marius Strobl wrote: > On Sun, Mar 29, 2009 at 08:15:34PM +0200, Andreas Tobler wrote: >> Marius Strobl wrote: >>> PCI AFSR 0x4000000000000000 indicates that the primary error >>> was a target abort. Given that no DMA is involved at this stage >>> this means it actually was the OHCI chip which complained >>> about the PIO access. If this is the first access after the >>> reset (check with "l *(0xc0659be4)", "l *(fwphy_rddata+0xe8)" >>> and "l *(fwohci_reset+0x298)" in gdb on the corresponding >>> kernel.debug what code is actually involved) I'd suspect >>> the problem to be a combination of a sloppy driver with a >>> chip that takes some more time than the other contenders >>> to get ready again after a reset, i.e. fwohci_reset() only >>> tries 100 times with waiting one millisecond between tries >>> for OHCI_HCC_RESET to clear after the reset (the latter part >>> is in line with the OHCI specification). Increasing to f.e. >>> 1000 tries should solve the panic then, if this is actually >>> the cause. Generally fwohci(4) should be changed to fail if >>> the chip doesn't become ready again after a reset instead >>> of just ignoring that problem though. At least fwohci_reset() >>> (there are probably more such functions in fwohci(4)) also >>> seems to miss some bus space barriers, which also could be >>> the cause of this panic. >> I increased the for counter to 1000 in fwohci_reset(). >> >> while(OREAD(sc, OHCI_HCCCTL) & OHCI_HCC_RESET) { >> - if (i++ > 100) break; >> + if (i++ > 1000) break; >> DELAY(1000); >> } >> >> This did not help so far. > > Okay, this was my best guess based on the information > available, sorry. What? No sorry, thank you! The advice from you helped me to get some more into the deepness of FreeBSD. I was unhappy with modifying the source and always have to power-off to remove the card to install a new kernel. I learned how to build a kernel with modules only support. IOW, I learned how to configure and build a kernel with firewire support in module only. Now I can boot and install new kernels w/o plugin/off the card. I see the positiv aspect here :) And feedback form the list is very much appreciated! Writing in direction of /dev/null is very frustrating. Getting a feedback with an advice helps here a lot! Even if the advice does not give the expected results. But it is a feedback. Thanks! > >> I also tried to check the addresses you mentioned with l *(0xXXXX) >> But here I miss some things. I guess I need to invoke gdb somehow? > > Yes, simply `gdb /path/to/kernel.debug` Heh, that only works when the gdb host target is from the same arch as the debugging target, right? Unfortunately I build all (except ports) on a MacBook Pro VM (amd64) instance and install it on my Mac and Sparc. There is no second Sparc available. > You might also want to bug firewire@ and simokawa@ regarding this. I guess so since on my iMac (G3) fw support is broken also since r187993. But the previous revision does not help here on sparc64. Another issue. Thanks! Andreas From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 30 23:03:19 2009 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 459A91065674 for ; Mon, 30 Mar 2009 23:03:19 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from sakima.Ivy.NET (sakima.Ivy.NET [IPv6:2610:1f8:dc:41:220:edff:fe27:e764]) by mx1.freebsd.org (Postfix) with ESMTP id C52EE8FC15 for ; Mon, 30 Mar 2009 23:03:17 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [IPv6:2610:1f8:dc:c0::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id 36D1BA8093 for ; Mon, 30 Mar 2009 19:03:16 -0400 (EDT) Received: by castrovalva.Ivy.NET (Postfix, from userid 405) id AEC0112FD0D; Mon, 30 Mar 2009 19:03:15 -0400 (EDT) To: freebsd-sparc64@freebsd.org References: <49CD39B7.3050500@nexus-ag.com> <20090328214138.GA93149@alchemy.franken.de> <20090330194350.GA2097@alchemy.franken.de> From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Mon_Mar_30_19:03:15_2009-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 30 Mar 2009 19:03:15 -0400 In-Reply-To: <20090330194350.GA2097@alchemy.franken.de> (Marius Strobl's message of "Mon, 30 Mar 2009 21:43:51 +0200") Message-ID: User-Agent: T-gnus/6.17.2 (based on No Gnus v0.2) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (alpha--netbsd) MULE/5.0 (SAKAKI) Subject: Re: kernel panic with firewire PCI card X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 23:03:20 -0000 --pgp-sign-Multipart_Mon_Mar_30_19:03:15_2009-1 Content-Type: text/plain; charset=US-ASCII >>>>> "ms" == Marius Strobl writes: ms> getting non-FCode/Sun graphics cards to work would be lots of ms> work IMO better spent on improving the support for the ms> "native" cards. native cards are silly/doomed. Their 3D is too slow to be worth supporting, there is no documentation for setting custom timings, they have no panel-friendly digital output, and even in analog they cannot push the resolutions attainable on relatively inexpensive modern monitors. creator3D is probably among the best and maxes at 1080p which is now the cheapest monitor you can buy within reason. You will struggle to find any new monitor that can be driven by a native card without pixel-scaling. unfortunately there is not much point supporting modern cards either since all but the most exotic are PCIe, and AIUI we don't run well on any PCIe sparc64 equipment, and secondly the Linux folk have caved in and failed to negotiate quality open-source drivers for any modern card so even if you could bring up the card on the bus you would have no Xorg .so to work with it---it's a miracle for them just to get amd64 blobs with all the compliant groveling they do. the approach is uniquely useful for video cards since it means you can rely on VESA and leave the timing configuration job in proprietary software instead of getting documentatino for it, just as you do with the FCode cards, which seems to be what motivated uvesafb (they do not just initialize the card but keep their VM around constantly). HOWEVER, a genericized uvesafb that worked with more than just framebuffers would be extremely useful for all sorts of things, even on native i386. It is not only a way to solve an immediate problem but a puzzle-piece for new device architectures. For example if we had something like Linux's PCI hotplug, we could hot-unplug a RAID card shackled with proprietary firmware, run the RAID configurator built into its BIOS, and then hot-plugin the card and reprobe its LUN's from freebsd. all over ssh. the peecee platform will always dominate the market for PCI cards, yet PCI busses will always be available on all kinds of notPeeCee equipment. Until EFI takes over on $cheapCPU, a way to safely run crappy proprietary BIOS addon ROMs inside a virtual machine with 1 VM per card, will remain useful all over the place not just in X11. As you said yourself it's already a de-facto requirement for full PCI support. EFI is also AIUI a native-code platform, so much of the VM would be needed even after such a migration, the same way a ppc VM is needed to really run the FCode on these speculated crappy Mac cards you mention that just use F bytecode to jump to ppc machinecode. --pgp-sign-Multipart_Mon_Mar_30_19:03:15_2009-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUASdFPs4nCBbTaW/4dAQKo/wP/T4TwifbIFamVkofI3wbcxLFUN5hulyiV mNVEfiXLLIg/uVFsZ23SFc4kexVR+sG+ZEUbbxLTKpEOgtEV5mtGJZdbiUNemCZ+ LQS5e+AtLzjfpYBrc1WmmKqHXa7wdlcXPovtLdTIc5WnfR4TyUE7bfJsxNyoqlir p2CsHvf31xs= =0eEh -----END PGP SIGNATURE----- --pgp-sign-Multipart_Mon_Mar_30_19:03:15_2009-1-- From owner-freebsd-sparc64@FreeBSD.ORG Sat Apr 4 04:46:29 2009 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4E37106566C for ; Sat, 4 Apr 2009 04:46:29 +0000 (UTC) (envelope-from yashy@yashy.com) Received: from proksie.yashy.com (mail.improfessional.com [24.68.32.17]) by mx1.freebsd.org (Postfix) with ESMTP id 9717C8FC0C for ; Sat, 4 Apr 2009 04:46:29 +0000 (UTC) (envelope-from yashy@yashy.com) Received: from [192.168.1.11] (delly.home [192.168.1.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proksie.yashy.com (Postfix) with ESMTPSA id 4151B5C1B for ; Fri, 3 Apr 2009 21:28:48 -0700 (PDT) Message-ID: <49D6E20A.3060207@yashy.com> Date: Fri, 03 Apr 2009 21:28:58 -0700 From: Yasholomew Yashinski User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: debugging hme0 issue X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 04:46:30 -0000 I'm downloading around 15 torrents: # pfctl -ss | wc -l No ALTQ support in kernel ALTQ related functions disabled 5805 I have ktorrent set to 800 connections max globally, so I'm not sure why so many states, even after I did pcftl -Fs it has went back to almost 6000. I'm not sure if all of this is a red herring. All I know is I keep losing connectivity. The only way to resolve things is: # ifconfig hme0 down && ifconfig hme0 up It started a few hours ago, and I'm now doing this every few minutes. This Ultra10 has been in use ~15 years, it's been up for months, I've downloaded torrents many times before, this is the first time I've ever had such an issue. Any help on how to debug this would be appreciated. # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll hme0 1500 08:00:20:de:af:01 223253211 0 58568655 1 20494 hme0 1500 24.68.32/22 yashy.com 3449717 - 33280781 - - (The 20494 collisions has not changed in an hour) hme0: flags=8843 mtu 1500 options=b inet yashy.com netmask 0xfffffc00 broadcast 24.68.35.255 ether 08:00:20:de:af:01 media: Ethernet autoselect (100baseTX ) status: active Thanks in advance, -- Yashy