Date: Fri, 06 Aug 2004 15:31:06 -0700 From: Nate Lawson <nate@root.org> To: Radek Kozlowski <radek@raadradd.com> Cc: sos@deepcore.dk Subject: Re: Panic on boot with today's CURRENT, ata related Message-ID: <411406AA.3030607@root.org> In-Reply-To: <20040806221109.GC55186@werd> References: <4113EB2A.7060401@root.org> <20040806221109.GC55186@werd>
next in thread | previous in thread | raw e-mail | index | archive | help
Radek Kozlowski wrote: > On Fri, Aug 06, 2004 at 01:33:46PM -0700, Nate Lawson wrote: > >>I took a quick look at this ATA panic. The exact same one occurs for >>Ceri. A quick dissassemble shows that the testb is the check for the >>DMA flag at the very end of ata_generic_transaction(). The bug appears >>to be that this may be a PIO request (since the DMA check is outside the >>switch() statement). The fix is to make sure it's a DMA request before >>dereferencing an element of the DMA struct. Try the attached patch. > > > I applied your changes to ata-lowlevel.c revision 1.41 manually and they > seem to solve the issue--my system now boots succesfully, thank you. You're welcome. I committed the fix. > I would also like to point out that since around the beggining of June > the ad0 here no longer boots in UDMA100 mode but uses PIO4 instead > (http://lists.freebsd.org/pipermail/freebsd-current/2004-June/029434.html). > > Trying to change the transfer mode to UDMA100 using atacontrol results > in a panic. I don't know if this backtrace will be in any way useful but > here it goes: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x48 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0449391 > stack pointer = 0x10:0xd302dba0 > frame pointer = 0x10:0xd302dbd4 > 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 = 4 (g_down) > > (kgdb) bt > #0 doadump () at pcpu.h:159 > #1 0xc04427f5 in db_fncall (dummy1=0, dummy2=0, dummy3=3999, dummy4=0xd302d9ac " `q<C0>\f") > at /usr/src/sys/ddb/db_command.c:531 > #2 0xc0442572 in db_command (last_cmdp=0xc0715724, cmd_table=0x0, aux_cmd_tablep=0xc06e2d90, > aux_cmd_tablep_end=0xc06e2d94) at /usr/src/sys/ddb/db_command.c:349 > #3 0xc044267a in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 > #4 0xc0444695 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221 > #5 0xc052c057 in kdb_trap (type=0, code=0, tf=0xd302db60) at /usr/src/sys/kern/subr_kdb.c:401 > #6 0xc068e5c8 in trap_fatal (frame=0xd302db60, eva=0) at /usr/src/sys/i386/i386/trap.c:807 > #7 0xc068e2f3 in trap_pfault (frame=0xd302db60, usermode=0, eva=72) at /usr/src/sys/i386/i386/trap.c:730 > #8 0xc068de82 in trap (frame= > {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1047235072, tf_esi = -1045272284, tf_ebp = -754787372, tf_isp = -754787444, tf_ebx = -1 > 047235072, tf_edx = 0, tf_ecx = 9167, tf_eax = -1047234904, tf_trapno = 12, tf_err = 0, tf_eip = -1069247599, tf_cs = 8, tf_eflags = 66050, > tf_esp = -1047234904, tf_ss = -805982208}) at /usr/src/sys/i386/i386/trap.c:417 > #9 0xc0449391 in ata_generic_transaction (request=0xc1b26924) at /usr/src/sys/dev/ata/ata-lowlevel.c:144 > #10 0xc0448379 in ata_start (ch=0xc1947600) at /usr/src/sys/dev/ata/ata-queue.c:194 > #11 0xc0447f0c in ata_queue_request (request=0xc1b26924) at /usr/src/sys/dev/ata/ata-queue.c:91 > #12 0xc04595d8 in ad_start (atadev=0xc19476a8) at /usr/src/sys/dev/ata/ata-disk.c:310 > #13 0xc04481c8 in ata_start (ch=0xc1947600) at /usr/src/sys/dev/ata/ata-queue.c:168 > #14 0xc045922e in adstrategy (bp=0xc1e5f738) at /usr/src/sys/dev/ata/ata-disk.c:229 > #15 0xc04cf8f6 in g_disk_start (bp=0xc1b29e70) at /usr/src/sys/geom/geom_disk.c:277 > #16 0xc04d17c0 in g_io_schedule_down (tp=0xc188f000) at /usr/src/sys/geom/geom_io.c:365 > #17 0xc04d1b1e in g_down_procbody () at /usr/src/sys/geom/geom_kern.c:113 > #18 0xc04f4ed0 in fork_exit (callout=0xc04d1b00 <g_down_procbody>, arg=0x0, frame=0x0) > at /usr/src/sys/kern/kern_fork.c:819 It looks like the DMA object for the channel is not being initialized. However, that is in another path (this backtrace is just a symptom triggered by the first DMA access to the drive). Someone who knows more about the control path for going from PIO -> DMA mode will have to look into this. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?411406AA.3030607>