Debian Bug report logs - #572168
radeontool 1.6: Nothing happens for "light off"

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: submit@bugs.debian.org

Subject: radeontool 1.6: Nothing happens for "light off"

Date: Mon, 1 Mar 2010 21:24:29 -0600

Package: radeontool
Version: 1.6.0-1
Severity: normal

Nothing happens for "radeontool light off" with radeontool 1.6.0
for my Dell Inspiron 4000.  Downgrading to 1.5-5 works.

Running 1.6.0 under strace yields a normal startup, then

[...]
stat64("/sys/bus/pci/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
brk(0)                                  = 0x8eae000
brk(0x8ecf000)                          = 0x8ecf000
open("/proc/mtrr", O_WRONLY)            = 3
open("/sys/bus/pci/devices", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
fcntl64(4, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
getdents(4, /* 16 entries */, 32768)    = 368
getdents(4, /* 0 entries */, 32768)     = 0
close(4)                                = 0
open("/sys/bus/pci/devices/0000:00:00.0/config", O_RDONLY) = 4
[...]
open("/sys/bus/pci/devices/0000:01:00.0/resource0", O_RDWR) = 4
mmap2(NULL, 67108864, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xb373a000
close(4)                                = 0
exit_group(0)                           = ?

Running under ltrace yields

__libc_start_main(0x804dd40, 3, 0xbfa5f764, 0x804e090, 0x804e080 <unfinished ...>
pci_system_init(0xb7784168, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0
pci_slot_match_iterator_create(0xbfa5f65c, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0x90201c0
pci_device_next(0x90201c0, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0x9018030
pci_device_probe(0x9018030, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0
pci_device_next(0x90201c0, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0x901813c
pci_device_probe(0x901813c, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0
pci_device_next(0x90201c0, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0x9018248
pci_device_probe(0x9018248, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0
pci_device_next(0x90201c0, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0x9018460
pci_device_probe(0x9018460, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0
pci_device_next(0x90201c0, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0x9018890
pci_device_probe(0x9018890, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0
pci_device_next(0x90201c0, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0x901899c
pci_device_probe(0x901899c, 1, 0xbfa5f6d0, 0xbfa5f6c4, 1) = 0
pci_device_map_region(0x901899c, 0, 1, 0xbfa5f6c4, 1) = 0
pci_device_map_region(0x901899c, 0, 1, 0xbfa5f6c4, 1) = 0
pci_iterator_destroy(0x90201c0, 0, 1, 0xbfa5f6c4, 1) = 3
+++ exited (status 0) +++

Running with --debug yields

$ radeontool --debug light off
Found card 1002:4c46 (30000)
Radeon found. Base control address is b35a1000; base framebuffer address is b35a1000.
reading RADEON_LVDS_GEN_CNTL (2d0) is 00ff0000
writing RADEON_LVDS_GEN_CNTL (2d0) -> 00ff0000
$ echo $?
0

My card is indeed a 1002:4c46, which is to say an ATI Technologies Inc
Rage Mobility M3 AGP 2x (r128).

Ideas?
Jonathan

Message #10 received at 572168@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 572168@bugs.debian.org

Subject: Re: radeontool 1.6: Nothing happens for "light off"

Date: Wed, 3 Mar 2010 09:57:56 -0600

Hi again,

Corresponding results for 1.5-5:

Jonathan Nieder wrote:

> $ radeontool --debug light off
> Found card 1002:4c46 (30000)
> Radeon found. Base control address is b35a1000; base framebuffer address is b35a1000.
> reading RADEON_LVDS_GEN_CNTL (2d0) is 00ff0000
> writing RADEON_LVDS_GEN_CNTL (2d0) -> 00ff0000

$ radeontool --debug light off
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility
M3 AGP 2x (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Dell Device 00b0
        Flags: bus master, stepping, 66MHz, medium devsel, latency 32, IRQ 11
        Memory at f8000000 (32-bit, prefetchable) [size=64M]
        I/O ports at ec00 [size=256]
        Memory at fdffc000 (32-bit, non-prefetchable) [size=16K]
Radeon found. Base control address is fdffc000.
reading RADEON_LVDS_GEN_CNTL (2d0) is 083dffa1
writing RADEON_LVDS_GEN_CNTL (2d0) -> 083dffa0

> Running 1.6.0 under strace yields a normal startup, then
  [... does an open-coded lspci then an anonymous mmap ...]

1.5-5 does normal startup, then:

pipe([3, 4])                            = 0
clone(Process 30867 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb76b3728) = 30867
[pid 30866] close(4)                    = 0
[pid 30866] fcntl64(3, F_GETFL)         = 0 (flags O_RDONLY)
[pid 30866] brk(0)                      = 0x9824000
[pid 30866] brk(0x9845000)              = 0x9845000
[pid 30866] fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
[pid 30866] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7807000
[pid 30866] _llseek(3, 0, 0xbfc07278, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 30867] close(3 <unfinished ...>
[pid 30866] read(3,  <unfinished ...>
[pid 30867] <... close resumed> )       = 0
[pid 30867] dup2(4, 1)                  = 1
[pid 30867] brk(0)                      = 0x9824000
[pid 30867] brk(0x9845000)              = 0x9845000
[pid 30867] execve("/sbin/lspci", ["lspci", "-v"], [/* 16 vars */]) = -1 ENOENT (No such file or directory)
[...]
[pid 30867] execve("/usr/bin/lspci", ["lspci", "-v"], [/* 16 vars */]) = 0
[...]
[pid 30867] exit_group(0)               = ?
Process 30867 detached
<... read resumed> "00:00.0 Host bridge: Intel Corpo"..., 4096) = 4096
--- SIGCHLD (Child exited) @ 0 (0) ---
open("/dev/mem", O_RDWR)                = 4
mmap2(0x9825000, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 4, 0xfdffc) = 0x9825000
exit_group(0)                           = ?

That is, it actually forks an "lspci -v" to do work for it.  Then it
mmaps the address 0x9825000 and presumably writes to it.

> Running under ltrace yields
 [device probing culminating in pci_device_map_region(0x901899c, ...)]

1.5-5 does normal startup, talks to lspci, then:

open("/dev/mem", 2, 027764227350)                  = 4
sysconf(30, 2, 0xbfd12ee8, 0xb7742e44, 0xb7739d90) = 4096
malloc(12287)                                      = 0x0941a170
mmap(0x941b000, 8192, 3, 17, 4)                    = 0x941b000
+++ exited (status 0) +++

> My card is indeed a 1002:4c46, which is to say an ATI Technologies Inc
> Rage Mobility M3 AGP 2x (r128).

Hope that helps,
Jonathan

Message #15 received at 572168@bugs.debian.org (full text, mbox, reply):

From: Tormod Volden <debian.tormod@gmail.com>

To: Jonathan Nieder <jrnieder@gmail.com>, 572168@bugs.debian.org

Subject: Re: Bug#572168: radeontool 1.6: Nothing happens for "light off"

Date: Fri, 5 Mar 2010 12:45:44 +0100

Thanks for your bug report. I am not surprised there are issues with
R128 cards since they are not Radeon cards. But since it worked with
1.5-5 we should be able to figure it out. As you saw, the scanning for
the card memory ranges has changed from using lspci to internal
parsing, and the detection logic is different. Can you please give the
output from: lspci -vvnn -d 1002:

Tormod

Message #20 received at 572168@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Tormod Volden <debian.tormod@gmail.com>

Cc: 572168@bugs.debian.org

Subject: Re: radeontool 1.6: Nothing happens for "light off"

Date: Fri, 5 Mar 2010 06:01:34 -0600

[Message part 1 (text/plain, inline)]

Tormod Volden wrote:

> Thanks for your bug report. I am not surprised there are issues with
> R128 cards since they are not Radeon cards. But since it worked with
> 1.5-5 we should be able to figure it out. As you saw, the scanning for
> the card memory ranges has changed from using lspci to internal
> parsing, and the detection logic is different.

Yes.  I wanted to bisect, but I couldn’t find a git repo incorporating
the old version.  I hope to make one collecting the tarballs I could
find this weekend.

> Can you please give the
> output from: lspci -vvnn -d 1002:

Attached.

Thanks,
Jonathan

[lspci-output.txt (text/plain, attachment)]

Message #25 received at 572168@bugs.debian.org (full text, mbox, reply):

From: Tormod Volden <debian.tormod@gmail.com>

To: Jonathan Nieder <jrnieder@gmail.com>, 572168@bugs.debian.org

Subject: Re: Bug#572168: radeontool 1.6: Nothing happens for "light off"

Date: Fri, 5 Mar 2010 17:00:27 +0100

> Yes.  I wanted to bisect, but I couldn’t find a git repo incorporating
> the old version.  I hope to make one collecting the tarballs I could
> find this weekend.

You can find the old versions in the upstream branch of
http://git.debian.org/?p=collab-maint/radeontool.git;a=summary but the
upstream history has some gaps. I tried once to merge all history I
could find into one repo (see
http://git.debian.org/?p=users/tormod-guest/radeontool.git.1;a=summary)
so it can be used for bisecting, but we do not use it for packaging.

>> Can you please give the
>> output from: lspci -vvnn -d 1002:
>
> Attached.

The old version just grepped the lspci output for "Memory" and "K" to
find the control region. The new one looks for a region of size
64K, which fails for your class of cards (yours is 16K). The region
index will then be uninitialized and if it happens to be 0, your frame
buffer will be accessed instead...

Message #30 received at 572168@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Tormod Volden <debian.tormod@gmail.com>

Cc: 572168@bugs.debian.org

Subject: Re: radeontool 1.6: Nothing happens for "light off"

Date: Fri, 5 Mar 2010 10:50:02 -0600

On Fri, Mar 05, 2010 at 05:00:27PM +0100, Tormod Volden wrote:

> You can find the old versions in the upstream branch of
> http://git.debian.org/?p=collab-maint/radeontool.git;a=summary but the
> upstream history has some gaps. I tried once to merge all history I
> could find into one repo (see
> http://git.debian.org/?p=users/tormod-guest/radeontool.git.1;a=summary)
> so it can be used for bisecting, but we do not use it for packaging.

Awesome, I’ll work from there and write an appropriate grafts file
to publish in README.source or something.

> The old version just grepped the lspci output for "Memory" and "K" to
> find the control region. The new one looks for a region of size
> 64K, which fails for your class of cards (yours is 16K). The region
> index will then be uninitialized and if it happens to be 0, your frame
> buffer will be accessed instead...

Thanks for the analysis.  Patches coming in a moment.

Message #35 received at 572168@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Tormod Volden <debian.tormod@gmail.com>, control@bugs.debian.org

Cc: 572168@bugs.debian.org

Subject: Re: radeontool 1.6: Nothing happens for "light off"

Date: Fri, 5 Mar 2010 11:08:14 -0600

[Message part 1 (text/plain, inline)]

tags 572168 + upstream patch
thanks

Jonathan Nieder wrote:
> On Fri, Mar 05, 2010 at 05:00:27PM +0100, Tormod Volden wrote:

>> The old version just grepped the lspci output for "Memory" and "K" to
>> find the control region. The new one looks for a region of size
>> 64K, which fails for your class of cards (yours is 16K). The region
>> index will then be uninitialized and if it happens to be 0, your frame
>> buffer will be accessed instead...
>
> Thanks for the analysis.  Patches coming in a moment.

Here are some patches against upstream master that seem to fix this.
I am attaching them rather than sending them as separate messages
since the Debian BTS deals better with that.

Thoughts?
Jonathan Nieder (3):
  radeontool: completely skip early cards with --skip
  radeontool: error out for missing control or fb region
  radeontool: handle r128 again

 radeontool.c |   21 ++++++++++++++-------
 1 files changed, 14 insertions(+), 7 deletions(-)

[01-skip-early-cards.txt (text/plain, attachment)]

[02-report-missing-regions.txt (text/plain, attachment)]

[03-r128-support.txt (text/plain, attachment)]

Message #42 received at 572168@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 572168@bugs.debian.org

Subject: [PATCH 4/3] radeontool: error out if too many control or fb regions

Date: Fri, 5 Mar 2010 13:38:19 -0600

[Message part 1 (text/plain, inline)]

Jonathan Nieder wrote:
>> On Fri, Mar 05, 2010 at 05:00:27PM +0100, Tormod Volden wrote:

>>> The old version just grepped the lspci output for "Memory" and "K" to
>>> find the control region. The new one looks for a region of size
>>> 64K, which fails for your class of cards (yours is 16K).
[...]
> Here are some patches against upstream master that seem to fix this.
> I am attaching them rather than sending them as separate messages
> since the Debian BTS deals better with that.

Here’s a fourth, to make sure I am not breaking anything for cards that
previously worked.

Side note: The wildly ill-advised ‘radeontool regmatch '*'’ command
locks up the system (it didn’t in version 1.5).

Of course, ‘radeontool regs’, ‘radeontool light on’, and
‘radeontool light off’ work without problems, which is more important.

[04-report-duplicate-regions (text/plain, attachment)]

Message #47 received at 572168@bugs.debian.org (full text, mbox, reply):

From: Tormod Volden <debian.tormod@gmail.com>

To: Jonathan Nieder <jrnieder@gmail.com>, 572168@bugs.debian.org

Subject: Re: Bug#572168: radeontool 1.6: Nothing happens for "light off"

Date: Sat, 6 Mar 2010 10:20:29 +0100

On Fri, Mar 5, 2010 at 6:08 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Here are some patches against upstream master that seem to fix this.
> I am attaching them rather than sending them as separate messages
> since the Debian BTS deals better with that.

Cool, thanks for your work!

>
> Thoughts?
> Jonathan Nieder (3):
>  radeontool: completely skip early cards with --skip

Good catch. ACK. Don't feel shy to rewrite the whole function if you
feel like it :)

>  radeontool: error out for missing control or fb region

ACK. But I would drop the comment about the old use of lspci. And
maybe use plain "int" for ctrl_region and fb_region to avoid any
casting.

>  radeontool: handle r128 again

I don't know how many cards and configurations are possible, maybe an
interval like 16-64 could be used? I also thought about adding a check
for the is_prefetchable (and !is_IO) flag which AFAICS seems to be on
for the control regions. However the flag was not set when I tried to
read it out with libpciaccess even though lspci indicates it. I don't
know if this is a bug in libpciaccess or if I tried to use it the
wrong way.

Tormod

Message #52 received at 572168@bugs.debian.org (full text, mbox, reply):

From: Tormod Volden <debian.tormod@gmail.com>

To: Jonathan Nieder <jrnieder@gmail.com>, 572168@bugs.debian.org

Subject: Re: Bug#572168: [PATCH 4/3] radeontool: error out if too many control or fb regions

Date: Sat, 6 Mar 2010 10:25:00 +0100

On Fri, Mar 5, 2010 at 8:38 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Here’s a fourth, to make sure I am not breaking anything for cards that
> previously worked.

Very good. I think upstream will know if there is a better way for
picking the right region.

> Side note: The wildly ill-advised ‘radeontool regmatch '*'’ command
> locks up the system (it didn’t in version 1.5).

Can you find out which register read locks up? As a wild guess I would
think more registers have been added and some are not compatible with
r128.

Message #57 received at 572168@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Tormod Volden <debian.tormod@gmail.com>

Cc: 572168@bugs.debian.org

Subject: [PATCH 0/3] Avoid lockup on ‘radeontool regmatch '*'’ on r128

Date: Sun, 14 Mar 2010 15:09:25 -0500

[Message part 1 (text/plain, inline)]

Hi again,

Sorry for the silence.

Tormod Volden wrote:
> On Fri, Mar 5, 2010 at 8:38 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> Side note: The wildly ill-advised ‘radeontool regmatch '*'’ command
>> locks up the system (it didn’t in version 1.5).
>
> Can you find out which register read locks up? As a wild guess I would
> think more registers have been added and some are not compatible with
> r128.

Apparently version 1.5 didn’t have a ‘regmatch’ command.  I don’t know
what I was thinking.

Here are some some patches to answer your questions.

Jonathan Nieder (3):
  radeontool regmatch: print name before reading each register
  radeontool regmatch: sync() before reading a bunch of registers
  Avoid lockup on ‘radeontool regmatch '*'’ on r128

 radeontool.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

[01-regmatch-split-print (text/plain, attachment)]

[02-regmatch-sync (text/plain, attachment)]

[03-avoid-lockup (text/plain, attachment)]

Message #66 received at 572168-close@bugs.debian.org (full text, mbox, reply):

From: Luigi Gangitano <luigi@debian.org>

To: 572168-close@bugs.debian.org

Subject: Bug#572168: fixed in radeontool 1.6.1-1

Date: Wed, 30 Jun 2010 15:58:21 +0000

Source: radeontool
Source-Version: 1.6.1-1

We believe that the bug you reported is fixed in the latest version of
radeontool, which is due to be installed in the Debian FTP archive:

radeontool_1.6.1-1.debian.tar.gz
  to main/r/radeontool/radeontool_1.6.1-1.debian.tar.gz
radeontool_1.6.1-1.dsc
  to main/r/radeontool/radeontool_1.6.1-1.dsc
radeontool_1.6.1-1_i386.deb
  to main/r/radeontool/radeontool_1.6.1-1_i386.deb
radeontool_1.6.1.orig.tar.gz
  to main/r/radeontool/radeontool_1.6.1.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 572168@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Luigi Gangitano <luigi@debian.org> (supplier of updated radeontool package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 30 Jun 2010 16:01:37 +0100
Source: radeontool
Binary: radeontool
Architecture: source i386
Version: 1.6.1-1
Distribution: unstable
Urgency: low
Maintainer: Luigi Gangitano <luigi@debian.org>
Changed-By: Luigi Gangitano <luigi@debian.org>
Description: 
 radeontool - utility to control ATI Radeon backlight functions on laptops
Closes: 570839 572168
Changes: 
 radeontool (1.6.1-1) unstable; urgency=low
 .
   [ Jonathan Nieder ]
   * New upstream release.
      - includes r128 support (closes: #572168).
   * Drop all patches (applied upstream).
   * Generate upstream changelog from git log.  See README.source
     for details.
   * debian/copyright: Fill in more details.
   * debian/rules: Rewrite using dh.  Requires a build-time
     dependency on debhelper 7.0.50.
   * debian/rules: Run autotools at build time.  Requires build-time
     dependencies on autoconf, automake, and libtool and a build-time
     conflict with automake1.4.
   * debian/radeontool.sgml: Move manpage to section 8 (thanks to
     Helge Kreutzmann, closes: #570839).
   * debian/rules: Apply patches at unpack time instead of build
     time by using dpkg source format 3.0 (quilt).  Remove build-time
     dependency on quilt.
   * debian/watch: Use uscan format version 3.
   * Use the bzip2-compressed version of the original source.
 .
   [ Luigi Gangitano ]
   * debian/radeontool.lintian-override: Override Lintian error on GPL reference
   * debian/control: Bump to standard-versione 3.9.0 (no change needed)
Checksums-Sha1: 
 0dc65b603808583347b17beadca3fa6bd7fd3606 1297 radeontool_1.6.1-1.dsc
 15d648f46b7a2e8d0bc27b7e6cdc8bfa3ddd4cab 407119 radeontool_1.6.1.orig.tar.gz
 ca906a483b9d886e7193f9d312d5499484b2cca8 10487 radeontool_1.6.1-1.debian.tar.gz
 f020c4e48fd70397a0b426982783dc8753df665c 67002 radeontool_1.6.1-1_i386.deb
Checksums-Sha256: 
 cb32f88c7e320037b3355da9d5faaf9d26b4fa7f4e68523966ee9637a7375f73 1297 radeontool_1.6.1-1.dsc
 f19a69cf22f2c2e6b5164924be5cdd8b5e554232d1aeda28755f17a311bc11dd 407119 radeontool_1.6.1.orig.tar.gz
 6dd82177e7b3718b9e258c3815a5194c52cedc28cccfce54cfc8ff7440de5773 10487 radeontool_1.6.1-1.debian.tar.gz
 33c570b30c0b883c06999034a22b642a95a93d771a7f4293c35a37dac9617649 67002 radeontool_1.6.1-1_i386.deb
Files: 
 eb9f4937181b6c605c0722b1a1fb71e3 1297 utils optional radeontool_1.6.1-1.dsc
 b8eb1126489a6a2c2bc6cd2c2198b790 407119 utils optional radeontool_1.6.1.orig.tar.gz
 cd043f5e793eca6ffc082051354fdcfa 10487 utils optional radeontool_1.6.1-1.debian.tar.gz
 dd0133d4f896009c579a49687704a968 67002 utils optional radeontool_1.6.1-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAkwrUTUACgkQ8ZumGJJMDCZOOACeOR10h5851Y/gNLTme+6gGgPZ
KvwAnRGibSBJ4BiOVnZcPCgtNiyVY3lh
=PGeQ
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.