Bug 15870

What do you think about passing kernel parameters during boot?
Like viafb.mode , viafb_active_device or viafb_accel=0.

jb

video=viafb:off
didn't help with Ubuntu

video=viafb:viafb_accel=0
didn't help with Ubuntu

Other users reported that they could boot when
remove "quiet splash" and add "viafb.modeset=0"

Recently Ubuntu's branch of module-init-tools is not loading viafb by default, so Ubuntu users can boot.

I don't know if it was blacklisted by Ubuntu before, or if it has anything to do with a Kernel change between .31 and .32, I don't have any idea of how automatic module loading works.

I can still make it freeze by doing
sudo modprobe viafb

It also freezes when I run
sudo modprobe viafb viafb_accel=0

Which tests would you like me to do?

Hi,
if "video=viafb:off
didn't help " so maybe viafb is compiled into kernel (is viafb.ko under /lib/
modules/... ?) and no other fb is avaiable.

I have another chipset (cx700, oqo model 02) so in your case the things may be different.

In may case:
1.
prior to kernels 2.6.33 viafb did not work without kernel options vmalloc=150MB
(or 190MB, 255MB - I do not know which is the best)
2. for 2.6.33 and 2.6.34-rc5 I do not need to use vmalloc option
3. I have also added video="viafb_active_dev=LCD+DVI
(without this it happend to display on device - I would like to know where...)
4.the only mode it works (in my case) is 640x480-60
(if I try to change the mode computer freezes)
So, maybe in your case there is also one (or more) mode it works.
5. when I start viafb in such a configuration I do not see a few bottom lines
  (partial success). So I may blacklist viafb and boot with vga=ask.

I think, that is all my experience with viafb.

Janusz

$ pwd
/lib/modules/2.6.32-21-generic/kernel/drivers/video/via
$ ls
viafb.ko
$ 

At
https://bugs.launchpad.net/bugs/558569
and mostly on its duplicate
https://bugs.launchpad.net/bugs/539020

You can see some tests I have done with another kernel developer.

It can be a particularity of Ubuntu that some kernel options are not respected during all the boot process.

For instance, video=viafb:off boot option didn't help, but adding 'blacklist viafb' to /etc/modprobe.d/whatever.conf made it work fine.

vga16fb is loaded by default

Ubuntu already fixed its branch of module-init-tools and I'm happy with it. The idea of filing this upstream bug is to test the latest kernel to see if viafb will eventually work fine with this shipset.

Also, my device shouldn't be inclusded at modules.pcimap since 2.6.32, as it really doesn't work with viafb.

Hi,
I think that there is a chance to start viafb
with options mentioned above, especially vmaloc.
Similar problems for Chrome 9 HC
were reported in ID 13976.

Thanks
Janusz

Following Florian's suggestion at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539020

I have already tried
vmalloc=268435456

What should I do exactly?

For vmalloc, the more the better, or the less the better?

I can try with vmalloc=400MB if you want.

On the BIOS setup they let me choose if I want to give 128MB or 256MB of my RAM to the graphics card.

