2.6.33-rc3 -- Intel 945GME (inteldrmfb) -- Two Tux images displayed are side by side (should only show one).
Miles Lane
include the Tux display option in my custom kernel builds. I don't
know how many kernel revisions ago it was when I started noticing
this. It seems like it might have been early in the 2.6 series
kernels.
dmesg:
Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel 945GME Chipset
agpgart-intel 0000:00:00.0: detected 7932K stolen memory
agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64
[drm] set up 7M of stolen space
integrated sync not supported
ACPI: Battery Slot [BAT0] (battery present)
[drm] initialized overlay support
[drm] LVDS-8: set mode 1024x600 27
Console: switching to colour frame buffer device 128x37
fb0: inteldrmfb frame buffer device
registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
# lspci -vvxxx -s 2.1
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME,
943/940GML Express Integrated Graphics Controller (rev 03)
Subsystem: ASUSTeK Computer Inc. Device 8340
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Region 0: Memory at f7f80000 (32-bit, non-prefetchable) [size=512K]
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 86 80 a6 27 07 00 90 00 03 00 80 03 00 00 80 00
10: 00 00 f8 f7 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 40 83
30: 00 00 00 00 d0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 48 00 00 00 09 00 09 71 23 25 4a a1
50: 0e 00 30 00 1b 00 00 00 00 00 00 00 00 00 80 7f
60: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 22 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 88 40 64 34 10 00 00 00 86 0f 05 00 00 00 00 00
From .config:
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_VGA_ARB=y
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_I915=y
CONFIG_DRM_I915_KMS=y
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
# Frame buffer hardware drivers
#
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# Display device support
#
CONFIG_DISPLAY_SUPPORT=y
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=128
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_CLUT224=y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
James Simmons
> For a long time I have gotten two pictures of Tux showing up when I
> include the Tux display option in my custom kernel builds. I don't
> know how many kernel revisions ago it was when I started noticing
> this. It seems like it might have been early in the 2.6 series
> kernels.
>
> dmesg:
>
> Linux agpgart interface v0.103
> agpgart-intel 0000:00:00.0: Intel 945GME Chipset
> agpgart-intel 0000:00:00.0: detected 7932K stolen memory
> agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
> [drm] Initialized drm 1.1.0 20060810
> i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> i915 0000:00:02.0: setting latency timer to 64
> [drm] set up 7M of stolen space
> integrated sync not supported
> ACPI: Battery Slot [BAT0] (battery present)
> [drm] initialized overlay support
> [drm] LVDS-8: set mode 1024x600 27
> Console: switching to colour frame buffer device 128x37
> fb0: inteldrmfb frame buffer device
> registered panic notifier
> [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
>
> # Graphics support
> #
> CONFIG_AGP=y
> CONFIG_AGP_INTEL=y
> CONFIG_VGA_ARB=y
> CONFIG_DRM=y
> CONFIG_DRM_KMS_HELPER=y
> CONFIG_DRM_I915=y
> CONFIG_DRM_I915_KMS=y
> CONFIG_VIDEO_OUTPUT_CONTROL=y
> CONFIG_FB=y
> CONFIG_FIRMWARE_EDID=y
> CONFIG_FB_BOOT_VESA_SUPPORT=y
> CONFIG_FB_CFB_FILLRECT=y
> CONFIG_FB_CFB_COPYAREA=y
> CONFIG_FB_CFB_IMAGEBLIT=y
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_TILEBLITTING=y
>
> # Frame buffer hardware drivers
> #
> CONFIG_FB_VESA=y
> CONFIG_FB_EFI=y
Try disabling these two above options.
Miles Lane
>
>> For a long time I have gotten two pictures of Tux showing up when I
>> include the Tux display option in my custom kernel builds. �I don't
>> know how many kernel revisions ago it was when I started noticing
>> this. �It seems like it might have been early in the 2.6 series
>> kernels.
>>
>> # Frame buffer hardware drivers
>> #
>> CONFIG_FB_VESA=y
>> CONFIG_FB_EFI=y
>
> Try disabling these two above options.
Well, that means that I don't get Tux at all. The point is that only
one copy should be displayed.
Miles
James Simmons
> On Wed, Jan 6, 2010 at 12:37 PM, James Simmons <jsim...@infradead.org> wrote:
> >
> >> For a long time I have gotten two pictures of Tux showing up when I
> >> include the Tux display option in my custom kernel builds. �I don't
> >> know how many kernel revisions ago it was when I started noticing
> >> this. �It seems like it might have been early in the 2.6 series
> >> kernels.
> >>
> [...]
> >> # Frame buffer hardware drivers
> >> #
> >> CONFIG_FB_VESA=y
> >> CONFIG_FB_EFI=y
> >
> > Try disabling these two above options.
>
> Well, that means that I don't get Tux at all. The point is that only
> one copy should be displayed.
I thought you had KMS enabled?? That provides a fbdev emulation layer.
Miles Lane
>
>> On Wed, Jan 6, 2010 at 12:37 PM, James Simmons <jsim...@infradead.org> wrote:
>> >
>> >> For a long time I have gotten two pictures of Tux showing up when I
>> >> include the Tux display option in my custom kernel builds. �I don't
>> >> know how many kernel revisions ago it was when I started noticing
>> >> this. �It seems like it might have been early in the 2.6 series
>> >> kernels.
>> >>
>> [...]
>> >> # Frame buffer hardware drivers
>> >> #
>> >> CONFIG_FB_VESA=y
>> >> CONFIG_FB_EFI=y
>> >
>> > Try disabling these two above options.
Okay. I disabled those two options and still get the two Tuxes. I
gues Bruno's message is correct, and I get two Tuxes because I have an
Atom processor with two cores.
Miles Lane
<bon...@linux-vserver.org> wrote:
> On Wed, 06 January 2010 Miles Lane <miles...@gmail.com> wrote:
>> For a long time I have gotten two pictures of Tux showing up when I
>> include the Tux display option in my custom kernel builds. �I don't
>> know how many kernel revisions ago it was when I started noticing
>> this. �It seems like it might have been early in the 2.6 series
>> kernels.
>
> exactly one core this is the correct bahavior, one tux per logical CPU.
>
> If you just want a single tux you can run your kernel on a system with
> only one logical CPU, boot it with maxcpus=1 or rebuild it with
> CONFIG_SMP=n... though in those case you will not be able to benefit
> from all of your CPU's resources..
>
> Bruno
Oh! Well, that explains it. That is truly weird functionality. Is
Tux a de facto
CPU presence indicator? It doesn't make any sense to me, if so.
Miles
Peter Zijlstra
> For a long time I have gotten two pictures of Tux showing up when I
> include the Tux display option in my custom kernel builds.
Doesn't it show one for each cpu in the system?
Bruno Prémont
> include the Tux display option in my custom kernel builds. I don't
> know how many kernel revisions ago it was when I started noticing
> this. It seems like it might have been early in the 2.6 series
> kernels.
Unless your system has exactly one CPU without hyperthreading and with
exactly one core this is the correct bahavior, one tux per logical CPU.
If you just want a single tux you can run your kernel on a system with
only one logical CPU, boot it with maxcpus=1 or rebuild it with
CONFIG_SMP=n... though in those case you will not be able to benefit
from all of your CPU's resources..
Bruno
> dmesg:
Miles Lane
> On Wed, 2010-01-06 at 12:16 -0500, Miles Lane wrote:
>> For a long time I have gotten two pictures of Tux showing up when I
>> include the Tux display option in my custom kernel builds.
>
> Doesn't it show one for each cpu in the system?
Apparently so. And, why this should be true is beyond me.
Peter Zijlstra
> On Wed, Jan 6, 2010 at 1:07 PM, Peter Zijlstra <pet...@infradead.org> wrote:
> > On Wed, 2010-01-06 at 12:16 -0500, Miles Lane wrote:
> >> For a long time I have gotten two pictures of Tux showing up when I
> >> include the Tux display option in my custom kernel builds.
> >
> > Doesn't it show one for each cpu in the system?
>
> Apparently so. And, why this should be true is beyond me.
drivers/video/fbmem.c:
int fb_show_logo(struct fb_info *info, int rotate)
{
int y;
y = fb_show_logo_line(info, rotate, fb_logo.logo, 0,
num_online_cpus());
y = fb_show_extra_logos(info, y, rotate);
return y;
}
I guess its just a cute way of showing off how many cpus you've got ;-)
Miles Lane
>> For a long time I have gotten two pictures of Tux showing up when I
>> include the Tux display option in my custom kernel builds.
>
> Doesn't it show one for each cpu in the system?
I know this is cosmetic, but could we change this behavior and just
show one Tux on all systems? As a software tester, this just looks
like a bug. Alternatively, let's put labels under the Tux images
showing "CPU (N)", "CPU (N+1)", ....
This seems like a much better way to know the state of your CPUs:
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU N280 @ 1.66GHz
stepping : 2
cpu MHz : 1667.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2
ssse3 xtpr pdcm movbe lahf_lm
bogomips : 3325.27
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU N280 @ 1.66GHz
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2
ssse3 xtpr pdcm movbe lahf_lm
bogomips : 3324.83
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:
And:
# dmesg | grep -i cpu
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
ACPI: SSDT 7f7aeb40 004F0 (v01 PmRef CpuPm 00003000 INTL 20051117)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
setup_percpu: NR_CPUS:5 nr_cpumask_bits:5 nr_cpu_ids:2 nr_node_ids:1
PERCPU: Embedded 15 pages/cpu @c6c00000 s39448 r0 d21992 u2097152
pcpu-alloc: s39448 r0 d21992 u2097152 alloc=1*4194304
pcpu-alloc: [0] 0 1
Initializing CPU#0
SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
RCU-based detection of stalled CPUs is enabled.
CPU 0 irqstacks, hard=c6c00000 soft=c6c01000
Initializing cgroup subsys cpuacct
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
mce: CPU supports 5 MCE banks
CPU0: Thermal monitoring enabled (TM2)
CPU0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz stepping 02
CPU 1 irqstacks, hard=c6e00000 soft=c6e01000
Initializing CPU#1
Brought up 2 CPUs
ACPI: SSDT 7f7ae180 001FA (v01 PmRef Cpu0Ist 00003000 INTL 20051117)
ACPI: SSDT 7f7ae410 00724 (v01 PmRef Cpu0Cst 00003001 INTL 20051117)
ACPI: SSDT 7f7ae0b0 000CC (v01 PmRef Cpu1Ist 00003000 INTL 20051117)
ACPI: SSDT 7f7ae380 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117)
HPET: 3 timers in total, 0 timers will be used for per-cpu timer
cpu0(2) debug files 135
cpu1(2) debug files 135
microcode: CPU0 sig=0x106c2, pf=0x4, revision=0x212
microcode: CPU1 sig=0x106c2, pf=0x4, revision=0x212
cpuidle: using governor ladder
cpuidle: using governor menu
Pavel Machek
> On Wed, Jan 6, 2010 at 1:07 PM, Peter Zijlstra <pet...@infradead.org> wrote:
> > On Wed, 2010-01-06 at 12:16 -0500, Miles Lane wrote:
> >> For a long time I have gotten two pictures of Tux showing up when I
> >> include the Tux display option in my custom kernel builds.
> >
> > Doesn't it show one for each cpu in the system?
>
> I know this is cosmetic, but could we change this behavior and just
> show one Tux on all systems? As a software tester, this just looks
Its well-known joke by now. Please keep it.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html