Dear Sirs,
Recenly, I test five big distributions with almost all kernels
from 2.4.21 to 2.6.9 on several slow computers with many different
(not quite new) graphics cards (most of them - nvidia: Riva TNT,
GeForce, GeForce2 and S3Savage).
I observe very wrong Xserver performance on each of kernel 2.6.x
and good performance on every 2.4.x kernel when computer boot
with vesafb
For example, when I try mplayer or xine - CPU utilization
by X process is 30 times larger on 2.6.x kernel then 2.4.x
==> top_2.4.27-0.pre2.1mdk <==
top - 14:27:50 up 7 min, 1 user, load average: 0.67, 0.25, 0.11
Tasks: 45 total, 3 running, 42 sleeping, 0 stopped, 0 zombie
Cpu(s): 27.4% user, 1.5% system, 0.0% nice, 71.1% idle
Mem: 190780k total, 106124k used, 84656k free, 5864k buffers
Swap: 626452k total, 0k used, 626452k free, 63480k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1549 pf 25 0 16684 16m 12m R 26.4 8.7 0:16.00 mplayer
1398 root 25 0 42620 9596 3028 S 0.3 5.0 0:03.33 X
1561 pf 25 0 13032 12m 12m R 0.3 6.8 0:00.18 mplayer
==> top_2.6.8.1-12mdk <==
top - 20:41:33 up 13 min, 1 user, load average: 0.93, 0.35, 0.21
Tasks: 48 total, 2 running, 46 sleeping, 0 stopped, 0 zombie
Cpu(s): 61.7% us, 3.5% sy, 0.0% ni, 34.5% id, 0.0% wa, 0.1% hi,
0.0% si
Mem: 191608k total, 113028k used, 78580k free, 6064k buffers
Swap: 626452k total, 0k used, 626452k free, 66712k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3841 pf 15 0 34320 16m 27m S 36.2 8.7 0:21.94 mplayer
3655 root 16 0 44448 9708 36m R 26.0 5.1 0:17.99 X
3715 pf 15 0 3224 1768 2764 S 0.8 0.9 0:00.82 rxvt.bin
3842 pf 15 0 29932 12m 27m S 0.5 6.8 0:00.28 mplayer
Every time when I use 2.6.x kernel I get warnigs (in xorg.log) similar
this:
(WW) NV(0): Failed to set up write-combining range
(0xe3000000,0x1000000)
When I use boot option "video=vesafb:nomtrr" with any 2.6.x kernel,
Xserver performance is nearly as good as under 2.4.x kernel
and warning (in xorg.log) does not appear.
It seems to be a problem with mtrr and vesafb described several times,
for example Jan 18, 2004 in thread "Overlapping MTRRs in 2.6.1"
but it was a long time ago.
My questions are simple:
1. The problem is because of a kernel bug or because of kernel feature?
2. Is this the same problem all the time not resolved yet
or I found several different kernel bugs (with the same symptoms)?
I did not test 2.6.0, 2.6.2 and 2.6.5 kernel yet:-)
Inspite of this problem is not as important as for example kernel panic
I am sure because of it many of trivial users think linux is slowly :-)
Pawel Fengler
P.S.
Sorry for my English. It is not as perfect as I wish it to be.
--
Pawel Fengler <[email protected]> wrote:
>
> When I use boot option "video=vesafb:nomtrr" with any 2.6.x kernel,
> Xserver performance is nearly as good as under 2.4.x kernel
> and warning (in xorg.log) does not appear.
>
> It seems to be a problem with mtrr and vesafb described several times,
> for example Jan 18, 2004 in thread "Overlapping MTRRs in 2.6.1"
> but it was a long time ago.
Please send the full dmesg output and the contents of /proc/mtrr for
2.6.10-rc2.
Pawel Fengler <[email protected]> writes:
> Recenly, I test five big distributions with almost all kernels
> from 2.4.21 to 2.6.9 on several slow computers with many different
> (not quite new) graphics cards (most of them - nvidia: Riva TNT,
> GeForce, GeForce2 and S3Savage).
> Every time when I use 2.6.x kernel I get warnigs (in xorg.log) similar
> this:
> (WW) NV(0): Failed to set up write-combining range
> (0xe3000000,0x1000000)
Try 2.6.10-rc2 -- should be fixed there.
Gerd
--
#define printk(args...) fprintf(stderr, ## args)
Dnia 24-11-2004, ?ro o godzinie 17:18 -0800, Andrew Morton napisa?(a):
> Please send the full dmesg output and the contents of /proc/mtrr for
> 2.6.10-rc2.
Thank you for your letter.
I find it necessary to inform you that problem with mtrr and vesafb
still exists for kernel 2.6.10-rc2. Warning message
"(WW) NV(0): Failed to set up write-combining range" in Xorg.log
appears as well. Xserver performance is wrong too.
As you wish I send dmesg output and the contents of /proc/mtrr for
2.6.10-rc2 from my first computer.
Pawel Fengler
-------------------------------------------------------------
cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size= 128MB: write-back, count=1
reg01: base=0x08000000 ( 128MB), size= 64MB: write-back, count=1
reg02: base=0xe3000000 (3632MB), size= 4MB: write-combining, count=1
dmesg
Linux version 2.6.10-rc2 (root@pc3) (gcc version 3.4.1 (Mandrakelinux
10.1 3.4.1-4mdk)) #1 Thu Nov 25 21:04:20 CET 2004
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000c000000 (usable)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
192MB LOWMEM available.
On node 0 totalpages: 49152
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 45056 pages, LIFO batch:11
HighMem zone: 0 pages, LIFO batch:1
DMI 2.1 present.
ACPI: Unable to locate RSDP
Built 1 zonelists
Kernel command line: BOOT_IMAGE=2610rc2 ro root=2102 acpi=ht
resume=/dev/hde1 splash=silent
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 400.889 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 191476k/196608k available (1902k kernel code, 4696k reserved,
407k data, 208k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode...
Ok.
Calibrating delay loop... 790.52 BogoMIPS (lpj=395264)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183f9ff 00000000 00000000 00000000
CPU: After vendor identify, caps: 0183f9ff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU: After all inits, caps: 0183f9ff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Celeron (Mendocino) stepping 05
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 172k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb430, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20041105
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: ACPI disable
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fbfd0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xbff8, dseg 0xf0000
PnPBIOS: 13 nodes reported by PnP BIOS; 13 recorded by driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:07.0
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
audit: initializing netlink socket (disabled)
audit(1101415675.269:0): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
devfs: 2004-01-31 Richard Gooch ([email protected])
devfs: boot_options: 0x0
Initializing Cryptographic API
Limiting direct PCI/PCI transfers.
vesafb: framebuffer at 0xe3000000, mapped to 0xcc880000, using 1875k,
total 4096k
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: protected mode interface info at c000:029f
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
PIIX4: IDE controller at PCI slot 0000:00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
ide0: Wait for ready failed before probe !
hdb: HL-DT-ST RW/DVD GCC-4320B, ATAPI CD/DVD-ROM drive
elevator: using anticipatory as default io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
SiI680: IDE controller at PCI slot 0000:00:10.0
PCI: Found IRQ 5 for device 0000:00:10.0
SiI680: chipset revision 2
SiI680: BASE CLOCK == 133
SiI680: 100% native mode on irq 5
ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio
ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: Maxtor 6Y200P0, ATA DISK drive
ide2 at 0xcc80e080-0xcc80e087,0xcc80e08a on irq 5
Probing IDE interface ide3...
hdg: ST36421A, ATA DISK drive
ide3 at 0xcc80e0c0-0xcc80e0c7,0xcc80e0ca on irq 5
hde: max request size: 64KiB
hde: 398297088 sectors (203928 MB) w/7936KiB Cache, CHS=24792/255/63,
UDMA(133)
hde: cache flushes supported
/dev/ide/host2/bus0/target0/lun0: p1 p2 p3
hdg: max request size: 64KiB
hdg: 12596850 sectors (6449 MB) w/256KiB Cache, CHS=13330/15/63, UDMA
(33)
hdg: cache flushes not supported
/dev/ide/host2/bus1/target0/lun0: p1 p2 < p5 >
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: ImPS/2 Logitech Wheel Mouse on isa0060/serio1
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET: Registered protocol family 1
BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Freeing unused kernel memory: 208k freed
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.2
PCI: Found IRQ 10 for device 0000:00:07.2
PCI: Sharing IRQ 10 with 0000:00:14.0
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: irq 10, io base 0xa000
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
EXT3 FS on hde2, internal journal
Adding 497972k swap on /dev/hde1. Priority:-1 extents:1
Adding 128480k swap on /dev/hdg5. Priority:-2 extents:1
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 440LX Chipset.
agpgart: Maximum main memory to use for agp memory: 150M
agpgart: AGP aperture is 16M @ 0xe2000000
input: PC Speaker
kjournald starting. Commit interval 5 seconds
EXT3 FS on hde3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdg1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
loop: loaded (max 8 devices)
hdb: ATAPI 8X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
PCI: Found IRQ 11 for device 0000:00:0f.0
3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
0000:00:0f.0: 3Com PCI 3c590 Vortex 10Mbps at 0xa400. Vers LK1.1.19
0000:00:0f.0: Overriding PCI latency timer (CFLT) setting of 64, new
value is 248.
PCI: Found IRQ 3 for device 0000:00:12.0
0000:00:12.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xbc00. Vers LK1.1.19
inserting floppy driver for 2.6.10-rc2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
NET: Registered protocol family 17
Creative EMU10K1 PCI Audio Driver, version 0.20a, 20:36:27 Nov 25 2004
PCI: Found IRQ 10 for device 0000:00:14.0
PCI: Sharing IRQ 10 with 0000:00:07.2
emu10k1: EMU10K1 rev 7 model 0x8064 found, IO at 0xc000-0xc01f, IRQ 10
ac97_codec: AC97 Audio codec, id: 0x8384:0x7608 (SigmaTel STAC9708)
emu10k1: SBLive! 5.1 card detected
--
24-11-2004, 17:18 -0800, Andrew Morton :
> Please send the full dmesg output and the contents of /proc/mtrr for
> 2.6.10-rc2.
Thank you for your post.
I find it necessary to inform you that problem with mtrr and vesafb
still exists for kernel 2.6.10-rc2. Warning message
"(WW) NV(0): Failed to set up write-combining range" in Xorg.log
appears as well. Xserver performance is wrong too.
As you wish I send dmesg output and the contents of /proc/mtrr for
2.6.10-rc2 from my first computer.
Pawel Fengler
-------------------------------------------------------------
cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size= 128MB: write-back, count=1
reg01: base=0x08000000 ( 128MB), size= 64MB: write-back, count=1
reg02: base=0xe3000000 (3632MB), size= 4MB: write-combining, count=1
dmesg
Linux version 2.6.10-rc2 (root@pc3) (gcc version 3.4.1 (Mandrakelinux
10.1 3.4.1-4mdk)) #1 Thu Nov 25 21:04:20 CET 2004
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000c000000 (usable)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
192MB LOWMEM available.
On node 0 totalpages: 49152
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 45056 pages, LIFO batch:11
HighMem zone: 0 pages, LIFO batch:1
DMI 2.1 present.
ACPI: Unable to locate RSDP
Built 1 zonelists
Kernel command line: BOOT_IMAGE=2610rc2 ro root=2102 acpi=ht
resume=/dev/hde1 splash=silent
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 400.889 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 191476k/196608k available (1902k kernel code, 4696k reserved,
407k data, 208k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode...
Ok.
Calibrating delay loop... 790.52 BogoMIPS (lpj=395264)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183f9ff 00000000 00000000 00000000
CPU: After vendor identify, caps: 0183f9ff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU: After all inits, caps: 0183f9ff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Celeron (Mendocino) stepping 05
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 172k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb430, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20041105
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: ACPI disable
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fbfd0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xbff8, dseg 0xf0000
PnPBIOS: 13 nodes reported by PnP BIOS; 13 recorded by driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:07.0
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
audit: initializing netlink socket (disabled)
audit(1101415675.269:0): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
devfs: 2004-01-31 Richard Gooch ([email protected])
devfs: boot_options: 0x0
Initializing Cryptographic API
Limiting direct PCI/PCI transfers.
vesafb: framebuffer at 0xe3000000, mapped to 0xcc880000, using 1875k,
total 4096k
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: protected mode interface info at c000:029f
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
PIIX4: IDE controller at PCI slot 0000:00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
ide0: Wait for ready failed before probe !
hdb: HL-DT-ST RW/DVD GCC-4320B, ATAPI CD/DVD-ROM drive
elevator: using anticipatory as default io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
SiI680: IDE controller at PCI slot 0000:00:10.0
PCI: Found IRQ 5 for device 0000:00:10.0
SiI680: chipset revision 2
SiI680: BASE CLOCK == 133
SiI680: 100% native mode on irq 5
ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio
ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: Maxtor 6Y200P0, ATA DISK drive
ide2 at 0xcc80e080-0xcc80e087,0xcc80e08a on irq 5
Probing IDE interface ide3...
hdg: ST36421A, ATA DISK drive
ide3 at 0xcc80e0c0-0xcc80e0c7,0xcc80e0ca on irq 5
hde: max request size: 64KiB
hde: 398297088 sectors (203928 MB) w/7936KiB Cache, CHS=24792/255/63,
UDMA(133)
hde: cache flushes supported
/dev/ide/host2/bus0/target0/lun0: p1 p2 p3
hdg: max request size: 64KiB
hdg: 12596850 sectors (6449 MB) w/256KiB Cache, CHS=13330/15/63, UDMA
(33)
hdg: cache flushes not supported
/dev/ide/host2/bus1/target0/lun0: p1 p2 < p5 >
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: ImPS/2 Logitech Wheel Mouse on isa0060/serio1
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET: Registered protocol family 1
BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Freeing unused kernel memory: 208k freed
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.2
PCI: Found IRQ 10 for device 0000:00:07.2
PCI: Sharing IRQ 10 with 0000:00:14.0
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: irq 10, io base 0xa000
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
EXT3 FS on hde2, internal journal
Adding 497972k swap on /dev/hde1. Priority:-1 extents:1
Adding 128480k swap on /dev/hdg5. Priority:-2 extents:1
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 440LX Chipset.
agpgart: Maximum main memory to use for agp memory: 150M
agpgart: AGP aperture is 16M @ 0xe2000000
input: PC Speaker
kjournald starting. Commit interval 5 seconds
EXT3 FS on hde3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdg1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
loop: loaded (max 8 devices)
hdb: ATAPI 8X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
PCI: Found IRQ 11 for device 0000:00:0f.0
3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
0000:00:0f.0: 3Com PCI 3c590 Vortex 10Mbps at 0xa400. Vers LK1.1.19
0000:00:0f.0: Overriding PCI latency timer (CFLT) setting of 64, new
value is 248.
PCI: Found IRQ 3 for device 0000:00:12.0
0000:00:12.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xbc00. Vers LK1.1.19
inserting floppy driver for 2.6.10-rc2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
NET: Registered protocol family 17
Creative EMU10K1 PCI Audio Driver, version 0.20a, 20:36:27 Nov 25 2004
PCI: Found IRQ 10 for device 0000:00:14.0
PCI: Sharing IRQ 10 with 0000:00:07.2
emu10k1: EMU10K1 rev 7 model 0x8064 found, IO at 0xc000-0xc01f, IRQ 10
ac97_codec: AC97 Audio codec, id: 0x8384:0x7608 (SigmaTel STAC9708)
emu10k1: SBLive! 5.1 card detected
--
Pawel Fengler <[email protected]> writes:
> > Please send the full dmesg output and the contents of /proc/mtrr for
> > 2.6.10-rc2.
> reg02: base=0xe3000000 (3632MB), size= 4MB: write-combining, count=1
> vesafb: framebuffer at 0xe3000000, mapped to 0xcc880000, using 1875k,
> total 4096k
The BIOS reports 4MB video memory, and vesafb adds an mtrr entry for
that. Looks ok, with the exception that the reported 4MB are probably
not correct, otherwise the X-Server wouldn't complain. vesafb in
2.6.10-rc2 has a option to overwrite the BIOS-reported value
(vtotal=n, with n in megabytes), that should fix it.
The reason that you don't see this with old kernels probably is just
that vesafb doesn't create mtrr entries by default in 2.4.x
Gerd
--
#define printk(args...) fprintf(stderr, ## args)
On Mon, Nov 29, 2004 at 12:12:08PM +0100, Gerd Knorr wrote:
> > > Please send the full dmesg output and the contents of /proc/mtrr for
> > > 2.6.10-rc2.
> > reg02: base=0xe3000000 (3632MB), size= 4MB: write-combining, count=1
> > vesafb: framebuffer at 0xe3000000, mapped to 0xcc880000, using 1875k,
> > total 4096k
>
> The BIOS reports 4MB video memory, and vesafb adds an mtrr entry for
> that. Looks ok, with the exception that the reported 4MB are probably
> not correct, otherwise the X-Server wouldn't complain.
vesafb is assuming that the memory used in the current screen mode
xres*yres*depth rounded up to nearest power of 2, is the amount of
ram the card has, which is not just wrong, it's dumb.
> vesafb in 2.6.10-rc2 has a option to overwrite the BIOS-reported value
> (vtotal=n, with n in megabytes), that should fix it.
which is an ugly hack for the above problem imo.
vesafb:nomtrr also fixes the problem, and leaves X free
to set things up correctly in my experience.
If vesafb can't get it right, maybe it shouldn't be
attempted to do it in the half-assed way it currently does.
Dave
On Mon, Nov 29, 2004 at 10:40:07AM -0500, Dave Jones wrote:
> On Mon, Nov 29, 2004 at 12:12:08PM +0100, Gerd Knorr wrote:
> > > > Please send the full dmesg output and the contents of /proc/mtrr for
> > > > 2.6.10-rc2.
> > > reg02: base=0xe3000000 (3632MB), size= 4MB: write-combining, count=1
> > > vesafb: framebuffer at 0xe3000000, mapped to 0xcc880000, using 1875k,
> > > total 4096k
> >
> > The BIOS reports 4MB video memory, and vesafb adds an mtrr entry for
> > that. Looks ok, with the exception that the reported 4MB are probably
> > not correct, otherwise the X-Server wouldn't complain.
>
> vesafb is assuming that the memory used in the current screen mode
> xres*yres*depth rounded up to nearest power of 2, is the amount of
> ram the card has, which is not just wrong, it's dumb.
It used to do that, but doesn't any more in 2.6.10-rc2. Check the
current code please.
vesafb now distinguishes between the amount of memory needed for the
video mode (that is used for ioremap() to avoid wasting address space,
reported as "using" in the kernel message quoted above) and the total
amount of memory (used for ressource allocation and mtrr records,
reported as "total" in the message above).
> > vesafb in 2.6.10-rc2 has a option to overwrite the BIOS-reported value
> > (vtotal=n, with n in megabytes), that should fix it.
>
> which is an ugly hack for the above problem imo.
The problem isn't vesafb, the problem is the BIOS.
On my machines it works perfectly fine. One has a radeon with 64MB, the
other a good old matrox with 8MB video memory. On both machines current
kernels correctly create mtrr records for the complete framebuffer, not
just the small piece actually used by vesafb for the fb console.
> vesafb:nomtrr also fixes the problem, and leaves X free
> to set things up correctly in my experience.
Yes, but that also results in a slow framebuffer console.
> If vesafb can't get it right, maybe it shouldn't be
> attempted to do it in the half-assed way it currently does.
Well, 2.6.10-rc1 + newer should get it right now. We can't do much
about BIOS bugs through, other than maybe disabling mtrr by default
if too many machines are affected.
Gerd
--
#define printk(args...) fprintf(stderr, ## args)
(loony with broken SPF mailfilter removed from Cc)
On Mon, Nov 29, 2004 at 05:22:42PM +0100, Gerd Knorr wrote:
> > vesafb is assuming that the memory used in the current screen mode
> > xres*yres*depth rounded up to nearest power of 2, is the amount of
> > ram the card has, which is not just wrong, it's dumb.
>
> It used to do that, but doesn't any more in 2.6.10-rc2. Check the
> current code please.
ah, I was looking at a 2.6.9 tree, my apologies.
but..
if (mtrr) {
int temp_size = size_total;
/* Find the largest power-of-two */
while (temp_size & (temp_size - 1))
temp_size &= (temp_size - 1);
/* Try and find a power of two to add */
while (temp_size && mtrr_add(vesafb_fix.smem_start, temp_size, MTRR_TYPE_WRCOMB, 1)==-EINVAL) {
temp_size >>= 1;
}
}
size_total is calculated thus:
size_total = screen_info.lfb_size * 65536;
if (vram_total)
size_total = vram_total * 1024 * 1024;
if (size_total < size_vmode)
size_total = size_vmode;
where is screen_info.lfb_size set ?
> > If vesafb can't get it right, maybe it shouldn't be
> > attempted to do it in the half-assed way it currently does.
>
> Well, 2.6.10-rc1 + newer should get it right now. We can't do much
> about BIOS bugs through, other than maybe disabling mtrr by default
> if too many machines are affected.
or blacklist if there aren't too many perhaps?
Dave
On Llu, 2004-11-29 at 15:40, Dave Jones wrote:
> which is an ugly hack for the above problem imo.
> vesafb:nomtrr also fixes the problem, and leaves X free
> to set things up correctly in my experience.
>
> If vesafb can't get it right, maybe it shouldn't be
> attempted to do it in the half-assed way it currently does.
The problem is not vesafb its X. If someone would go fix the Xorg code
to handle extending existing maps the problem will go away.
> size_total is calculated thus:
>
> size_total = screen_info.lfb_size * 65536;
That comes almost directly from the BIOS, the screen_info struct is
filled by the real mode boot code (vga.S IIRC).
> if (vram_total)
> size_total = vram_total * 1024 * 1024;
The vesafb option to override stuff.
> if (size_total < size_vmode)
> size_total = size_vmode;
Thats kida silly, but as I've found some simliar construct in the old
code I left it in to avoid breaking stuff. Guess there is a reason that
this was there. I'll take that as proof that broken BIOSes exist which
don't fill screen_info.lfb_size correctly ;)
> or blacklist if there aren't too many perhaps?
Hmm, how identify them? Map the BIOS and poke around there?
screen_info gives next to no info here.
Maybe it works better to walk the PCI device list, find the correct
gfx card using the framebuffer start address, then double-check the
size by looking at the PCI ressources?
Gerd
--
#define printk(args...) fprintf(stderr, ## args)
On Mon, Nov 29, 2004 at 06:34:19PM +0100, Gerd Knorr wrote:
> > size_total is calculated thus:
> >
> > size_total = screen_info.lfb_size * 65536;
>
> That comes almost directly from the BIOS, the screen_info struct is
> filled by the real mode boot code (vga.S IIRC).
ah yes, video.S, (sets PARAM_LFB_SIZE), which is why my grep failed.
> > or blacklist if there aren't too many perhaps?
>
> Hmm, how identify them? Map the BIOS and poke around there?
> screen_info gives next to no info here.
>
> Maybe it works better to walk the PCI device list, find the correct
> gfx card using the framebuffer start address, then double-check the
> size by looking at the PCI ressources?
Maybe.
Something I toyed with at one point, which only works for AGP cards is..
search the pci config space for an agp header, and then check the amount
of prefetchable memory range behind the bridge.
Even that wasn't foolproof however, and there were a few quirks
to work around still. You see all sorts of strange things there,
like onboard gfx with 16MB advertising 64MB prefetchable ranges.
Dave
On Llu, 2004-11-29 at 17:34, Gerd Knorr wrote:
> Thats kida silly, but as I've found some simliar construct in the old
> code I left it in to avoid breaking stuff. Guess there is a reason that
> this was there. I'll take that as proof that broken BIOSes exist which
> don't fill screen_info.lfb_size correctly ;)
Indeed. Also some report less than the full amount because they only
support VGA modes in the lower bits of memory and others like Intel
ICH/GCH based systems report 1Mb because in essence the question has no
right answer.
> Maybe it works better to walk the PCI device list, find the correct
> gfx card using the framebuffer start address, then double-check the
> size by looking at the PCI ressources?
Very very few cards have a PCI resource map that gives useful size
information because they have apertures and are sometimes also windowed
or not all CPU accessible.
On Llu, 2004-11-29 at 18:17, Dave Jones wrote:
> Even that wasn't foolproof however, and there were a few quirks
> to work around still. You see all sorts of strange things there,
> like onboard gfx with 16MB advertising 64MB prefetchable ranges.
Thats normal rather than a quirk. You've got big and little endian
apertures. You may have dithering depth apertures, YUV convertor
apertures and so on.