100% CPU pg processes that don't die.

I'm load testing a machine, and i'm seeing idle in transaction
processes that are no longer hooked to any outside client, that pull
100% CPU and can't be kill -9ed. I'm using pgbench -c 1000 -t 1000.
postgresql.conf attached. This is on a 8 CPU AMD box with hardware
RAID. I'll likely never see this many parallel connections in
production, but who knows... I want to reboot the machine to test at
a lower number of threads but if there's more info in it to gain
knowledge from I'll leave it up.

They look like this in top:

3552 postgres 20 0 8286m 82m 78m R 100 0.3 195:04.22 postgres:
postgres postgres [local] idle in transaction
3561 postgres 20 0 8286m 83m 79m R 100 0.3 195:04.20 postgres:
postgres postgres [local] idle in transaction

This in ps aux|grep postgres:

postgres 3561 95.2 0.2 8485376 85708 ? Rs 09:45 197:17
postgres: postgres postgres [local] idle in transaction

The db is still up and accessable. I'm also getting this in my
/var/log/messages:

Aug 9 13:13:21 engelberg kernel: [71242.734934] CPU 1:
Aug 9 13:13:21 engelberg kernel: [71242.734935] Modules linked in:
iptable_filter ip_tables x_tables parport_pc lp parport loop ipv6
evdev i2c_nforce2 pcspkr shpchp button pci_hotplug i2c_core pata_amd
ata_generic ext3 jbd mbcache sg sr_mod cdrom sd_mod e1000 floppy
arcmsr pata_acpi libata ehci_hcd forcedeth ohci_hcd scsi_mod usbcore
thermal processor fan fbcon tileblit font bitblit softcursor fuse
Aug 9 13:13:21 engelberg kernel: [71242.734972] Pid: 294, comm:
kswapd0 Not tainted 2.6.24-19-server #1
Aug 9 13:13:21 engelberg kernel: [71242.734974] RIP:
0010:[floppy:_spin_lock_irqsave+0x12/0x30]
[floppy:_spin_lock_irqsave+0x12/0x30] _spin_lock_irqsave+0x12/0x30
Aug 9 13:13:21 engelberg kernel: [71242.734980] RSP:
0018:ffff810415423df8 EFLAGS: 00000286
Aug 9 13:13:21 engelberg kernel: [71242.734982] RAX: 0000000000000246
RBX: ffff81000003137d RCX: 0000000000000003
Aug 9 13:13:21 engelberg kernel: [71242.734984] RDX: 0000000000000001
RSI: ffff810415423ea0 RDI: ffff81000003137d
Aug 9 13:13:21 engelberg kernel: [71242.734987] RBP: ffff810415423d60
R08: 0000000000000000 R09: 0000000000000000
Aug 9 13:13:21 engelberg kernel: [71242.734989] R10: 0000000000000000
R11: ffffffff881a46b0 R12: ffff810415423d60
Aug 9 13:13:21 engelberg kernel: [71242.734991] R13: ffffffff8028d11e
R14: ffff81041f6b2670 R15: ffff810420168178
Aug 9 13:13:21 engelberg kernel: [71242.734994] FS:
00007f51096fd700(0000) GS:ffff8108171a2300(0000)
knlGS:0000000000000000
Aug 9 13:13:21 engelberg kernel: [71242.734997] CS: 0010 DS: 0018
ES: 0018 CR0: 000000008005003b
Aug 9 13:13:21 engelberg kernel: [71242.734999] CR2: 00007f4f27ebffd0
CR3: 0000000000201000 CR4: 00000000000006e0
Aug 9 13:13:21 engelberg kernel: [71242.735001] DR0: 0000000000000000
DR1: 0000000000000000 DR2: 0000000000000000
Aug 9 13:13:21 engelberg kernel: [71242.735003] DR3: 0000000000000000
DR6: 00000000ffff0ff0 DR7: 0000000000000400
Aug 9 13:13:21 engelberg kernel: [71242.735006]
Aug 9 13:13:21 engelberg kernel: [71242.735006] Call Trace:
Aug 9 13:13:21 engelberg kernel: [71242.735009]
[usbcore:prepare_to_wait+0x23/0x80] prepare_to_wait+0x23/0x80
Aug 9 13:13:21 engelberg kernel: [71242.735013] [kswapd+0xfa/0x560]
kswapd+0xfa/0x560
Aug 9 13:13:21 engelberg kernel: [71242.735020] [<ffffffff80254260>]
autoremove_wake_function+0x0/0x30
Aug 9 13:13:21 engelberg kernel: [71242.735026] [kswapd+0x0/0x560]
kswapd+0x0/0x560
Aug 9 13:13:21 engelberg kernel: [71242.735030] [kthread+0x4b/0x80]
kthread+0x4b/0x80
Aug 9 13:13:21 engelberg kernel: [71242.735034] [child_rip+0xa/0x12]
child_rip+0xa/0x12
Aug 9 13:13:21 engelberg kernel: [71242.735040] [kthread+0x0/0x80]
kthread+0x0/0x80
Aug 9 13:13:21 engelberg kernel: [71242.735043] [child_rip+0x0/0x12]
child_rip+0x0/0x12
Aug 9 13:13:21 engelberg kernel: [71242.735046]

Does this look like a kernel bug or a pgsql bug to most people?