Date: Tue, 14 Jan 2003 21:30:36 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> To: Thomas Moestl <tmoestl@gmx.net> 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: <20030114211838.C2122-100000@localhost.my.domain> In-Reply-To: <20030112225517.GB278@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 i= s > > > 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 t= he > > 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. The _real_ cause of the breakage is likely in the code that has been changed and you may preferably look into it, in my opinion. G=E9rard. 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?20030114211838.C2122-100000>