So it makes a big difference if I boot with 2.6.32 (currently the official kernel for Ubuntu 10.04) or 2.6.34 ( from https://wiki.ubuntu.com/KernelTeam/MainlineBuilds ) ?

Thanks for posting this bug.
Can you please test Jon's patches? None of them are labled as bug fixes but there is the chance of accidently fixing it. I just want to make sure that we don't end up figuring out a hardware issue that won't exist in the future code.
You can get a full kernel tree with these patches by
git clone git://git.lwn.net/linux-2.6.git
cd linux-2.6
git checkout origin/viafb-posted
Then just compile and test it (probably together with "vmalloc=" would be most useful)
If it does not help I'll try to rip the I2C stuff out of the driver (which is currently my main suspect) and post a test patch to figure out whether the issue is really located in the I2C code.

@Leo:
vmalloc just reserves space that is different than reserving real memory (RAM). The problem is that you have more video memory than the space reserved for accessing it. Currently viafb very poorly fails for such cases. Any size that makes the ioremap failure disappear is enough.
Concerning viafb every kernel version makes a huge difference as there currently is a lot of work going on. That's also a reason for working on top of the code that will likely appear in 2.6.35

@jb:
The (current) default output of viafb is the primary/CRT output. It might be possible that there is no hardware output wired to it (so it's maybe sort of dead end)
I would be also interested in your mode changing bug. Do you mind opening a bugreport for it if you have some spare time? It would help to know whether this happens only if you use fbset or also if you try specifing a different mode via viafb_mode and whether pure frequency selection via viafb_refresh is affected.

Thank you very much for detailed information.
I am testing with git and others kernels.
By the way, the:
"2. for 2.6.33 and 2.6.34-rc5 I do not need to use vmalloc option"
is not true (without vmalloc vga16fb was started ....)

I don't know what "just compile and test it" means in terms of terminal commands.

"make && sudo make install && sudo update-grub && sudo reboot" ?

When booting, "vmalloc=400MB" is fine?

After boot and login, "sudo modprobe viafb" is fine?

I'm running standard Ubuntu 10.04.

@jb
Thanks. I hope to get rid of the need for vmalloc in future but it is tricky.

@Leo
That sounds mostly correct (I think you need to configure the kernel before via "make menuconfig" or similiar). That would work but you do probably prefer a way that's better integrated in your distro. I just tried searching one to give you an idea what I'm talking about but can't say how up-to-date or correct it is:
http://www.howtoforge.com/kernel_compilation_ubuntu_p2
(page 2 is relevant as page 1 is done via the steps I described above). Hope you can figure out the correct way. The steps you described should also work so if you are unsure you can also use them.
Testing as you described is fine.

Some test are in ID 15904, thanks again - I have additional modes :)

In Ubuntu my way to copile kernel was:
1.copy config  xx like in
http://www.howtoforge.com/kernel_compilation_ubuntu_p2
2. make xconfig or menuconfig
3.readthis xx config
4. to skip kpkg, initrd, etc
I changed from modules to compiled-in drivers for my hdd
5. make 
6. make modules_install
7. lilo.conf and lilo

@Leo
Do you have any problems while compiling kernel?
It is very easy, after installing first own kernel it is just automatic.

I am following https://wiki.ubuntu.com/KernelTeam/GitKernelBuild

Replacing instructions 1-2-3 by

git clone git://git.lwn.net/linux-2.6.git
cd linux-2.6
git checkout origin/viafb-posted

Note instruction 6. Should I enable "Kernel debugging" ?

As there is no one else I can push the work on, I'll take this bug.

@Leo
Okay.
It's more like replacing 2-3, you can still do it everywhere you want (step 1).
Well although I don't expect it to help very much in this case, debugging is in general a good idea when debugging problems so I'd enable it.

Created attachment 26274 [details]
screenshot kernel panic

I couldn't boot.

Any suggestios?

Did not I say
"4. to skip kpkg, initrd, etc" ? :)

There is something bad with initrd -
the new kernel does not see your hdd.

I think that there are two ways to solve it.

1. construct right initrd/initramfs
(ie one which loads modules for your hdd)
Do you have involved a initrd in grub/lilo?

or
2. lsmod, find modules for hdd,
make menuconfig/xconfig, change these to built-in,
grub/lilo for this new kernel (without any initrd/initramfs)

Did not I say
"4. to skip kpkg, initrd, etc" ? :)

There is something bad with initrd -
the new kernel does not see your hdd.

I think that there are two ways to solve it.

1. construct right initrd/initramfs
(ie one which loads modules for your hdd)
Do you have involved a initrd in grub/lilo?

or
2. lsmod, find modules for hdd,
make menuconfig/xconfig, change these to built-in,
grub/lilo for this new kernel (without any initrd/initramfs)

If you boot from an usb device (pendrive, external hdd) 
there is only the first way.

If you prefer the way with initramfs maybe it would be good idea
to unpack "the maintainers - working" initramfs and this new one?
One can next see if both have been loading the same modules.
I don't know from what device you boot and how you boot.
So my answers can be only very general.

Hi jb,

It is a laptop, with magnetic HD, an MBR, some primary and logical ext4 partitions with latest Ubuntu standard install, so using Grub 2. More detais about the hardware can be found in the automatically attached files at https://bugs.launchpad.net/bugs/539020

I will try to recompile it with other settings to see if I can overcome this filessystem mounting issue. I know nothing about building and setting up kernel. So it sounded simpler to just follow https://wiki.ubuntu.com/KernelTeam/GitKernelBuild as it gives me terminal commands to copy-paste :-)

