Date: Tue, 15 Apr 2008 14:28:17 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@FreeBSD.org> To: Niclas Zeising <niclas.zeising@gmail.com> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ata ata-all.h ata-chipset.c ata-dma.c ata-lowlevel.c Message-ID: <1DFDA463-5E5E-4EE5-BF2D-E738D10E57F7@FreeBSD.org> In-Reply-To: <4803D34C.4030706@gmail.com> References: <200804141834.m3EIYOXP044870@repoman.freebsd.org> <4803D34C.4030706@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Thats actually a separate problem. I've put in stops to check that the =20= PRD table size doesn't get out of hand. Until now that wasn't a =20 problem but now that we move to having more than on request flying pr =20= channel it needs to be within bounds. The check correctly panic's as we outgrow the table, however thats not =20= very usefull :) Fix coming up with the next round of updates, I also need to go back =20 to the old way of preallocing the SG tables etc, busdma is simply too =20= cycle greedy to be called for each request, as performance has been =20 shown to decrease quite a bit. -S=F8ren On 14Apr, 2008, at 23:57 , Niclas Zeising wrote: > S=F8ren Schmidt wrote: >> sos 2008-04-14 18:34:24 UTC >> FreeBSD src repository >> Modified files: >> sys/dev/ata ata-all.h ata-chipset.c ata-=20 >> dma.c ata-lowlevel.c Log: >> Fix problem with slave devices. >> Fix or rather bring ENOMEM problems back to the state it was before. >> Temporarily disable PortMultipliers on AHCI devices. >> Revision Changes Path >> 1.132 +1 -1 src/sys/dev/ata/ata-all.h >> 1.216 +4 -3 src/sys/dev/ata/ata-chipset.c >> 1.153 +4 -4 src/sys/dev/ata/ata-dma.c >> 1.82 +7 -8 src/sys/dev/ata/ata-lowlevel.c > > > Hi! > I still have problems with my install blowing up with the panic =20 > message "to many DMA segment entries". I haven't tried this last =20 > change though. > Unfortunately I can't send a decent backtrace since doing "call =20 > doadump" fom ddb only makes the machine panic again. > > The panic occurs when trying to do a installworld, probably because =20= > of high disc I/O. The march snapshot doesn't inhibit this problem. I =20= > can at least do a cvsup followed by a buildworld and make kernel. > The harddrive is a 114473MB Hitachi SATA150 drive, in my system on =20 > ad8 (ata4-master). The bios runs sata in native mode. The controller =20= > is an Intel AHCI controller. I've compiled a custom kernel (removed =20= > raid and scsi devices I don't use, along with ethernet devices I =20 > don't use, and added sound device and crypto device as well as =20 > GEOM_ELI and GEOM_BDE. Also removed some compat options. Everything =20= > is compiled with standard options except cputype?=3Dcore2. > The machine runs amd64. > > The following is the hand-transcribed backtrace from the panic: > > panic: too many DMA segment entries > > cpuid =3D 1 > KDB: stack backtrace: > db_trace_self_wrappoer() at db_trace_self_wrapper+0x2a > panic() at panic+0x173 > ata_setup_interrupt at ata_setup_interrupt > bus_dmamap_load() at ata_dmaload+0x17e > ata_ahci_begin_transaction() at ata_ahci_begin_transaction+0x1f9 > ata_start() at ata_start+0x1a4 > g_io_schedule_up() at g_io_schedule_up+0x4d > g_up_procvody() at g_up_procbody+0x6f > fork_exit() at fork_exit+0x12a > fork_trampoline at fork_trampoline+0xe > --- trap 0, rip =3D 0 rsp =3D 0xffffffffab899d30, rbp =3D 0 --- > KDB: enter: panic > [thread pid 3 tid 100009 ] > Stopped at kdb_enter+0x3d: movq $0,0x4060f6(%rip) > db> show locs > exclusive sleep mutex ATA state lock r =3D 0 (0xffffff000130a78) =20 > locked @ /usr/src/sys/dev/ata/ata-queue.c:192 > exclusive sleep mutex ATA queue lock r =3D 0 (0xffffff0001303ab0 =20 > locked @ /usr/src/sys/dev/ata/ata-queue.c:175 > > Then I try 'call doadump' and get the following panic. Don't know if =20= > it's because of the earlier one or if it's another bug. Probably the =20= > former, but I include the transcription anyway. > > db> call doadump > Physical memory: 1998MB > Dumping 132MB:panic: _mtx_lock_sleep: recursed on non-recursive =20 > mutex ATA queue lock @ /usr/src/sys/dev/ata/ata-queue.c:86 > > cpuid =3D 1 > KDB: stack backtrace: > db_trace_self_wrapper at db_trace_self_wrapper+0x2a > mi_switch() at mi_switch+0x363 > sched_bind() at sched_bind+0x78 > boot() at boot+0x3f > panic() at panic+0x15d > _mtx_lock_flags() at _mtx_lock_flags > _mtx_lock_flags() at _mtx_lock_flags+0xc0 > ata_queue_request() at ata_queue_request+0x9a > ad_dump() at ad_dump+0x90 > minidumpsys() at minidumpsys+0x23 > dumpsys() at dumpsys+0x23 > doadump() at doadump()+0x49 > db_fncall() at db_fncall+0x88 > db_command() at db_command+0x1eb > db_command_loop() at db_command_loop+0x50 > db_trap() at db_trap+0x87 > kdb_trap() at kdb_trap+0x82 > trap() at trap+0x159 > calltrap() at calltrap+0x8 > --- trap 0x3, rip =3D 0xffffffff80305aaf, rsp =3D 0xffffffffab899940, =20= > rbp =3D 0xffffffffab099960 --- > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x16c > ata_setup_interrupt() at ata_setup_interrupt > bus_dmamap_load() at bus_dmamap_load+0x353 > ata_dmaload() at ata_dmaload+0x17e > ata_ahci_begin_transaction() at ata_ahci_begin_transaction+0x1f9 > ata_start() at ata_start+0x1a4 > g_io_schedule_up() at g_io_schedule_up+0x4d > g_up_procbody() at g_up_procbody+0x6f > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffffffab899d30, rbp =3D 0 --- > > That's pretty much all I can get for now. Tell me if you need more =20 > information. > > Regards! > Niclas Zeising >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1DFDA463-5E5E-4EE5-BF2D-E738D10E57F7>