vesa fb is slow on 2.6.15.1

vesa fb is slow on 2.6.15.1

[Hai Zaar]

Dear list,
I have framebuffer problems with vanilla 2.6.15.1 - its very slow.
I'm using vesafb and booting with 'vga=795'.
I've used 2.6.11.12 before, and running 'cat
/usr/share/man/man1/bash.1' on tty1 took
12 seconds. Now, with 2.6.15.1 it takes 3 minutes.

Now the details of 2.6.15.1 system:

During boot I have:
PCI: Failed to allocate mem resource #6:20000@f8000000 for 0000:40:00.0

relevant snip of the .config
#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y

And as I've said, I boot with 'vga=795'. Graphics card is Nvidia
Quadro FX1500 (PCIE).

# lspci  -vv -s 40:00.0
40:00.0 VGA compatible controller: nVidia Corporation: Unknown device
00ce (rev a2) (prog-if 00 [VGA])
	Subsystem: nVidia Corporation: Unknown device 0243
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 169
	Region 0: Memory at f8000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at f0000000 (64-bit, prefetchable) [size=128M]
	Region 3: Memory at f9000000 (64-bit, non-prefetchable) [size=16M]
	Capabilities: [60] 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-
	Capabilities: [68] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [78] #10 [0001]

# cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 512MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0xfeda0000 (4077MB), size= 128KB: uncachable, count=1

No 'write-combining' entry! But with 2.6.11.12 I do have one:
<2.6.11.12 system> cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 512MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0xfeda0000 (4077MB), size= 128KB: uncachable, count=1
reg05: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=1


Where to continue to?
P.S. I'm not on the list, so please CC me.
--
Zaar

Re: vesa fb is slow on 2.6.15.1

[Antonino A. Daplas]

Hai Zaar wrote:
> 
> # cat /proc/mtrr
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
> reg02: base=0xc0000000 (3072MB), size= 512MB: write-back, count=1
> reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
> reg04: base=0xfeda0000 (4077MB), size= 128KB: uncachable, count=1
> 
> No 'write-combining' entry! But with 2.6.11.12 I do have one:
> <2.6.11.12 system> cat /proc/mtrr
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
> reg02: base=0xc0000000 (3072MB), size= 512MB: write-back, count=1
> reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
> reg04: base=0xfeda0000 (4077MB), size= 128KB: uncachable, count=1
> reg05: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=1

mtrr now defaults to off in vesafb because of conflicts with xorg/
xfree86.  You have to explicitly enable it with a boot option.  Try
this:

video=vesafb:mtrr:3,ypan

Tony

Re: vesa fb is slow on 2.6.15.1

[Hai Zaar]

On 1/26/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>
> mtrr now defaults to off in vesafb because of conflicts with xorg/
> xfree86.  You have to explicitly enable it with a boot option.  Try
> this:
>
> video=vesafb:mtrr:3,ypan
>
> Tony
>
I've replaced 'vga=795' with 'video=vesafb:mtrr:3,ypan' and rebooted.
Now framebuffer is not activated at all - I get plain old 80x25
console. Are you sure that old vesafb (not vesafb-tng) driver
understands 'video=...' parameters style?

--
Zaar

Re: vesa fb is slow on 2.6.15.1

[Alistair John Strachan]

On Thursday 26 January 2006 16:06, Hai Zaar wrote:
> On 1/26/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > mtrr now defaults to off in vesafb because of conflicts with xorg/
> > xfree86.  You have to explicitly enable it with a boot option.  Try
> > this:
> >
> > video=vesafb:mtrr:3,ypan
> >
> > Tony
>
> I've replaced 'vga=795' with 'video=vesafb:mtrr:3,ypan' and rebooted.
> Now framebuffer is not activated at all - I get plain old 80x25
> console. Are you sure that old vesafb (not vesafb-tng) driver
> understands 'video=...' parameters style?

Do not replace vga= and it will work fine. See Documentation/fb/vesafb.txt.

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: vesa fb is slow on 2.6.15.1

[Antonino A. Daplas]

Hai Zaar wrote:
> On 1/26/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> I've replaced 'vga=795' with 'video=vesafb:mtrr:3,ypan' and rebooted.
> Now framebuffer is not activated at all - I get plain old 80x25
> console. Are you sure that old vesafb (not vesafb-tng) driver
> understands 'video=...' parameters style?
> 

You need both vga= and video=vesafb

Tony

Re: vesa fb is slow on 2.6.15.1

[Hai Zaar]