Hi Leo,
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild 
looks fine but about initrd/initrfs
there is only ".. make-kpkg --initrd ...".

Who knows what is the resulting image.
I think however, that your last steps are the grub use,
and you put in grub config file the  name of your image
(something like "initrd=your_image" ).

If you would like you could inspect yours and maintainer's images, as follows.

1. copy /boot/mainainer_image to a current working directory.
2. if its name does not end with .gz
  mv maintainer_image maintainer_image.gz
3. gunzip -9  maintainer_image.gz
4. cpio -i < ./maintainer_image.gz

One level "bellow" the current directory you will see
the unpacked image. You will find modules and can
look into ../curren_working_directory/init  .

The same you could do with your_image.

Maybe "it sounded simpler" but you probably have correct kernel
(if you used "maintainers kernel config" ) and problems are hidden
in initrd image).

4. cpio -i < ./maintainer_image

:)

and 
3. gunzip   maintainer_image.gz

I'am very sorry (copy and paste .....)

Created attachment 26320 [details]
syslog, lsmod, and kernel version - without vmalloc

As long as it boots we are fine?

Cause it did boot!

( I followed https://wiki.ubuntu.com/KernelTeam/GitKernelBuild#Using%20Ubuntu%20Kernel%20Configuration )

Without the vmalloc, I could even loaded viafb without freezing.

It complained that it couldn't do much without proper vmalloc, but it loaded.

I will try to get some Desktop special effects now and see if it freezes. Then reboot and be right back.

Great : :)

Created attachment 26322 [details]
syslog with vmalloc

Booted in recovery mode.

Logged in as root.

Ran:
$ sync ; sync ; sync
$ modprobe viafb ; sync ; sync ; sync
to get as much as possible to the attached syslog.

First time with vmalloc=300MB, second time with vmalloc=180MB

It freezes the screen and most of the keyboard (Capslock freezes, but numlock, wireless on/off and brightness still work).

I will now try to learn how to run these tests from a pendrive, and how to keep the HD off, it is getting very unhappy with all these hard poweroffs.

viafb_accel=0 ??
You can try to test with several viafb_mode
(booting from pendrive of course; I have seen something like
"ubuntu live" on the net; mkinitrd/mkinitramfs is needed to
get correct image or ...   :)  )

something like

$ modprobe viafb viafb_mode=640x480 viafb_accel=0

?

Anything to add to the boot line?

Hi Leo,

it's good that you managed to compile and boot your own kernel. Can you please update to our latest driver via

git reset --hard
git fetch origin
git checkout origin/viafb-posted

in your .../linux-2.6/ directory as we have fixed 3 bugs there and you are hitting at least one. It works quickly and just fetches a few 100KB. After that you need to recompile the module via
make modules
or
make M=drivers/video/via modules
(the later recompiles only the module but might be more problematic)
and than testing via (assuming that no framebuffer is loaded yet)
insmod drivers/video/via/viafb.ko <module parameters>

Please note also that all tries without vmalloc are a waste of time as viafb does not load correctly (even if you have a different impression due to one bug that was fixed in the meantime)

I hope that you can find something that keeps your HD alive. It's not trivial to remaster some of the live distributions to run a custom kernel. Theoretically for testing the viafb.ko and a statically complied busybox (with insmod) on a pendrive (or even a ramdisk) would be sufficient but I don't know a good way to shut down all Ubuntu services running that would allow you to send your HD to sleep via hdparm after mounting the pendrive.

I'll try to get a patch ready in the next few hours to actually start finding and fixing the bug. Thanks.

Hi Leo,
update first, as Florian said.
Maybe it not freezes your laptop but only switch display to CRT
(it was the case for my umpc for kernel taken about week ago,
after update two days ago it also display on LCD:  viafb_active_dev=LCD)

I have viafb compiled as module so I put options in modprobe.conf,
and reboot after changing say viafb_accel.

In the case I can see what is on the screen I am traying eg.
fbset "800x480-60"

@Florian  hdd safe ?
My own live distribution mount only a partition from an usb device
and several files from that partition (eg fs.squash as ro rootfs).
All my disks may be rw mounted if I want.
If a disk is not mounted is it safe during crash?

Hi Leo,

