cvs commit: src/sys/dev/ata ata-all.h ata-chipset.c ata-dma.c ata-lowlevel.c

Niclas Zeising niclas.zeising at gmail.com
Mon Apr 14 21:57:43 UTC 2008


Søren 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-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 message 
"to many DMA segment entries". I haven't tried this last change though.
Unfortunately I can't send a decent backtrace since doing "call doadump" 
fom ddb only makes the machine panic again.

The panic occurs when trying to do a installworld, probably because of 
high disc I/O. The march snapshot doesn't inhibit this problem. I 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 ad8 
(ata4-master). The bios runs sata in native mode. The controller is an 
Intel AHCI controller. I've compiled a custom kernel (removed raid and 
scsi devices I don't use, along with ethernet devices I don't use, and 
added sound device and crypto device as well as GEOM_ELI and GEOM_BDE. 
Also removed some compat options. Everything is compiled with standard 
options except cputype?=core2.
The machine runs amd64.

The following is the hand-transcribed backtrace from the panic:

panic: too many DMA segment entries

cpuid = 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 = 0 rsp = 0xffffffffab899d30, rbp = 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 = 0 (0xffffff000130a78) locked @ 
/usr/src/sys/dev/ata/ata-queue.c:192
exclusive sleep mutex ATA queue lock r = 0 (0xffffff0001303ab0 locked @ 
/usr/src/sys/dev/ata/ata-queue.c:175

Then I try 'call doadump' and get the following panic. Don't know if 
it's because of the earlier one or if it's another bug. Probably the 
former, but I include the transcription anyway.

db> call doadump
Physical memory: 1998MB
Dumping 132MB:panic: _mtx_lock_sleep: recursed on non-recursive mutex 
ATA queue lock @ /usr/src/sys/dev/ata/ata-queue.c:86

cpuid = 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 = 0xffffffff80305aaf, rsp = 0xffffffffab899940, rbp = 
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 = 0, rsp = 0xffffffffab899d30, rbp = 0 ---

That's pretty much all I can get for now. Tell me if you need more 
information.

Regards!
Niclas Zeising


More information about the cvs-src mailing list