Skip to contentSkip to conversation

New: viafb + vmalloc

Bugme-new Andrew Morton 3 participants 7 messages Aug 13, 2009 – Aug 14, 2009 1 message not in the archive Framebuffer layer

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

#1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 16 lines · On Thu, 13 Aug 2009 15:22:41 GMT [email protected] 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: [email protected]
        ReportedBy: [email protected]
        Regression: No

OK, this is bad.

Quoted 71 lines

#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 ]---
Quoted 2 lines

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.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

#2 lore raw

Hi,

excuse me to interfere although I don't know the memory subsystem/functions very well.

Quoted 95 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 16 lines · On Thu, 13 Aug 2009 15:22:41 GMT [email protected] 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: [email protected]
        ReportedBy: [email protected]
        Regression: No

OK, this is bad.

Quoted 70 lines

#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 ]---
Quoted 7 lines
Quoted 2 lines

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?)

Quoted 5 lines

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

#3 lore raw
Quoted 12 lines · Florian Tobias Schandinat
Quoted 6 lines
Quoted 3 lines

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

#4 lore raw
Quoted 3 lines · Roman Sergeev

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.

Quoted 2 lines

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

#5 lore raw

Hi!

Quoted 12 lines · Florian Tobias Schandinat
Quoted 3 lines · Roman Sergeev

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.

Quoted 10 lines
Quoted 2 lines

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

#6 lore raw

Hi,

thanks a lot for your testing!

Quoted 4 lines · Roman Sergeev

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.
Quoted 42 lines

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)
Quoted 8 lines

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.

Quoted 1 line

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

#7 lore raw

Hi!

Quoted 9 lines · Florian Tobias Schandinat

Hi,

thanks a lot for your testing!

Quoted 3 lines · Roman Sergeev

test # 1
* send to kernel "vmalloc=260M"

# modprobe viafb
Quoted 9 lines

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
Quoted 30 lines
Quoted 15 lines

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"
...
Quoted 8 lines
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.

Quoted 4 lines

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july