by the way what is the "Driver" and "Options"
in your xorg.conf (Section "Device")?
I have also troubles with accel in X,
maybe X problems and viafb are connected ...

I won't run a live distribution, I will do a full Ubuntu install to a USB partition.

Ubuntu can turn off the power of other devices, and after that you cannot even mount them. Palimpsest 2.30.1 offers to poweroff disks (I guess behind the scenes it only asks the kernel to do that), so hard that it even disappears from the /dev folder.

Is that really safe? Can I really turn off the power of an unmounted disk?
___

As you see on the latest syslog, both times the last recorded line was:
viafb_init_dvi_size: DVI panel size undetected!

Maybe it only switchs display to CRT, but as a side effect, even the keyboard is frozen. In Ubuntu 9.10, pressing the power key makes it poweroff after a countdown of 60 seconds, and yet it didn't react to this key.

I will try viafb_active_dev=LCD aftwer I overcome the HD issue.
___

I cannot know if X problems and viafb are connected, but viafb freezes the same way when I choose recovery mode from the boot menu.

This latest xorg does not use an xorg.conf file. I googled a lot but no luck.
___

"make modules" asked a question, I just pressed enter:
  VIAFB camera controller support (VIDEO_VIA_CAMERA) [N/m/?] (NEW) 

$ lsmod | grep fb
fbcon                  35102  71 
tileblit                2031  1 fbcon
font                    7557  1 fbcon
bitblit                 4707  1 fbcon
vga16fb                11385  1 
vgastate                8961  1 vga16fb
$ 

I just need to remove vga16fb before 
insmod drivers/video/via/viafb.ko <module parameters>
?
___

Is it a good idea that you give me a .img file with the minimal contents so that writing it to an active primary ext2 usb partition allows me to boot, poweroff hd, and perform the tests, without interference from distro stuff or xorg?

I did

( sleep 10 ; hdparm -Y /dev/sda ; poweroff ) & insmod viafb.ko viafb_active_dev=LCD viafb_accel=0 viafb_mode=640x480-60

It froze but in a totally different way. There was stuff written at the screen. It was silent for about 1 minute, then the cooler started, but not so strong as in the other freezes.

When I powered it down it didn't make so bad a hurting noise either.

Hi Leo.
I will try to answer for some of your questions,
maybe Florian will give deeper explanations.

1. I agree, but live is close connected
(I have some days seen something like "ubuntu flash booting")

2. I don't know if power off for devices is required to be sure
   that hdd is safe

3 ?

4. For now, I am ignoring so soft (?) problems

5. This looks really vary bad for me
  (Florian said that there will be a patch to investigate this)

6. In my case viafb is enough stable to test without booting from usb;
  I do not start X (gdm/kdm) automaticaly after boot (/etc/rc# )
   so I can test only problems connected with fb (not X).
   As Florian said, preparing usb-ubuntu with rc3 kernel
   may take same time 
7. I think that they are closly related 
  (doing experiments with X sometimes viafb console is destroyed;
  the code for fb and X driver probably are writing to the same
  hardware I/O ports, ....)

8. Maybe you could look into  /var/log/Xorg.log and see
   if it looks that vesa driver is used
  or openchrome?
9. ?

10. if I use vmalloc both vga16 and viafb are loaded and viafb is active;
 if the activity of viafb (after setting some parameters in modprobe.conf)
is that I cannot see anything I type reboot Enter - for my umpc it works;
next time I boot without vnalloc, vga16 is active and I can change modprobe.conf

11. I don't think. First, I am now using my own img containig modules from 2.6.32
(not this where Florian make changes). Second, this img works very good with all my computers, but is not written in so general way to be sure that works on every computer. I think that the way to use it would be:
  a)unpack my img
  b)exchange modules by the from 2.6.34-rc3
    and libraries from your ubuntu
  c)pack it again
  d)boot from internal hdd but mouting file system which is on usb device
    (for that I am using another img)
  e)and finally write MBR by grub/lilo on usb device
It may take some time when doing first time.
I am not sure if this is a way you would like. I can attache my img,
but it will take some further work.
On the other hand you are very well booting with img using only ubuntu tools.
It could be much more simple way. 

The easiest way would be booting from internal disk on the conditions that hdd is safe
(maybe not starting X, with native mode and without accel )