>
> You need both vga= and video=vesafb
Thanks a lot - it did the trick - the speed is back!

But anyway, do you have a clue why do I still get this error?
PCI: Failed to allocate mem resource #6:20000@f8000000 for 0000:40:00.0
I've several workstations with _exactly_ the same hardware. I've tried
two of them - both give the error with 2.6.15.1 (and no errors with
2.6.11.12).
>
> Tony
>


--
Zaar

Re: vesa fb is slow on 2.6.15.1

[Hai Zaar]

On 1/27/06, Hai Zaar <haizaar@gmail.com> wrote:
> >
> > You need both vga= and video=vesafb
> Thanks a lot - it did the trick - the speed is back!
BTW, if I use 'ywrap' instead of 'ypan' its even a bit faster: 'cat
/usr/share/man/man1/bash.1'  on tty1 take 11 seconds with ywrap,
against 12 seconds with ypan.

>
> But anyway, do you have a clue why do I still get this error?
> PCI: Failed to allocate mem resource #6:20000@f8000000 for 0000:40:00.0
> I've several workstations with _exactly_ the same hardware. I've tried
> two of them - both give the error with 2.6.15.1 (and no errors with
> 2.6.11.12).
> >
> > Tony
> >
>
>
> --
> Zaar
>


--
Zaar

Re: vesa fb is slow on 2.6.15.1

[Antonino A. Daplas]

Hai Zaar wrote:
>> You need both vga= and video=vesafb
> Thanks a lot - it did the trick - the speed is back!
> 
> But anyway, do you have a clue why do I still get this error?
> PCI: Failed to allocate mem resource #6:20000@f8000000 for 0000:40:00.0
> I've several workstations with _exactly_ the same hardware. I've tried
> two of them - both give the error with 2.6.15.1 (and no errors with
> 2.6.11.12).

Can you post the entire dmesg?

Tony

Re: vesa fb is slow on 2.6.15.1

[Hai Zaar]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

> >
> > But anyway, do you have a clue why do I still get this error?
> > PCI: Failed to allocate mem resource #6:20000@f8000000 for 0000:40:00.0
> > I've several workstations with _exactly_ the same hardware. I've tried
> > two of them - both give the error with 2.6.15.1 (and no errors with
> > 2.6.11.12).
>
> Can you post the entire dmesg?
>
> Tony
>

Attached.

Thanks.
--
Zaar

