On Tue, Aug 24, 2010 at 10:52:36AM -0600, Cam Macdonell wrote:
> Hi, 64-bit BARs still do not seem to be working.
>
> When using the latest seabios the guest does not hit a "BUG:"
> statement, but booting still fails
>
> HPET: 1 timers in total, 0 timers will be used for per-cpu timer
> divide error: 0000 [#1] SMP
> last sysfs file:
> CPU 0
> Modules linked in:
>
> Pid: 1, comm: swapper Not tainted 2.6.35+ #299 /Bochs
> RIP: 0010:[<ffffffff812a9b5b>] [<ffffffff812a9b5b>] hpet_alloc+0x12c/0x35b
> RSP: 0018:ffff88007d7b3d80 EFLAGS: 00010246
> RAX: 00038d7ea4c68000 RBX: ffff88007d062cc0 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff817bb9b0
> RBP: ffff88007d7b3dc0 R08: 00000000000080d0 R09: ffffc90000000000
> R10: ffff88007d72b5a0 R11: 0000000000000000 R12: ffff88007d7b3dd0
> R13: ffffc90000000000 R14: 0000000000000000 R15: ffffffff817a41c3
> FS: 0000000000000000(0000) GS:ffff880002000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001a42000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper (pid: 1, threadinfo ffff88007d7b2000, task ffff88007d7b8000)
> Stack:
> ffff88007f43ab90 ffff88007f43ab90 ffffffff81ca6174 ffffffff81b1f5e1
> <0> 0000000000000000 0000000000000100 0000000000000100 0000000000000000
> <0> ffff88007d7b3e80 ffffffff810294ea 00000000fed00000 ffffc90000000000
> Call Trace:
> [<ffffffff81b1f5e1>] ? hpet_late_init+0x0/0xea
> [<ffffffff810294ea>] hpet_reserve_platform_timers+0x10b/0x115
> [<ffffffff81b1f5e1>] ? hpet_late_init+0x0/0xea
> [<ffffffff81b1f64c>] hpet_late_init+0x6b/0xea
> [<ffffffff81b1f5e1>] ? hpet_late_init+0x0/0xea
> [<ffffffff81002069>] do_one_initcall+0x5e/0x159
> [<ffffffff81b0d72a>] kernel_init+0x19a/0x228
> [<ffffffff8100aa24>] kernel_thread_helper+0x4/0x10
> [<ffffffff81b0d590>] ? kernel_init+0x0/0x228
> [<ffffffff8100aa20>] ? kernel_thread_helper+0x0/0x10
> Code: 89 1d ca b2 b3 00 48 c1 ea 21 8b 73 34 49 c7 c7 c3 41 7a 81 48
> 8d 04 02 4c 89 f2 48 c7 c7 b0 b9 7b 81 48 c1 ea 20 48 89 d1 31 d2 <48>
> f7 f1 83 7b 30 01 48 c7 c1 86 1c 7d 81 49 0f 46 cf 48 89 43
> RIP [<ffffffff812a9b5b>] hpet_alloc+0x12c/0x35b
> RSP <ffff88007d7b3d80>
> ---[ end trace a7919e7f17c0a725 ]---
> Kernel panic - not syncing: Attempted to kill init!
> Pid: 1, comm: swapper Tainted: G D 2.6.35+ #299
> Call Trace:
> [<ffffffff81459a85>] panic+0x8b/0x10b
> [<ffffffff81056a83>] ? exit_ptrace+0x38/0x121
> [<ffffffff8104f9e8>] do_exit+0x7a/0x722
> [<ffffffff8104c3bd>] ? spin_unlock_irqrestore+0xe/0x10
> [<ffffffff8104cfd6>] ? kmsg_dump+0x12b/0x145
> [<ffffffff8145ccc8>] oops_end+0xbf/0xc7
> [<ffffffff8100d299>] die+0x5a/0x63
> [<ffffffff8145c6d2>] do_trap+0x121/0x130
> [<ffffffff8100b560>] do_divide_error+0x96/0x9f
> [<ffffffff812a9b5b>] ? hpet_alloc+0x12c/0x35b
> [<ffffffff8120cf80>] ? radix_tree_preload+0x34/0x88
> [<ffffffff8100a83b>] divide_error+0x1b/0x20
> [<ffffffff812a9b5b>] ? hpet_alloc+0x12c/0x35b
> [<ffffffff81b1f5e1>] ? hpet_late_init+0x0/0xea
> [<ffffffff810294ea>] hpet_reserve_platform_timers+0x10b/0x115
> [<ffffffff81b1f5e1>] ? hpet_late_init+0x0/0xea
> [<ffffffff81b1f64c>] hpet_late_init+0x6b/0xea
> [<ffffffff81b1f5e1>] ? hpet_late_init+0x0/0xea
> [<ffffffff81002069>] do_one_initcall+0x5e/0x159
> [<ffffffff81b0d72a>] kernel_init+0x19a/0x228
> [<ffffffff8100aa24>] kernel_thread_helper+0x4/0x10
> [<ffffffff81b0d590>] ? kernel_init+0x0/0x228
> [<ffffffff8100aa20>] ? kernel_thread_helper+0x0/0x10
>
> seabios output for the device:
>
> PCI: bus=0 devfn=0x20: vendor_id=0x1af4 device_id=0x1110
> region 0: 0xf1020000
> region 2: 0x00000000
> init smm
>
> Running the latest seabios, the debug output only remaps the BAR
> twice, once with a potentially correct address of e00000000
>
> pci_read_config: (val) 0xe0000004 <- 0x18 (addr)
The upstream seabios lacks overflow check at the moment.
I haven't found time to address PMM yet.
> pci_default_write_config: (val) 0x0 -> 0x18 (addr)
> IVSHMEM: guest pci addr = e0000000, guest h/w addr = 2164588544, size =
> 20000000
> pci_read_config: (val) 0xe0000004 <- 0x18 (addr)
> pci_default_write_config: (val) 0x0 -> 0x18 (addr)
> pci_read_config: (val) 0x0 <- 0x1c (addr)
> pci_default_write_config: (val) 0x0 -> 0x1c (addr)
> IVSHMEM: guest pci addr = ffffffff00000000, guest h/w addr =
> 2164588544, size = 20000000
> pci_read_config: (val) 0xffffffff <- 0x1c (addr)
> pci_default_write_config: (val) 0x0 -> 0x1c (addr)
> pci_read_config: (val) 0x0 <- 0x20 (addr)
>
> the pci writes are all still 0, I can't see how my debug statements
> are incorrect though. Below is my trivial pci config debugging patch.
The debug out put should be before the for-loop.
for (i = 0; i < l && addr + i < config_size; val >>= 8, ++i) {
^^^^^^^^^
Here val becomes 0
uint8_t wmask = d->wmask[addr + i];
d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val & wmask);
}
--
yamahata
