Re: [2.6.13-rc3][PCMCIA] - iounmap: bad address f1d62000
On Sat, Jul 16, 2005 at 05:12:58PM +0200, Dominik Brodowski wrote: > Could you check whether this patch helps, please? > > Index: 2.6.13-rc3-git2/drivers/pcmcia/cistpl.c > === > --- 2.6.13-rc3-git2.orig/drivers/pcmcia/cistpl.c > +++ 2.6.13-rc3-git2/drivers/pcmcia/cistpl.c > @@ -88,31 +88,38 @@ EXPORT_SYMBOL(release_cis_mem); > static void __iomem * This patch appears to have cured it! Good job. Just in case it is of use to use, I've also responded to your first request below. > Hi, > > Could you send me the output of /proc/iomem on both a working kernel and on > 2.6.13-rc3-APM, please? > > Thanks, > Dominik First is as fails, second is same kernel with your patch applied, where it seems to work just fine. Let me know if you would like it from 2.6.12.2 or 2.6.11.4-21.7 (SuSE 9.3) kernel. Linux X31 2.6.13-rc3-APM #13 Fri Jul 15 23:55:12 EDT 2005 i686 i686 i386 GNU/Linux -0009efff : System RAM 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000c : Video ROM 000d-000d0fff : Adapter ROM 000d1000-000d1fff : Adapter ROM 000d2000-000d3fff : reserved 000e-000e : Extension ROM 000f-000f : System ROM 0010-2ff5 : System RAM 0010-00361cfc : Kernel code 00361cfd-004083e7 : Kernel data 2ff6-2ff76fff : ACPI Tables 2ff77000-2ff78fff : ACPI Non-volatile Storage 2ff8-2fff : reserved 3000-33ff : :00:1f.1 b000-bfff : :02:00.0 b000-bfff : yenta_socket b100-b1000fff : :02:00.1 b100-b1000fff : yenta_socket c000-c3ff : :00:1d.7 c000-c3ff : ehci_hcd c800-c8ff : :00:1f.5 c800-c8ff : Intel 82801DB-ICH4 cc00-cdff : :00:1f.5 cc00-cdff : Intel 82801DB-ICH4 c010-c01f : PCI Bus #01 c010-c010 : :01:00.0 c010-c010 : radeonfb c012-c013 : :01:00.0 c020-cfff : PCI Bus #02 c020-c020 : :02:01.0 c021-c021 : :02:02.0 c021-c021 : ath c022-c023 : :02:01.0 c024-c02407ff : :02:00.2 c024-c02407ff : ohci1394 c120-c1200fff : pcmcia_socket1 c200-c3ff : PCI CardBus #03 c400-c5ff : PCI CardBus #07 d000-dfff : :00:00.0 e000-e7ff : PCI Bus #01 e000-e7ff : :01:00.0 e000-e7ff : radeonfb e800-efff : PCI Bus #02 e800-e9ff : PCI CardBus #03 ea00-ebff : PCI CardBus #07 ec00-ec00 : :02:01.0 ff80- : reserved == Linux X31 2.6.13-rc3-APM #14 Sat Jul 16 10:19:10 EDT 2005 i686 i686 i386 GNU/Linux -0009efff : System RAM 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000c : Video ROM 000d-000d0fff : Adapter ROM 000d1000-000d1fff : Adapter ROM 000d2000-000d3fff : reserved 000e-000e : Extension ROM 000f-000f : System ROM 0010-2ff5 : System RAM 0010-00359af0 : Kernel code 00359af1-003fe3e7 : Kernel data 2ff6-2ff76fff : ACPI Tables 2ff77000-2ff78fff : ACPI Non-volatile Storage 2ff8-2fff : reserved 3000-33ff : :00:1f.1 b000-bfff : :02:00.0 b000-bfff : yenta_socket b100-b1000fff : :02:00.1 b100-b1000fff : yenta_socket c000-c3ff : :00:1d.7 c000-c3ff : ehci_hcd c800-c8ff : :00:1f.5 c800-c8ff : Intel 82801DB-ICH4 cc00-cdff : :00:1f.5 cc00-cdff : Intel 82801DB-ICH4 c010-c01f : PCI Bus #01 c010-c010 : :01:00.0 c010-c010 : radeonfb c012-c013 : :01:00.0 c020-cfff : PCI Bus #02 c020-c020 : :02:01.0 c021-c021 : :02:02.0 c021-c021 : ath c022-c023 : :02:01.0 c024-c02407ff : :02:00.2 c024-c02407ff : ohci1394 c120-c1200fff : pcmcia_socket1 c200-c3ff : PCI CardBus #03 c400-c5ff : PCI CardBus #07 d000-dfff : :00:00.0 e000-e7ff : PCI Bus #01 e000-e7ff : :01:00.0 e000-e7ff : radeonfb e800-efff : PCI Bus #02 e800-e9ff : PCI CardBus #03 ea00-ebff : PCI CardBus #07 ec00-ec00 : :02:01.0 ff80- : reserved -- 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kern
Re: [2.6.13-rc3][PCMCIA] - iounmap: bad address f1d62000
BM31T1100 or Temic TFDS6000/TFDS6500
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
usbcore: registered new driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
PCI: Found IRQ 11 for device :00:1f.6
PCI: Sharing IRQ 11 with :00:1f.3
PCI: Sharing IRQ 11 with :00:1f.5
PCI: Sharing IRQ 11 with :02:00.1
PCI: Setting latency timer of device :00:1f.6 to 64
subfs 0.9
/dev/vmmon[4638]: Module vmmon: registered with major=10 minor=165
/dev/vmmon[4638]: Module vmmon: initialized
hde: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hde: drive_cmd: error=0x04 { DriveStatusError }
ide: failed opcode was: 0xa1
/dev/vmnet: open called by PID 4718 (vmnet-bridge)
/dev/vmnet: hub 0 does not exist, allocating memory.
/dev/vmnet: port on hub 0 successfully opened
bridge-eth0: peer interface eth0 not found, will wait for it to come up
bridge-eth0: attached
/dev/vmnet: open called by PID 4918 (vmnet-netifup)
/dev/vmnet: hub 1 does not exist, allocating memory.
/dev/vmnet: port on hub 1 successfully opened
/dev/vmnet: open called by PID 4920 (vmnet-netifup)
/dev/vmnet: hub 8 does not exist, allocating memory.
/dev/vmnet: port on hub 8 successfully opened
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 855PM Chipset.
agpgart: AGP aperture is 256M @ 0xd000
/dev/vmnet: open called by PID 4896 (vmnet-natd)
/dev/vmnet: port on hub 8 successfully opened
[drm] Initialized drm 1.0.0 20040925
PCI: Found IRQ 11 for device :01:00.0
PCI: Sharing IRQ 11 with :00:1d.0
PCI: Sharing IRQ 11 with :02:00.0
PCI: Sharing IRQ 11 with :02:01.0
[drm] Initialized radeon 1.16.0 20050311 on minor 0:
agpgart: Found an AGP 2.0 compliant device at :00:00.0.
agpgart: Putting AGP V2 device at :00:00.0 into 4x mode
agpgart: Putting AGP V2 device at :01:00.0 into 4x mode
/dev/vmnet: open called by PID 4985 (vmnet-dhcpd)
/dev/vmnet: port on hub 8 successfully opened
/dev/vmnet: open called by PID 4984 (vmnet-dhcpd)
/dev/vmnet: port on hub 1 successfully opened
vmnet1: no IPv6 routers present
vmnet8: no IPv6 routers present
IBM machine detected. Enabling interrupts during APM calls.
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
ath0: no IPv6 routers present
ReiserFS: loop3: found reiserfs format "3.6" with standard journal
ReiserFS: loop3: using ordered data mode
ReiserFS: loop3: journal params: device loop3, size 8192, journal first block
18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: loop3: checking transaction log (loop3)
ReiserFS: loop3: Using r5 hash to sort names
agpgart: Found an AGP 2.0 compliant device at :00:00.0.
agpgart: Putting AGP V2 device at :00:00.0 into 4x mode
agpgart: Putting AGP V2 device at :01:00.0 into 4x mode
agpgart: Found an AGP 2.0 compliant device at :00:00.0.
agpgart: Putting AGP V2 device at :00:00.0 into 4x mode
agpgart: Putting AGP V2 device at :01:00.0 into 4x mode
--
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
[EMAIL PROTECTED] http://www.networkingunlimited.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.13-rc3][PCMCIA] - iounmap: bad address f1d62000
/vmmon[4638]: Module vmmon: registered with major=10 minor=165
/dev/vmmon[4638]: Module vmmon: initialized
hde: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hde: drive_cmd: error=0x04 { DriveStatusError }
ide: failed opcode was: 0xa1
/dev/vmnet: open called by PID 4718 (vmnet-bridge)
/dev/vmnet: hub 0 does not exist, allocating memory.
/dev/vmnet: port on hub 0 successfully opened
bridge-eth0: peer interface eth0 not found, will wait for it to come up
bridge-eth0: attached
/dev/vmnet: open called by PID 4918 (vmnet-netifup)
/dev/vmnet: hub 1 does not exist, allocating memory.
/dev/vmnet: port on hub 1 successfully opened
/dev/vmnet: open called by PID 4920 (vmnet-netifup)
/dev/vmnet: hub 8 does not exist, allocating memory.
/dev/vmnet: port on hub 8 successfully opened
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 855PM Chipset.
agpgart: AGP aperture is 256M @ 0xd000
/dev/vmnet: open called by PID 4896 (vmnet-natd)
/dev/vmnet: port on hub 8 successfully opened
[drm] Initialized drm 1.0.0 20040925
PCI: Found IRQ 11 for device :01:00.0
PCI: Sharing IRQ 11 with :00:1d.0
PCI: Sharing IRQ 11 with :02:00.0
PCI: Sharing IRQ 11 with :02:01.0
[drm] Initialized radeon 1.16.0 20050311 on minor 0:
agpgart: Found an AGP 2.0 compliant device at :00:00.0.
agpgart: Putting AGP V2 device at :00:00.0 into 4x mode
agpgart: Putting AGP V2 device at :01:00.0 into 4x mode
/dev/vmnet: open called by PID 4985 (vmnet-dhcpd)
/dev/vmnet: port on hub 8 successfully opened
/dev/vmnet: open called by PID 4984 (vmnet-dhcpd)
/dev/vmnet: port on hub 1 successfully opened
vmnet1: no IPv6 routers present
vmnet8: no IPv6 routers present
IBM machine detected. Enabling interrupts during APM calls.
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
ath0: no IPv6 routers present
ReiserFS: loop3: found reiserfs format 3.6 with standard journal
ReiserFS: loop3: using ordered data mode
ReiserFS: loop3: journal params: device loop3, size 8192, journal first block
18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: loop3: checking transaction log (loop3)
ReiserFS: loop3: Using r5 hash to sort names
agpgart: Found an AGP 2.0 compliant device at :00:00.0.
agpgart: Putting AGP V2 device at :00:00.0 into 4x mode
agpgart: Putting AGP V2 device at :01:00.0 into 4x mode
agpgart: Found an AGP 2.0 compliant device at :00:00.0.
agpgart: Putting AGP V2 device at :00:00.0 into 4x mode
agpgart: Putting AGP V2 device at :01:00.0 into 4x mode
--
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
[EMAIL PROTECTED] http://www.networkingunlimited.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.13-rc3][PCMCIA] - iounmap: bad address f1d62000
On Sat, Jul 16, 2005 at 05:12:58PM +0200, Dominik Brodowski wrote: Could you check whether this patch helps, please? Index: 2.6.13-rc3-git2/drivers/pcmcia/cistpl.c === --- 2.6.13-rc3-git2.orig/drivers/pcmcia/cistpl.c +++ 2.6.13-rc3-git2/drivers/pcmcia/cistpl.c @@ -88,31 +88,38 @@ EXPORT_SYMBOL(release_cis_mem); static void __iomem * This patch appears to have cured it! Good job. Just in case it is of use to use, I've also responded to your first request below. Hi, Could you send me the output of /proc/iomem on both a working kernel and on 2.6.13-rc3-APM, please? Thanks, Dominik First is as fails, second is same kernel with your patch applied, where it seems to work just fine. Let me know if you would like it from 2.6.12.2 or 2.6.11.4-21.7 (SuSE 9.3) kernel. Linux X31 2.6.13-rc3-APM #13 Fri Jul 15 23:55:12 EDT 2005 i686 i686 i386 GNU/Linux -0009efff : System RAM 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000c : Video ROM 000d-000d0fff : Adapter ROM 000d1000-000d1fff : Adapter ROM 000d2000-000d3fff : reserved 000e-000e : Extension ROM 000f-000f : System ROM 0010-2ff5 : System RAM 0010-00361cfc : Kernel code 00361cfd-004083e7 : Kernel data 2ff6-2ff76fff : ACPI Tables 2ff77000-2ff78fff : ACPI Non-volatile Storage 2ff8-2fff : reserved 3000-33ff : :00:1f.1 b000-bfff : :02:00.0 b000-bfff : yenta_socket b100-b1000fff : :02:00.1 b100-b1000fff : yenta_socket c000-c3ff : :00:1d.7 c000-c3ff : ehci_hcd c800-c8ff : :00:1f.5 c800-c8ff : Intel 82801DB-ICH4 cc00-cdff : :00:1f.5 cc00-cdff : Intel 82801DB-ICH4 c010-c01f : PCI Bus #01 c010-c010 : :01:00.0 c010-c010 : radeonfb c012-c013 : :01:00.0 c020-cfff : PCI Bus #02 c020-c020 : :02:01.0 c021-c021 : :02:02.0 c021-c021 : ath c022-c023 : :02:01.0 c024-c02407ff : :02:00.2 c024-c02407ff : ohci1394 c120-c1200fff : pcmcia_socket1 c200-c3ff : PCI CardBus #03 c400-c5ff : PCI CardBus #07 d000-dfff : :00:00.0 e000-e7ff : PCI Bus #01 e000-e7ff : :01:00.0 e000-e7ff : radeonfb e800-efff : PCI Bus #02 e800-e9ff : PCI CardBus #03 ea00-ebff : PCI CardBus #07 ec00-ec00 : :02:01.0 ff80- : reserved == Linux X31 2.6.13-rc3-APM #14 Sat Jul 16 10:19:10 EDT 2005 i686 i686 i386 GNU/Linux -0009efff : System RAM 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000c : Video ROM 000d-000d0fff : Adapter ROM 000d1000-000d1fff : Adapter ROM 000d2000-000d3fff : reserved 000e-000e : Extension ROM 000f-000f : System ROM 0010-2ff5 : System RAM 0010-00359af0 : Kernel code 00359af1-003fe3e7 : Kernel data 2ff6-2ff76fff : ACPI Tables 2ff77000-2ff78fff : ACPI Non-volatile Storage 2ff8-2fff : reserved 3000-33ff : :00:1f.1 b000-bfff : :02:00.0 b000-bfff : yenta_socket b100-b1000fff : :02:00.1 b100-b1000fff : yenta_socket c000-c3ff : :00:1d.7 c000-c3ff : ehci_hcd c800-c8ff : :00:1f.5 c800-c8ff : Intel 82801DB-ICH4 cc00-cdff : :00:1f.5 cc00-cdff : Intel 82801DB-ICH4 c010-c01f : PCI Bus #01 c010-c010 : :01:00.0 c010-c010 : radeonfb c012-c013 : :01:00.0 c020-cfff : PCI Bus #02 c020-c020 : :02:01.0 c021-c021 : :02:02.0 c021-c021 : ath c022-c023 : :02:01.0 c024-c02407ff : :02:00.2 c024-c02407ff : ohci1394 c120-c1200fff : pcmcia_socket1 c200-c3ff : PCI CardBus #03 c400-c5ff : PCI CardBus #07 d000-dfff : :00:00.0 e000-e7ff : PCI Bus #01 e000-e7ff : :01:00.0 e000-e7ff : radeonfb e800-efff : PCI Bus #02 e800-e9ff : PCI CardBus #03 ea00-ebff : PCI CardBus #07 ec00-ec00 : :02:01.0 ff80- : reserved -- 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IDE_CS problems with Compact Flash
Seeing strange results when using compact flash in a ThinkPad X31. Seems to work OK, but when the card is inserted or the system is booted with the card already inserted, I get a few hundred lines of complaint in the syslog. Prior to 2.6.12-rc2-mm2, I also had problems shutting down. Result would be that in order to read off the card, I would need to shut down the system, remove the card, reboot, and then insert the card again. During reboot, I'd get a message from PCMCIA about cleaning up old devices. Note that the failure mode was the Compact Flash card would mount, and I could read the root directory, but I could not read a file in the root directory. The process doing the read would lock up in "D" state and never (waited hours) return. Any ideas about what is going on here? In particular is this a known problem, a bad configuration on my part, or just plain bad luck? Vince Apr 8 12:33:27 localhost kernel: Kernel logging (proc) stopped. Apr 8 12:33:27 localhost kernel: Kernel log daemon terminating. Apr 8 12:33:28 localhost exiting on signal 15 Apr 8 12:35:29 localhost syslogd 1.4.1: restart (remote reception). Apr 8 12:35:29 localhost cardmgr[3434]: executing: './ide start hde 2>&1' Apr 8 12:35:29 localhost cardmgr[3434]: + dosfsck 2.10, 22 Sep 2003, FAT32, LFN Apr 8 12:35:29 localhost cardmgr[3434]: + /dev/hde1: 35 files, 32099/63422 clusters Apr 8 12:35:30 localhost cardmgr[3434]: + /dev/hde1 on /media/flash type vfat (rw) Apr 8 12:35:34 localhost kernel: klogd 1.4.1, log source = /proc/kmsg started. Apr 8 12:35:34 localhost kernel: 4> [] do_mem_probe+0x11b/0x200 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [] validate_mem+0x44/0x60 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [] md5_transform+0x90/0x6f0 Apr 8 12:35:34 localhost kernel: [] md5_transform+0x90/0x6f0 Apr 8 12:35:34 localhost kernel: [] pcmcia_nonstatic_validate_mem+0x78/0x80 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [] pcmcia_validate_mem+0x1a/0x30 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [] pcmcia_card_add+0x2d/0xe0 [pcmcia] Apr 8 12:35:34 localhost kernel: [] new_inode+0x24/0xb0 Apr 8 12:35:34 localhost kernel: [] schedule+0x31d/0x630 Apr 8 12:35:34 localhost kernel: [] kobject_get+0x17/0x20 Apr 8 12:35:34 localhost kernel: [] class_device_get+0x18/0x20 Apr 8 12:35:34 localhost kernel: [] ds_event+0xf2/0x100 [pcmcia] Apr 8 12:35:34 localhost kernel: [] send_event+0x88/0x100 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [] pccard_register_pcmcia+0x88/0x90 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [] pcmcia_bus_add_socket+0xa0/0xf0 [pcmcia] Apr 8 12:35:34 localhost kernel: [] class_interface_register+0x8d/0xc0 Apr 8 12:35:34 localhost kernel: [] init_pcmcia_bus+0x1b/0x30 [pcmcia] Apr 8 12:35:34 localhost kernel: [] sys_init_module+0x132/0x1f0 Apr 8 12:35:34 localhost kernel: [] sysenter_past_esp+0x5c/0x7d Apr 8 12:35:34 localhost kernel: iounmap: bad address f0f5a000 Apr 8 12:35:34 localhost kernel: [] readable+0x67/0xa0 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [] cis_readable+0xa5/0x100 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [] do_mem_probe+0x11b/0x200 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [] validate_mem+0x44/0x60 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [] md5_transform+0x90/0x6f0 Apr 8 12:35:34 localhost kernel: [] md5_transform+0x90/0x6f0 Apr 8 12:35:34 localhost kernel: [] pcmcia_nonstatic_validate_mem+0x78/0x80 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [] pcmcia_validate_mem+0x1a/0x30 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [] pcmcia_card_add+0x2d/0xe0 [pcmcia] Apr 8 12:35:34 localhost kernel: [] new_inode+0x24/0xb0 Apr 8 12:35:34 localhost kernel: [] schedule+0x31d/0x630 Apr 8 12:35:34 localhost kernel: [] kobject_get+0x17/0x20 Apr 8 12:35:34 localhost kernel: [] class_device_get+0x18/0x20 Apr 8 12:35:34 localhost kernel: [] ds_event+0xf2/0x100 [pcmcia] Apr 8 12:35:34 localhost kernel: [] send_event+0x88/0x100 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [] pccard_register_pcmcia+0x88/0x90 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [] pcmcia_bus_add_socket+0xa0/0xf0 [pcmcia] Apr 8 12:35:34 localhost kernel: [] class_interface_register+0x8d/0xc0 Apr 8 12:35:34 localhost kernel: [] init_pcmcia_bus+0x1b/0x30 [pcmcia] Apr 8 12:35:34 localhost kernel: [] sys_init_module+0x132/0x1f0 Apr 8 12:35:34 localhost kernel: [] sysenter_past_esp+0x5c/0x7d Apr 8 12:35:34 localhost kernel: 0xc9a0-0xca1fiounmap: bad address f0f5a000 Apr 8 12:35:34 localhost kernel: [] set_cis_map+0xe8/0x100 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [] remove_vm_area+0x5d/0xa0 Apr 8 12:35:34 localhost kernel: [] pcmcia_read_cis_mem+0x130/0x1b0 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [] set_cis_map+0xe8/0x100 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [] read_cis_cache+0x19a/0x1a0 [pcmcia_core] Apr 8 12:35:34
IDE_CS problems with Compact Flash
Seeing strange results when using compact flash in a ThinkPad X31. Seems to work OK, but when the card is inserted or the system is booted with the card already inserted, I get a few hundred lines of complaint in the syslog. Prior to 2.6.12-rc2-mm2, I also had problems shutting down. Result would be that in order to read off the card, I would need to shut down the system, remove the card, reboot, and then insert the card again. During reboot, I'd get a message from PCMCIA about cleaning up old devices. Note that the failure mode was the Compact Flash card would mount, and I could read the root directory, but I could not read a file in the root directory. The process doing the read would lock up in D state and never (waited hours) return. Any ideas about what is going on here? In particular is this a known problem, a bad configuration on my part, or just plain bad luck? Vince Apr 8 12:33:27 localhost kernel: Kernel logging (proc) stopped. Apr 8 12:33:27 localhost kernel: Kernel log daemon terminating. Apr 8 12:33:28 localhost exiting on signal 15 Apr 8 12:35:29 localhost syslogd 1.4.1: restart (remote reception). Apr 8 12:35:29 localhost cardmgr[3434]: executing: './ide start hde 21' Apr 8 12:35:29 localhost cardmgr[3434]: + dosfsck 2.10, 22 Sep 2003, FAT32, LFN Apr 8 12:35:29 localhost cardmgr[3434]: + /dev/hde1: 35 files, 32099/63422 clusters Apr 8 12:35:30 localhost cardmgr[3434]: + /dev/hde1 on /media/flash type vfat (rw) Apr 8 12:35:34 localhost kernel: klogd 1.4.1, log source = /proc/kmsg started. Apr 8 12:35:34 localhost kernel: 4 [f0b2a73b] do_mem_probe+0x11b/0x200 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [f0b2a864] validate_mem+0x44/0x60 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [c020] md5_transform+0x90/0x6f0 Apr 8 12:35:34 localhost kernel: [c020] md5_transform+0x90/0x6f0 Apr 8 12:35:34 localhost kernel: [f0b2a8f8] pcmcia_nonstatic_validate_mem+0x78/0x80 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [f0d6b04a] pcmcia_validate_mem+0x1a/0x30 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [f0f6f96d] pcmcia_card_add+0x2d/0xe0 [pcmcia] Apr 8 12:35:34 localhost kernel: [c0178524] new_inode+0x24/0xb0 Apr 8 12:35:34 localhost kernel: [c039711d] schedule+0x31d/0x630 Apr 8 12:35:34 localhost kernel: [c02040d7] kobject_get+0x17/0x20 Apr 8 12:35:34 localhost kernel: [c026c9a8] class_device_get+0x18/0x20 Apr 8 12:35:34 localhost kernel: [f0f703c2] ds_event+0xf2/0x100 [pcmcia] Apr 8 12:35:34 localhost kernel: [f0d67878] send_event+0x88/0x100 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [f0d682c8] pccard_register_pcmcia+0x88/0x90 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [f0f709c0] pcmcia_bus_add_socket+0xa0/0xf0 [pcmcia] Apr 8 12:35:34 localhost kernel: [c026ca4d] class_interface_register+0x8d/0xc0 Apr 8 12:35:34 localhost kernel: [f0f5801b] init_pcmcia_bus+0x1b/0x30 [pcmcia] Apr 8 12:35:34 localhost kernel: [c0134652] sys_init_module+0x132/0x1f0 Apr 8 12:35:34 localhost kernel: [c0102c73] sysenter_past_esp+0x5c/0x7d Apr 8 12:35:34 localhost kernel: iounmap: bad address f0f5a000 Apr 8 12:35:34 localhost kernel: [f0b2a307] readable+0x67/0xa0 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [f0b2a4e5] cis_readable+0xa5/0x100 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [f0b2a73b] do_mem_probe+0x11b/0x200 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [f0b2a864] validate_mem+0x44/0x60 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [c020] md5_transform+0x90/0x6f0 Apr 8 12:35:34 localhost kernel: [c020] md5_transform+0x90/0x6f0 Apr 8 12:35:34 localhost kernel: [f0b2a8f8] pcmcia_nonstatic_validate_mem+0x78/0x80 [rsrc_nonstatic] Apr 8 12:35:34 localhost kernel: [f0d6b04a] pcmcia_validate_mem+0x1a/0x30 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [f0f6f96d] pcmcia_card_add+0x2d/0xe0 [pcmcia] Apr 8 12:35:34 localhost kernel: [c0178524] new_inode+0x24/0xb0 Apr 8 12:35:34 localhost kernel: [c039711d] schedule+0x31d/0x630 Apr 8 12:35:34 localhost kernel: [c02040d7] kobject_get+0x17/0x20 Apr 8 12:35:34 localhost kernel: [c026c9a8] class_device_get+0x18/0x20 Apr 8 12:35:34 localhost kernel: [f0f703c2] ds_event+0xf2/0x100 [pcmcia] Apr 8 12:35:34 localhost kernel: [f0d67878] send_event+0x88/0x100 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [f0d682c8] pccard_register_pcmcia+0x88/0x90 [pcmcia_core] Apr 8 12:35:34 localhost kernel: [f0f709c0] pcmcia_bus_add_socket+0xa0/0xf0 [pcmcia] Apr 8 12:35:34 localhost kernel: [c026ca4d] class_interface_register+0x8d/0xc0 Apr 8 12:35:34 localhost kernel: [f0f5801b] init_pcmcia_bus+0x1b/0x30 [pcmcia] Apr 8 12:35:34 localhost kernel: [c0134652] sys_init_module+0x132/0x1f0 Apr 8 12:35:34 localhost kernel: [c0102c73] sysenter_past_esp+0x5c/0x7d Apr 8 12:35:34 localhost kernel: 0xc9a0-0xca1fiounmap: bad address f0f5a000 Apr 8 12:35:34 localhost kernel: [f0d688e8] set_cis_map+0xe8/0x100 [pcmcia_core] Apr
APM vs. USB BlueTooth in 2.6.11
SuSE 9.2 on IBM ThinkPad X31 (2884-JUU), 2.6.11 kernel. Great having a notebook where everything just works. Bluetooth (hci_usb) works fine, but after suspend/resume cycle using APM the BlueTooth interface dies (LED goes out) and I can't get it back by unloading/reloading modules. However, if I compile the bluetooth and hci_usb into the kernel rather than as modules, suspend resume seems to work fine. (APM is configured to stop/start Bluetooth service around a suspend/resume cycle). Any idea why? FWIW: I still use APM because ACPI suspend to RAM consumes 1250 mW/hour while APM suspend to RAM is only 360 mW/hour, not worth the fancy features, but that is another topic. Windows XP ACPI suspend to RAM consumes 525 mW/hour. Any suggestions on how to reduce power consumption when suspended using ACPI? -- 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
APM vs. USB BlueTooth in 2.6.11
SuSE 9.2 on IBM ThinkPad X31 (2884-JUU), 2.6.11 kernel. Great having a notebook where everything just works. Bluetooth (hci_usb) works fine, but after suspend/resume cycle using APM the BlueTooth interface dies (LED goes out) and I can't get it back by unloading/reloading modules. However, if I compile the bluetooth and hci_usb into the kernel rather than as modules, suspend resume seems to work fine. (APM is configured to stop/start Bluetooth service around a suspend/resume cycle). Any idea why? FWIW: I still use APM because ACPI suspend to RAM consumes 1250 mW/hour while APM suspend to RAM is only 360 mW/hour, not worth the fancy features, but that is another topic. Windows XP ACPI suspend to RAM consumes 525 mW/hour. Any suggestions on how to reduce power consumption when suspended using ACPI? -- 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc5
In article <[EMAIL PROTECTED]> you write: > > >Hey, I hoped -rc4 was the last one, but we had some laptop resource >conflicts, various ppc TLB flush issues, some possible stack overflows in >networking and a number of other details warranting a quick -rc5 before >the final 2.6.11. > >This time it's really supposed to be a quickie, so people who can, please >check it out, and we'll make the real 2.6.11 asap. Hmmm. Also seems to have introduced a laptop conflict. Bluetooth no longer survives a suspend/resume cycle. IBM ThinkPad X31 (2884-JUU) using hci_usb. Bluetooth service is shut down before suspend and restarted upon return. Works fine in rc4. # lspci :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03) :00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03) :00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) :00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) :00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) :00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller (rev 01) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) :00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01) :00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 01) :00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) :00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) :00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY :02:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa) :02:00.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa) :02:00.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 02) :02:01.0 Ethernet controller: Intel Corp. 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) :02:02.0 Ethernet controller: Atheros Communications, Inc. AR5211 802.11ab NIC (rev 01) # Unlike earlier problems (circa 2.6.10), the bluetooth LED comes back on, but the drivers complain of no device available and socket in use. Vince -- 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc5
In article [EMAIL PROTECTED] you write: Hey, I hoped -rc4 was the last one, but we had some laptop resource conflicts, various ppc TLB flush issues, some possible stack overflows in networking and a number of other details warranting a quick -rc5 before the final 2.6.11. This time it's really supposed to be a quickie, so people who can, please check it out, and we'll make the real 2.6.11 asap. Hmmm. Also seems to have introduced a laptop conflict. Bluetooth no longer survives a suspend/resume cycle. IBM ThinkPad X31 (2884-JUU) using hci_usb. Bluetooth service is shut down before suspend and restarted upon return. Works fine in rc4. # lspci :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03) :00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03) :00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) :00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) :00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) :00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller (rev 01) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) :00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01) :00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 01) :00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) :00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) :00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY :02:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa) :02:00.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa) :02:00.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 02) :02:01.0 Ethernet controller: Intel Corp. 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) :02:02.0 Ethernet controller: Atheros Communications, Inc. AR5211 802.11ab NIC (rev 01) # Unlike earlier problems (circa 2.6.10), the bluetooth LED comes back on, but the drivers complain of no device available and socket in use. Vince -- 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon FB troubles with recent kernels
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:[EMAIL PROTECTED] > > > > Note the "video=radeonfb:[EMAIL PROTECTED]" 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon FB troubles with recent kernels
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:[EMAIL PROTECTED] Note the video=radeonfb:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon FB troubles with recent kernels
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 = 0x4f0077hsync_strt_wid = 0x11028a > > v_total_disp = 0x18f01b5 vsync_strt_wid = 0x60191 > > pixclock = 15384 > > freq = 6500 > > Console: switching to colour frame buffer device 53x18 > > radeonfb (: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:[EMAIL PROTECTED] Note the "video=radeonfb:[EMAIL PROTECTED]" 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon FB troubles with recent kernels
>> 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:[EMAIL PROTECTED]") 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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] ide_setup: idebus=66 Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (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 0180 CPU: After vendor identify, caps: a7e9f9bf 0180 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 1024K CPU: After all inits, caps: a7e9f9bf 0040 0180 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 :00:1f.1 PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Embedded Control
Re: Radeon FB troubles with recent kernels
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:[EMAIL PROTECTED]) 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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] ide_setup: idebus=66 Local APIC disabled by BIOS -- you can enable it with lapic mapped APIC to d000 (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 0180 CPU: After vendor identify, caps: a7e9f9bf 0180 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 1024K CPU: After all inits, caps: a7e9f9bf 0040 0180 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 :00:1f.1 PCI: Transparent bridge - :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
Re: Radeon FB troubles with recent kernels
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 = 0x4f0077hsync_strt_wid = 0x11028a v_total_disp = 0x18f01b5 vsync_strt_wid = 0x60191 pixclock = 15384 freq = 6500 Console: switching to colour frame buffer device 53x18 radeonfb (: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:[EMAIL PROTECTED] Note the video=radeonfb:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon FB troubles with recent kernels
In article <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]") 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon FB troubles with recent kernels
In article [EMAIL PROTECTED] 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:[EMAIL PROTECTED]) 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 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