[-- Attachment #2: dmesg.log --]
[-- Type: text/x-log, Size: 17921 bytes --]

Linux version 2.6.15.1 (root@localhost) (gcc version 3.4.3) #1 SMP PREEMPT Fri Jan 27 13:26:34 IST 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000dfff5000 (usable)
 BIOS-e820: 00000000dfff5000 - 00000000e0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
2687MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f9bf0
On node 0 totalpages: 917493
  DMA zone: 4096 pages, LIFO batch:0
  DMA32 zone: 0 pages, LIFO batch:0
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 688117 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v002 COMPAQ                                ) @ 0x000e8e10
ACPI: XSDT (v001 COMPAQ CPQ0063  0x20050602  0x00000000) @ 0xdfff50ec
ACPI: FADT (v003 COMPAQ TUMWATER 0x00000001  0x00000000) @ 0xdfff52ac
ACPI: SSDT (v001 COMPAQ  PROJECT 0x00000001 MSFT 0x0100000e) @ 0xdfff657a
ACPI: MADT (v001 COMPAQ TUMWATER 0x00000001  0x00000000) @ 0xdfff53b8
ACPI: ASF! (v032 COMPAQ TUMWATER 0x00000001  0x00000000) @ 0xdfff543c
ACPI: MCFG (v001 COMPAQ TUMWATER 0x00000001  0x00000000) @ 0xdfff54a6
ACPI: DSDT (v001 COMPAQ     DSDT 0x00000001 MSFT 0x0100000e) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x06] enabled)
Processor #6 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] enabled)
Processor #7 15:4 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at e2000000 (gap: e0000000:1ec00000)
Built 1 zonelists
Kernel command line: quiet selinux=0 vga=795 video=vesafb:mtrr:3,ywrap
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 3601.544 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 3624808k/3669972k available (1949k kernel code, 43888k reserved, 588k data, 208k init, 2752468k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 7206.77 BogoMIPS (lpj=3603389)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff 20000000 00000000 00000000 0000659d 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 20000000 00000000 00000000 0000659d 00000000 00000000
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 20000000 00000000 00000080 0000659d 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
CPU0: Thermal monitoring enabled
mtrr: v2.0 (20020519)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Xeon(TM) CPU 3.60GHz stepping 01
Booting processor 1/1 eip 3000
Initializing CPU#1
Calibrating delay using timer specific routine.. 7199.36 BogoMIPS (lpj=3599683)
CPU: After generic identify, caps: bfebfbff 20000000 00000000 00000000 0000659d 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 20000000 00000000 00000000 0000659d 00000000 00000000
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 20000000 00000000 00000080 0000659d 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (24) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Xeon(TM) CPU 3.60GHz stepping 01
Booting processor 2/6 eip 3000
Initializing CPU#2
Calibrating delay using timer specific routine.. 7199.34 BogoMIPS (lpj=3599673)
CPU: After generic identify, caps: bfebfbff 20000000 00000000 00000000 0000659d 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 20000000 00000000 00000000 0000659d 00000000 00000000
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 3
CPU: After all inits, caps: bfebfbff 20000000 00000000 00000080 0000659d 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#2.
CPU2: Intel P4/Xeon Extended MCE MSRs (24) available
CPU2: Thermal monitoring enabled
CPU2: Intel(R) Xeon(TM) CPU 3.60GHz stepping 01
Booting processor 3/7 eip 3000
Initializing CPU#3
Calibrating delay using timer specific routine.. 7199.38 BogoMIPS (lpj=3599694)
CPU: After generic identify, caps: bfebfbff 20000000 00000000 00000000 0000659d 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 20000000 00000000 00000000 0000659d 00000000 00000000
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 3
CPU: After all inits, caps: bfebfbff 20000000 00000000 00000080 0000659d 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#3.
CPU3: Intel P4/Xeon Extended MCE MSRs (24) available
CPU3: Thermal monitoring enabled
CPU3: Intel(R) Xeon(TM) CPU 3.60GHz stepping 01
Total of 4 processors activated (28804.87 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization across 4 CPUs: passed.
Brought up 4 CPUs
checking if image is initramfs... it is
Freeing initrd memory: 7166k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.20 entry at 0xeb5df, last bus=64
PCI: Using MMCONFIG
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 10 11 14 15)
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region f800-f87f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region fa00-fa3f claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:40:00.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.XPA_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.XPB_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.XPA1._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 15 devices
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca)
pnp: 00:0a: ioport range 0xcb0-0xcbf has been reserved
pnp: 00:0a: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:0b: ioport range 0x400-0x41f has been reserved
pnp: 00:0b: ioport range 0x420-0x43f has been reserved
pnp: 00:0b: ioport range 0x440-0x45f has been reserved
pnp: 00:0b: ioport range 0x460-0x47f could not be reserved
pnp: 00:0b: ioport range 0x480-0x48f has been reserved
pnp: 00:0b: ioport range 0xf800-0xf81f could not be reserved
pnp: 00:0b: ioport range 0xf820-0xf83f has been reserved
pnp: 00:0b: ioport range 0xf840-0xf85f has been reserved
PCI: Bridge: 0000:00:02.0
  IO window: disabled.
  MEM window: fa100000-fa1fffff
  PREFETCH window: e2000000-e20fffff
PCI: Bridge: 0000:00:03.0
  IO window: disabled.
  MEM window: fa200000-fa2fffff
  PREFETCH window: disabled.
