Bug 13976
| Summary: | viafb + vmalloc | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Roman Sergeev (sungeneral) |
| Component: | Video(Other) | Assignee: | drivers_video-other |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | alan, leonardo.rolla, Tom, z5b8j123 |
| Priority: | P1 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.30.4 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | Segment of kern.log showing output of added debug output in relevant functions. | ||
|
Description
Roman Sergeev
2009-08-13 15:22:39 UTC
x86 platform (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 13 Aug 2009 15:22:41 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13976 > > Summary: viafb + vmalloc > Product: Drivers > Version: 2.5 > Kernel Version: 2.6.30.4 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Video(Other) > AssignedTo: drivers_video-other@kernel-bugs.osdl.org > ReportedBy: sungeneral@gmail.com > Regression: No OK, this is bad. > > #modprobe viafb > Jun 21 05:17:53 mini2133 [ 50.504357] VIA Graphics Intergration Chipset > framebuffer 2.4 initializing > Jun 21 05:17:53 mini2133 [ 50.583434] vmap allocation for size 268439552 > failed: use vmalloc=<size> to increase size. > Jun 21 05:17:53 mini2133 [ 50.583443] ioremap failed > > if add parametr vmalloc=260M to kernel > > #modprobe viafb > Jun 21 05:11:17 mini2133 [ 60.692317] VIA Graphics Intergration Chipset > framebuffer 2.4 initializing > Jun 21 05:11:17 mini2133 [ 60.772731] vmap allocation for size 16781312 > failed: use vmalloc=<size> to increase size. > Jun 21 05:11:17 mini2133 [ 60.772750] BUG: unable to handle kernel NULL > pointer dereference at 00000004 > Jun 21 05:11:17 mini2133 [ 60.772921] IP: [<ef64a798>] > viafb_init_2d_engine+0x16/0x583 [viafb] > Jun 21 05:11:17 mini2133 [ 60.773005] *pde = 00000000 > Jun 21 05:11:17 mini2133 [ 60.773005] Oops: 0002 [#1] SMP > Jun 21 05:11:17 mini2133 [ 60.773005] last sysfs file: > > /sys/devices/pci0000:00/0000:00:0f.0/host0/target0:0:0/0:0:0:0/block/sda/uevent > Jun 21 05:11:17 mini2133 [ 60.773005] Modules linked in: viafb(+) > i2c_algo_bit via drm via_agp agpgart > Jun 21 05:11:17 mini2133 [ 60.773005] > Jun 21 05:11:17 mini2133 [ 60.773005] Pid: 4084, comm: modprobe Not tainted > (2.6.30-gentoo-r4 #13) > Jun 21 05:11:17 mini2133 [ 60.773005] EIP: 0060:[<ef64a798>] EFLAGS: > 00010202 > CPU: 0 > Jun 21 05:11:17 mini2133 [ 60.773005] EIP is at > viafb_init_2d_engine+0x16/0x583 [viafb] > Jun 21 05:11:17 mini2133 [ 60.773005] EAX: 00000004 EBX: ed8a5280 ECX: > c256d700 EDX: 00000000 > Jun 21 05:11:17 mini2133 [ 60.773005] ESI: fffffffc EDI: 00000000 EBP: > ed8b3f18 ESP: ed8b3f08 > Jun 21 05:11:17 mini2133 [ 60.773005] DS: 007b ES: 007b FS: 00d8 GS: 0033 > SS: 0068 > Jun 21 05:11:17 mini2133 [ 60.773005] Process modprobe (pid: 4084, > ti=ed8b2000 task=ee7da220 task.ti=ed8b2000) > Jun 21 05:11:17 mini2133 [ 60.773005] Stack: > Jun 21 05:11:17 mini2133 [ 60.773005] 00000000 ed8a5280 fffffffc 00000000 > ed8b3f40 ef656505 00000000 ed8b3f40 > Jun 21 05:11:17 mini2133 [ 60.773005] c1062132 00000000 00000000 ef6535e4 > fffffffc 00000000 ed8b3f9c c1001137 > Jun 21 05:11:17 mini2133 [ 60.773005] ef656000 00000000 ef6535e4 00000001 > 00000000 c15dec24 00000000 c15dec34 > Jun 21 05:11:17 mini2133 [ 60.773005] Call Trace: > Jun 21 05:11:17 mini2133 [ 60.773005] [<ef656505>] ? > viafb_init+0x505/0xd2c > [viafb] > Jun 21 05:11:17 mini2133 [ 60.773005] [<c1062132>] ? > marker_update_probe_range+0x1cf/0x1de > Jun 21 05:11:17 mini2133 [ 60.773005] [<c1001137>] ? > do_one_initcall+0x4a/0x10c > Jun 21 05:11:17 mini2133 [ 60.773005] [<ef656000>] ? viafb_init+0x0/0xd2c > [viafb] > Jun 21 05:11:17 mini2133 [ 60.773005] [<c103ae2d>] ? > __blocking_notifier_call_chain+0x40/0x4c > Jun 21 05:11:17 mini2133 [ 60.773005] [<c10481f6>] ? > sys_init_module+0x87/0x18b > Jun 21 05:11:17 mini2133 [ 60.773005] [<c1002a44>] ? > sysenter_do_call+0x12/0x22 > Jun 21 05:11:17 mini2133 [ 60.773005] Code: ff ff 03 00 89 42 44 a1 44 38 > 65 > ef 81 40 38 00 20 04 00 5d c3 55 31 d2 89 e5 57 56 53 83 ec 04 a1 44 38 65 ef > 8b 40 1c 83 c0 04 <89> 10 a1 44 38 65 ef 8b 40 1c 83 c0 08 89 10 a1 44 38 65 > ef > 8b > Jun 21 05:11:17 mini2133 [ 60.773005] EIP: [<ef64a798>] > viafb_init_2d_engine+0x16/0x583 [viafb] SS:ESP 0068:ed8b3f08 > Jun 21 05:11:17 mini2133 [ 60.773005] CR2: 0000000000000004 > Jun 21 05:11:17 mini2133 [ 60.779905] ---[ end trace c390d80983a29e06 ]--- > > ps: viafb build as a module > a) The driver appears to be ioremapping more virtual address space than the machine can provide. Is that expected? b) When ioremap_nocache() failed, the driver went and crashed the machine. I don't see how this can happen - via_pci_probe() seems to handle this correctly. It should return -ENOMEM rather than -1, but that's minor. Reply-To: FlorianSchandinat@gmx.de Hi, excuse me to interfere although I don't know the memory subsystem/functions very well. Andrew Morton schrieb: > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Thu, 13 Aug 2009 15:22:41 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > >> http://bugzilla.kernel.org/show_bug.cgi?id=13976 >> >> Summary: viafb + vmalloc >> Product: Drivers >> Version: 2.5 >> Kernel Version: 2.6.30.4 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: normal >> Priority: P1 >> Component: Video(Other) >> AssignedTo: drivers_video-other@kernel-bugs.osdl.org >> ReportedBy: sungeneral@gmail.com >> Regression: No > > OK, this is bad. > >> #modprobe viafb >> Jun 21 05:17:53 mini2133 [ 50.504357] VIA Graphics Intergration Chipset >> framebuffer 2.4 initializing >> Jun 21 05:17:53 mini2133 [ 50.583434] vmap allocation for size 268439552 >> failed: use vmalloc=<size> to increase size. >> Jun 21 05:17:53 mini2133 [ 50.583443] ioremap failed >> >> if add parametr vmalloc=260M to kernel >> >> #modprobe viafb >> Jun 21 05:11:17 mini2133 [ 60.692317] VIA Graphics Intergration Chipset >> framebuffer 2.4 initializing >> Jun 21 05:11:17 mini2133 [ 60.772731] vmap allocation for size 16781312 >> failed: use vmalloc=<size> to increase size. >> Jun 21 05:11:17 mini2133 [ 60.772750] BUG: unable to handle kernel NULL >> pointer dereference at 00000004 >> Jun 21 05:11:17 mini2133 [ 60.772921] IP: [<ef64a798>] >> viafb_init_2d_engine+0x16/0x583 [viafb] >> Jun 21 05:11:17 mini2133 [ 60.773005] *pde = 00000000 >> Jun 21 05:11:17 mini2133 [ 60.773005] Oops: 0002 [#1] SMP >> Jun 21 05:11:17 mini2133 [ 60.773005] last sysfs file: >> >> /sys/devices/pci0000:00/0000:00:0f.0/host0/target0:0:0/0:0:0:0/block/sda/uevent >> Jun 21 05:11:17 mini2133 [ 60.773005] Modules linked in: viafb(+) >> i2c_algo_bit via drm via_agp agpgart >> Jun 21 05:11:17 mini2133 [ 60.773005] >> Jun 21 05:11:17 mini2133 [ 60.773005] Pid: 4084, comm: modprobe Not >> tainted >> (2.6.30-gentoo-r4 #13) >> Jun 21 05:11:17 mini2133 [ 60.773005] EIP: 0060:[<ef64a798>] EFLAGS: >> 00010202 >> CPU: 0 >> Jun 21 05:11:17 mini2133 [ 60.773005] EIP is at >> viafb_init_2d_engine+0x16/0x583 [viafb] >> Jun 21 05:11:17 mini2133 [ 60.773005] EAX: 00000004 EBX: ed8a5280 ECX: >> c256d700 EDX: 00000000 >> Jun 21 05:11:17 mini2133 [ 60.773005] ESI: fffffffc EDI: 00000000 EBP: >> ed8b3f18 ESP: ed8b3f08 >> Jun 21 05:11:17 mini2133 [ 60.773005] DS: 007b ES: 007b FS: 00d8 GS: 0033 >> SS: 0068 >> Jun 21 05:11:17 mini2133 [ 60.773005] Process modprobe (pid: 4084, >> ti=ed8b2000 task=ee7da220 task.ti=ed8b2000) >> Jun 21 05:11:17 mini2133 [ 60.773005] Stack: >> Jun 21 05:11:17 mini2133 [ 60.773005] 00000000 ed8a5280 fffffffc 00000000 >> ed8b3f40 ef656505 00000000 ed8b3f40 >> Jun 21 05:11:17 mini2133 [ 60.773005] c1062132 00000000 00000000 ef6535e4 >> fffffffc 00000000 ed8b3f9c c1001137 >> Jun 21 05:11:17 mini2133 [ 60.773005] ef656000 00000000 ef6535e4 00000001 >> 00000000 c15dec24 00000000 c15dec34 >> Jun 21 05:11:17 mini2133 [ 60.773005] Call Trace: >> Jun 21 05:11:17 mini2133 [ 60.773005] [<ef656505>] ? >> viafb_init+0x505/0xd2c >> [viafb] >> Jun 21 05:11:17 mini2133 [ 60.773005] [<c1062132>] ? >> marker_update_probe_range+0x1cf/0x1de >> Jun 21 05:11:17 mini2133 [ 60.773005] [<c1001137>] ? >> do_one_initcall+0x4a/0x10c >> Jun 21 05:11:17 mini2133 [ 60.773005] [<ef656000>] ? viafb_init+0x0/0xd2c >> [viafb] >> Jun 21 05:11:17 mini2133 [ 60.773005] [<c103ae2d>] ? >> __blocking_notifier_call_chain+0x40/0x4c >> Jun 21 05:11:17 mini2133 [ 60.773005] [<c10481f6>] ? >> sys_init_module+0x87/0x18b >> Jun 21 05:11:17 mini2133 [ 60.773005] [<c1002a44>] ? >> sysenter_do_call+0x12/0x22 >> Jun 21 05:11:17 mini2133 [ 60.773005] Code: ff ff 03 00 89 42 44 a1 44 38 >> 65 >> ef 81 40 38 00 20 04 00 5d c3 55 31 d2 89 e5 57 56 53 83 ec 04 a1 44 38 65 >> ef >> 8b 40 1c 83 c0 04 <89> 10 a1 44 38 65 ef 8b 40 1c 83 c0 08 89 10 a1 44 38 65 >> ef >> 8b >> Jun 21 05:11:17 mini2133 [ 60.773005] EIP: [<ef64a798>] >> viafb_init_2d_engine+0x16/0x583 [viafb] SS:ESP 0068:ed8b3f08 >> Jun 21 05:11:17 mini2133 [ 60.773005] CR2: 0000000000000004 >> Jun 21 05:11:17 mini2133 [ 60.779905] ---[ end trace c390d80983a29e06 ]--- >> >> ps: viafb build as a module >> > > a) The driver appears to be ioremapping more virtual address space > than the machine can provide. > > Is that expected? I don't know. Is the video memory size detection of (I think) 256 MB correct? What is the graphic chip? (CLE266, CN400, CN700, KM400, CX700 or VX800?) > b) When ioremap_nocache() failed, the driver went and crashed the > machine. I don't see how this can happen - via_pci_probe() seems to > handle this correctly. > > It should return -ENOMEM rather than -1, but that's minor. If an ioremap_nocache() can cause this, I don't see why it can't be the later one: viaparinfo->io_virt = ioremap_nocache() As far as I know this is only used for acceleration so a quick test can be done with viafb_accel=0 module parameter. Regards, Florian Tobias Schandinat Reply-To: FlorianSchandinat@gmx.de Hi, excuse me to interfere although I don't know the memory subsystem/functions very well. Andrew Morton schrieb: > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Thu, 13 Aug 2009 15:22:41 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > >> http://bugzilla.kernel.org/show_bug.cgi?id=13976 >> >> Summary: viafb + vmalloc >> Product: Drivers >> Version: 2.5 >> Kernel Version: 2.6.30.4 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: normal >> Priority: P1 >> Component: Video(Other) >> AssignedTo: drivers_video-other@kernel-bugs.osdl.org >> ReportedBy: sungeneral@gmail.com >> Regression: No > > OK, this is bad. > >> #modprobe viafb >> Jun 21 05:17:53 mini2133 [ 50.504357] VIA Graphics Intergration Chipset >> framebuffer 2.4 initializing >> Jun 21 05:17:53 mini2133 [ 50.583434] vmap allocation for size 268439552 >> failed: use vmalloc=<size> to increase size. >> Jun 21 05:17:53 mini2133 [ 50.583443] ioremap failed >> >> if add parametr vmalloc=260M to kernel >> >> #modprobe viafb >> Jun 21 05:11:17 mini2133 [ 60.692317] VIA Graphics Intergration Chipset >> framebuffer 2.4 initializing >> Jun 21 05:11:17 mini2133 [ 60.772731] vmap allocation for size 16781312 >> failed: use vmalloc=<size> to increase size. >> Jun 21 05:11:17 mini2133 [ 60.772750] BUG: unable to handle kernel NULL >> pointer dereference at 00000004 >> Jun 21 05:11:17 mini2133 [ 60.772921] IP: [<ef64a798>] >> viafb_init_2d_engine+0x16/0x583 [viafb] >> Jun 21 05:11:17 mini2133 [ 60.773005] *pde = 00000000 >> Jun 21 05:11:17 mini2133 [ 60.773005] Oops: 0002 [#1] SMP >> Jun 21 05:11:17 mini2133 [ 60.773005] last sysfs file: >> >> /sys/devices/pci0000:00/0000:00:0f.0/host0/target0:0:0/0:0:0:0/block/sda/uevent >> Jun 21 05:11:17 mini2133 [ 60.773005] Modules linked in: viafb(+) >> i2c_algo_bit via drm via_agp agpgart >> Jun 21 05:11:17 mini2133 [ 60.773005] >> Jun 21 05:11:17 mini2133 [ 60.773005] Pid: 4084, comm: modprobe Not >> tainted >> (2.6.30-gentoo-r4 #13) >> Jun 21 05:11:17 mini2133 [ 60.773005] EIP: 0060:[<ef64a798>] EFLAGS: >> 00010202 >> CPU: 0 >> Jun 21 05:11:17 mini2133 [ 60.773005] EIP is at >> viafb_init_2d_engine+0x16/0x583 [viafb] >> Jun 21 05:11:17 mini2133 [ 60.773005] EAX: 00000004 EBX: ed8a5280 ECX: >> c256d700 EDX: 00000000 >> Jun 21 05:11:17 mini2133 [ 60.773005] ESI: fffffffc EDI: 00000000 EBP: >> ed8b3f18 ESP: ed8b3f08 >> Jun 21 05:11:17 mini2133 [ 60.773005] DS: 007b ES: 007b FS: 00d8 GS: 0033 >> SS: 0068 >> Jun 21 05:11:17 mini2133 [ 60.773005] Process modprobe (pid: 4084, >> ti=ed8b2000 task=ee7da220 task.ti=ed8b2000) >> Jun 21 05:11:17 mini2133 [ 60.773005] Stack: >> Jun 21 05:11:17 mini2133 [ 60.773005] 00000000 ed8a5280 fffffffc 00000000 >> ed8b3f40 ef656505 00000000 ed8b3f40 >> Jun 21 05:11:17 mini2133 [ 60.773005] c1062132 00000000 00000000 ef6535e4 >> fffffffc 00000000 ed8b3f9c c1001137 >> Jun 21 05:11:17 mini2133 [ 60.773005] ef656000 00000000 ef6535e4 00000001 >> 00000000 c15dec24 00000000 c15dec34 >> Jun 21 05:11:17 mini2133 [ 60.773005] Call Trace: >> Jun 21 05:11:17 mini2133 [ 60.773005] [<ef656505>] ? >> viafb_init+0x505/0xd2c >> [viafb] >> Jun 21 05:11:17 mini2133 [ 60.773005] [<c1062132>] ? >> marker_update_probe_range+0x1cf/0x1de >> Jun 21 05:11:17 mini2133 [ 60.773005] [<c1001137>] ? >> do_one_initcall+0x4a/0x10c >> Jun 21 05:11:17 mini2133 [ 60.773005] [<ef656000>] ? viafb_init+0x0/0xd2c >> [viafb] >> Jun 21 05:11:17 mini2133 [ 60.773005] [<c103ae2d>] ? >> __blocking_notifier_call_chain+0x40/0x4c >> Jun 21 05:11:17 mini2133 [ 60.773005] [<c10481f6>] ? >> sys_init_module+0x87/0x18b >> Jun 21 05:11:17 mini2133 [ 60.773005] [<c1002a44>] ? >> sysenter_do_call+0x12/0x22 >> Jun 21 05:11:17 mini2133 [ 60.773005] Code: ff ff 03 00 89 42 44 a1 44 38 >> 65 >> ef 81 40 38 00 20 04 00 5d c3 55 31 d2 89 e5 57 56 53 83 ec 04 a1 44 38 65 >> ef >> 8b 40 1c 83 c0 04 <89> 10 a1 44 38 65 ef 8b 40 1c 83 c0 08 89 10 a1 44 38 65 >> ef >> 8b >> Jun 21 05:11:17 mini2133 [ 60.773005] EIP: [<ef64a798>] >> viafb_init_2d_engine+0x16/0x583 [viafb] SS:ESP 0068:ed8b3f08 >> Jun 21 05:11:17 mini2133 [ 60.773005] CR2: 0000000000000004 >> Jun 21 05:11:17 mini2133 [ 60.779905] ---[ end trace c390d80983a29e06 ]--- >> >> ps: viafb build as a module >> > > a) The driver appears to be ioremapping more virtual address space > than the machine can provide. > > Is that expected? I don't know. Is the video memory size detection of (I think) 256 MB correct? What is the graphic chip? (CLE266, CN400, CN700, KM400, CX700 or VX800?) > b) When ioremap_nocache() failed, the driver went and crashed the > machine. I don't see how this can happen - via_pci_probe() seems to > handle this correctly. > > It should return -ENOMEM rather than -1, but that's minor. If an ioremap_nocache() can cause this, I don't see why it can't be the later one: viaparinfo->io_virt = ioremap_nocache() As far as I know this is only used for acceleration so a quick test can be done with viafb_accel=0 module parameter. Regards, Florian Tobias Schandinat On 14.08.2009, at 1:24, Florian Tobias Schandinat wrote: >>> >>> ps: viafb build as a module >>> >> a) The driver appears to be ioremapping more virtual address space >> than the machine can provide. >> Is that expected? > > I don't know. > Is the video memory size detection of (I think) 256 MB correct? > What is the graphic chip? (CLE266, CN400, CN700, KM400, CX700 or > VX800?) > 01:00.0 VGA compatible controller: VIA Technologies, Inc. P4M900 [Chrome 9 HC] (rev 01) with shadow ram (total 2Gb, but system see 1768Mb... maybe 280Mb) after modprobe viafb don't die, they going to new state viafb 75212 1 - Loading 0xef642000 Reply-To: FlorianSchandinat@gmx.de Roman Sergeev schrieb: > 01:00.0 VGA compatible controller: VIA Technologies, Inc. P4M900 [Chrome > 9 HC] (rev 01) > with shadow ram (total 2Gb, but system see 1768Mb... maybe 280Mb) This makes sense: 2 GB physical RAM - 256 MB used as shared memory video RAM = 1792 MB available I don't know where the other memory is lost but the video memory size seems to be detected correctly. > after modprobe viafb don't die, they going to new state > viafb 75212 1 - Loading 0xef642000 I don't know if I get you right here: After "modprobe viafb viafb_accel=0" the module does no longer crash? But I don't know what state you are talking about. Is the module usable? (i.e. does "modprobe fbcon" give you a working framebuffer console?) Or can you otherwise post a new log? An alternative to disabling the hardware acceleration might be to increase vmalloc=260M to a value greater than 256+16 MB, like vmalloc=300MB or so. Okay, I think I have a deeper understanding now: - the driver tries to remap 256 MB (video framebuffer) and 16 MB (MMIO registers) - the free region is per default only 128 MB and is only on systems with significant less physical RAM than kernel virtual memory space bigger So in addition to handle the second ioremap failure (for which I have already a patch prepared) one of the following might be nice - add/reuse module/boot parameter to limit the available video memory size - automatically try to remap smaller parts of the video memory if the first ioremap fails - after having checked the code again I think it uses very rarely the remapped video memory. If I didn't miss a big thing after having my recent patches applied there might be 2-3 places left that use a few kilobytes of it. Nothing that justifies permanently remapping the whole bunch. If no one speaks against it I'll try to replace this big remap with one or two small ones. Though this might take a while. Any comments? Regards, Florian Tobias Schandinat Reply-To: FlorianSchandinat@gmx.de Roman Sergeev schrieb: > 01:00.0 VGA compatible controller: VIA Technologies, Inc. P4M900 [Chrome > 9 HC] (rev 01) > with shadow ram (total 2Gb, but system see 1768Mb... maybe 280Mb) This makes sense: 2 GB physical RAM - 256 MB used as shared memory video RAM = 1792 MB available I don't know where the other memory is lost but the video memory size seems to be detected correctly. > after modprobe viafb don't die, they going to new state > viafb 75212 1 - Loading 0xef642000 I don't know if I get you right here: After "modprobe viafb viafb_accel=0" the module does no longer crash? But I don't know what state you are talking about. Is the module usable? (i.e. does "modprobe fbcon" give you a working framebuffer console?) Or can you otherwise post a new log? An alternative to disabling the hardware acceleration might be to increase vmalloc=260M to a value greater than 256+16 MB, like vmalloc=300MB or so. Okay, I think I have a deeper understanding now: - the driver tries to remap 256 MB (video framebuffer) and 16 MB (MMIO registers) - the free region is per default only 128 MB and is only on systems with significant less physical RAM than kernel virtual memory space bigger So in addition to handle the second ioremap failure (for which I have already a patch prepared) one of the following might be nice - add/reuse module/boot parameter to limit the available video memory size - automatically try to remap smaller parts of the video memory if the first ioremap fails - after having checked the code again I think it uses very rarely the remapped video memory. If I didn't miss a big thing after having my recent patches applied there might be 2-3 places left that use a few kilobytes of it. Nothing that justifies permanently remapping the whole bunch. If no one speaks against it I'll try to replace this big remap with one or two small ones. Though this might take a while. Any comments? Regards, Florian Tobias Schandinat Hi! On 14.08.2009, at 12:49, Florian Tobias Schandinat wrote: > Roman Sergeev schrieb: >> 01:00.0 VGA compatible controller: VIA Technologies, Inc. P4M900 >> [Chrome 9 HC] (rev 01) >> with shadow ram (total 2Gb, but system see 1768Mb... maybe 280Mb) > > This makes sense: > 2 GB physical RAM > - 256 MB used as shared memory video RAM > = 1792 MB available > I don't know where the other memory is lost but the video memory > size seems to be detected correctly. > >> after modprobe viafb don't die, they going to new state >> viafb 75212 1 - Loading 0xef642000 > > I don't know if I get you right here: > After "modprobe viafb viafb_accel=0" the module does no longer > crash? But I don't know what state you are talking about. Is the > module usable? (i.e. does "modprobe fbcon" give you a working > framebuffer console?) Or can you otherwise post a new log? > > i make some "test" test # 0 # modprobe viafb FATAL: Error inserting viafb (/lib/modules/2.6.30-gentoo-r4/kernel/ drivers/video/via/viafb.ko): Operation not permitted log: Jun 22 00:34:48 mini2133 [ 89.952746] VIA Graphics Intergration Chipset framebuffer 2.4 initializing Jun 22 00:34:48 mini2133 [ 90.031236] vmap allocation for size 268439552 failed: use vmalloc=<size> to increase size. Jun 22 00:34:48 mini2133 [ 90.031244] ioremap failed test # 1 * send to kernel "vmalloc=260M" # modprobe viafb Killed log: Jun 22 00:41:50 mini2133 [ 46.690400] VIA Graphics Intergration Chipset framebuffer 2.4 initializing Jun 22 00:41:50 mini2133 [ 46.770663] vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size. Jun 22 00:41:50 mini2133 [ 46.770684] BUG: unable to handle kernel NULL pointer dereference at 00000004 Jun 22 00:41:50 mini2133 [ 46.770885] IP: [<ef64a798>] viafb_init_2d_engine+0x16/0x583 [viafb] Jun 22 00:41:50 mini2133 [ 46.771005] *pde = 00000000 Jun 22 00:41:50 mini2133 [ 46.771005] Oops: 0002 [#1] SMP Jun 22 00:41:50 mini2133 [ 46.771005] last sysfs file: /sys/devices/ pci0000:00/0000:00:0f.0/host0/target0:0:0/0:0:0:0/block/sda/uevent Jun 22 00:41:50 mini2133 [ 46.771005] Modules linked in: viafb(+) i2c_algo_bit via drm via_agp agpgart Jun 22 00:41:50 mini2133 [ 46.771005] Jun 22 00:41:50 mini2133 [ 46.771005] Pid: 4094, comm: modprobe Not tainted (2.6.30-gentoo-r4 #13) Jun 22 00:41:50 mini2133 [ 46.771005] EIP: 0060:[<ef64a798>] EFLAGS: 00010202 CPU: 0 Jun 22 00:41:50 mini2133 [ 46.771005] EIP is at viafb_init_2d_engine +0x16/0x583 [viafb] Jun 22 00:41:50 mini2133 [ 46.771005] EAX: 00000004 EBX: ed8bd280 ECX: c256d700 EDX: 00000000 Jun 22 00:41:50 mini2133 [ 46.771005] ESI: fffffffc EDI: 00000000 EBP: ed8c1f18 ESP: ed8c1f08 Jun 22 00:41:50 mini2133 [ 46.771005] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jun 22 00:41:50 mini2133 [ 46.771005] Process modprobe (pid: 4094, ti=ed8c0000 task=ee7d84e0 task.ti=ed8c0000) Jun 22 00:41:50 mini2133 [ 46.771005] Stack: Jun 22 00:41:50 mini2133 [ 46.771005] 00000000 ed8bd280 fffffffc 00000000 ed8c1f40 ef656505 00000000 ed8c1f40 Jun 22 00:41:50 mini2133 [ 46.771005] c1062132 00000000 00000000 ef6535e4 fffffffc 00000000 ed8c1f9c c1001137 Jun 22 00:41:50 mini2133 [ 46.771005] ef656000 00000000 ef6535e4 00000001 00000000 c15dec24 00000000 c15dec34 Jun 22 00:41:50 mini2133 [ 46.771005] Call Trace: Jun 22 00:41:50 mini2133 [ 46.771005] [<ef656505>] ? viafb_init +0x505/0xd2c [viafb] Jun 22 00:41:50 mini2133 [ 46.771005] [<c1062132>] ? marker_update_probe_range+0x1cf/0x1de Jun 22 00:41:50 mini2133 [ 46.771005] [<c1001137>] ? do_one_initcall +0x4a/0x10c Jun 22 00:41:50 mini2133 [ 46.771005] [<ef656000>] ? viafb_init +0x0/0xd2c [viafb] Jun 22 00:41:50 mini2133 [ 46.771005] [<c103ae2d>] ? __blocking_notifier_call_chain+0x40/0x4c Jun 22 00:41:50 mini2133 [ 46.771005] [<c10481f6>] ? sys_init_module +0x87/0x18b Jun 22 00:41:50 mini2133 [ 46.771005] [<c1002a44>] ? sysenter_do_call+0x12/0x22 Jun 22 00:41:50 mini2133 [ 46.771005] Code: ff ff 03 00 89 42 44 a1 44 38 65 ef 81 40 38 00 20 04 00 5d c3 55 31 d2 89 e5 57 56 53 83 ec 04 a1 44 38 65 ef 8b 40 1c 83 c0 04 <89> 10 a1 44 38 65 ef 8b 40 1c 83 c0 08 89 10 a1 44 38 65 ef 8b Jun 22 00:41:50 mini2133 [ 46.771005] EIP: [<ef64a798>] viafb_init_2d_engine+0x16/0x583 [viafb] SS:ESP 0068:ed8c1f08 Jun 22 00:41:50 mini2133 [ 46.771005] CR2: 0000000000000004 Jun 22 00:41:50 mini2133 [ 46.777862] ---[ end trace e41091c450ca8ab2 ]--- status: # grep viafb /proc/modules viafb 75212 1 - Loading 0xef642000 i2c_algo_bit 4656 1 viafb, Live 0xef624000 test # 2 * send to kernel "vmalloc=300M" * modprobe viafb * loaded ok status: # grep viafb /proc/modules viafb 71840 1 - Live 0xece42000 i2c_algo_bit 4656 1 viafb, Live 0xece24000 log: Jun 21 23:52:12 mini2133 [ 47.308459] VIA Graphics Intergration Chipset framebuffer 2.4 initializing Jun 21 23:52:12 mini2133 [ 47.393518] Console: switching to colour frame buffer device 80x30 but i see "test color mode" fbset -i mode "640x480-60" # D: 25.175 MHz, H: 31.469 kHz, V: 59.940 Hz geometry 640 480 640 480 32 timings 39722 48 16 33 10 96 2 accel true rgba 8/16,8/8,8/0,0/0 endmode Frame buffer device information: Name : Via Address : 0xc0000000 Size : 268156928 Type : PACKED PIXELS Visual : TRUECOLOR XPanStep : 0 YPanStep : 1 YWrapStep : 0 LineLength : 2560 MMIO Address: 0xfc000000 MMIO Size : 16777216 Accelerator : Unknown (50) if i loading module with parametrs "modprobe viafb viafb_mode=800x600 viafb_refresh=60" they still go "test color mode" log: Jun 22 00:28:11 mini2133 [ 142.994541] VIA Graphics Intergration Chipset framebuffer 2.4 initializing Jun 22 00:28:11 mini2133 [ 143.079079] Console: switching to colour frame buffer device 100x37 ps: other \ standart kernel framebuffer module on this card works well Reply-To: FlorianSchandinat@gmx.de Hi, thanks a lot for your testing! Roman Sergeev schrieb: > test # 1 > * send to kernel "vmalloc=260M" > > # modprobe viafb For my patch to fix this bug I would be interested in something like this: * send to kernel "vmalloc=260M" # modprobe viafb viafb_accel=0 If it is similar to the result of test #2 I could simply disable hardware acceleration if the second ioremap fails which is IMHO better than refusing to work as hardware acceleration is a nice to have but not crucial for device operation. > test # 2 > * send to kernel "vmalloc=300M" > * modprobe viafb > * loaded ok > > status: > # grep viafb /proc/modules > viafb 71840 1 - Live 0xece42000 > i2c_algo_bit 4656 1 viafb, Live 0xece24000 > > log: > Jun 21 23:52:12 mini2133 [ 47.308459] VIA Graphics Intergration > Chipset framebuffer 2.4 initializing > Jun 21 23:52:12 mini2133 [ 47.393518] Console: switching to colour > frame buffer device 80x30 > > but i see "test color mode" > > fbset -i > > mode "640x480-60" > # D: 25.175 MHz, H: 31.469 kHz, V: 59.940 Hz > geometry 640 480 640 480 32 > timings 39722 48 16 33 10 96 2 > accel true > rgba 8/16,8/8,8/0,0/0 > endmode > > Frame buffer device information: > Name : Via > Address : 0xc0000000 > Size : 268156928 > Type : PACKED PIXELS > Visual : TRUECOLOR > XPanStep : 0 > YPanStep : 1 > YWrapStep : 0 > LineLength : 2560 > MMIO Address: 0xfc000000 > MMIO Size : 16777216 > Accelerator : Unknown (50) > > if i loading module with parametrs "modprobe viafb viafb_mode=800x600 > viafb_refresh=60" > they still go "test color mode" > log: > Jun 22 00:28:11 mini2133 [ 142.994541] VIA Graphics Intergration > Chipset framebuffer 2.4 initializing > Jun 22 00:28:11 mini2133 [ 143.079079] Console: switching to colour > frame buffer device 100x37 This looks fine. I'd guess the driver itself is working. Unfortunately I do not fully understand the term "test color mode". Can you describe what you see? monocolor, if yes what color or some strange patterns? even whether it is shown immediately or is somehow slowly painted might help. Perhaps using the module parameter viafb_active_dev= with one of CRT, DVI or LCD helps? If it doesn't....well I'm aware of one bug in that code that I hit on my netbook. Will send you a fix if your observations sound related. > ps: other \ standart kernel framebuffer module on this card works well Yeah, the problem we now hit is some monitor misconfiguration but as the standard vga/vesa driver does not really know about those device specific things that's expected. Thanks, Florian Tobias Schandinat Reply-To: FlorianSchandinat@gmx.de Hi, thanks a lot for your testing! Roman Sergeev schrieb: > test # 1 > * send to kernel "vmalloc=260M" > > # modprobe viafb For my patch to fix this bug I would be interested in something like this: * send to kernel "vmalloc=260M" # modprobe viafb viafb_accel=0 If it is similar to the result of test #2 I could simply disable hardware acceleration if the second ioremap fails which is IMHO better than refusing to work as hardware acceleration is a nice to have but not crucial for device operation. > test # 2 > * send to kernel "vmalloc=300M" > * modprobe viafb > * loaded ok > > status: > # grep viafb /proc/modules > viafb 71840 1 - Live 0xece42000 > i2c_algo_bit 4656 1 viafb, Live 0xece24000 > > log: > Jun 21 23:52:12 mini2133 [ 47.308459] VIA Graphics Intergration > Chipset framebuffer 2.4 initializing > Jun 21 23:52:12 mini2133 [ 47.393518] Console: switching to colour > frame buffer device 80x30 > > but i see "test color mode" > > fbset -i > > mode "640x480-60" > # D: 25.175 MHz, H: 31.469 kHz, V: 59.940 Hz > geometry 640 480 640 480 32 > timings 39722 48 16 33 10 96 2 > accel true > rgba 8/16,8/8,8/0,0/0 > endmode > > Frame buffer device information: > Name : Via > Address : 0xc0000000 > Size : 268156928 > Type : PACKED PIXELS > Visual : TRUECOLOR > XPanStep : 0 > YPanStep : 1 > YWrapStep : 0 > LineLength : 2560 > MMIO Address: 0xfc000000 > MMIO Size : 16777216 > Accelerator : Unknown (50) > > if i loading module with parametrs "modprobe viafb viafb_mode=800x600 > viafb_refresh=60" > they still go "test color mode" > log: > Jun 22 00:28:11 mini2133 [ 142.994541] VIA Graphics Intergration > Chipset framebuffer 2.4 initializing > Jun 22 00:28:11 mini2133 [ 143.079079] Console: switching to colour > frame buffer device 100x37 This looks fine. I'd guess the driver itself is working. Unfortunately I do not fully understand the term "test color mode". Can you describe what you see? monocolor, if yes what color or some strange patterns? even whether it is shown immediately or is somehow slowly painted might help. Perhaps using the module parameter viafb_active_dev= with one of CRT, DVI or LCD helps? If it doesn't....well I'm aware of one bug in that code that I hit on my netbook. Will send you a fix if your observations sound related. > ps: other \ standart kernel framebuffer module on this card works well Yeah, the problem we now hit is some monitor misconfiguration but as the standard vga/vesa driver does not really know about those device specific things that's expected. Thanks, Florian Tobias Schandinat Hi! On 14.08.2009, at 16:44, Florian Tobias Schandinat wrote: > Hi, > > thanks a lot for your testing! > > Roman Sergeev schrieb: >> test # 1 >> * send to kernel "vmalloc=260M" >> # modprobe viafb > > For my patch to fix this bug I would be interested in something like > this: > * send to kernel "vmalloc=260M" > # modprobe viafb viafb_accel=0 > If it is similar to the result of test #2 I could simply disable > hardware acceleration if the second ioremap fails which is IMHO > better than refusing to work as hardware acceleration is a nice to > have but not crucial for device operation. > yes, it's working log: Jun 22 06:15:50 mini2133 [ 59.646904] VIA Graphics Intergration Chipset framebuffer 2.4 initializing Jun 22 06:15:50 mini2133 [ 59.727808] vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size. Jun 22 06:15:50 mini2133 [ 59.732024] Console: switching to colour frame buffer device 80x30 # grep viafb /proc/modules viafb 71840 1 - Live 0xef642000 i2c_algo_bit 4656 1 viafb, Live 0xef624000 >> test # 2 >> * send to kernel "vmalloc=300M" >> * modprobe viafb >> * loaded ok >> status: >> # grep viafb /proc/modules >> viafb 71840 1 - Live 0xece42000 >> i2c_algo_bit 4656 1 viafb, Live 0xece24000 >> log: >> Jun 21 23:52:12 mini2133 [ 47.308459] VIA Graphics Intergration >> Chipset framebuffer 2.4 initializing >> Jun 21 23:52:12 mini2133 [ 47.393518] Console: switching to >> colour frame buffer device 80x30 >> but i see "test color mode" >> ... >> if i loading module with parametrs "modprobe viafb >> viafb_mode=800x600 viafb_refresh=60" >> they still go "test color mode" >> log: >> Jun 22 00:28:11 mini2133 [ 142.994541] VIA Graphics Intergration >> Chipset framebuffer 2.4 initializing >> Jun 22 00:28:11 mini2133 [ 143.079079] Console: switching to >> colour frame buffer device 100x37 > > This looks fine. I'd guess the driver itself is working. > Unfortunately I do not fully understand the term "test color mode". > Can you describe what you see? monocolor, if yes what color or some > strange patterns? even whether it is shown immediately or is somehow > slowly painted might help. > > Perhaps using the module parameter viafb_active_dev= with one of > CRT, DVI or LCD helps? > If it doesn't....well I'm aware of one bug in that code that I hit > on my netbook. Will send you a fix if your observations sound related. # modprobe viafb viafb_accel=0 viafb_active_dev=LCD viafb_mode=1024x768 works.... log: Jun 22 06:30:01 mini2133 [ 40.666874] VIA Graphics Intergration Chipset framebuffer 2.4 initializing Jun 22 06:30:01 mini2133 [ 40.748196] vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size. Jun 22 06:30:01 mini2133 [ 40.752198] Console: switching to colour frame buffer device 128x48 # fbset -i mode "1024x768-60" # D: 64.998 MHz, H: 48.362 kHz, V: 60.002 Hz geometry 1024 768 1024 768 32 timings 15385 160 24 29 3 136 6 rgba 8/16,8/8,8/0,0/0 endmode Frame buffer device information: Name : Via Address : 0xc0000000 Size : 268435456 Type : PACKED PIXELS Visual : TRUECOLOR XPanStep : 0 YPanStep : 1 YWrapStep : 0 LineLength : 4096 MMIO Address: 0xfc000000 MMIO Size : 16777216 Accelerator : Unknown (50) "test color mode" - it's like lcd test : red-green-blue-grey- gradient-...etc Created attachment 25774 [details]
Segment of kern.log showing output of added debug output in relevant functions.
printk debug statements were added to the relevant functions while tracking down the problem. I've attached this trace in case it helps.
I just encountered this same error (with the same size, which is significant) testing a new driver in 2.6.31.6. There appears to be a bug in _ioremap_caller(). In my case the driver is attempting to map a PCI BAR of size 0xfffffff. _ioremap_caller() uses the supplied phys_addr and size to calculate last_addr. It then uses last_addr to calculate (and overwrite) size! A problem in itself. In re-calculating size, it first page-aligns last_addr which has the effect of rounding up the address, and thus the size. In my case size is now 0x10000000. This is the real problem: the size has effectively been page-aligned! _ioremap_caller() calls get_vm_area_caller() using that size. get_vm_area_caller() calls __get_vm_area_node() with the same size and a starting address of VMALLOC_START. Based on the size, __get_vm_area_node() determines that alignment is to 0x80000 and and adds an extra page to the size (I'm sure there's a good reason for this...) changing it to 0x10001000. It then calls alloc_vmap_area(). alloc_vmap_area() aligns vstart to an 0x80000 boundary, changing it from 0xf7ffe000 to 0xf8000000. When it validates (addr + size - 1 < addr) it overflows, failing the test and it outputs the error "vmap allocation for size 268439552 failed: use vmalloc=<size> to increase size" The main problem is that the size is (effectively) being page-aligned. I don't see any way that this can be valid. __get_vm_area_node() also page-aligns the size, producing the same problem. I still don't see how page-aligning a size can be valid, but the simple fix of removing the page-aligns breaks other things badly. Viafb on oqo model 02 (cx700). Prior to 2.6.33 not started (errors in dmesg) without vmalloc=150MB. 2.6.33 and 2.6.34 vmalloc no needed. When started with noaccel and mode 640x400-60 a few bottom lines are not visible. Trying to change mode freezes completely computer without any log. Maybe these problems are connected with ID 15372. jb $ grep viafb syslog May 11 17:32:27 leorolla-usb-boot kernel: [ 5.667046] viafb 0000:01:00.0: power state changed by ACPI to D0 May 11 17:32:27 leorolla-usb-boot kernel: [ 5.667102] viafb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 May 11 17:32:27 leorolla-usb-boot kernel: [ 5.789397] viafb: probe of 0000:01:00.0 failed with error -12 May 11 18:43:59 leorolla-usb-boot kernel: [ 5.327073] viafb 0000:01:00.0: power state changed by ACPI to D0 May 11 18:43:59 leorolla-usb-boot kernel: [ 5.327131] viafb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 May 11 18:43:59 leorolla-usb-boot kernel: [ 5.398862] viafb_init_dvi_size: DVI panel size undetected! May 11 18:49:00 leorolla-usb-boot kernel: [ 6.062497] viafb 0000:01:00.0: power state changed by ACPI to D0 May 11 18:49:00 leorolla-usb-boot kernel: [ 6.062626] viafb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 May 11 18:49:00 leorolla-usb-boot kernel: [ 6.126065] viafb: probe of 0000:01:00.0 failed with error -12 May 11 19:22:00 leorolla-usb-boot kernel: [ 1513.857084] viafb: Unknown symbol i2c_bit_add_bus May 11 19:42:46 leorolla-usb-boot kernel: [ 141.758569] viafb: Unknown symbol i2c_bit_add_bus May 11 19:49:51 leorolla-usb-boot kernel: [ 342.565394] viafb: Unknown symbol i2c_bit_add_bus $ I am so sorry. I cross-posted by accident from Bug #15870. |