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

[Søren Schmidt]

Hi

Thats actually a separate problem. I've put in stops to check that the  
PRD table size doesn't get out of hand. Until now that wasn't a  
problem but now that we move to having more than on request flying pr  
channel it needs to be within bounds.
The check correctly panic's as we outgrow the table, however thats not  
very usefull :)

Fix coming up with the next round of updates, I also need to go back  
to the old way of preallocing the SG tables etc, busdma is simply too  
cycle greedy to be called for each request, as performance has been  
shown to decrease quite a bit.

-Søren




On 14Apr, 2008, at 23:57 , Niclas Zeising wrote:

> 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
>