PCI: Failed to allocate mem resource #6:20000@f8000000 for 0000:40:00.0
PCI: Bridge: 0000:00:04.0
  IO window: disabled.
  MEM window: f8000000-f9ffffff
  PREFETCH window: f0000000-f7ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 3000-3fff
  MEM window: fa000000-fa0fffff
  PREFETCH window: e2100000-e21fffff
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:02.0 to 64
ACPI: PCI Interrupt 0000:00:03.0[A] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:03.0 to 64
ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:04.0 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1138378882.362:1): initialized
highmem bounce pool size: 64 pages
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:02.0 to 64
Allocate Port Service[pcie00]
Allocate Port Service[pcie01]
ACPI: PCI Interrupt 0000:00:03.0[A] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:03.0 to 64
Allocate Port Service[pcie00]
Allocate Port Service[pcie01]
ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:04.0 to 64
Allocate Port Service[pcie00]
Allocate Port Service[pcie01]
vesafb: framebuffer at 0xf0000000, mapped to 0xf8880000, using 10240k, total 131072k
vesafb: mode is 1280x1024x32, linelength=5120, pages=0
vesafb: protected mode interface info at 00ff:44f0
vesafb: scrolling: redraw
vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
vesafb: Mode is VGA compatible
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
PNP: PS/2 Controller [PNP0303:KBD,PNP0f0e:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
usbmon: debugfs is not available
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: irq 177, io mem 0xfa300000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 169, io base 0x00004440
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 185, io base 0x00004460
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 193
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 193, io base 0x00004480
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 169, io base 0x000044a0
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usb 4-1: new full speed USB device using uhci_hcd and address 2
hub 4-1:1.0: USB hub found
hub 4-1:1.0: 4 ports detected
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 9, 3145728 bytes)
TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
Using IPI No-Shortcut mode
ACPI wakeup devices: 
PCI0  XPA SLO4  XPB SLO2  HUB COM1 USB1 USB2 USB3 USB4 EUSB  NIC PBTN 
ACPI: (supports S0 S1 S3 S4 S5)
Freeing unused kernel memory: 208k freed
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SCSI subsystem initialized
libata version 1.20 loaded.
ata_piix 0000:00:1f.2: version 1.05
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 193
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0x4810 ctl 0x482A bmdma 0x44F0 irq 193
ata2: SATA max UDMA/133 cmd 0x4818 ctl 0x482E bmdma 0x44F8 irq 193
ICH5: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 193
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x44e0-0x44e7, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x44e8-0x44ef, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
Fusion MPT base driver 3.03.04
Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT SPI Host driver 3.03.04
usb 4-1.1: new low speed USB device using uhci_hcd and address 3
ata1: dev 0 cfg 49:2f00 82:3069 83:7d01 84:4023 85:3069 86:3401 87:4023 88:203f
ata1: dev 0 ATA-7, max UDMA/100, 78165360 sectors: LBA48
ata1: dev 0 configured for UDMA/100
scsi0 : ata_piix
ata2: SATA port has no device.
scsi1 : ata_piix
  Vendor: ATA       Model: ST340014AS        Rev: 3.43
  Type:   Direct-Access                      ANSI SCSI revision: 05
