* Re: Radeon FB troubles with recent kernels [not found] ` <3yatk-4mE-29@gated-at.bofh.it> @ 2005-02-15 15:07 ` Vincent C Jones 2005-02-15 22:02 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 16+ messages in thread From: Vincent C Jones @ 2005-02-15 15:07 UTC (permalink / raw) To: linux-kernel; +Cc: benh >> On my Thinkpad X31 with a Radeon Mobility M6 LY I see a major >> regression going from 2.6.11-rc3 to rc4. With rc-4, the frame >> buffer console (using "video=radeonfb:1024x768-24@60") comes up as >> 640x480 expanded to 1024x768. The inability of ACPI suspend to turn >> off the backlight also returns. Using rc-3, frame buffer console >> works fine and suspend/resume appears to work reliably without >> needing radeontool to turn off the backlight (as long as I do it >> from X.org X). > >Ok, this is getting complicated. So far, I'm getting a bit more success >reports that regression reports, so I'm keen to keep this new radeonfb >for 2.6.11... > >There are several issues involved Thanks for the detailed explanation. >As far as the mode setting is concerned, I'm not sure what's going on >whith your specific model, could you please enable radeonfb debug output >in the kernel config and send me the complete dmesg log ? Appended to the end of this response. >As far as the panel blanking is concerned (either during suspend or >normal console blanking), this is a tricky matter. It seems that a bit >of code that works for some panels won't work with others. So far, I >managed to isolate the issue to some panels relying on an inverted >signal out of the chip. I'm in contact with ATI to try to solve that >problem, it might be possible to get proper infos about the type of >panel connected via the BIOS ROM image. Unfortunately, I don't think >I'll get a definitive answer before 2.6.11 is released. > >Note that some users have successfully enabled the powerbook/ibook >specific power management code I have in there for thinkpads. I intend t >o merge some of that stuff after 2.6.11 is done. > >Ben. Thanks for your support and efforts. -- Dr. Vincent C. Jones, PE Expert advice and a helping hand Computer Network Consultant for those who want to manage and Networking Unlimited, Inc. control their networking destiny Phone: +1 201 568-7810 14 Dogwood Lane, Tenafly, NJ 07670 VCJones@NetworkingUnlimited.com http://www.networkingunlimited.com ====================================================================== dmesg with radeonfb & i2c debugs enabled ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ kernel command line: auto BOOT_IMAGE=Test_9.2 ro root=306 pci=usepirqmask desktop idebus=66 video=radeonfb:1024x768-24@60 ide_setup: idebus=66 Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to ffffd000 (01601000) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 599.655 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 775068k/785792k available (2255k kernel code, 10264k reserved, 629k data, 172k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1187.84 BogoMIPS (lpj=593920) 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: a7e9f9bf 00000000 00000000 00000000 00000180 00000000 00000000 CPU: After vendor identify, caps: a7e9f9bf 00000000 00000000 00000000 00000180 00000000 00000000 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 1024K CPU: After all inits, caps: a7e9f9bf 00000000 00000000 00000040 00000180 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel(R) Pentium(R) M processor 1400MHz stepping 05 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0200 (from 0800) NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd8d6, last bus=8 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050125 ACPI: Found ECDT ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Embedded Controller [EC] (gpe 28) ACPI: Power Resource [PUBS] (on) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] SCSI subsystem initialized Linux Kernel Card Services options: [pci] [cardbus] [pm] PCI: Using ACPI for IRQ routing ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary ** workaround, the "pci=routeirq" argument restores the old ** behavior. If this argument makes the device work again, ** please email the output of "lspci" to bjorn.helgaas@hp.com ** so I can fix the driver. Simple Boot Flag at 0x35 set to 0x1 audit: initializing netlink socket (disabled) audit(1108478269.712:0): initialized Initializing Cryptographic API radeonfb_pci_register BEGIN ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 radeonfb (0000:01:00.0): Found 16384k of DDR 32 bits wide videoram radeonfb (0000:01:00.0): mapped 16384k videoram radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=144.00 Mhz, System=144.00 MHz radeonfb: PLL min 12000 max 35000 i2c_adapter i2c-0: registered as adapter #0 i2c_adapter i2c-1: registered as adapter #1 i2c_adapter i2c-2: registered as adapter #2 i2c_adapter i2c-3: registered as adapter #3 1 chips in connector info - chip 1 has 1 connectors * connector 0 of type 2 (CRT) : 2300 Starting monitor auto detection... i2c_adapter i2c-0: master_xfer: with 2 msgs. i2c_adapter i2c-0: master_xfer: with 2 msgs. i2c_adapter i2c-0: master_xfer: with 2 msgs. radeonfb: I2C (port 1) ... not found i2c_adapter i2c-1: master_xfer: with 2 msgs. i2c_adapter i2c-1: master_xfer: with 2 msgs. i2c_adapter i2c-1: master_xfer: with 2 msgs. radeonfb: I2C (port 2) ... not found i2c_adapter i2c-2: master_xfer: with 2 msgs. i2c_adapter i2c-2: master_xfer: with 2 msgs. i2c_adapter i2c-2: master_xfer: with 2 msgs. radeonfb: I2C (port 3) ... not found i2c_adapter i2c-3: master_xfer: with 2 msgs. i2c_adapter i2c-3: master_xfer: with 2 msgs. i2c_adapter i2c-3: master_xfer: with 2 msgs. radeonfb: I2C (port 4) ... not found i2c_adapter i2c-1: master_xfer: with 2 msgs. i2c_adapter i2c-1: master_xfer: with 2 msgs. i2c_adapter i2c-1: master_xfer: with 2 msgs. radeonfb: I2C (port 2) ... not found i2c_adapter i2c-3: master_xfer: with 2 msgs. i2c_adapter i2c-3: master_xfer: with 2 msgs. i2c_adapter i2c-3: master_xfer: with 2 msgs. radeonfb: I2C (port 4) ... not found Non-DDC laptop panel detected i2c_adapter i2c-2: master_xfer: with 2 msgs. i2c_adapter i2c-2: master_xfer: with 2 msgs. i2c_adapter i2c-2: master_xfer: with 2 msgs. radeonfb: I2C (port 3) ... not found i2c_adapter i2c-3: master_xfer: with 2 msgs. i2c_adapter i2c-3: master_xfer: with 2 msgs. i2c_adapter i2c-3: master_xfer: with 2 msgs. radeonfb: I2C (port 4) ... not found radeonfb: Monitor 1 type LCD found radeonfb: Monitor 2 type no found radeonfb: panel ID string: 1024x768 radeonfb: detected LVDS panel size from BIOS: 1024x768 BIOS provided panel power delay: 1000 radeondb: BIOS provided dividers will be used ref_divider = 8 post_divider = 2 fbk_divider = 4d Scanning BIOS table ... 320 x 350 320 x 400 320 x 400 320 x 480 400 x 600 512 x 384 640 x 350 640 x 400 640 x 475 640 x 480 720 x 480 720 x 576 800 x 600 848 x 480 1024 x 768 Found panel in BIOS table: hblank: 320 hOver_plus: 16 hSync_width: 136 vblank: 38 vOver_plus: 2 vSync_width: 6 clock: 6500 Setting up default mode based on panel info radeonfb: Dynamic Clock Power Management enabled hStart = 656, hEnd = 792, hTotal = 960 vStart = 402, vEnd = 408, vTotal = 438 h_total_disp = 0x4f0077 hsync_strt_wid = 0x11028a v_total_disp = 0x18f01b5 vsync_strt_wid = 0x60191 pixclock = 15384 freq = 6500 Console: switching to colour frame buffer device 53x18 radeonfb (0000:01:00.0): ATI Radeon LY radeonfb_pci_register END ACPI: AC Adapter [AC] (off-line) ACPI: Battery Slot [BAT0] (battery present) ACPI: Power Button (FF) [PWRF] ACPI: Lid Switch [LID] ACPI: Sleep Button (CM) [SLPB] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3] C4[C3]) ACPI: Processor [CPU] (supports 8 throttling states) ACPI: Thermal Zone [THM0] (51 C) ibm_acpi: IBM ThinkPad ACPI Extras v0.8 ibm_acpi: http://ibm-acpi.sf.net/ ibm_acpi: dock device not present ibm_acpi: bay device not present Real Time Clock Driver v1.12 Non-volatile memory driver v1.2 i8xx TCO timer: initialized (0x1060). heartbeat=30 sec (nowayout=0) Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected an Intel 855PM Chipset. agpgart: Maximum main memory to use for agp memory: 690M agpgart: AGP aperture is 256M @ 0xd0000000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 [drm] Initialized radeon 1.14.0 20050125 on minor 0: ACPI: PS/2 Keyboard Controller [KBD] at I/O 0x60, 0x64, irq 1 ACPI: PS/2 Mouse Controller [MOU] at irq 12 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 io scheduler noop registered io scheduler deadline registered io scheduler cfq registered Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 66MHz system bus speed for PIO modes ICH4: IDE controller at PCI slot 0000:00:1f.1 PCI: Enabling device 0000:00:1f.1 (0005 -> 0007) ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11 ICH4: chipset revision 1 ICH4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: HTS726060M9AT00, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hda: max request size: 1024KiB hda: 117210240 sectors (60011 MB) w/7877KiB Cache, CHS=16383/255/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 > hda4 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 input: PS/2 Generic Mouse on isa0060/serio1 input: PC Speaker i2c /dev entries driver i2c-core: driver dev_driver registered. i2c_adapter i2c-0: Registered as minor 0 i2c_adapter i2c-1: Registered as minor 1 i2c_adapter i2c-2: Registered as minor 2 i2c_adapter i2c-3: Registered as minor 3 i801_smbus 0000:00:1f.3: I801 using PCI Interrupt for SMBus. i801_smbus 0000:00:1f.3: SMBREV = 0x1 i801_smbus 0000:00:1f.3: I801_smba = 0x1880 i2c_adapter i2c-4: Registered as minor 4 i2c_adapter i2c-4: registered as adapter #4 NET: Registered protocol family 2 IP: routing cache hash table of 8192 buckets, 64Kbytes TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) NET: Registered protocol family 1 ACPI wakeup devices: LID SLPB PCI0 UART PCI1 DOCK USB0 USB1 USB2 AC9M ACPI: (supports S0 S3 S4 S5) ReiserFS: hda6: found reiserfs format "3.6" with standard journal ReiserFS: hda6: using ordered data mode ReiserFS: hda6: journal params: device hda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda6: checking transaction log (hda6) ReiserFS: hda6: Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Freeing unused kernel memory: 172k freed Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A Adding 1572440k swap on /dev/hda8. Priority:42 extents:1 usbcore: registered new driver usbfs usbcore: registered new driver hub device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com Intel(R) PRO/1000 Network Driver - version 5.6.10.1-k2-NAPI Copyright (c) 1999-2004 Intel Corporation. ACPI: PCI interrupt 0000:02:01.0[A] -> GSI 11 (level, low) -> IRQ 11 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection USB Universal Host Controller Interface driver v2.2 ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) -> IRQ 11 uhci_hcd 0000:00:1d.0: UHCI Host Controller ath_hal: module license 'Proprietary' taints kernel. ath_hal: 0.9.12.14 (AR5210, AR5211, AR5212) wlan: 0.8.4.5 (EXPERIMENTAL) PCI: Setting latency timer of device 0000:00:1d.0 to 64 uhci_hcd 0000:00:1d.0: irq 11, io base 0x1800 uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ath_rate_onoe: 1.0 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 11 (level, low) -> IRQ 11 uhci_hcd 0000:00:1d.1: UHCI Host Controller ath_pci: 0.9.4.12 (EXPERIMENTAL) PCI: Setting latency timer of device 0000:00:1d.1 to 64 uhci_hcd 0000:00:1d.1: irq 11, io base 0x1820 uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 11 (level, low) -> IRQ 11 uhci_hcd 0000:00:1d.2: UHCI Host Controller PCI: Setting latency timer of device 0000:00:1d.2 to 64 uhci_hcd 0000:00:1d.2: irq 11, io base 0x1840 uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11 ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 11 (level, low) -> IRQ 11 ehci_hcd 0000:00:1d.7: EHCI Host Controller PCI: Setting latency timer of device 0000:00:1d.7 to 64 ehci_hcd 0000:00:1d.7: irq 11, pci mem 0xc0000000 ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4 PCI: cache line size of 32 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 hub 4-0:1.0: USB hub found hub 4-0:1.0: 6 ports detected ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 11 (level, low) -> IRQ 11 usb 3-1: new full speed USB device using uhci_hcd and address 2 ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: mac 4.2 phy 3.0 5ghz radio 1.7 2ghz radio 2.3 ath0: 802.11 address: 00:05:4e:41:3e:59 ath0: Use hw queue 0 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 0 for WME_AC_VI traffic ath0: Use hw queue 0 for WME_AC_VO traffic ath0: Atheros 5211: mem=0xc0210000, irq=11 ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 11 (level, low) -> IRQ 11 Yenta: CardBus bridge found at 0000:02:00.0 [1014:0532] Yenta: ISA IRQ mask 0x04b8, PCI irq 11 Socket status: 30000006 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 ACPI: PCI interrupt 0000:02:00.1[B] -> GSI 11 (level, low) -> IRQ 11 Yenta: CardBus bridge found at 0000:02:00.1 [1014:0532] Yenta: ISA IRQ mask 0x04b8, PCI irq 11 Socket status: 30000006 ohci1394: $Rev: 1223 $ Ben Collins <bcollins@debian.org> ACPI: PCI interrupt 0000:02:00.2[C] -> GSI 11 (level, low) -> IRQ 11 ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11] MMIO=[c0240000-c02407ff] Max Packet=[2048] ieee1394: Host added: ID:BUS[0-00:1023] GUID[00061b031001139f] Bluetooth: Core ver 2.7 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: HCI USB driver ver 2.8 st: Version 20041025, fixed bufsize 32768, s/g segs 256 usbcore: registered new driver hci_usb Bluetooth: L2CAP ver 2.7 Bluetooth: L2CAP socket layer initialized Bluetooth: HIDP (Human Interface Emulation) ver 1.1 Bluetooth: RFCOMM ver 1.5 Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized ReiserFS: hda7: found reiserfs format "3.6" with standard journal ReiserFS: hda7: using ordered data mode ReiserFS: hda7: journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda7: checking transaction log (hda7) ReiserFS: hda7: Using r5 hash to sort names ReiserFS: hda9: found reiserfs format "3.6" with standard journal ReiserFS: hda9: using ordered data mode ReiserFS: hda9: journal params: device hda9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda9: checking transaction log (hda9) ReiserFS: hda9: Using r5 hash to sort names ReiserFS: hda10: found reiserfs format "3.6" with standard journal ReiserFS: hda10: using ordered data mode ReiserFS: hda10: journal params: device hda10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda10: checking transaction log (hda10) ReiserFS: hda10: Using r5 hash to sort names NTFS driver 2.1.22 [Flags: R/O MODULE]. NTFS volume version 3.1. cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0x800-0x80f: clean. cs: IO port probe 0x800-0x80f: clean. cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x370-0x377 cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x370-0x377 cs: IO port probe 0xa00-0xaff: clean. cs: IO port probe 0xa00-0xaff: clean. ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:1f.5 to 64 intel8x0_measure_ac97_clock: measured 49395 usecs intel8x0: clocking to 48000 NET: Registered protocol family 23 NET: Registered protocol family 10 Disabled Privacy Extensions on device c039d880(lo) IPv6 over IPv4 tunneling driver Disabled Privacy Extensions on device eebae000(sit0) ath0: no IPv6 routers present parport0: PC-style at 0x3bc [PCSPP(,...)] lp0: using parport0 (polling). usbcore: registered new driver usbserial drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0 agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode hStart = 656, hEnd = 792, hTotal = 960 vStart = 402, vEnd = 408, vTotal = 438 h_total_disp = 0x4f0077 hsync_strt_wid = 0x11028a v_total_disp = 0x18f01b5 vsync_strt_wid = 0x60191 pixclock = 15384 freq = 6500 # # # ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-15 15:07 ` Radeon FB troubles with recent kernels Vincent C Jones @ 2005-02-15 22:02 ` Benjamin Herrenschmidt 2005-02-16 1:53 ` Vincent C Jones 0 siblings, 1 reply; 16+ messages in thread From: Benjamin Herrenschmidt @ 2005-02-15 22:02 UTC (permalink / raw) To: Vincent C Jones; +Cc: Linux Kernel list On Tue, 2005-02-15 at 10:07 -0500, Vincent C Jones wrote: > .../... > > radeonfb: panel ID string: 1024x768 > radeonfb: detected LVDS panel size from BIOS: 1024x768 > BIOS provided panel power delay: 1000 > radeondb: BIOS provided dividers will be used > ref_divider = 8 > post_divider = 2 > fbk_divider = 4d > Scanning BIOS table ... > 320 x 350 > 320 x 400 > 320 x 400 > 320 x 480 > 400 x 600 > 512 x 384 > 640 x 350 > 640 x 400 > 640 x 475 > 640 x 480 > 720 x 480 > 720 x 576 > 800 x 600 > 848 x 480 > 1024 x 768 > Found panel in BIOS table: > hblank: 320 > hOver_plus: 16 > hSync_width: 136 > vblank: 38 > vOver_plus: 2 > vSync_width: 6 > clock: 6500 > Setting up default mode based on panel info So far, things look good. At this point, the driver should have obtained the 1024x768 mode that matches your panel... Can you look at radeon_monitor.c, function radeon_check_modes(). This function calls radeon_get_panel_info_BIOS() which is the above. Then, it gets into the if () block that follow that comment: /* * If we have some valid panel infos, we setup the default mode based on * those */ Could you add some more printk's in there to see what's going on ? It should setup a 1024x768 mode at this point... Also, it should not get into any of the other if () statements of this function, except the last bit, in if (1) which adds the panel mode to the list for the driver. Can you check that happens ? (Especially, check that mode_option is NULL and thus the driver isn't trying to override the panel mode from the command line arguments). If all of that looks good, then maybe look at what's going on in the function radeon_match_mode()... Maybe it's not matching the mode properly. > radeonfb: Dynamic Clock Power Management enabled > hStart = 656, hEnd = 792, hTotal = 960 > vStart = 402, vEnd = 408, vTotal = 438 > h_total_disp = 0x4f0077 hsync_strt_wid = 0x11028a > v_total_disp = 0x18f01b5 vsync_strt_wid = 0x60191 > pixclock = 15384 > freq = 6500 > Console: switching to colour frame buffer device 53x18 > radeonfb (0000:01:00.0): ATI Radeon LY > radeonfb_pci_register END > ACPI: AC Adapter [AC] (off-line) > ACPI: Battery Slot [BAT0] (battery present) > ACPI: Power Button (FF) [PWRF] > ACPI: Lid Switch [LID] > ACPI: Sleep Button (CM) [SLPB] > ACPI: Video Device [VID] (multi-head: yes rom: no post: no) > ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3] C4[C3]) > ACPI: Processor [CPU] (supports 8 throttling states) > ACPI: Thermal Zone [THM0] (51 C) > ibm_acpi: IBM ThinkPad ACPI Extras v0.8 > ibm_acpi: http://ibm-acpi.sf.net/ > ibm_acpi: dock device not present > ibm_acpi: bay device not present > Real Time Clock Driver v1.12 > Non-volatile memory driver v1.2 > i8xx TCO timer: initialized (0x1060). heartbeat=30 sec (nowayout=0) > Linux agpgart interface v0.100 (c) Dave Jones > agpgart: Detected an Intel 855PM Chipset. > agpgart: Maximum main memory to use for agp memory: 690M > agpgart: AGP aperture is 256M @ 0xd0000000 > [drm] Initialized drm 1.0.0 20040925 > ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 > [drm] Initialized radeon 1.14.0 20050125 on minor 0: > ACPI: PS/2 Keyboard Controller [KBD] at I/O 0x60, 0x64, irq 1 > ACPI: PS/2 Mouse Controller [MOU] at irq 12 > serio: i8042 AUX port at 0x60,0x64 irq 12 > serio: i8042 KBD port at 0x60,0x64 irq 1 > io scheduler noop registered > io scheduler deadline registered > io scheduler cfq registered > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 66MHz system bus speed for PIO modes > ICH4: IDE controller at PCI slot 0000:00:1f.1 > PCI: Enabling device 0000:00:1f.1 (0005 -> 0007) > ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 > ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11 > ICH4: chipset revision 1 > ICH4: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:pio, hdd:pio > Probing IDE interface ide0... > hda: HTS726060M9AT00, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Probing IDE interface ide1... > hda: max request size: 1024KiB > hda: 117210240 sectors (60011 MB) w/7877KiB Cache, CHS=16383/255/63, UDMA(100) > hda: cache flushes supported > hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 > hda4 > mice: PS/2 mouse device common for all mice > input: AT Translated Set 2 keyboard on isa0060/serio0 > input: PS/2 Generic Mouse on isa0060/serio1 > input: PC Speaker > i2c /dev entries driver > i2c-core: driver dev_driver registered. > i2c_adapter i2c-0: Registered as minor 0 > i2c_adapter i2c-1: Registered as minor 1 > i2c_adapter i2c-2: Registered as minor 2 > i2c_adapter i2c-3: Registered as minor 3 > i801_smbus 0000:00:1f.3: I801 using PCI Interrupt for SMBus. > i801_smbus 0000:00:1f.3: SMBREV = 0x1 > i801_smbus 0000:00:1f.3: I801_smba = 0x1880 > i2c_adapter i2c-4: Registered as minor 4 > i2c_adapter i2c-4: registered as adapter #4 > NET: Registered protocol family 2 > IP: routing cache hash table of 8192 buckets, 64Kbytes > TCP established hash table entries: 131072 (order: 8, 1048576 bytes) > TCP bind hash table entries: 65536 (order: 6, 262144 bytes) > TCP: Hash tables configured (established 131072 bind 65536) > NET: Registered protocol family 1 > ACPI wakeup devices: > LID SLPB PCI0 UART PCI1 DOCK USB0 USB1 USB2 AC9M > ACPI: (supports S0 S3 S4 S5) > ReiserFS: hda6: found reiserfs format "3.6" with standard journal > ReiserFS: hda6: using ordered data mode > ReiserFS: hda6: journal params: device hda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 > ReiserFS: hda6: checking transaction log (hda6) > ReiserFS: hda6: Using r5 hash to sort names > VFS: Mounted root (reiserfs filesystem) readonly. > Freeing unused kernel memory: 172k freed > Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled > ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A > Adding 1572440k swap on /dev/hda8. Priority:42 extents:1 > usbcore: registered new driver usbfs > usbcore: registered new driver hub > device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com > Intel(R) PRO/1000 Network Driver - version 5.6.10.1-k2-NAPI > Copyright (c) 1999-2004 Intel Corporation. > ACPI: PCI interrupt 0000:02:01.0[A] -> GSI 11 (level, low) -> IRQ 11 > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > USB Universal Host Controller Interface driver v2.2 > ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) -> IRQ 11 > uhci_hcd 0000:00:1d.0: UHCI Host Controller > ath_hal: module license 'Proprietary' taints kernel. > ath_hal: 0.9.12.14 (AR5210, AR5211, AR5212) > wlan: 0.8.4.5 (EXPERIMENTAL) > PCI: Setting latency timer of device 0000:00:1d.0 to 64 > uhci_hcd 0000:00:1d.0: irq 11, io base 0x1800 > uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1 > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 2 ports detected > ath_rate_onoe: 1.0 > ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 > ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 11 (level, low) -> IRQ 11 > uhci_hcd 0000:00:1d.1: UHCI Host Controller > ath_pci: 0.9.4.12 (EXPERIMENTAL) > PCI: Setting latency timer of device 0000:00:1d.1 to 64 > uhci_hcd 0000:00:1d.1: irq 11, io base 0x1820 > uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2 > hub 2-0:1.0: USB hub found > hub 2-0:1.0: 2 ports detected > ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 11 (level, low) -> IRQ 11 > uhci_hcd 0000:00:1d.2: UHCI Host Controller > PCI: Setting latency timer of device 0000:00:1d.2 to 64 > uhci_hcd 0000:00:1d.2: irq 11, io base 0x1840 > uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3 > hub 3-0:1.0: USB hub found > hub 3-0:1.0: 2 ports detected > ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11 > ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 11 (level, low) -> IRQ 11 > ehci_hcd 0000:00:1d.7: EHCI Host Controller > PCI: Setting latency timer of device 0000:00:1d.7 to 64 > ehci_hcd 0000:00:1d.7: irq 11, pci mem 0xc0000000 > ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4 > PCI: cache line size of 32 is not supported by device 0000:00:1d.7 > ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 > hub 4-0:1.0: USB hub found > hub 4-0:1.0: 6 ports detected > ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 11 (level, low) -> IRQ 11 > usb 3-1: new full speed USB device using uhci_hcd and address 2 > ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > ath0: mac 4.2 phy 3.0 5ghz radio 1.7 2ghz radio 2.3 > ath0: 802.11 address: 00:05:4e:41:3e:59 > ath0: Use hw queue 0 for WME_AC_BE traffic > ath0: Use hw queue 0 for WME_AC_BK traffic > ath0: Use hw queue 0 for WME_AC_VI traffic > ath0: Use hw queue 0 for WME_AC_VO traffic > ath0: Atheros 5211: mem=0xc0210000, irq=11 > ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 11 (level, low) -> IRQ 11 > Yenta: CardBus bridge found at 0000:02:00.0 [1014:0532] > Yenta: ISA IRQ mask 0x04b8, PCI irq 11 > Socket status: 30000006 > ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 > ACPI: PCI interrupt 0000:02:00.1[B] -> GSI 11 (level, low) -> IRQ 11 > Yenta: CardBus bridge found at 0000:02:00.1 [1014:0532] > Yenta: ISA IRQ mask 0x04b8, PCI irq 11 > Socket status: 30000006 > ohci1394: $Rev: 1223 $ Ben Collins <bcollins@debian.org> > ACPI: PCI interrupt 0000:02:00.2[C] -> GSI 11 (level, low) -> IRQ 11 > ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11] MMIO=[c0240000-c02407ff] Max Packet=[2048] > ieee1394: Host added: ID:BUS[0-00:1023] GUID[00061b031001139f] > Bluetooth: Core ver 2.7 > NET: Registered protocol family 31 > Bluetooth: HCI device and connection manager initialized > Bluetooth: HCI socket layer initialized > Bluetooth: HCI USB driver ver 2.8 > st: Version 20041025, fixed bufsize 32768, s/g segs 256 > usbcore: registered new driver hci_usb > Bluetooth: L2CAP ver 2.7 > Bluetooth: L2CAP socket layer initialized > Bluetooth: HIDP (Human Interface Emulation) ver 1.1 > Bluetooth: RFCOMM ver 1.5 > Bluetooth: RFCOMM socket layer initialized > Bluetooth: RFCOMM TTY layer initialized > ReiserFS: hda7: found reiserfs format "3.6" with standard journal > ReiserFS: hda7: using ordered data mode > ReiserFS: hda7: journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 > ReiserFS: hda7: checking transaction log (hda7) > ReiserFS: hda7: Using r5 hash to sort names > ReiserFS: hda9: found reiserfs format "3.6" with standard journal > ReiserFS: hda9: using ordered data mode > ReiserFS: hda9: journal params: device hda9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 > ReiserFS: hda9: checking transaction log (hda9) > ReiserFS: hda9: Using r5 hash to sort names > ReiserFS: hda10: found reiserfs format "3.6" with standard journal > ReiserFS: hda10: using ordered data mode > ReiserFS: hda10: journal params: device hda10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 > ReiserFS: hda10: checking transaction log (hda10) > ReiserFS: hda10: Using r5 hash to sort names > NTFS driver 2.1.22 [Flags: R/O MODULE]. > NTFS volume version 3.1. > cs: IO port probe 0xc00-0xcff: clean. > cs: IO port probe 0xc00-0xcff: clean. > cs: IO port probe 0x820-0x8ff: clean. > cs: IO port probe 0x820-0x8ff: clean. > cs: IO port probe 0x800-0x80f: clean. > cs: IO port probe 0x800-0x80f: clean. > cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 > cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 > cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x370-0x377 > cs: IO port probe 0x100-0x3af: excluding 0x170-0x177 0x370-0x377 > cs: IO port probe 0xa00-0xaff: clean. > cs: IO port probe 0xa00-0xaff: clean. > ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 11 (level, low) -> IRQ 11 > PCI: Setting latency timer of device 0000:00:1f.5 to 64 > intel8x0_measure_ac97_clock: measured 49395 usecs > intel8x0: clocking to 48000 > NET: Registered protocol family 23 > NET: Registered protocol family 10 > Disabled Privacy Extensions on device c039d880(lo) > IPv6 over IPv4 tunneling driver > Disabled Privacy Extensions on device eebae000(sit0) > ath0: no IPv6 routers present > parport0: PC-style at 0x3bc [PCSPP(,...)] > lp0: using parport0 (polling). > usbcore: registered new driver usbserial > drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0 > agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. > agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode > agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode > hStart = 656, hEnd = 792, hTotal = 960 > vStart = 402, vEnd = 408, vTotal = 438 > h_total_disp = 0x4f0077 hsync_strt_wid = 0x11028a > v_total_disp = 0x18f01b5 vsync_strt_wid = 0x60191 > pixclock = 15384 > freq = 6500 > > # # # -- Benjamin Herrenschmidt <benh@kernel.crashing.org> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-15 22:02 ` Benjamin Herrenschmidt @ 2005-02-16 1:53 ` Vincent C Jones 2005-02-16 2:41 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 16+ messages in thread From: Vincent C Jones @ 2005-02-16 1:53 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: Linux Kernel list On Wed, Feb 16, 2005 at 09:02:01AM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2005-02-15 at 10:07 -0500, Vincent C Jones wrote: > > > .../... > > > > radeonfb: panel ID string: 1024x768 > > radeonfb: detected LVDS panel size from BIOS: 1024x768 > > BIOS provided panel power delay: 1000 > > radeondb: BIOS provided dividers will be used > > ref_divider = 8 > > post_divider = 2 > > fbk_divider = 4d > > Scanning BIOS table ... > > 320 x 350 > > 320 x 400 > > 320 x 400 > > 320 x 480 > > 400 x 600 > > 512 x 384 > > 640 x 350 > > 640 x 400 > > 640 x 475 > > 640 x 480 > > 720 x 480 > > 720 x 576 > > 800 x 600 > > 848 x 480 > > 1024 x 768 > > Found panel in BIOS table: > > hblank: 320 > > hOver_plus: 16 > > hSync_width: 136 > > vblank: 38 > > vOver_plus: 2 > > vSync_width: 6 > > clock: 6500 > > Setting up default mode based on panel info > > So far, things look good. At this point, the driver should have obtained > the 1024x768 mode that matches your panel... > > Can you look at radeon_monitor.c, function radeon_check_modes(). This > function calls radeon_get_panel_info_BIOS() which is the above. Then, it > gets into the if () block that follow that comment: > > /* > * If we have some valid panel infos, we setup the default mode based on > * those > */ > > Could you add some more printk's in there to see what's going on ? It should > setup a 1024x768 mode at this point... > > Also, it should not get into any of the other if () statements of this function, > except the last bit, in if (1) which adds the panel mode to the list for the > driver. Can you check that happens ? (Especially, check that mode_option is NULL > and thus the driver isn't trying to override the panel mode from the command > line arguments). This appears to be the challenge... the mode_option is being set from the command line. > > If all of that looks good, then maybe look at what's going on in the function > radeon_match_mode()... Maybe it's not matching the mode properly. > > > radeonfb: Dynamic Clock Power Management enabled > > hStart = 656, hEnd = 792, hTotal = 960 > > vStart = 402, vEnd = 408, vTotal = 438 > > h_total_disp = 0x4f0077 hsync_strt_wid = 0x11028a > > v_total_disp = 0x18f01b5 vsync_strt_wid = 0x60191 > > pixclock = 15384 > > freq = 6500 > > Console: switching to colour frame buffer device 53x18 > > radeonfb (0000:01:00.0): ATI Radeon LY > > radeonfb_pci_register END > > ACPI: AC Adapter [AC] (off-line) . . . Setting up default mode based on panel info vcj: var->xres = 1024, yres = 768 vcj: var->xres_virtual = 1024, yres_virtual = 768 vcj: var->hsync_len = 136, vsync_len = 6 vcj: var->sync = 0x3 vcj: Inside if (mode_option) vcj: Inside if (fb_find_mode(xxx)) with fb_find_mode = 3 vcj: Inside if (1) vcj: Leaving radeon_check_modes radeonfb: Dynamic Clock Power Management enabled . . . Duhhh... Going back to the beginning, guess what I find... Kernel command line: auto BOOT_IMAGE=Test_9.2 ro root=306 pci=usepirqmask desktop idebus=66 video=radeonfb:1024x768-24@60 Note the "video=radeonfb:1024x768-24@60" which used to be required to get the console into 1024x768 mode but is documented in "modefb.txt" as an invalid combination of mode specifications (and also states that radeonfb does not support mode specification...). So other than the loss of temporary working of backlight controls, I just see undocumented progress :-) Thanks again, and keep up the great work! -- Dr. Vincent C. Jones, PE Expert advice and a helping hand Computer Network Consultant for those who want to manage and Networking Unlimited, Inc. control their networking destiny Phone: +1 201 568-7810 14 Dogwood Lane, Tenafly, NJ 07670 VCJones@NetworkingUnlimited.com http://www.networkingunlimited.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-16 1:53 ` Vincent C Jones @ 2005-02-16 2:41 ` Benjamin Herrenschmidt 2005-02-16 14:39 ` Vincent C Jones 0 siblings, 1 reply; 16+ messages in thread From: Benjamin Herrenschmidt @ 2005-02-16 2:41 UTC (permalink / raw) To: Vincent C Jones; +Cc: Linux Kernel list On Tue, 2005-02-15 at 20:53 -0500, Vincent C Jones wrote: > > Kernel command line: auto BOOT_IMAGE=Test_9.2 ro root=306 pci=usepirqmask desktop idebus=66 video=radeonfb:1024x768-24@60 > > Note the "video=radeonfb:1024x768-24@60" which used to be required to > get the console into 1024x768 mode but is documented in "modefb.txt" > as an invalid combination of mode specifications (and also states > that radeonfb does not support mode specification...). So other > than the loss of temporary working of backlight controls, I just > see undocumented progress :-) > > Thanks again, and keep up the great work! Heh, good. Well, the mode spec should work in fact, provided that you get the syntax right, though I haven't tried. I'll have a look later, but if it doesn't work, then it was always broken and it's not a regression :) I still want to fix more stuff in this area, but for now, I'm concerned mostly about regressions. Can you remind me exactly what's up with the backlight control ? Ben. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-16 2:41 ` Benjamin Herrenschmidt @ 2005-02-16 14:39 ` Vincent C Jones 0 siblings, 0 replies; 16+ messages in thread From: Vincent C Jones @ 2005-02-16 14:39 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: Linux Kernel list On Wed, Feb 16, 2005 at 01:41:20PM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2005-02-15 at 20:53 -0500, Vincent C Jones wrote: > > > > > Kernel command line: auto BOOT_IMAGE=Test_9.2 ro root=306 pci=usepirqmask desktop idebus=66 video=radeonfb:1024x768-24@60 > > > > Note the "video=radeonfb:1024x768-24@60" which used to be required to > > get the console into 1024x768 mode but is documented in "modefb.txt" > > as an invalid combination of mode specifications (and also states > > that radeonfb does not support mode specification...). So other > > than the loss of temporary working of backlight controls, I just > > see undocumented progress :-) > > > > Thanks again, and keep up the great work! > > Heh, good. Well, the mode spec should work in fact, provided that you > get the syntax right, though I haven't tried. I'll have a look later, > but if it doesn't work, then it was always broken and it's not a > regression :) I still want to fix more stuff in this area, but for now, > I'm concerned mostly about regressions. > > Can you remind me exactly what's up with the backlight control ? > > Ben. Out of the box (SuSE 9.2) with kernel 2.6.11-rc2, powersaved successfully suspends to RAM and resumes correctly (can't speak for earlier versions). With 2.6.11-rc3, suspend to RAM works except that the backlight on the display does not stay turned off. Once suspended, the backlight is on even if the lid switch is closed! Others with X31's (and I assume, other ThinkPads, and probably other notebooks) have only gotten ACPI to work with earlier kernels by using the radeontool to turn off the back light. See, for example, http://www.summet.com/x31/ which includes the following: Suspend to memory works well if you configure a few files like this: * Create an /etc/acpi/events/sleepbtn file as follows: event=button[ /]sleep action=/etc/acpi/actions/sleepbtn.sh * Create an /etc/acpi/actions/sleepbtn.sh file as follows: #!/bin/bash #Stop the bluetooth service. service bluetooth stop #sync the disks. sync && sync && sync #Change the screen to VT1 (text mode) /usr/bin/chvt 1 #turn off the backlight on the laptop # (Note: You must have the radeontool installed....) /usr/sbin/radeontool light off #perform the actual "go-to-sleep" function. echo "mem" > /sys/power/state #Pause a second or two to let us sleep. sleep 2 #Sleepytime...Everything after this line gets exectued #after the user resumes... #switch back to the Xterminal (automatically turns on backlight) /usr/bin/chvt 7 #restart services... service bluetooth start # # # -- Dr. Vincent C. Jones, PE Expert advice and a helping hand Computer Network Consultant for those who want to manage and Networking Unlimited, Inc. control their networking destiny Phone: +1 201 568-7810 14 Dogwood Lane, Tenafly, NJ 07670 VCJones@NetworkingUnlimited.com http://www.networkingunlimited.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels
@ 2005-02-16 10:08 tvrtko.ursulin
0 siblings, 0 replies; 16+ messages in thread
From: tvrtko.ursulin @ 2005-02-16 10:08 UTC (permalink / raw)
To: Matt Mackall; +Cc: adaplas, benh, linux-kernel
On 14/02/2005 20:39:02 linux-kernel-owner wrote:
>On my Thinkpad T30 with a Radeon Mobility M7 LW, I get interesting
>console video corruption if I start GDM, switch back to text mode,
>then stop it again. X is Xfree86 from Debian/unstable or X.org 6.8.2.
>
>The corruption shows up whenever the console scrolls after X has been
>shut down and manifests as horizontal lines spaced about 4 pixel rows
>apart containing contents recognizable as the X display. Switch from
>vt1 to vt2 and back or visual bell clears things back to normal, but
>corruption will reappear on the next scroll.
>
>This has appeared in at least 2.6.11-rc3-mm2 and rc4.
Same problem here (same chip) for a long long time (at least 2.6.6) so I
don't think it appeared with latest changes.
--
Tvrtko August Ursulin
Software Engineer, Sophos
Tel: 01235 559933
Web: www.sophos.com
Sophos - protecting businesses against viruses and spam
^ permalink raw reply [flat|nested] 16+ messages in thread[parent not found: <3xVku-kH-15@gated-at.bofh.it>]
* Re: Radeon FB troubles with recent kernels [not found] <3xVku-kH-15@gated-at.bofh.it> @ 2005-02-15 3:14 ` Vincent C Jones 2005-02-15 12:46 ` Benjamin Herrenschmidt 2005-02-15 12:50 ` Benjamin Herrenschmidt 0 siblings, 2 replies; 16+ messages in thread From: Vincent C Jones @ 2005-02-15 3:14 UTC (permalink / raw) To: linux-kernel; +Cc: mpm In article <3xVku-kH-15@gated-at.bofh.it> you write: >On my Thinkpad T30 with a Radeon Mobility M7 LW, I get interesting >console video corruption if I start GDM, switch back to text mode, >then stop it again. X is Xfree86 from Debian/unstable or X.org 6.8.2. > >The corruption shows up whenever the console scrolls after X has been >shut down and manifests as horizontal lines spaced about 4 pixel rows >apart containing contents recognizable as the X display. Switch from >vt1 to vt2 and back or visual bell clears things back to normal, but >corruption will reappear on the next scroll. > >This has appeared in at least 2.6.11-rc3-mm2 and rc4. On my Thinkpad X31 with a Radeon Mobility M6 LY I see a major regression going from 2.6.11-rc3 to rc4. With rc-4, the frame buffer console (using "video=radeonfb:1024x768-24@60") comes up as 640x480 expanded to 1024x768. The inability of ACPI suspend to turn off the backlight also returns. Using rc-3, frame buffer console works fine and suspend/resume appears to work reliably without needing radeontool to turn off the backlight (as long as I do it from X.org X). -- Dr. Vincent C. Jones, PE Expert advice and a helping hand Computer Network Consultant for those who want to manage and Networking Unlimited, Inc. control their networking destiny Phone: +1 201 568-7810 14 Dogwood Lane, Tenafly, NJ 07670 VCJones@NetworkingUnlimited.com http://www.networkingunlimited.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-15 3:14 ` Vincent C Jones @ 2005-02-15 12:46 ` Benjamin Herrenschmidt 2005-02-15 12:50 ` Benjamin Herrenschmidt 1 sibling, 0 replies; 16+ messages in thread From: Benjamin Herrenschmidt @ 2005-02-15 12:46 UTC (permalink / raw) To: Vincent C Jones; +Cc: linux-kernel, mpm On Mon, 2005-02-14 at 22:14 -0500, Vincent C Jones wrote: > In article <3xVku-kH-15@gated-at.bofh.it> you write: > >On my Thinkpad T30 with a Radeon Mobility M7 LW, I get interesting > >console video corruption if I start GDM, switch back to text mode, > >then stop it again. X is Xfree86 from Debian/unstable or X.org 6.8.2. > > > >The corruption shows up whenever the console scrolls after X has been > >shut down and manifests as horizontal lines spaced about 4 pixel rows > >apart containing contents recognizable as the X display. Switch from > >vt1 to vt2 and back or visual bell clears things back to normal, but > >corruption will reappear on the next scroll. > > > >This has appeared in at least 2.6.11-rc3-mm2 and rc4. > > On my Thinkpad X31 with a Radeon Mobility M6 LY I see a major > regression going from 2.6.11-rc3 to rc4. With rc-4, the frame > buffer console (using "video=radeonfb:1024x768-24@60") comes up as > 640x480 expanded to 1024x768. The inability of ACPI suspend to turn > off the backlight also returns. Using rc-3, frame buffer console > works fine and suspend/resume appears to work reliably without > needing radeontool to turn off the backlight (as long as I do it > from X.org X). Ok, so, about half of users are reporting an improvement, and half are reporting a regression... this is getting nasty... As far as the mode is concerned, can you send me a complete dmesg log with the radeonfb debug output enabled in your .config ? Now, regarding backlight and suspend, it's a more complicated problem. So far, I managed to "isolate" the issue to the type of flat panel connected to the chip. In some cases, it seems, the panel uses an inverted signal to drive the backlight. So depending on the type of panel, a given bit of code will work ... or not. I'm in contact with ATI to try to figure out how to get some proper infos about the backlight from the BIOS (if possible at all), and some other folks are working on adapting my power management code to various model of thinkpads. Unfortunately, I can't promise a version of radeonfb that will fix everything for everybody by 2.6.11... there are still a few "gray areas" in there, that I'm trying to clear up, hopefully ATI will provide me with the proper infos soon... Ben. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-15 3:14 ` Vincent C Jones 2005-02-15 12:46 ` Benjamin Herrenschmidt @ 2005-02-15 12:50 ` Benjamin Herrenschmidt 1 sibling, 0 replies; 16+ messages in thread From: Benjamin Herrenschmidt @ 2005-02-15 12:50 UTC (permalink / raw) To: Vincent C Jones; +Cc: linux-kernel, mpm > On my Thinkpad X31 with a Radeon Mobility M6 LY I see a major > regression going from 2.6.11-rc3 to rc4. With rc-4, the frame > buffer console (using "video=radeonfb:1024x768-24@60") comes up as > 640x480 expanded to 1024x768. The inability of ACPI suspend to turn > off the backlight also returns. Using rc-3, frame buffer console > works fine and suspend/resume appears to work reliably without > needing radeontool to turn off the backlight (as long as I do it > from X.org X). Ok, this is getting complicated. So far, I'm getting a bit more success reports that regression reports, so I'm keen to keep this new radeonfb for 2.6.11... There are several issues involved As far as the mode setting is concerned, I'm not sure what's going on whith your specific model, could you please enable radeonfb debug output in the kernel config and send me the complete dmesg log ? As far as the panel blanking is concerned (either during suspend or normal console blanking), this is a tricky matter. It seems that a bit of code that works for some panels won't work with others. So far, I managed to isolate the issue to some panels relying on an inverted signal out of the chip. I'm in contact with ATI to try to solve that problem, it might be possible to get proper infos about the type of panel connected via the BIOS ROM image. Unfortunately, I don't think I'll get a definitive answer before 2.6.11 is released. Note that some users have successfully enabled the powerbook/ibook specific power management code I have in there for thinkpads. I intend t o merge some of that stuff after 2.6.11 is done. Ben. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Radeon FB troubles with recent kernels @ 2005-02-14 20:39 Matt Mackall 2005-02-14 22:38 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 16+ messages in thread From: Matt Mackall @ 2005-02-14 20:39 UTC (permalink / raw) To: linux-kernel; +Cc: benh, adaplas On my Thinkpad T30 with a Radeon Mobility M7 LW, I get interesting console video corruption if I start GDM, switch back to text mode, then stop it again. X is Xfree86 from Debian/unstable or X.org 6.8.2. The corruption shows up whenever the console scrolls after X has been shut down and manifests as horizontal lines spaced about 4 pixel rows apart containing contents recognizable as the X display. Switch from vt1 to vt2 and back or visual bell clears things back to normal, but corruption will reappear on the next scroll. This has appeared in at least 2.6.11-rc3-mm2 and rc4. -- Mathematics is the supreme nostalgia of our time. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-14 20:39 Matt Mackall @ 2005-02-14 22:38 ` Benjamin Herrenschmidt 2005-02-14 23:08 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 16+ messages in thread From: Benjamin Herrenschmidt @ 2005-02-14 22:38 UTC (permalink / raw) To: Matt Mackall; +Cc: linux-kernel, adaplas On Mon, 2005-02-14 at 12:39 -0800, Matt Mackall wrote: > On my Thinkpad T30 with a Radeon Mobility M7 LW, I get interesting > console video corruption if I start GDM, switch back to text mode, > then stop it again. X is Xfree86 from Debian/unstable or X.org 6.8.2. > > The corruption shows up whenever the console scrolls after X has been > shut down and manifests as horizontal lines spaced about 4 pixel rows > apart containing contents recognizable as the X display. Switch from > vt1 to vt2 and back or visual bell clears things back to normal, but > corruption will reappear on the next scroll. > > This has appeared in at least 2.6.11-rc3-mm2 and rc4. Appeared ? hah... that's strange. X is known to fuck up the chip when quit, but I wouldn't have expected any change due to the new version of radeonfb. From what you describe, it looks like an offset register is changed by X, or the surface control. My patch did not change any of radeonfb accel code though... I'll catch up with you on IRC ... Ben. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-14 22:38 ` Benjamin Herrenschmidt @ 2005-02-14 23:08 ` Benjamin Herrenschmidt 2005-02-15 0:02 ` Antonino A. Daplas 2005-02-15 0:20 ` Matt Mackall 0 siblings, 2 replies; 16+ messages in thread From: Benjamin Herrenschmidt @ 2005-02-14 23:08 UTC (permalink / raw) To: Matt Mackall; +Cc: linux-kernel, adaplas > Appeared ? hah... that's strange. X is known to fuck up the chip when > quit, but I wouldn't have expected any change due to the new version of > radeonfb. From what you describe, it looks like an offset register is > changed by X, or the surface control. > > My patch did not change any of radeonfb accel code though... > > I'll catch up with you on IRC ... Ok, from our discussions, it's not related to the power management code, and an engine reset triggered by fbset fixes it. So at this point, I can see no change in the driver explaining it... We did some changes to the VT layer to force a mode setting (and thus an engine reset) when going away from X, so I can't see why that wouldn't work, while using fbset later on works ... this goes through the same code path in the driver... unless we are facing a timing issue... X is known to play funny tricks, like touching the engine when it's in the background (not frontmost VT) and quit, or possibly other bad things on console switch. Maybe I changed enough delays (speeded up) the mode switch so that we fall into a case where X has not finished mucking up with us... Can you try adding some msleep(200) or so at the beginning at radeonfb_set_par() or radeon_write_mode() to see if that makes any difference ? Some printk's in there would help to... I expect calls to radeon_engine_init() to fix it and such a call is present in the mode restore unless accel is disabled... Can you check what's happening ? Ben. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-14 23:08 ` Benjamin Herrenschmidt @ 2005-02-15 0:02 ` Antonino A. Daplas 2005-02-15 0:20 ` Matt Mackall 1 sibling, 0 replies; 16+ messages in thread From: Antonino A. Daplas @ 2005-02-15 0:02 UTC (permalink / raw) To: Benjamin Herrenschmidt, Matt Mackall; +Cc: linux-kernel, adaplas On Tuesday 15 February 2005 07:08, Benjamin Herrenschmidt wrote: > > Appeared ? hah... that's strange. X is known to fuck up the chip when > > quit, but I wouldn't have expected any change due to the new version of > > radeonfb. From what you describe, it looks like an offset register is > > changed by X, or the surface control. > > > > My patch did not change any of radeonfb accel code though... > > > > I'll catch up with you on IRC ... > > Ok, from our discussions, it's not related to the power management code, > and an engine reset triggered by fbset fixes it. So at this point, I can > see no change in the driver explaining it... > > We did some changes to the VT layer to force a mode setting (and thus an > engine reset) when going away from X, so I can't see why that wouldn't > work, while using fbset later on works ... this goes through the same > code path in the driver... unless we are facing a timing issue... You can also try inserting something like this before register_framebuffer() info->flags |= FBINFO_MISC_MODESWITCHLATE; to delay the call to set_par as late as possible. It's the same hack used in rivafb, but there were reports before that it does not work with a few radeon setups. Tony > > X is known to play funny tricks, like touching the engine when it's in > the background (not frontmost VT) and quit, or possibly other bad things > on console switch. Maybe I changed enough delays (speeded up) the mode > switch so that we fall into a case where X has not finished mucking up > with us... > > Can you try adding some msleep(200) or so at the beginning at > radeonfb_set_par() or radeon_write_mode() to see if that makes any > difference ? > > Some printk's in there would help to... I expect calls to > radeon_engine_init() to fix it and such a call is present in the mode > restore unless accel is disabled... > > Can you check what's happening ? > > Ben. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-14 23:08 ` Benjamin Herrenschmidt 2005-02-15 0:02 ` Antonino A. Daplas @ 2005-02-15 0:20 ` Matt Mackall 2005-02-15 1:07 ` Benjamin Herrenschmidt 1 sibling, 1 reply; 16+ messages in thread From: Matt Mackall @ 2005-02-15 0:20 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linux-kernel, adaplas On Tue, Feb 15, 2005 at 10:08:11AM +1100, Benjamin Herrenschmidt wrote: > > > Appeared ? hah... that's strange. X is known to fuck up the chip when > > quit, but I wouldn't have expected any change due to the new version of > > radeonfb. From what you describe, it looks like an offset register is > > changed by X, or the surface control. > > > > My patch did not change any of radeonfb accel code though... > > > > I'll catch up with you on IRC ... > > Ok, from our discussions, it's not related to the power management code, > and an engine reset triggered by fbset fixes it. So at this point, I can > see no change in the driver explaining it... > > We did some changes to the VT layer to force a mode setting (and thus an > engine reset) when going away from X, so I can't see why that wouldn't > work, while using fbset later on works ... this goes through the same > code path in the driver... unless we are facing a timing issue... > > X is known to play funny tricks, like touching the engine when it's in > the background (not frontmost VT) and quit, or possibly other bad things > on console switch. Maybe I changed enough delays (speeded up) the mode > switch so that we fall into a case where X has not finished mucking up > with us... > > Can you try adding some msleep(200) or so at the beginning at > radeonfb_set_par() or radeon_write_mode() to see if that makes any > difference ? Nope. No printk outputs from _set_par, _write_mode, or _engine_init. Just to clarify: the gdm stop is done from tty1 while gdm is running on tty7, so I don't think it's a matter of mode switch logic. If I do "sleep 5; /etc/init.d/gdm stop" and then switch to tty7 and wait for it to stop, all is fine. Also, I'm still seeing the LCD blooming + hang on starting radeonfb. It's something like 1 in 10 boots rather than every boot now though. -- Mathematics is the supreme nostalgia of our time. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-15 0:20 ` Matt Mackall @ 2005-02-15 1:07 ` Benjamin Herrenschmidt 2005-02-15 6:06 ` Matt Mackall 0 siblings, 1 reply; 16+ messages in thread From: Benjamin Herrenschmidt @ 2005-02-15 1:07 UTC (permalink / raw) To: Matt Mackall; +Cc: linux-kernel, adaplas > Nope. No printk outputs from _set_par, _write_mode, or _engine_init. > > Just to clarify: the gdm stop is done from tty1 while gdm is running > on tty7, so I don't think it's a matter of mode switch logic. Ohhh, this is a known bug then. When you kill X while it's not on the front VT, it will crap on the engine. This has always been the case, I suppose that if you didn't notice it before, it 's because you are lucky :) > If I do "sleep 5; /etc/init.d/gdm stop" and then switch to tty7 and > wait for it to stop, all is fine. Yes. > > Also, I'm still seeing the LCD blooming + hang on starting radeonfb. > It's something like 1 in 10 boots rather than every boot now though. Does it actually hangs ? That's weird... looks like a chip crash. Can you check if that happens with radeonfb.default_dynclk=-1 on the kernel command line ? Ben. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Radeon FB troubles with recent kernels 2005-02-15 1:07 ` Benjamin Herrenschmidt @ 2005-02-15 6:06 ` Matt Mackall 0 siblings, 0 replies; 16+ messages in thread From: Matt Mackall @ 2005-02-15 6:06 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: linux-kernel, adaplas On Tue, Feb 15, 2005 at 12:07:34PM +1100, Benjamin Herrenschmidt wrote: > > > Nope. No printk outputs from _set_par, _write_mode, or _engine_init. > > > > Just to clarify: the gdm stop is done from tty1 while gdm is running > > on tty7, so I don't think it's a matter of mode switch logic. > > Ohhh, this is a known bug then. When you kill X while it's not on the > front VT, it will crap on the engine. This has always been the case, I > suppose that if you didn't notice it before, it 's because you are > lucky :) I think I noticed it in the course of testing recent fbdev and console code changes.. > > Also, I'm still seeing the LCD blooming + hang on starting radeonfb. > > It's something like 1 in 10 boots rather than every boot now though. > > Does it actually hangs ? That's weird... looks like a chip crash. Can > you check if that happens with radeonfb.default_dynclk=-1 on the kernel > command line ? Hard to say, it's rather a pain to reproduce. I can add that to my default boot and if it shows up again, I'll let you know. -- Mathematics is the supreme nostalgia of our time. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2005-02-16 14:42 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <3y1SR-5K6-1@gated-at.bofh.it>
[not found] ` <3yatk-4mE-29@gated-at.bofh.it>
2005-02-15 15:07 ` Radeon FB troubles with recent kernels Vincent C Jones
2005-02-15 22:02 ` Benjamin Herrenschmidt
2005-02-16 1:53 ` Vincent C Jones
2005-02-16 2:41 ` Benjamin Herrenschmidt
2005-02-16 14:39 ` Vincent C Jones
2005-02-16 10:08 tvrtko.ursulin
[not found] <3xVku-kH-15@gated-at.bofh.it>
2005-02-15 3:14 ` Vincent C Jones
2005-02-15 12:46 ` Benjamin Herrenschmidt
2005-02-15 12:50 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2005-02-14 20:39 Matt Mackall
2005-02-14 22:38 ` Benjamin Herrenschmidt
2005-02-14 23:08 ` Benjamin Herrenschmidt
2005-02-15 0:02 ` Antonino A. Daplas
2005-02-15 0:20 ` Matt Mackall
2005-02-15 1:07 ` Benjamin Herrenschmidt
2005-02-15 6:06 ` Matt Mackall
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox