Date: Sat, 16 Sep 2006 15:16:51 +0100 From: "Joao Barros" <joao.barros@gmail.com> To: current@freebsd.org, stable@freebsd.org, Chris <devnullaccount@yahoo.se>, "=?ISO-8859-1?Q?S=F8ren_Schmidt?=" <sos@deepcore.dk> Subject: panic: integer divide fault on 6.1 Message-ID: <70e8236f0609160716y56f2a8a6lfabc60966feb1a43@mail.gmail.com> In-Reply-To: <70e8236f0609141204k57cc16e8v640a692783cdbb77@mail.gmail.com> References: <70e8236f0609090456l31cb39d8if9bdf2d664886a13@mail.gmail.com> <200609091907.06716.max@love2party.net> <70e8236f0609091302i1c98f8f7t6ad32cd602b054c@mail.gmail.com> <20060909200549.GA66552@xor.obsecurity.org> <70e8236f0609100842v2d10408blca90b966a1f5ff7@mail.gmail.com> <45043A4F.3010308@errno.com> <70e8236f0609121614h7457f75cufcd232555e0ae5c@mail.gmail.com> <4507A35B.6080205@deepcore.dk> <70e8236f0609130336q66d426dcwa11cede423bcc6f0@mail.gmail.com> <70e8236f0609141204k57cc16e8v640a692783cdbb77@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all, I was contacted by Chris who had the same problem. Since I didn't follow up on my problem he asked me if it was solved and indeed it was solved by S=F8ren and the fix has been committed to CURRENT: http://lists.freebsd.org/pipermail/cvs-all/2006-September/188353.html I'm hoping this gets MFC'ed in time for 6.2 My conversation with S=F8ren is bellow: ---------- Forwarded message ---------- From: Joao Barros <joao.barros@gmail.com> Date: Sep 14, 2006 8:04 PM Subject: Re: Fwd: panic: integer divide fault on 6.1 To: S=F8ren Schmidt <sos@deepcore.dk> On 9/13/06, Joao Barros <joao.barros@gmail.com> wrote: > On 9/13/06, S=F8ren Schmidt <sos@deepcore.dk> wrote: > > Joao Barros wrote: > > > ---------- Forwarded message ---------- > > > From: Sam Leffler <sam@errno.com> > > > Date: Sep 10, 2006 5:16 PM > > > Subject: Re: panic: integer divide fault on 6.1 > > > To: Joao Barros <joao.barros@gmail.com> > > > Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Kris > > > Kennaway <kris@obsecurity.org> > > > > > > > > > Joao Barros wrote: > > >> On 9/9/06, Kris Kennaway <kris@obsecurity.org> wrote: > > >>> On Sat, Sep 09, 2006 at 09:02:35PM +0100, Joao Barros wrote: > > >>> > On 9/9/06, Max Laier <max@love2party.net> wrote: > > >>> > > > > >>> > >Can you try to get a dump, trace, or at least figure out which > > >>> function > > >>> > >the IP is refering to? > > >>> > > > > >>> > > > >>> > Well, the problem only occurs when I boot from the disk and the > > >>> > installed kernel doesn't have debug support. > > >>> > Does 'set dumpdev=3D' work from the boot loader? I tried some > > >>> > combinations with no success. > > >>> > > >>> No. > > >>> > > >>> > I can try and install a 6-STABLE snapshot if there's no way of > > >>> getting > > >>> > the info needed. > > >>> > > >>> You can either try to install a new kernel with DDB support, or fol= low > > >>> the "instruction pointer" method in the developers handbook chapter= on > > >>> kernel debugging. > > >> > > >> I copied a CURRENT kernel from a 200608 snapshot and the problem als= o > > >> occurs thus I'm adding current@. > > >> My current laptop doesn't have a serial port so I'm copying this by > > >> hand: > > >> > > >> Fatal trap 18: integer divide fault while in kernel mode > > >> cpuid =3D 0; apic id =3D 00 > > >> instruction pointer =3D 0x20:0xc08a1fb7 > > >> stack pointer =3D 0x28:0xc0c20b14 > > >> frame pointer =3D 0x28:0xc0c20b9c > > >> code segment =3D base 0x0, limit 0xfffff, type 0x1b > > >> =3D DPL 0, pres 1, def32 1, gran 1 > > >> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > >> current process =3D 0 (swapper) > > >> [thread pid 0 tid 0 ] > > >> Stopped at __qdivrem+0x3b: divl %ecx,%eax > > >> > > >> db> bt > > >> Tracing pid 0 tid0 td 0xc0a0c818 > > >> __qdivrem(37fdfa0,0,0,0,0,...) at __qdivrem+0x3b > > >> __udivdi3(37fdfa0,0,0,0) at __udivdi3+0x16 > > >> ata_raid_promise_read_meta(c37a5000,c09f4a80,1,8086,c37a5000,...) at > > >> ata_raid_promise_read_meta+0x9b > > >> ata_raid_read_metadata(c37a5000,c37a5000,c0c20c70,c06b58a4,c37a5000,= ...) > > >> at ata_raid_metadata+0x2be > > >> ata_raid_subdisk_attach(c37a5000) at ata_raid_subdisk_attach+0x33 > > >> device_attach(c37a5000,c37a5180,c37a5000,c36885c0,0,...) at > > >> device_attach+0x58 > > >> device_probe_and_attach(c37a5200,c37a5200,c08ec9a9,0,c37a5180,...) a= t > > >> bus_generic_attach+0x16 > > >> ad_attach(c37a5200) at ad_attach+0x2c8 > > >> device_attach(c37a5200,c095f2d0,c37a5200,0,c368d800,...) at > > >> device_attach+0x58 > > >> device_probe_and_attach(c37a5200) at device_probe_and_atach+0xe0 > > >> bus_generic_attach(c3659080,c3659080,ffffffff,0,c37a5200,...) at > > >> bus_generic_attach+0x16 > > >> ata_identify(c3659080) at ata_identify+0x1c8 > > >> ata_boot_attach(0xc0a11d80,0,c09212e7,47,...) at ata_boot_attach+0x3= e > > >> run_interrupt_drive_config_hooks(0,c1ec00,c1e000,0,c0451065,...) at > > >> run_interrupt_drive_config_hooks+0x43 > > >> mi_startup() at mi_startup+0x96 > > >> begin() at begin+0x2c > > >> > > >> This board has a Promise SATA raid controller and it is disabled in > > >> the BIOS. I even tried disabling it through a jumper but it still > > >> stops. > > >> > > > > > > In sys/dev/ata/ata-raid.h the PROMISE_LBA macro does an unchecked > > > calculation that apparently can divide by zero. Soren would likely > > > understand the root cause of this problem but until then you can patc= h > > > the driver to workaround the problem. > > > > > > Sam > > > > > > > > > Hi S=F8ren, > > > > > > I don't know if you bumped into this thread but this should definitel= y > > > be fixed. > > > Do you want me to open a PR? > > > > > Hmm, the problem seems to be that the geometry thats gotten from the > > disk has (all) zero's in it, which we cannot handle. > > Its most likely because your BIOS put invalid or no current geometry > > info in the disks parameters page. > > > > If you are up to a little debugging, you could try this patch: > > > > diff -u -r1.189.2.4 ata-disk.c > > --- ata-disk.c 4 Apr 2006 16:07:42 -0000 1.189.2.4 > > +++ ata-disk.c 13 Sep 2006 06:18:59 -0000 > > @@ -97,7 +97,8 @@ > > } > > device_set_ivars(dev, adp); > > > > - if (atadev->param.atavalid & ATA_FLAG_54_58) { > > + if ((atadev->param.atavalid & ATA_FLAG_54_58) && > > + atadev->param.current_heads && atadev->param.current_sectors) { > > adp->heads =3D atadev->param.current_heads; > > adp->sectors =3D atadev->param.current_sectors; > > adp->total_secs =3D (u_int32_t)atadev->param.current_size_1 | > > > > > > -S=F8ren > > > > Sure, I'll test it when I get home later today and start building a > kernel on another machine that's currently off. > I'll give you feedback tomorrow. > Thanks, > > -- > Joao Barros > I'm happy to report that your patch did the trick. The machine happily boot a today's CURRENT+patch :) Tell me if you need to test something more. Thanks! -- Joao Barros
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70e8236f0609160716y56f2a8a6lfabc60966feb1a43>