Bug#392946: radeontool: Nothing happens for light off

2010-02-08 Thread Tormod Volden
Thanks for your report. We have just released a new 1.6.0-1 version,
so it would be nice if you could test it and tell us if the issue has
been resolved or not.

The package has a new upstream maintainer and has received quite some
work since the last release. For the other code issues mentioned in
comments here, it would be fantastic if you could provide patches and
send them either upstream or to us for review. It would make sense to
open separate Debian bug reports for each of them to keep track of it,
since they are not necessarily related to this bug report. Thanks in
advance!



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#392946: radeontool: Nothing happens for light off

2007-11-03 Thread Eliot Gehrt Setzer
Hello;

 1. the author is somewhat confused over the usage of mmap, there's
no need to malloc memory beforehand and then overmap it. in fact,
it's a very bad thing to do.

I noticed another clear mistake in this package a long time ago and
recompiled in order to fix my own version. I hoped that someone else
would fix it before I upgraded again, but it has not happened, so I
finally get around to reporting it...

The use of volatile in the code does not make very much sense;
most noticeably, the declaration:

 /* Not the address but what it points to is volatile. */
 unsigned char * volatile radeon_cntl_mem;

appears near the top of radeontool.c. The comment that explicitly
contradicts what the code says, since unsigned char * volatile
declares a volatile pointer to non-volatile unsigned char, not a
non-volatile pointer to volatile unsigned char (this is consistent
with how const works).

If you don't trust me about this, ask cdecl:
$ cdecl
Type `help' or `?' for help
cdecl explain unsigned char * volatile o;
declare o as volatile pointer to unsigned char
cdecl explain volatile unsigned char * o;
declare o as pointer to volatile unsigned char

To really fix this, a lot of changes might be necessary in radeontool.c
to make the types agree after changing this, but the solution that I
used when I compiled my own version before is simple: remove -O2 from
CFLAGS in the Makefile. volatile has no effect in unoptimized programs,
so doing this completely eliminates the issue.

I do not have any evidence that doing this fixes any particular
problem with radeontool, however; paraphrasing Donald E. Knuth,
I have only proved it [in]correct, not tried it.

Eliot Setzer



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#392946: radeontool: Nothing happens for light off

2006-11-26 Thread pageexec
Hello,

i see two potential issues with radeontool:

1. the author is somewhat confused over the usage of mmap, there's
   no need to malloc memory beforehand and then overmap it. in fact,
   it's a very bad thing to do.

2. grsec has checks on what can be mmap'ed from /dev/mem, have you
   enabled that option by any chance?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#392946: radeontool: Nothing happens for light off

2006-10-14 Thread Helge Kreutzmann
Package: radeontool
Version: 1.5-4
Severity: normal

Nothing happens for radeontool light off on my iBook G4. Running 
this command under strace yields:

execve(/usr/sbin/radeontool, [radeontool, light, off], [/* 13 vars */]) 
= 0
uname({sys=Linux, node=thirtyto, ...}) = 0
brk(0)  = 0x10012830
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x3002a000
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=74957, ...}) = 0
mmap(NULL, 74957, PROT_READ, MAP_PRIVATE, 3, 0) = 0x3002b000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/tls/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\314..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1393780, ...}) = 0
mmap(0xfe8a000, 1464452, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0xfe8a000
mprotect(0xffd3000, 116868, PROT_NONE)  = 0
mmap(0xffe3000, 45056, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149000) = 0xffe3000
mmap(0xffee000, 6276, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffee000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x3003e000
mprotect(0xffe3000, 28672, PROT_READ)   = 0
mprotect(0x30028000, 4096, PROT_READ)   = 0
munmap(0x3002b000, 74957)   = 0
pipe([3, 4])= 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x3003e288) = 17749
close(4)= 0
fcntl64(3, F_GETFL) = 0 (flags O_RDONLY)
brk(0)  = 0x10012830
brk(0x10033830) = 0x10033830
brk(0x10034000) = 0x10034000
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x30018000
_llseek(3, 0, 0x7ff33748, SEEK_CUR) = -1 ESPIPE (Illegal seek)
read(3, :00:0b.0 Host bridge: Apple ..., 4096) = 3417
open(/dev/mem, O_RDWR)= 4
mmap(0x10013000, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 4, 
0x9000) = 0x10013000
exit_group(0)   = ?
Process 17450 detached

But there is no process 17450 (I tried this several times, the process
number changes, but I've not seen this process). Btw. it is unclear
for me why a process should detach at all.

I issued this command as root! Nevertheless, could it be, that it is
not possible because I use grsecurity?

radeontool regs yields:

RADEON_DAC_CNTL=022100ff
RADEON_DAC_CNTL2=0200
RADEON_TV_DAC_CNTL=03025600
RADEON_DISP_OUTPUT_CNTL=
RADEON_CONFIG_MEMSIZE=0002
RADEON_AUX_SC_CNTL=
RADEON_CRTC_EXT_CNTL=4800
RADEON_CRTC_GEN_CNTL=00020003
RADEON_CRTC2_GEN_CNTL=80020002
RADEON_DEVICE_ID=635c
RADEON_DISP_MISC_CNTL=00023033
RADEON_GPIO_MONID=
RADEON_GPIO_MONIDB=0003
RADEON_GPIO_CRT2_DDC=0003
RADEON_GPIO_DVI_DDC=0303
RADEON_GPIO_VGA_DDC=0003
RADEON_LVDS_GEN_CNTL=a13c0d00

Please tell me which other information you need.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.7-grsec-cz01
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)

Versions of packages radeontool depends on:
ii  libc62.3.6.ds1-4 GNU C Library: Shared libraries

radeontool recommends no packages.

-- no debconf information
-- 
  Dr. Helge Kreutzmann  [EMAIL PROTECTED]
Dipl.-Phys.   http://www.helgefjell.de
64bit GNU powered gpg signed mail preferred
   Help keep free software libre: http://www.ffii.de/


signature.asc
Description: Digital signature