Re: panic: integer divide fault on 6.1

On 9/10/06, Sam Leffler <sam_at_errno.com> wrote:
> Joao Barros wrote:
> > On 9/9/06, Kris Kennaway <kris_at_obsecurity.org> wrote:
> >> On Sat, Sep 09, 2006 at 09:02:35PM +0100, Joao Barros wrote:
> >> > On 9/9/06, Max Laier <max_at_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=' 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 follow
> >> the "instruction pointer" method in the developers handbook chapter on
> >> kernel debugging.
> >
> > I copied a CURRENT kernel from a 200608 snapshot and the problem also
> > occurs thus I'm adding current_at_.
> > 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 = 0; apic id = 00
> > instruction pointer     = 0x20:0xc08a1fb7
> > stack pointer           = 0x28:0xc0c20b14
> > frame pointer           = 0x28:0xc0c20b9c
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                       = DPL 0, pres 1, def32 1, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 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,...) at
> > 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+0x3e
> > 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 patch
> the driver to workaround the problem.
>
>         Sam
>
>

Thanks for narrowing it down!

-- 
Joao Barros