Please, do not smile too much from my methods.
I am using gentoo now and there are tools in gentoo to make bootable flash drives
(in ubuntu also, I am almost sure) but for me my way is more simple.
But, I have spent about two days (maybe four years ago) to start first live/flash
and now I am doing only small changes .....

What is your booting device when you are doing hdparm?

The patch I obtained:
viafb not really started, so no crashes,
patched kernel only is doing some tests for the driver.

It is the best way, I think

 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
$

Created attachment 26345 [details]
Xorg.0.log

@jb
If you don't have mounted the disks that will prevent damaging the file system. But an uncontrolled power off might put some physical strain on the disks if they are still spinning. Although I assume that most modern disks should handle it gracefully (as power outages can occur any time) it can't hurt to stop the spinning before. But I'm not an expert here.

@Leo
Yes, this sounds like a good idea. Yes, it should be safe to turn the power of unused drives off (although I don't know what exactly the tool you mentioned does). Probably everything that keeps the disks from spinning should be good enough.
___
Yes, I saw that line. But it doesn't reveal anything. I still think that the most probable cause of this mess is some I2C stuff as if I recall it correctly it used to crash even without the "vmalloc=" option (and therefore it crashed before touching any of it's core functionality like mode setting or hardware acceleration) so no need to test the "viafb_active_dev=" option yet.
___
___
Yeah just pressing enter was alright. For the crash we are not interested in whether Jon's new camera driver works.
Well removing a framebuffer module is really painful. Probably it would be easier to also blacklist vga16fb. But while at it: I hope what we are seeing is not a resource conflict between vga16fb and viafb as using modprobe and insmod is very similar. Please test whether blacklisting vga16fb (and ensuring that no framebuffer is running) is all that is needed to fix the problem.
___
Your idea is better. I was just worried about space but if a "full" installation on USB is not a probelm that's fine with me. At least I do neither blame X nor Ubuntu for anything that is happens until now. And I'm currently also a bit short on time and doing such an image would take a lot.

@Leo-2
Um, we currently do not support mode strings in the form viafb_mode=640x480-60 but only viafb_mode=640x480 viafb_refresh=60. Is this with the updated and recompiled driver? That would worry me as than we would exit without touching the hardware _at_all_. Instead it should just output somethin like this:
"insmod: error inserting '.../viafb.ko': -1 Invalid parameters"

$ cat xorg.conf 
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# Note that some configuration settings that could be done previously
# in this file, now are automatically configured by the server and settings
# here are ignored.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "Device"
	Identifier	"Configured Video Device"
EndSection

Section "Monitor"
	Identifier	"Configured Monitor"
EndSection

Section "Screen"
	Identifier	"Default Screen"
	Monitor		"Configured Monitor"
	Device		"Configured Video Device"
EndSection
$

I did 3 tests, results are similar:

( sleep 10 ; hdparm -Y /dev/sda ; poweroff ) & insmod viafb.ko
viafb_active_dev=LCD viafb_accel=0 viafb_mode=640x480-60

( sleep 2 ; poweroff ) & insmod viafb.ko viafb_active_dev=LCD viafb_accel=0
viafb_mode=1280x800-60 viafb_display_hardware_layout=0

insmod viafb.ko viafb_active_dev=LCD viafb_mode=1280x800 viafb_refresh=60
viafb_accel=0 & ( sleep 2 ; poweroff )

viafb complains about a variable set to -1 or so, but it's too quick for me to
read.

Then it proceeds to shut down and stops with a lot of dmesg at the screen.

Last lines are
[  "time" ] CR2: 0000....00001c
[  "time" ] ---[ end trace 60064669ba5531bb ]---

From there I do a hard poweroff, but it makes no bad noise.

Each case viafb left me the same message to the syslog (I will show next).

My hardware is odd enough so hard poweroff could make damage, even unmounted. That's why I wanted it unmountd and unspinned ;-)

hdparm -Y /dev/sda should do the trick, although with my odd HD it only lasts a second. hdparm -y /dev/sda at least puts it slow instead of sleeeping.

I installed Ubuntu 9.04 to a USB. It's a true install, in a primary ext3 partition. I used the distro LiveUSB to install to another USB. And I explicitly told it no to use the swap from /dev/sda

"insmod: error inserting '.../viafb.ko': -1 Invalid parameters"