input: Microsoft Natural Keyboard Pro as /class/input/input0
input: USB HID v1.10 Keyboard [Microsoft Natural Keyboard Pro] on usb-0000:00:1d.2-1.1
input: Microsoft Natural Keyboard Pro as /class/input/input1
input: USB HID v1.10 Device [Microsoft Natural Keyboard Pro] on usb-0000:00:1d.2-1.1
usb 4-1.2: new low speed USB device using uhci_hcd and address 4
Probing IDE interface ide1...
input: Microsoft Microsoft IntelliMouse® Explorer as /class/input/input2
input: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse® Explorer] on usb-0000:00:1d.2-1.2
usbcore: registered new driver yealink
drivers/usb/input/yealink.c: Yealink phone driver:yld-20050816
hdc: HL-DT-STDVD-ROM GDR8163B, ATAPI CD/DVD-ROM drive
hdd: Maxtor 2B020H1, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
hdd: max request size: 128KiB
hdd: 40020624 sectors (20490 MB) w/2048KiB Cache, CHS=39703/16/63, UDMA(100)
hdd: cache flushes not supported
 hdd: hdd1
ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 18 (level, low) -> IRQ 193
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
scsi2 : ioc0: LSI53C1030, FwRev=01032500h, Ports=1, MaxQ=222, IRQ=193
SCSI device sda: 78165360 512-byte hdwr sectors (40021 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 78165360 512-byte hdwr sectors (40021 MB)
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
EXT3 FS on hdd1, internal journal
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver

Re: vesa fb is slow on 2.6.15.1

[Antonino A. Daplas]

Hai Zaar wrote:
>>> But anyway, do you have a clue why do I still get this error?
>>> PCI: Failed to allocate mem resource #6:20000@f8000000 for 0000:40:00.0
>>> I've several workstations with _exactly_ the same hardware. I've tried
>>> two of them - both give the error with 2.6.15.1 (and no errors with
>>> 2.6.11.12).
>> Can you post the entire dmesg?
>>
>> Tony
>>
> 
> Attached.
> 

Looks harmless to me.

Can you check /proc/iomem just to verify if that particular address has
been reserved by the OS.

And, are you experiencing any problems with your nvidia card, ie, are
you able to launch X?

Tony

Re: vesa fb is slow on 2.6.15.1

[Hai Zaar]

>
> Looks harmless to me.
>
> Can you check /proc/iomem just to verify if that particular address has
> been reserved by the OS.
Relevant iomem entries are:
f0000000-f7ffffff : PCI Bus #40
 f0000000-f7ffffff : 0000:40:00.0
   f0000000-f7ffffff : vesafb
f8000000-f9ffffff : PCI Bus #40
 f8000000-f8ffffff : 0000:40:00.0
 f9000000-f9ffffff : 0000:40:00.0
After I load nvidia.ko, it changes to:
f0000000-f7ffffff : PCI Bus #40
 f0000000-f7ffffff : 0000:40:00.0
   f0000000-f7ffffff : vesafb
f8000000-f9ffffff : PCI Bus #40
 f8000000-f8ffffff : 0000:40:00.0
   f8000000-f8ffffff : nvidia
 f9000000-f9ffffff : 0000:40:00.0

>
> And, are you experiencing any problems with your nvidia card, ie, are
> you able to launch X?
X is working fine. KDE runs, glxgears reports 890fps on full screen (1280x1024)

I usually boot with 'quiet' option, so this error is very evident. I
personally can live with it, but I'll surely get a bunch of mail from
my users reporting the "problem". I hope it will be fixed new next
releases.

Anyway. Thanks a lot for your help guys!

Re: vesa fb is slow on 2.6.15.1

[Hai Zaar]

On 1/28/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Hai Zaar wrote:
> >> Looks harmless to me.
> >>
> >> Can you check /proc/iomem just to verify if that particular address has
> >> been reserved by the OS.
> > Relevant iomem entries are:
> > f0000000-f7ffffff : PCI Bus #40
> >   f0000000-f7ffffff : 0000:40:00.0
> >     f0000000-f7ffffff : vesafb
> > f8000000-f9ffffff : PCI Bus #40
> >   f8000000-f8ffffff : 0000:40:00.0
> >   f9000000-f9ffffff : 0000:40:00.0
> > After I load nvidia.ko, it changes to:
> > f0000000-f7ffffff : PCI Bus #40
> >   f0000000-f7ffffff : 0000:40:00.0
> >     f0000000-f7ffffff : vesafb
> > f8000000-f9ffffff : PCI Bus #40
> >   f8000000-f8ffffff : 0000:40:00.0
>     ^^^^^^^^
> Yes, this address range (16M) is already allocated to resource #0
> of the nvidia card.  So trying to allocate resource #6 on the same
> address looks bogus to me.

Ok. What now?
I've rebooted without 'vga' and 'video' parameters at all - the error stays.

BTW: How do you know that its allocated to resource #0 - are resource
numbers written somewhere in /proc/iomem and I've missed it?


> Tony
>


--
Zaar

Re: vesa fb is slow on 2.6.15.1

[Antonino A. Daplas]

Hai Zaar wrote:
> On 1/28/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Hai Zaar wrote:
>>>> Looks harmless to me.
>>>>
>>>> Can you check /proc/iomem just to verify if that particular address has
>>>> been reserved by the OS.
>>> Relevant iomem entries are:
>>> f0000000-f7ffffff : PCI Bus #40
>>>   f0000000-f7ffffff : 0000:40:00.0
>>>     f0000000-f7ffffff : vesafb
>>> f8000000-f9ffffff : PCI Bus #40
>>>   f8000000-f8ffffff : 0000:40:00.0
>>>   f9000000-f9ffffff : 0000:40:00.0
>>> After I load nvidia.ko, it changes to:
>>> f0000000-f7ffffff : PCI Bus #40
>>>   f0000000-f7ffffff : 0000:40:00.0
>>>     f0000000-f7ffffff : vesafb
>>> f8000000-f9ffffff : PCI Bus #40
>>>   f8000000-f8ffffff : 0000:40:00.0
>>     ^^^^^^^^
>> Yes, this address range (16M) is already allocated to resource #0
>> of the nvidia card.  So trying to allocate resource #6 on the same
>> address looks bogus to me.
> 
> Ok. What now?

Well, it looks to me like a harmless message and I'll just ignore it, I think,
as long as the affected pci device works properly.

> I've rebooted without 'vga' and 'video' parameters at all - the error stays.
> 
> BTW: How do you know that its allocated to resource #0 - are resource
> numbers written somewhere in /proc/iomem and I've missed it?

This was part of your lspci:

	Region 0: Memory at f8000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at f0000000 (64-bit, prefetchable) [size=128M]
	Region 3: Memory at f9000000 (64-bit, non-prefetchable) [size=16M]

See region 0.


Tony