since kernel .39 i can not boot, when kernel go to gmbus start the issue. I try capture a dump with kexec, but no success, so i have the idea to make video booting, kernel version 2.6.39-02745-g0b26d47 and 2.6.39 vanilla same problem.
lspci -v 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Elitegroup Computer Systems Device 995b Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f8000000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 3 Kernel driver in use: i915
att
Hi Yermandu,
Please pay attention when writing and proofread yourself before sending. You certainly meant i915, not i195, in the subject line. I've fixed it. This is important if you want to get the attention of the relevant maintainers and developers.
On Mon, 23 May 2011 19:33:15 -0300, Yermandu Patapitafious wrote:
since kernel .39 i can not boot, when kernel go to gmbus start the issue. I try capture a dump with kexec, but no success, so i have the idea to make video booting, kernel version 2.6.39-02745-g0b26d47 and 2.6.39 vanilla same problem.
What is the last kernel that works for you?
Are you running self-built or distribution kernels?
Can we please see the kernel configuration file? You seem to have verbose debugging options enabled (CONFIG_DEBUG_KOBJECT at least.) it makes the logs harder to read.
Unfortunately the beginning is pretty hard to read. It would be great if you were able to get us the kernel logs in a text form, using some form of serial console.
I see references to i2c_for_each_dev, a new function which only i2c-dev and i2c-core are using at the moment. So if you have CONFIG_I2C_CHARDEV set, and this is a self-built kernel, try again without it just to get it out of the picture.
Note that logs from a pure 2.6.39 kernel would probably be more useful than from a later git snapshot. The 2.6.40 development branch is very young and could have other problems.
Alternatively, if you are familiar with git, a git bisection would help too.
Hello Jean,
Thanks for answer, i will take more atention in subjects,
What is the last kernel that works for you?
Are you running self-built or distribution kernels? Can we please see the kernel configuration file?
My Last kernel working from git repository was 2.6.38-rc8+, the stable line .38.X work fines. I use the git version from kernel.org site pull and build manually be me. The Latest Stable Kernel is from gentoo-sources, and i always compile manually too. I have attached .config kernel in mail.
It would be great if you were able to get us the kernel logs in a text form, using some form of serial console.
Removing the CONFIG_I2C_CHARDEV has not effect, the panic continues happing I looking for some way to send panic log in text, but no success yet.
On Wed, 25 May 2011 10:38:59 -0300, Yermandu Patapitafious wrote:
Hello Jean,
Thanks for answer, i will take more atention in subjects,
What is the last kernel that works for you?
Are you running self-built or distribution kernels? Can we please see the kernel configuration file?
My Last kernel working from git repository was 2.6.38-rc8+, the stable line .38.X work fines.
OK, this is good, it means the bisection domain isn't too big.
Can you remember if you made any kernel configuration change between 2.6.38 and 2.6.39?
I use the git version from kernel.org site pull and build manually be me. The Latest Stable Kernel is from gentoo-sources, and i always compile manually too. I have attached .config kernel in mail.
I see you have many debug options enabled. I suggest you try building a kernel without these and see if it makes a difference.
It would be great if you were able to get us the kernel logs in a text form, using some form of serial console.
Removing the CONFIG_I2C_CHARDEV has not effect, the panic continues happing I looking for some way to send panic log in text, but no success yet.
If you can't get a serial console to capture the complete error log, the other approach is to bisect between kernels 2.6.38 and 2.6.39, to find the faulty commit. If you're used to building your kernel yourself, it shouldn't be too difficult. Just clone Linus' kernel tree and follow the git bisect manual page: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
Can you remember if you made any kernel configuration change between 2.6.38 and 2.6.39?
At begin not, I reutilize the config file when the issue start. I do the bisect session, in the end i receive the message:
674479124f8cbc4b5507d914ccd63ad08fd5326e was both good and bad
Bisect log attached.
I try config file removing some set, and fight with console. I m back if i get log.
dri-devel@lists.freedesktop.org
-
Jean Delvare -
Yermandu Patapitafious