It really sounds like what I (almost) saw!
I guess it was it.

// Post 42 should be at position 36, we made posting conflicts.

> That would worry me as than we would exit without touching
the hardware _at_all_. Instead it should just output somethin like this:
"insmod: error inserting '.../viafb.ko': -1 Invalid parameters"

Indeed, it just exited gracefully. It was my "poweroff" that had its effect.

So, your hdd is safe now?

How do you know that "My hardware is odd enough so hard poweroff could make damage, even unmounted" ?

Your new distro (ubuntu on usb) does not load viafb during system start?
(udev should do it)

I didn't   insmod yet, I have parameters in modprobe.conf
and  viafb is loaded before logging.

Have you used vmalloc parameter ?

Thanks for info about hdd
and Xorg.0.log :)

Created attachment 26347 [details]
patch to test if i2c causes the crash

@jb
Ubuntu has blacklisted it in the meantime.

@Leo
Attached is a patch to find out whether the crash happens in the i2c area. Please go to your .../linux-2.6/ directory and apply it via
patch -Np1 -i <patchfile>
and recompile the module
make modules
and test it just as before (boot with "vmalloc="; insmod viafb.ko) and say whether it behaves different. Thanks.

Oh, I just forgot to mention:
Please do a
modprobe i2c_algo_bit
before insmod viafb.ko to avoid "viafb: Unknown symbol i2c_bit_add_bus" (normally modprobe takes care of such things but as we just insmod it instead of replacing the existing viafb and using modprobe we have to do this on our own)

(In reply to comment #37)
> The patch I obtained:
> viafb not really started, so no crashes,
> patched kernel only is doing some tests for the driver.
> 
> It is the best way, I think

Yeah, I like the idea. How can I apply it?

(In reply to comment #47)
> @Leo
> Attached is a patch to find out whether the crash happens in the i2c area.
> Please go to your .../linux-2.6/ directory and apply it via
> patch -Np1 -i <patchfile>
> and recompile the module
> make modules
> and test it just as before (boot with "vmalloc="; insmod viafb.ko) and say
> whether it behaves different. Thanks.

In this case I will run again without this patch but with modprobe i2c_algo_bit, so I can tell if it behaves _different_ :-)

My hdd oddity... I cannot say for sure, but I can hear it spinning, and I can hear a nasty sound when I do a hard poweroff, and it sounds and more rough after that. But sure I can't say for sure.

Hi Leo,
probably this is inadequate to your hardware,
but for my via cx700 I blacklist:
usb (ehci, uhci, usbcore),net, wifi, sound
and testing viafb somtime I have loaded via-agp, sometimes no.
So, if you want, blacklist them and see if there are any differences.
(If there will be no crash ....  - but, I don't think so)

The order of mails here is terrible....
@#49
Just ask Florian for a patch which ends its investigation before crash.
(I have obtained this kind patch, but in the meantime
Florian also has removed "my crashes" at all -
and this an idea I like :)  )

Before the patch:

modprobe i2c_algo_bit
sync ; ( sleep 2 ; poweroff ) & ( insmod viafb.ko viafb_active_dev=LCD 
viafb_mode=1280x800 kkk 60 viafb_accel=0 ; sync ) & sync ; sync

Freezes so bad that the "poweroff" command is never lauched.

Nothing written to /var/sys/syslog (nothing at all, so I guess it is rather related to booting options of 'recovery mode' than viafb)

With the patch:

leorolla@leorolla-usb-boot:~$ cat /var/log/syslog | tail 
May 12 14:22:02 leorolla-usb-boot anacron[3539]: Anacron 2.3 started on 2010-05-12
May 12 14:22:02 leorolla-usb-boot anacron[3539]: Normal exit (0 jobs run)
May 12 14:23:30 leorolla-usb-boot kernel: [  116.833466] handle_rx_packet: invalid, small RX packet : 1
May 12 14:26:08 leorolla-usb-boot kernel: [  275.076066] VIA Graphics Intergration Chipset framebuffer 2.4 initializing
May 12 14:26:08 leorolla-usb-boot kernel: [  275.078658] viafb 0000:01:00.0: power state changed by ACPI to D0
May 12 14:26:08 leorolla-usb-boot kernel: [  275.078700]   alloc irq_desc for 16 on node -1
May 12 14:26:08 leorolla-usb-boot kernel: [  275.078704]   alloc kstat_irqs on node -1
May 12 14:26:08 leorolla-usb-boot kernel: [  275.078724] viafb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
May 12 14:26:08 leorolla-usb-boot kernel: [  275.093376] viafb: no GPIOs configured
May 12 14:26:08 leorolla-usb-boot kernel: [  275.093857] viafb_init_dvi_size: DVI panel size undetected!
leorolla@leorolla-usb-boot:~$ lsmod | grep fb
viafb                  78098  0 
i2c_algo_bit            4852  1 viafb
leorolla@leorolla-usb-boot:~$ 

Not bad :-)

I will now try to enable ubuntu desktop shiny kung-fu effects. Let me post beforhands just in case.

So it looks like we've found the origin of this bug. I am currently trying to find out what is needed to get it really fixed. I don't want to disable I2C by default (and add another annoying module option to allow enabling it) if there is a way around it. Hope we can get it fixed before 2.6.35 is released.

By the way, it's not a regression as viafb never worked for you (I assume). You just noticed it because the module was not loaded automatically on older kernels.

Just a little unrelated question:
Does it also work without "viafb_accel=0"?
And you probably also want to do a "modprobe fbcon" after you loaded viafb to actually see whether it works (your console resolution should change than to the 1280x800 you specified).

It had some fbcon loaded somewhere after. I will check with care.

I didn't do an extensive test of all combinations.Pure "modprobe viafb" freezes as badly as before. I will try a few more (first removing viafb_accel=0) and report back.

When it loaded successfully, first it scrambled the whole screen and its colors, and then after I played with the desktop it suddenly became all smooth.

I wrote to the maintainer of this nice page http://kmuto.jp/debian/hcl/index.rhtmlx (actually that's how I first suspected that it was viafb preventing me from booting ubuntu testing release) and he replied to me saying that all his database comes from a modules.pcimap file. Unless there is some misunderstanding somewhere, it is a truly severe regression bug for that file saying that my hardware is supported since 2.6.32 with viafb.

update:

Without viafb_accel=0 it worked just as well........

confb is loaded and it changes console resolution, but scrambles all its pixels around, in a periodic fashion.

The computer gets much slower after loading viafb.

Still desktop effects cannot be enabled, they say the driver was not found.

Strange... now it works whether or not I give it parameters...

I even removed it from the blacklist and copied viafb.ko to the true folder and it loads fine during boot.

*sigh* I hoped that someone would come up with a better idea to fix this in the meantime. I guess I'll answer your questions now and then wait for another week for suggestions.

Well a regression would be something where we get further away from the desired destination (which is, of course, supporting your hardware). viafb "supports" your hardware beginning with linux kernel 2.6.28 so if there was a point between 2.6.28 and now where a "modprobe viafb" did not cause this crash than you were right and this is a regression, I'd ask you to show me exactly what patch caused it and based on this produce a fix. However until now I understand that this is not the case but the only thing that happened is you noticing that it does not work because it gets auto loaded in 2.6.32 and later. This is no regression as we technically use only the correct API. That this has side effects like auto loading and the entry in modules.pcimap was not the main point of the patch but can't be avoided (I think) because the later is auto-generated and the module (auto) loading is controlled by your userspace. And please keep in mind that it would be impossible to ensure that it works for all. As I've told you there are some people with the same IGP (that makes it for viafb the same hardware) who successfully use the driver (probably a different motherboard than yours but that is nothing viafb normally "sees").

It would be very strange if viafb slows down your computer.

Probably those desktop effects you are talking about would need 3D/drm (just a wild guess). That's completely different from viafb and unfortunately not likely to happen. I think there is some non-free drm support for your IGP from VIA but installing this could be painful and might force you to downgrade parts of your system (and it's non-free anyway). It's questionable whether there will be ever 3D support for your (P4M900) and mine (VX800) IGP, sorry.

OK. If you need further testings I will do them.

Created attachment 30312 [details]
test if reordered i2c initialization works better

This patch makes small changes to the I2C initialization. It could be that this fixes the bug (at least it improves the behavior in I2C related issues I can test) and it would be no problem to add it to mainline.
Can you please test whether this patch applied to a kernel that would crash otherwise helps?