Date: Tue, 14 Jan 2003 21:10:30 +0100 From: Thomas Moestl <tmoestl@gmx.net> To: =?iso-8859-1?Q?G=E9rard?= Roudier <groudier@free.fr> Cc: Roderick van Domburg <r.s.a.vandomburg@student.utwente.nl>, freebsd-sparc64@FreeBSD.ORG Subject: Re: panic: trap: fast data access mmu miss Message-ID: <20030114201030.GA947@crow.dom2ip.de> In-Reply-To: <20030114211838.C2122-100000@localhost.my.domain> References: <20030112225517.GB278@crow.dom2ip.de> <20030114211838.C2122-100000@localhost.my.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2003/01/14 at 21:30:36 +0100, Gérard Roudier wrote: > > > On Sun, 12 Jan 2003, Thomas Moestl wrote: > > > On Sun, 2003/01/12 at 16:13:20 +0100, Roderick van Domburg wrote: > > > > > Running on a Sun Enterprise 250 with a single UltraSparc-II > > > > > CPU, 512 MB RAM and three Fujitsu SCSI-II hard disks. I've had > > > > > this same problem with sources over the past few (three?) days. > > > > > I had to copy this dmesg by hand, so please bear with any > > > > > possible typos. > > > > > > > > Please try the attached diff. The crash was due to what I consider a > > > > driver bug (not checking the error in the bus_dmamap_load() callback), > > > > however due to the FreeBSD busdma API being largely undocumented it is > > > > a bit difficult to tell what should be considered legal. Much more > > > > problematic is to assume that the first segment's bus address will be > > > > 0 in the error case. This is not currently guaranteed by any > > > > implementation. > > > > > > > > The attached patch fixes that, and also passes a valid pointer to the > > > > callback for maximum compatability. It also fixes some other bugs I > > > > came across. > > > > > > > > This does however still not address the reason for the > > > > bus_dmamap_load() failure; I'm not really sure why this does > > > > happen. Please look for messages like: > > > > __sym_calloc2: failed to allocate ... > > > > and tell me if you see any of them. > > > > > > Thanks for the patches! Unfortunately however, it still doesn't seem to > > > attach sym1 quite right, I believe. Your patches did make the booting > > > process advance further, but the kernel failed to mount root. Here is the > > > dmesg, once again manually copied. That __sym_calloc2 message is right on > > > the second line. > > > > Hmmm, that's what I expected. Can you please try the attached patch > > instead? It adds some more error reporting, so I should be able to see > > what exactly is going wrong. Please mail me any new lines of output > > appearing directly above the __sym_calloc2 message. > > > > I think I've already ruled out most causes; I'm suspecting that > > malloc() might be failing due to massive use of M_NOWAIT in the > > related code. > > If less than 20K of memory is massive allocation, then your mail may well > come from twenty years ago IT age and I can only be dreaming at the > moment. :-) > > The driver fails during initialisation after having allocated less than > 20K in PAGE size chunk for the controller and probably less than 2 PAGES > if PAGE size is large. I was not refering to sym alone. The IOMMU code itself also uses M_NOWAIT to allocate DVMA memory and resource descriptors, and it's not unlikely that previosly intialized drivers have used it and drained the pool. The last round of updates increased the number of allocations the IOMMU code does, hence this suspicion (it turns out to be rather unlikely after reading some more allocator code though :) - Thomas -- Thomas Moestl <tmoestl@gmx.net> http://www.tu-bs.de/~y0015675/ <tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030114201030.GA947>