**** BEGIN LOGGING AT Sat Jan 28 02:59:58 2006
Jan 28 04:17:16 <lennert> [g2]: the driver is accessing physical addresses as virtual addresses
Jan 28 04:17:20 <lennert> [g2]: this is ixp4xx, i guess?
Jan 28 13:03:33 <ka6sox> see velinp bounce
Jan 28 13:09:11 <lennert> hehe
Jan 28 13:14:47 <ka6sox> lennert, the glue logic is mostly gone...now 3 cpld's
Jan 28 13:18:32 <lennert> cool
Jan 28 14:38:01 <[g2]> lennert yeah its on the Loft and that's what I thought too about access
Jan 28 14:40:15 <lennert> [g2]: ?
Jan 28 14:40:39 <lennert> oh, i see
Jan 28 14:40:46 <[g2]> lennert sorry :( I was responding to you comment from 10 hrs ago 
Jan 28 14:40:50 <lennert> yeah, it's trying to access iomap cookies directly, probably
Jan 28 14:40:54 <lennert> or something like that
Jan 28 14:40:56 <lennert> do you have a backtrace?
Jan 28 14:41:00 <lennert> can you find the offending function?
Jan 28 14:41:01 <[g2]> sure
Jan 28 14:41:16 <lennert> which kernel version?
Jan 28 14:41:51 <[g2]> 2..6.1
Jan 28 14:41:53 <[g2]> 2..6.15
Jan 28 14:42:15 <[g2]> wow stellar typing from [g2] today
Jan 28 14:42:49 <[g2]> this is the lastest Atheros madwifi-ng driver
Jan 28 14:43:18 <lennert> s/lastest/latest/ :)
Jan 28 14:43:30 <[g2]> I'm guessing either something isn't mapped right on the Loft or they are expecting something (like PCI support) to be handled differently like on x6
Jan 28 14:43:36 <[g2]> s/x6/x86/
Jan 28 14:43:37 <purl> [g2] meant: I'm guessing either something isn't mapped right on the Loft or they are expecting something (like PCI support) to be handled differently like on x86
Jan 28 14:45:16 <[g2-lap]> http://pastebin.ca/38936
Jan 28 14:45:38 <[g2-lap]> ath_hal_reg_read is the offender
Jan 28 14:45:47 <lennert> right
Jan 28 14:46:09 <[g2-lap]> it's the instruction right after the "Before" printk
Jan 28 14:46:22 <lennert> well
Jan 28 14:46:38 <lennert> it might be doing ioremap() and then dereferencing the returned cookie
Jan 28 14:46:48 <lennert> i'm not exactly sure
Jan 28 14:47:06 <lennert> it's certainly doing something wrong
Jan 28 14:47:10 <[g2]> nod
Jan 28 14:48:54 <lennert> have you asked the atheros people?
Jan 28 14:49:22 <[g2]> there's an open ticked on madwifi
Jan 28 14:50:34 <lennert> ok
Jan 28 14:52:20 <[g2-lap]> old_mmap(NULL, 223692, PROT_READ|PROT_WRITE, MAP_PRIVATE,Unable to handle kernel paging request at virtual address 48004004
Jan 28 14:52:21 <[g2-lap]>  3, 0) = 0x40142000
Jan 28 14:52:21 <[g2-lap]> init_module(".ELF...a", 0x369cc)        = 0pgd = c2038000
Jan 28 14:52:21 <[g2-lap]> munmap(0x40142000, 223692)              = 0
Jan 28 14:52:21 <[g2-lap]> close(3)         [48004004] *pgd=00000000                       = 0
Jan 28 14:53:07 <[g2-lap]> lennert does that mean the mmap is failing ?
Jan 28 14:53:15 <[g2-lap]> old_mmap that is
Jan 28 14:53:40 <[g2-lap]> that was from an strace of the modprobe
Jan 28 14:53:55 <lennert> well, it's crashing in init_module()
Jan 28 14:54:08 <lennert> but.. the oops is shown before strace has a chance to print old_mmap()
Jan 28 14:54:15 <lennert> so that's why it looks like it's crashing in old_mmap()
Jan 28 14:54:35 <lennert> init_module calls the module init function
Jan 28 14:56:16 <[g2-lap]> I know the line of code that's failing I don't know why the memory map isn't properly setup
Jan 28 14:57:34 <[g2-lap]> I'd guess that the ath_pci_probe or the pci_probe would be responsible for mapping the PCI address properly
Jan 28 14:57:55 <[g2-lap]> the address is in the PCI config region of the card
Jan 28 14:58:10 <[g2-lap]> lspci -v
Jan 28 14:58:10 <[g2-lap]> 0000:00:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
Jan 28 14:58:10 <[g2-lap]>         Subsystem: Unknown device 185f:1012
Jan 28 14:58:10 <[g2-lap]>         Flags: bus master, medium devsel, latency 168, IRQ 27
Jan 28 14:58:10 <[g2-lap]>         Memory at 48000000 (32-bit, non-prefetchable) [size=64K]
Jan 28 14:58:11 <[g2-lap]>         Capabilities: [44] Power Management version 2
Jan 28 14:58:33 <[g2-lap]> we are getting quite far
Jan 28 14:58:42 <[g2-lap]> I don't know if there's a race
Jan 28 14:59:19 <[g2-lap]> as that area starts out disabled and the driver doesn't opps on the second modprobe, but things still aren't fully setup properly
Jan 28 14:59:28 <[g2-lap]> things for the driver that is
Jan 28 15:09:20 <lennert> can you check what that accessor function is doing?
Jan 28 15:10:46 <[g2]> lennert sure
Jan 28 15:13:25 <[g2]> lennert what do I need to do to turn on KERN_INFO message ?
Jan 28 15:13:36 * [g2] googles at the same time
Jan 28 15:29:46 <[g2]> dinner bbiab
Jan 28 15:36:52 <lennert> well
Jan 28 15:36:57 <lennert> you should be able to see them in 'dmesg'
Jan 28 15:36:59 <lennert> (i think)
Jan 28 15:52:15 <[g2]> nod. the printk is right _after_ the ath_hal_probe (which we are oopsing in before the return)
Jan 28 20:51:51 <ka6sox> ~seen Chanserv
Jan 28 20:51:58 <purl> ka6sox: i haven't seen 'chanserv'
Jan 28 20:52:08 <lennert> chanserv sig11d.. wow
Jan 28 20:52:36 <ka6sox> ~seen ChanServ
Jan 28 20:52:38 <purl> ka6sox: i haven't seen 'chanserv'
Jan 28 20:52:43 <ka6sox> heh
Jan 28 21:53:54 <ka6sox> morning velinp 
Jan 28 21:54:13 <velinp> ka6sox: morning
Jan 28 21:55:26 <velinp> ka6sox: PM about debian-armeb ?
Jan 28 21:58:05 <ka6sox> didn't see one
**** ENDING LOGGING AT Sun Jan 29 02:59:57 2006