[Xen-devel] Re: userspace block backend / gntdev problems

[Gerd Hoffmann <kraxel@xxxxxxxxxx>]

Derek Murray wrote:
> The 128-grant limit is fairly arbitrary, and I wanted to see how people
> were using gntdev before changing this. The reason for using a
> fixed-size array is that it gives us O(1)-time mapping and unmapping of
> single grants, which I anticipated would be the most frequently-used
> case.

Ok, try a hash instead of a list then ;)

>> Second problem is that batched grant mappings (using
>> xc_gnttab_map_grant_refs) don't work reliable.  Symtoms I see are random
>> failures with ENOMEM for no obvious reason (128 grant limit is *far*
>> away).
> 
> If it's failing with ENOMEM, a possible reason is that the address space
> for mapping grants within gntdev (the array I mentioned above) is
> becoming fragmented. Are you combining the mapping of single grants and
> batches within the same gntdev instance?

Yes, I'm mixing up single and batched maps (the later can have different
sizes too, depending on the requests coming in, in the 1 -> 11 range).
But I've seen ENOMEM failures with *only* the shared ring being mapped,
i.e. one of 128 slots being used.  That can't be fragmentation ...

>> Also host kernel crashes (kernel 2.6.21-2952.fc8xen).
> 
> When does this happen? Could you post the kernel OOPS?

Dunno what exactly triggers it.  Oops attached.

cheers,
  Gerd


BUG: unable to handle kernel NULL pointer dereference at virtual address 
00000000
 printing eip:
0143e000 -> *pde = 00000000:5016e001
2c76e000 -> *pme = 00000000:00000000
Oops: 0000 [#1]
SMP 
last sysfs file: /devices/xen-backend/vbd-1-51712/statistics/wr_sect
Modules linked in: ipt_MASQUERADE(U) iptable_nat(U) nf_nat(U) 
nf_conntrack_ipv4(U) xt_state(U) nf_conntrack(U) nfnetlink(U) ipt_REJECT(U) 
xt_tcpudp(U) iptable_filter(U) ip_tables(U) x_tables(U) bridge(U) nfsd(U) 
exportfs(U) lockd(U) nfs_acl(U) autofs4(U) sunrpc(U) ipv6(U) ext2(U) loop(U) 
dm_multipath(U) netbk(U) blkbk(U) 8250_pnp(U) 8250_pci(U) snd_hda_intel(U) 
snd_hda_codec(U) snd_seq_dummy(U) snd_seq_oss(U) snd_seq_midi_event(U) 
snd_seq(U) snd_seq_device(U) snd_pcm_oss(U) snd_mixer_oss(U) snd_pcm(U) 
i2c_i801(U) parport_pc(U) snd_timer(U) i2c_core(U) snd(U) parport(U) 8250(U) 
e1000(U) pcspkr(U) soundcore(U) serio_raw(U) serial_core(U) ata_generic(U) 
snd_page_alloc(U) sr_mod(U) sg(U) cdrom(U) ata_piix(U) dm_snapshot(U) 
dm_zero(U) dm_mirror(U) dm_mod(U) ahci(U) libata(U) sd_mod(U) scsi_mod(U) 
ext3(U) jbd(U) mbcache(U) uhci_hcd(U) ohci_hcd(U) ehci_hcd(U)
CPU:    0
EIP:    0061:[<c10e85ba>]    Not tainted VLI
EFLAGS: 00010282   (2.6.21-2952.fc8xen #1)
EIP is at __sync_single+0x1c/0x197
eax: 00000000   ebx: 0005a6ca   ecx: 00000002   edx: 00000000
esi: 00000000   edi: 00000000   ebp: 00000400   esp: c136ce80
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0069
Process swapper (pid: 0, ti=c136c000 task=c12d4260 task.ti=c1314000)
Stack: 00000002 ed6a1000 c1c5d100 c1c5d100 c136cee8 c1c5d5c0 00000000 c102b7a1 
       0005a6ca 00000000 00000000 ed6a1000 c10e87db 00000400 00000002 00000400 
       00000000 00000400 00000000 ec7fb480 c10e8a3e 00000002 00000001 c1d87848 
Call Trace:
 [<c102b7a1>] lock_timer_base+0x19/0x35
 [<c10e87db>] unmap_single+0x55/0xd2
 [<c10e8a3e>] swiotlb_unmap_sg+0x103/0x120
 [<ee107fec>] ata_sg_clean+0x103/0x1b9 [libata]
 [<ee1080f0>] __ata_qc_complete+0x4e/0x92 [libata]
 [<c1009859>] timer_interrupt+0x5a4/0x5b7
 [<ee10bc70>] ata_qc_complete_multiple+0x87/0x9d [libata]
 [<ee0e5f22>] ahci_interrupt+0x2ff/0x4bd [ahci]
 [<c104a53a>] handle_IRQ_event+0x36/0x6e
 [<c104b9f2>] handle_level_irq+0x81/0xc7
 [<c104b971>] handle_level_irq+0x0/0xc7
 [<c100719a>] do_IRQ+0xac/0xd2
 [<c1036cb6>] ktime_get+0xf/0x2b
 [<c114f076>] evtchn_do_upcall+0x82/0xdb
 [<c100585e>] hypervisor_callback+0x46/0x4e
 [<c1008840>] raw_safe_halt+0xb3/0xd5
 [<c100452e>] xen_idle+0x31/0x5c
 [<c1003435>] cpu_idle+0xa3/0xbc
 [<c1319be4>] start_kernel+0x481/0x489
 [<c131925a>] unknown_bootoption+0x0/0x202
 =======================
Code: c8 09 d0 5a 0f 94 c0 59 0f b6 c0 5b 5e 5f c3 55 57 56 89 c6 53 83 ec 20 
89 4c 24 04 8b 4c 24 38 89 54 24 18 8b 6c 24 34 89 0c 24 <8b> 08 c1 e9 1e 69 c9 
80 12 00 00 81 c1 00 9e 2d c1 8b 99 0c 12 
EIP: [<c10e85ba>] __sync_single+0x1c/0x197 SS:ESP 0069:c136ce80
Kernel panic - not syncing: Fatal exception in interrupt
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel