dmesg output: are any of these bugs?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I've just build 2.6.29-rc8 from GIT, and booted it successfully. I then
compared the dmesg output with that generated by the current Ubuntu
Jaunty kernel (2.6.28.8-9) on the same hardware. There are some
differences that seem significant to me. Perhaps people here could
indicate which are worth reporting, and to where?

The test system is an hp/compaq nc8430 laptop, Core Duo, ATI graphics.

The source was fetched from
   ...
with "git log" reporting this as the most recent commit:
  commit 326d8519fc97be186c55ac605c3a7c957c758ae1
  Date:   Sat Mar 14 12:02:21 2009 -0700


Lines with "<" are from 2.6.28-9's dmesg.
Lines with ">" are 2.6.29-rc8's dmesg.



# whole new (and mildly scary) message
> FADT: X_PM1a_EVT_BLK.bit_width (16) does not match PM1_EVT_LEN (4)




# build process automatically adds crashkernel option, but it is
# not right. Possibly this is an issue with the debian/ubuntu build
# process rather than the kernel or kbuild..
#(Kernel command line: root=UUID=2d002b46-48ff-4439-a542-d613bc58c8f0
#  ro quiet splash  crashkernel=384M-2G:64M@16M,2G-:128M@16M)

> crashkernel reservation failed - memory is in use




# woohoo - my cpu is now magically faster :-)
# Is this clock difference significant?

< Fast TSC calibration using PIT
< Detected 1994.913 MHz processor.
---
> TSC: PIT calibration matches PMTIMER. 1 loops
> Detected 1994.953 MHz processor.

< Calibrating delay loop (skipped), value calculated using timer
frequency.. 3989.82 BogoMIPS (lpj=7979652)
---
> Calibrating delay loop (skipped), value calculated using timer
frequency.. 3989.90 BogoMIPS (lpj=7979812)




# new kernel is considerably larger: (I do have btrfs enabled in
# new kernel, and added "Y" to new config options
# that default to Y but this is a 10% increase)

< Memory: 2052884k/2096960k available (4032k kernel code, 42624k
reserved, 2199k data, 528k init, 1191752k highmem)
> Memory: 2012252k/2096960k available (4437k kernel code, 83236k
reserved, 2225k data, 540k init, 1191752k highmem)

<       .init : 0xc071d000 - 0xc07a1000   ( 528 kB)
<       .data : 0xc04f00af - 0xc0715e60   (2199 kB)
<       .text : 0xc0100000 - 0xc04f00af   (4032 kB)
---
>       .init : 0xc0789000 - 0xc0810000   ( 540 kB)
>       .data : 0xc05557e7 - 0xc0781ca0   (2225 kB)
>       .text : 0xc0100000 - 0xc05557e7   (4437 kB)



# looks like linefeed mangling in initramfs vs
# "high resolution mode" (timers) output
# --> multipart log messages are probably a bad idea
# in thread-enabled code..
< checking if image is initramfs... it is
< Freeing initrd memory: 7465k freed

> checking if image is initramfs...<7>Switched to high resolution mode
on CPU 1
> Switched to high resolution mode on CPU 0
>  it is
> Freeing initrd memory: 47715k freed


# yep, the above is definitely a race: I got this on a later boot, where
the messages look right.
[...] checking if image is initramfs... it is
[...] Freeing initrd memory: 47715k freed
[...] cpufreq: No nForce2 chipset.



# No longer detecting C3 state support???
< ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
---
> ACPI: CPU0 (power states: C1[C1] C2[C2])



# strange timestamps
# This might just be a clock artifact.
# If not, then this is a massive bootup delay
# It does not happen on 2.6.28-9, but happens every time
# on 2.6.29-rc8
[    0.480220] checking if image is initramfs...<7>Switched to high
resolution mode on CPU 1
[    0.504006] Switched to high resolution mode on CPU 0
[    2.420786]  it is
[    4.481146] Freeing initrd memory: 47715k freed




# Code that seems to have a printf as well as a printk or
# similar problem (message appears on screen during bootup
# as well as in log)
# NB: this happens in 2.6.28.8 as well.
[    4.481783] cpufreq: No nForce2 chipset.




Note: I'm hoping to find time to tackle the two simplest issues above
(message "race" and cpufreq print statement) myself. Look like good
kernel starter projects.

But if people could tell me whether to bother reporting the others, that
would be great...

Thanks,

Simon




--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux