Bug#744623: (no subject)
On Tue, 2014-10-21 at 16:23 -0700, Geoff Levand wrote: X-Debbugs-CC: Benjamin Herrenschmidt b...@kernel.crashing.org Hi, On Tue, 2014-10-21 at 09:41 -0200, Breno Leitao wrote: Hi Geoff, Any status about this bug? This is caused by the altivec optimized routines done by Ben Herrenschmidt. I've tried to fix those up, but could never figure them out enough to do so. The quick fix is to add --enable-altivec=no to the powerpc build. The proper fix is to update the altivec routines. Ben, do you want to give that a try? libtwin/twin_primitive.c:292:38: error: incompatible types when initializing type '__vector unsigned short' using type '__vector unsigned char' const vector unsigned short v8 = vec_splat_u8(8); ^ libtwin/twin_primitive.c:309:9: error: incompatible types when assigning to type '__vector unsigned char' from type '__vector unsigned short' dst = vec_perm(dmule, dmulo, merge); ^ yeah it looks bad ... not sure what's up there, I'll need to context switch a pile of old crap back into my brain.. Where do you keep that libtwin ? Or is it the upstream fdo one ? Cheers, Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614221: iMac-G3 fails to boot with 2.6.37-1-powerpc (Bug#614221)
On Tue, 2011-03-08 at 13:00 +0100, Michel Dänzer wrote:
On Die, 2011-03-08 at 07:30 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2011-03-07 at 10:45 +0100, Michel Dänzer wrote:
I've been using radeon KMS on my PowerBook ever since I got it working
initially about 1.5 years ago and fixing issues as time permits.
The major outstanding issues I'm aware of are:
* The uninorth AGP driver doesn't allow AGP transfer rates beyond
1x to work reliably with KMS. Benjamin Herrenschmidt (CC'd) was
working on a fix for this, any progress Ben?
I have hacks.
FWIW, I've been using the hack at the end of this mail for AGP 1x.
.../...
Ok I'll try to give it another go here one of these days, I think I
still have some of my old hacks too.
Cheers,
Ben.
But I never got it working reliably. In fact, on the laptop I have
here, even with PCI GART, it's still unstable if I use KMS/DRI2.
I know your PowerBook was affected by the problem fixed by commit
b7d8cce5b558e0c0aa6898c9865356481598b46d ('drm/radeon/kms: MC vram map
needs to be = pci aperture size'), which went into 2.6.37. Still no
better with that?
* Come to think of it, the OFfb handover probably only works for
me thanks to a patch drm/radeon: Add early unregister of
firmware fb's by BenH. Ben/Dave, what's the status of that?
Dave ? Was this ever merged ?
Apparently it went into 2.6.37, I didn't notice because it went into
different places in the code compared to the patch I had from you.
* Various endianness issues in the Mesa drivers.
Right, and the later aren't getting any better :-( It's busted even
without KMS nowadays.
Unfortunately, I have about 0 time to spend on that at the moment.
I recommend that distros stick to radeonfb + UMS for the time being on
ppc32.
One problem being that the classic Mesa r300 driver is essentially
unmaintained, and evidently rotting
commit 9a86d7fa5bb0b4fe228becf9ed9831bac985702c
Author: Michel Dänzer daen...@vmware.com
Date: Thu Jan 6 18:34:28 2011 +0100
agp/uninorth: Fix lockups with radeon KMS and 1x.
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index f845a8f..a32c492 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -80,7 +80,7 @@ static void uninorth_tlbflush(struct agp_memory *mem)
ctrl | UNI_N_CFG_GART_INVAL);
pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL, ctrl);
- if (uninorth_rev = 0x30) {
+ if (!mem uninorth_rev = 0x30) {
pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
ctrl | UNI_N_CFG_GART_2xRESET);
pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614221: iMac-G3 fails to boot with 2.6.37-1-powerpc (Bug#614221)
On Mon, 2011-03-07 at 10:45 +0100, Michel Dänzer wrote: I've been using radeon KMS on my PowerBook ever since I got it working initially about 1.5 years ago and fixing issues as time permits. The major outstanding issues I'm aware of are: * The uninorth AGP driver doesn't allow AGP transfer rates beyond 1x to work reliably with KMS. Benjamin Herrenschmidt (CC'd) was working on a fix for this, any progress Ben? I have hacks. But I never got it working reliably. In fact, on the laptop I have here, even with PCI GART, it's still unstable if I use KMS/DRI2. * Come to think of it, the OFfb handover probably only works for me thanks to a patch drm/radeon: Add early unregister of firmware fb's by BenH. Ben/Dave, what's the status of that? Dave ? Was this ever merged ? * LVDS backlight control was only added for 2.6.38, and some concerns were raised about the prerequisite backlight infrastructure changes, so I'm not sure if it's staying in for 2.6.38 final. * No suspend to RAM support yet. Suspend to disk seems to work though without AGP, I have some hackish fixes for it to work with AGP as well that I need to clean up and submit. * Various endianness issues in the Mesa drivers. Right, and the later aren't getting any better :-( It's busted even without KMS nowadays. Unfortunately, I have about 0 time to spend on that at the moment. I recommend that distros stick to radeonfb + UMS for the time being on ppc32. Cheers, Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506964: [PATCH] suspend/resume for ATI Mobility Radeon RV350
On Thu, 2009-01-08 at 21:57 +0100, Wolfgang Kroener wrote:
Hi,
On Wed, Oct 01, 2008 at 08:10:10, Benjamin Herrenschmidt wrote:
Can you resend it with a proper Signed-off-by: line ? Thanks !
I think the mail (http://lkml.org/lkml/2008/10/1/134) got lost
somewhere, so I try again:
Fell through the cracks along with some of my own radeonfb patches :-)
Thanks for reminding.
Cheers,
Ben.
radeonfb suspend/resume for Acer Travelmate 29X
This patch adds suspend/resume for the Acer Travelmate 290D/292LMi with
the following graphic-chip:
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350
[Mobility Radeon 9600 M10] [1002:4e50] (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] TravelMate 290 [1025:005a]
Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 10
Memory at a800 (32-bit, prefetchable) [size=128M]
I/O ports at c100 [size=256]
Memory at e001 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at a000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
Kernel driver in use: radeonfb
Kernel modules: radeonfb
Signed-off-by: Wolfgang Kroener l...@azog.de
---
drivers/video/aty/radeon_pm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/video/aty/radeon_pm.c b/drivers/video/aty/radeon_pm.c
index 675abda..5e4b2da 100644
--- a/drivers/video/aty/radeon_pm.c
+++ b/drivers/video/aty/radeon_pm.c
@@ -89,6 +89,9 @@ static struct radeon_device_id radeon_workaround_list[] = {
BUGFIX(Acer Aspire 2010,
PCI_VENDOR_ID_AI, 0x0061,
radeon_pm_off, radeon_reinitialize_M10),
+ BUGFIX(Acer Travelmate 290D/292LMi,
+PCI_VENDOR_ID_AI, 0x005a,
+radeon_pm_off, radeon_reinitialize_M10),
{ .ident = NULL }
};
--
1.5.6.5
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#435226: log's incomplete
The log is incomplete... looks like the bcm43xx driver is so verbose, it kicked useful things out. Thus I can't see the output from the video driver which is the interesting bit... Also, is it nvidiafb or rivafb ? Cheers, Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433236: Subject: linux-image-2.6.21-2-powerpc: radeonfb broken with Apple Cinema Display, connected via DVI
On Mon, 2007-07-30 at 20:41 +0200, Stephane Louise wrote: Bonjour Ben, merci pour le suivit. Benjamin Herrenschmidt a écrit : Does this happen also without radeonfb and with X alone using the X radeon driver ? Yes, unless I misunderstand you. I tried several options at the yaboot prompt (nofb or video=of), and speaking of Xorg, I don't use the UseFBDev for X11 since it rarely works with LCD panels (same with the Apple 20 and the Samsung 206, most of the valid resolutions don't work with UseFBDev). Just to make sure I understand properly: with video=ofonly and X with the config below, you still get a black screen ? It looks like the monitor powers off right ? I saw that with issues with Apple doing non-kosher things with the DDC line but we had that fixed long ago... Ben. Here are my device and monitor sections of xorg.conf: Section Device Identifier ATI Technologies, Inc. RV280 [Radeon 9200] Driver radeon BusID PCI:0:16:0 Option UseFBDev false Option AGPMode 4 Option AGPFastWrite true Option ReverseDDCtrue Option PanelSize 1680x1050 Option AccelMethod XAA Option AccelDFS on Option EnablePageFliptrue Option ColorTiling on Option EnableDepthMoves true Option RenderAccel true Option DRI true Option XAANoOffscreenPixmaps true EndSection Section Monitor Identifier Apple Cinema Display 20 Option MonitorLayout TMDS,NONE Option DPMS HorizSync 28-68 VertRefresh 60 DisplaySize 434 270 Option DPMS ModeLine 1680x1050 119.06 1680 1728 1760 1840 1050 1053 1059 1080 +HSync -VSync Modeline 1280x800 67.26 1280 1312 1560 1592 800 817 824 841 Modeline 1024x640 51.90 1024 1056 1248 1280 640 653 660 673 Modeline 800x500 30.98 800 832 944 976 500 510 515 526 EndSection Tell me if I can do something else to help.
Bug#433236: Subject: linux-image-2.6.21-2-powerpc: radeonfb broken with Apple Cinema Display, connected via DVI
On Sat, 2007-07-21 at 23:19 +0200, Stephane Louise wrote: Hi, I can confirm this bug. I have also a Mac Mini G4/1.5GHz with a 20 Apple Cinema Display (DVI model), and the kernel starts fine but the monitor switches off in the early phase of the boot process. Otherwise, it is fine, and I can connect through ssh to the machine, or login blindly. Here are some parts of the dmesg log that could be relevant: Does this happen also without radeonfb and with X alone using the X radeon driver ? Ben. Kernel command line: root=/dev/hda3 ro mpic: Setting up MPIC MPIC 1version 1.2 at 8004, max 4 CPUs mpic: ISU size: 64, shift: 6, mask: 3f mpic: Initializing for 64 sources PID hash table entries: 2048 (order: 11, 8192 bytes) GMT Delta read from XPRAM: 0 minutes, DST: off time_init: decrementer frequency = 41.600571 MHz time_init: processor frequency = 1499.94 MHz Console: colour dummy device 80x25 serial8250_console_init: nothing to do on PowerMac Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) High memory: 0k Memory: 508288k/524288k available (3272k kernel code, 15512k reserved, 124k data, 189k bss, 188k init) Calibrating delay loop... 82.94 BogoMIPS (lpj=165888) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 device-tree: Duplicate name in /cpus/PowerPC,[EMAIL PROTECTED], renamed to l2-cache#1 NET: Registered protocol family 16 KeyWest i2c @0xf8001003 irq 42 /[EMAIL PROTECTED]/[EMAIL PROTECTED] channel 0 bus multibus channel 1 bus multibus KeyWest i2c @0x80018000 irq 26 /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] channel 0 bus multibus PMU i2c /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/pmu-i2c channel 1 bus multibus channel 2 bus multibus ... PCI: Enabling device :00:10.0 (0006 - 0007) radeonfb (:00:10.0): Invalid ROM signature 0 should be 0xaa55 radeonfb: Retrieved PLL infos from Open Firmware radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=190.00 Mhz, System=250.00 MHz radeonfb: PLL min 12000 max 35000 i2c_adapter i2c-2: unable to read EDID block. i2c_adapter i2c-2: unable to read EDID block. i2c_adapter i2c-2: unable to read EDID block. radeonfb: Monitor 1 type DFP found radeonfb: EDID probed radeonfb: Monitor 2 type DFP found radeonfb: EDID probed Console: switching to colour frame buffer device 210x65 radeonfb (:00:10.0): ATI Radeon Yb Generic RTC Driver v1.07 Macintosh non-volatile memory driver v1.1 serial8250_init: nothing to do on PowerMac pmac_zilog: 0.6 (Benjamin Herrenschmidt [EMAIL PROTECTED]) ttyS0 at MMIO 0x80013020 (irq = 22) is a Z85c30 ESCC - Serial port ttyS1 at MMIO 0x80013000 (irq = 23) is a Z85c30 ESCC - Serial port ... PowerMac i2c bus pmu 2 registered PowerMac i2c bus pmu 1 registered PowerMac i2c bus mac-io 0 registered PowerMac i2c bus uni-n 1 registered PowerMac i2c bus uni-n 0 registered ... [drm] Initialized drm 1.1.0 20060810 [drm] Initialized radeon 1.25.0 20060524 on minor 0 agpgart: Putting AGP V2 device at :00:0b.0 into 4x mode agpgart: Putting AGP V2 device at :00:10.0 into 4x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode [drm] writeback test succeeded in 1 usecs ~$ cat /proc/cpuinfo processor : 0 cpu : 7447A, altivec supported clock : 1499.94MHz revision: 0.5 (pvr 8003 0105) bogomips: 82.94 timebase: 41600571 platform: PowerMac machine : PowerMac10,2 motherboard : PowerMac10,2 MacRISC3 Power Macintosh detected as : 287 (Unknown Intrepid-based) pmac flags : L2 cache: 512K unified pmac-generation : NewWorld ~$ cat /proc/version Linux version 2.6.21-2-powerpc (Debian 2.6.21-6) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070629 (prerelease) (Debian 4.1.2-13)) #1 Tue Jul 10 19:09:48 CEST 2007 ~$ cat /proc/dri/0/name radeon :00:10.0 pci::00:10.0 And from /var/log/Xorg.0.log ... (II) RADEON(0): Page flipping enabled (II) RADEON(0): Will try to use DMA for Xv image transfers (II) RADEON(0): Generation 2 PCI interface, using max accessible memory (II) RADEON(0): Detected total video RAM=65536K, accessible=131072K (PCI BAR=131072K) (--) RADEON(0): Mapped VideoRAM: 65536 kByte (64 bit DDR SDRAM) (II) RADEON(0): Color tiling enabled by default (II) Loading sub module ddc (II) LoadModule: ddc(II) Module already built-in (II) Loading sub module i2c (II) LoadModule: i2c(II) Module already built-in (II) RADEON(0): I2C bus DDC initialized. (II) Attempted to read BIOS 64KB from /sys/bus/pci/devices/:00:10.0/rom: got 0KB (WW) RADEON(0): Video BIOS not detected in PCI space! (WW) RADEON(0): Attempting to read Video BIOS from legacy ISA space! (WW) RADEON(0): Unrecognized BIOS signature
Bug#434305: pbbuttonsd: pbbuttons scripts trigger hdparm -p, clears PIO mode
Package: pbbuttonsd Version: 0.7.9-2 Severity: normal The scripts shipped with pbbuttons will cause it to issue a hdparm -p /dev/device (device is typically hda or whatever ide device is there) I think this used to trigger an autotune of the interface, but current hdparm instead sends the kernel a command to set the drive to PIO 0 mode instead, which is bogus (it still autotunes if you uses -p 255). It's not clear whether that is an hdparm bug though. In any case, pbbuttons shouldn't tweak that setting, the kernel does a fine job on powermac with IDE settings and should be left alone. The consequences of the above at this point are to use suboptimal timings for the command phase of IDE operations and for the data phase of non DMA commands. However, depending on what kind of IDE patches from Bart will or will not get merged upstream, this will also cause the kernel to disable DMA on the interfaces, which is pretty bad. I would suggest to remove any such attempts at touching the IDE interface speed settings. ide-pmac get those fine by default in the kernel, there is no need to muck around. Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23-rc1 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Versions of packages pbbuttonsd depends on: ii hdparm7.6-1 tune hard disk parameters for high ii libasound21.0.14a-2 ALSA library ii libc6 2.6-2 GNU C Library: Shared libraries ii libgcc1 1:4.2.1-0 GCC support library ii libglib2.0-0 2.12.13-1 The GLib library of C routines ii libstdc++64.2.1-0The GNU Standard C++ Library v3 ii lsb-base 3.0-12 Linux Standard Base 3.0 init scrip ii makedev 2.3.1-79 creates device files in /dev ii udev 0.076-3/dev/ and hotplug management daemo Versions of packages pbbuttonsd recommends: pn laptop-mode-tools none (no description available) -- debconf information: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = en_AU:en_US:en_GB:en, LC_ALL = (unset), LANG = en_AU are supported and installed on your system. perl: warning: Falling back to the standard locale (C). locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407671: kernel 2.6.18: Confusion about Macintosh backlight configuration
On Mon, 2007-01-22 at 16:05 +0100, Matthias Grimm wrote: On Mon, 22 Jan 2007 14:33:35 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Which solution you prefer is up to you but I would be glad if at least solution #1 could be realised. For now, at least, what prevents you from having all enabled and have pbbuttonsd still call PMU_IOC_GRAB_BACKLIGHT ? Nothing. Pbbuttonsd does so by now but this wouldn't help if someone set CONFIG_PMAC_BACKLIGHT_LEGACY to off. I check this out with debian, hoping you will find a smart solution for this in the future. I think the debian people getting aware of this backwards compatibility problem now and there is hope they will fix it for etch. Yes, debian should keep CONFIG_PMAC_BACKLIGHT_LEGACY enabled. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407671: kernel 2.6.18: Confusion about Macintosh backlight configuration
This will allow modern systems to be compiled only with CONFIG_PMAC_BACKLIGHT and a user space daemon does the rest. I hope my point could be seen. I would really appreciate if the configuration could be cleaned up. Other solutions could be: 2. If the sysfs backlight driver is opened switch kernel backlight keys handling off by calling PMU_IOC_GRAB_BACKLIGHT for machines that support the sysfs backlight interface. 3. Remove the kernel backlight keys control code from the kernel. Which solution you prefer is up to you but I would be glad if at least solution #1 could be realised. For now, at least, what prevents you from having all enabled and have pbbuttonsd still call PMU_IOC_GRAB_BACKLIGHT ? In the long run, we might want something smarter indeed, not sure what the best solution is... I like having the kernel control work always when no daemon is there. Among others, because we have this never solved problem where occasionally, the internal flat panel doesn't sync properly and the only way to get it back is to turn the backlight all the way down and back up a few times until it kicks in. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397942: g5 imacs now silent?
On Thu, 2006-11-30 at 23:04 +0100, Étienne Bersac wrote: Hi, Beware not to confuse iMac G5 rev AB and rev C (among PowerMac G5). iMac G5 rev C (chip PowerMac 12,1) do not have yet their windfarm driver. Benh told that he began the work on this driver but has difficulties to get access to de device. Benh, can you confirm ? Yes, I did some initial work to dig as much info as I could from darwin, but it seems that apple, once again, changed everything and thus I'm not confident writing and releasing a driver without physical access to the HW to verify by myself that the fans are behaving properly. I haven't managed to get access to that machine yet. Ben.
Bug#389007: [Xorg-driver-ati] Bug#389007: Regression: Radeon 9200 powers off Apple Cinema Display connected via DVI
On Thu, 2006-10-26 at 19:25 +0100, Roger Leigh wrote: Benjamin Herrenschmidt [EMAIL PROTECTED] writes: I found a solution to the problem. Adding Option PanelSize 1680x1050 Option MonitorLayout TMDS,NONE made the display work correctly. IIRC this was needed with XOrg 6.9, but wasn't needed with 7.0 (because it was intelligent enough to autodetect correctly?). This seems to be a regression in 7.1. Both the PanelSize and MonitorLayout need to be exactly as above. If either is commented out, or I change MonitorLayout to just TMDS, the monitor powers off. Just in case it's affecting anything, I'm adding append=video=radeonfb:[EMAIL PROTECTED] in my yaboot.conf in order to get a fullscreen framebuffer. radeonfb shouldn't need that ... What if, instead, you use Option ReverseDDC true btw ? Same symptoms ? Yes, the display just powers off on startup (this is with PanelSize and MonitorLayout commented out). ANd with NoDDC ? Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389007: [Xorg-driver-ati] Bug#389007: Regression: Radeon 9200 powers off Apple Cinema Display connected via DVI
I found a solution to the problem. Adding Option PanelSize 1680x1050 Option MonitorLayout TMDS,NONE made the display work correctly. IIRC this was needed with XOrg 6.9, but wasn't needed with 7.0 (because it was intelligent enough to autodetect correctly?). This seems to be a regression in 7.1. Both the PanelSize and MonitorLayout need to be exactly as above. If either is commented out, or I change MonitorLayout to just TMDS, the monitor powers off. Just in case it's affecting anything, I'm adding append=video=radeonfb:[EMAIL PROTECTED] in my yaboot.conf in order to get a fullscreen framebuffer. radeonfb shouldn't need that ... What if, instead, you use Option ReverseDDC true btw ? Same symptoms ? Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389007: [Xorg-driver-ati] Bug#389007: Regression: Radeon 9200 powers off Apple Cinema Display connected via DVI
On Mon, 2006-09-25 at 10:02 +0200, Michel Dänzer wrote: Yes, although it might also make sense to try the current master and ati-1-0-branch heads. I tried this out. All revisions built OK, but all caused the monitor to power off. Installing the old xserver-xorg-core and xserver-xorg-video-ati gives a working setup. I also tried using git-bisect with git://anongit.freedesktop.org/git/xorg/xserver, but done of the revisions would compile due to various type errors, I guess due to the incompatible changes made since 7.0. Did you try the server-1_1-branch? Maybe we could help you get past the errors if you posted them. Is there anything else I can do? Some ideas: * Build 6.6.2 against xserver-xorg-dev 1.0 and see if that works. * Look for any differences in the log files. What monitor model is it precisely ? I fixed a problem at one point that was causing exactly that behaviour on my Apple Cinema HD display. The problem was that the driver was leaving the i2c lines used for DDC in the high state. I put them back down at the end of the DDC procedure and that fixed it. Now it's possible that this change got lost ... Ben.
Bug#389007: [Xorg-driver-ati] Bug#389007: Regression: Radeon 9200 powers off Apple Cinema Display connected via DVI
On Mon, 2006-09-25 at 11:25 +0100, Roger Leigh wrote: Benjamin Herrenschmidt [EMAIL PROTECTED] writes: What monitor model is it precisely ? It's a 2005 Aluminium 20 Cinema Display. Model No. A1081 according the bottom edge. It has built-in USB and FireWire hubs and touch-sensitive brightness and power buttons on the right-hand edge, if that helps. Sounds like the same as mine except mine is 23... did we change something there ? I fixed a problem at one point that was causing exactly that behaviour on my Apple Cinema HD display. The problem was that the driver was leaving the i2c lines used for DDC in the high state. I put them back down at the end of the DDC procedure and that fixed it. Now it's possible that this change got lost ... It was a problem for me IIRC around May/June 2005. Regards, Roger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388459: Fix for ATI lockups with M6, M7 and r7000
http://people.freedesktop.org/~airlied/radeon_rn50_memmap.diff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369167: DRI probably broken: where to reportbug
On Sun, 2006-06-11 at 20:31 +0200, Michel Dänzer wrote: On Sun, 2006-06-11 at 20:14 +0200, Wolfgang Pfeiffer wrote: On Sun, Jun 11, 2006 at 01:34:52PM +0200, Michel Dänzer wrote: Does the attached patch help with Option UseFBDev? Yes. :))) ... Thanks a lot, Michel ... :) Excellent, thanks for testing. Ben, do you think this will also work with integrated chipsets? I have no idea... Ben.
Bug#369167: DRI probably broken: where to reportbug
On Thu, 2006-06-08 at 11:48 +0200, Michel Dänzer wrote: On Wed, 2006-06-07 at 23:31 +0200, Wolfgang Pfeiffer wrote: On Wed, Jun 07, 2006 at 11:09:43AM +0200, Michel Dänzer wrote: On Mon, 2006-06-05 at 20:05 +0200, Wolfgang Pfeiffer wrote: [ 136.378439] [drm] Setting GART location based on old memory map This should only happen if the X driver thinks the radeon DRM is older than 1.23. Please provide the full X log file that corresponds to this. I don't have the log for this crash any more: But in the same message you were quoting me from you can see a similar message [/var/log/kern.log: Setting GART location based on old memory map] for just one crash later that happened on Jun 5 19:37. The corresponding Xorg.log should be the one in a message I sent a bit later, namely on Mon, 5 Jun 2006 22:35:36 +0200: http://lists.debian.org/debian-powerpc/2006/06/msg00038.html (please look for The complete log:) From the log in there: (II) RADEON(0): [dri] Found DRI library version 1.2.0 and kernel module version 1.25.0 Ben, any idea how this can result in the DRM using the old memory map, as seen above? Do you agree that the breakage might be related to this? I don't know about the breakage cause but yeah.. I would have expected this to be the new memory map, maybe it's a bug with UseFBDev ? Ben.
Bug#347786: xserver-xorg: GPM repeater broken since 6.9
On Tue, 2006-02-14 at 20:16 +0200, Martin-Éric Racine wrote: Ben: would you know why this only seems to affect PowerMac users? No, no idea, might indeed be an endian bug Ben.
Bug#347786: xserver-xorg: GPM repeater broken since 6.9
On Tue, 2006-02-14 at 20:16 +0200, Martin-Éric Racine wrote: ti, 2006-02-14 kello 23:14 +0700, Eugene Konev kirjoitti: 1. The correct way to use gpm with X server with /dev/input/mice in linux 2.6 is _not_ use gpm repeater, as kernel driver is perfectly capable to multiplex events itself. Wrong. Using GPM with X precisely implies using the repeater. 2. This bug seems to be specific to ppc (endianness?) architecture, as I cannot reproduce it on x86 with any of the configs provided in the bug log. That could be. I can suggest rebuilding xorg with *DEBUG* options #define'd in xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c and providing resulting debug logs (and logs from gpm with verbosity increased) to the bug log. Unfortunately, I do not have the disk space or CPU resources to do that. Perhaps the submitter does? Ben: would you know why this only seems to affect PowerMac users? I'll have to dig into the bug report to get more info, no time right now though but I'll let you know. Ben.
Bug#326149: /dev/event0 missing
On Fri, 2005-11-18 at 12:15 -0200, Otavio Salvador wrote: Marcus Better [EMAIL PROTECTED] writes: Hello, I am the maintainer of input-utils. A user reported a problem (bug #326149) on the powerpc architecture that I need some help investigating, since I don't have a ppc machine. Apparently on his system the event devices start at /dev/input/event1, and there is no /dev/input/event0. Can someone confirm if this is always the case on ppc? Yes, I have the same. Look [EMAIL PROTECTED]:~$ ls /dev/input/event* -l crw-rw 1 root root 13, 69 2005-11-18 10:12 /dev/input/event5 crw-rw 1 root root 13, 70 2005-11-18 10:12 /dev/input/event6 crw-rw 1 root root 13, 71 2005-11-18 10:12 /dev/input/event7 [EMAIL PROTECTED]:~$ uname -a Linux ibook 2.6.15-rc1-20051118-g2cdce0d1 #1 PREEMPT Fri Nov 18 10:02:09 BRST 2005 ppc GNU/Linux I have that here too, but it's weird, I think it might be yet another udev bug. [EMAIL PROTECTED]:~/kernels/linux-work$ ls -l /dev/input/ total 0 crw-rw 1 root root 13, 68 2005-11-15 17:36 event4 crw-rw 1 root root 13, 63 2005-11-15 17:35 mice That's all ! As you can see, a lot of stuff is missing there: [EMAIL PROTECTED]:~/kernels/linux-work$ ls -l /sys/class/input/ total 0 lrwxrwxrwx 1 root root 0 2005-11-19 10:44 event0 - ../../class/input/input0/event0 lrwxrwxrwx 1 root root 0 2005-11-19 10:44 event1 - ../../class/input/input1/event1 lrwxrwxrwx 1 root root 0 2005-11-19 10:44 event2 - ../../class/input/input2/event2 lrwxrwxrwx 1 root root 0 2005-11-19 10:44 event3 - ../../class/input/input3/event3 lrwxrwxrwx 1 root root 0 2005-11-19 10:44 event4 - ../../class/input/input4/event4 drwxr-xr-x 6 root root 0 2005-11-15 17:35 input0 drwxr-xr-x 5 root root 0 2005-11-15 17:35 input1 drwxr-xr-x 5 root root 0 2005-11-15 17:35 input2 drwxr-xr-x 6 root root 0 2005-11-15 17:35 input3 drwxr-xr-x 5 root root 0 2005-11-15 17:37 input4 drwxr-xr-x 2 root root 0 2005-11-15 17:35 mice lrwxrwxrwx 1 root root 0 2005-11-19 10:44 mouse0 - ../../class/input/input0/mouse0 lrwxrwxrwx 1 root root 0 2005-11-19 10:44 mouse1 - ../../class/input/input3/mouse1 So I think it's udev that is broken (version 0.074-2 from sid) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326149: /dev/event0 missing
On Fri, 2005-11-18 at 11:20 +0100, Marcus Better wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yves-Alexis Perez wrote: Events are dynamically created/deleted by udev, and they start at 0. But maybe this is a kernel bug, or udev bug.. No, I think it is perfectly OK. input-utils will have to be fixed to deal with it. Well, at least for me, the missing devices _are_ in sysfs ... Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326149: /dev/event0 missing
So I think it's udev that is broken (version 0.074-2 from sid) Could you report a bug to udev's maintainer? I just upgraded to 0.074-3 and the problem seems to be fixed [EMAIL PROTECTED]:~$ ls -l /dev/input/ total 0 crw-rw 1 root root 13, 64 2005-11-19 11:30 event0 crw-rw 1 root root 13, 65 2005-11-19 11:30 event1 crw-rw 1 root root 13, 66 2005-11-19 11:30 event2 crw-rw 1 root root 13, 67 2005-11-19 11:30 event3 crw-rw 1 root root 13, 68 2005-11-19 11:30 event4 crw-rw 1 root root 13, 63 2005-11-19 11:30 mice crw-rw 1 root root 13, 32 2005-11-19 11:30 mouse0 crw-rw 1 root root 13, 33 2005-11-19 11:30 mouse1 Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330118: libc6: Fix crashes with 64k pages
Package: libc6 Version: 2.3.5-6 Severity: normal ppc32 glibc has a problem when running with a ppc64 kernel with 64k pages support enabled. This is fixed in upstream glibc CVS already (64k pages support isn't yet available in the released kernels, but I'll release the patch soon and it would be useful to have glibc fixed in debian before the kernel is there). The ref. to the upstream fix is: Changes by: [EMAIL PROTECTED] 2005-09-20 07:46:15 Modified files: elf: dl-load.c Log message: 2005-09-20 Roland McGrath [EMAIL PROTECTED] [BZ #1346] * elf/dl-load.c (_dl_map_object_from_fd) [HAVE_Z_RELRO]: Do * relro magic on __stack_prot only if [SHARED]. Skip mprotect if __stack_prot lies outside the page-rounded-down relro region. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/elf/dl-load.c.diff?cvsroot=glibcr1=1.270r2=1.271 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-rc2-gack Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323894: wesnoth: Wesnoth 0.9.5 aborts at launch
Package: wesnoth Version: 0.9.5-1 Severity: normal Battle for Wesnoth v0.9.5 Started on Fri Aug 19 16:26:06 2005 started game: 3446302398 terminate called after throwing an instance of 'zipios::FCollException' what(): Unable to find zip structure: End-of-central-directory Aborted -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-rc6-gack Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages wesnoth depends on: ii libc6 2.3.5-3GNU C Library: Shared libraries an ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.1-4 GCC support library ii libsdl-image1 1.2.4-1image loading library for Simple D ii libsdl-mixer1 1.2.6-1.1 mixer library for Simple DirectMed ii libsdl-net1.2 1.2.5-4network library for Simple DirectM ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-5 Simple DirectMedia Layer ii libstdc++64.0.1-4The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-14X Window System protocol client li ii libzipios++0 0.1.5.9+cvs.2004.02.07-3.1 a small C++ library for reading zi ii ttf-dejavu1.11-1 Bitstream Vera fonts with addition ii wesnoth-data 0.9.5-1data files for Wesnoth ii xlibs 6.8.2.dfsg.1-5 X Window System client libraries m ii zlib1g1:1.2.3-3 compression library - runtime wesnoth recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307993: CE in gen_subprogram_die at dwarf2out.c:10913 building glibc 2.3.5 with nptl
Ok, the bug has been fixed. It was causing any architecture to die on NPTL build with -g1 with 3.4. The patch below should be applied on debian's 3.4 package asap so we can start using it for building experimental glibc :) http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00685.html Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307985: libc6: 2.3.5-1 ppc built lacks GLIBC_2.3.3 version in libpthread
The bug has been fixed in gcc (though it may not have hit 3.4 CVS yet). See debian #307993 for details. This bug was causing any arch to die when building glibc with -g1, it's a gcc 3.4 regression, and now that it's fixed, it should be possible to switch the 2.3.5 package to gcc 3.4 (well, at least as soon as the fix hits debian's gcc 3.4 package) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307993: CE in gen_subprogram_die at dwarf2out.c:10913 building glibc 2.3.5 with nptl
On Sat, 2005-05-07 at 09:05 +0200, Matthias Klose wrote: Ubuntu currently builds glibc-2.3.5 with gcc-3.4 CVS 20050209, that's older than the Debian gcc-3.4 CVS 20050314. Jeff, any hints? I'll update gcc-3.4 to the current CVS once -13 enters testing. I doubt current CVS fixes it (from the changelog) but I'm building anyway to confirm. An older snapshot I built on 20041116 already has the problem it seems. I submited a gcc bug report upstream to gcc bugzilla, #21457 in the meantime. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307985: libc6: 2.3.5-1 ppc built lacks GLIBC_2.3.3 version in libpthread
gcc-3.4 tst-fini1mod.c -c -std=gnu99 -O2 -O3 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -fstrict-aliasing -g -g1 -pipe -mnew-mnemonics -fpic-I../include -I. -I/home/benh/glibc-2.3.5/build-tree/powerpc-nptl/nptl -I.. -I../libio -I/home/benh/glibc-2.3.5/build-tree/powerpc-np tl -I../sysdeps/powerpc/powerpc32/elf -I../sysdeps/powerpc/elf -I../nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../nptl/sysdeps/unix/sysv/l inux/powerpc -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/powerpc -I../sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../sysdeps/unix/sysv/linux/powerpc -I../sysdeps/unix/sysv/linux -I.. /sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/powerpc -I../sysdep s/unix -I../sysdeps/posix -I../sysdeps/powerpc/powerpc32/fpu -I../sysdeps/powerpc/powerpc32 -I../sysdeps/wordsize-32 -I../sysdeps/powerpc/soft-f p -I../sysdeps/powerpc/fpu -I../sysdeps/powerpc -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generi c/elf -I../sysdeps/generic -nostdinc -isystem /usr/lib/gcc/powerpc-linux/3.4.4/include -isystem /home/benh/glibc-2.3.5/debian/include -D_LIBC_RE ENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DSHARED -DNOT_IN_libc=1 -DNOT_IN_libc -o /home/benh/glibc-2.3.5/build-tre e/powerpc-nptl/nptl/tst-fini1mod.os -MD -MP -MF /home/benh/glibc-2.3.5/build-tree/powerpc-nptl/nptl/tst-fini1mod.os.dt -MT /home/benh/glibc-2.3. 5/build-tree/powerpc-nptl/nptl/tst-fini1mod.os ../elf/tst-execstack-mod.c: In function `tryme': ../elf/tst-execstack-mod.c:24: internal compiler error: in gen_subprogram_die, at dwarf2out.c:10913 Looks like our gcc-3.4 isn't quite there yet ... Huh. I've never seen that one before; yeah, file a bug, I suppose. Ok, that happens to be a known old gcc-3.4 regression (#16676 in gcc bugzilla). It is caused by the use of -g1 and nested functions. debian nptl makefile adds -g1 for a reason I don't know. Turning that into -g2 appear to fix it for a couple of files, I'm now trying a full -g2 build. I'm trying to get gcc folks interested in fixing it, but it seem to be difficult to get them interested in anything non-4.0 :( Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307985: libc6: 2.3.5-1 ppc built lacks GLIBC_2.3.3 version in libpthread
On Sat, 2005-05-07 at 01:37 -0400, Daniel Jacobowitz wrote: /usr/bin/gcc still doesn't have PPC TLS support. Does glibc default to using 3.4 nowadays? Smart choice I guess. I think that's right but I haven't looked at the packaging in about a year now. gcc-3.4 tst-fini1mod.c -c -std=gnu99 -O2 -O3 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -fstrict-aliasing -g -g1 -pipe -mnew-mnemonics -fpic-I../include -I. -I/home/benh/glibc-2.3.5/build-tree/powerpc-nptl/nptl -I.. -I../libio -I/home/benh/glibc-2.3.5/build-tree/powerpc-np tl -I../sysdeps/powerpc/powerpc32/elf -I../sysdeps/powerpc/elf -I../nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../nptl/sysdeps/unix/sysv/l inux/powerpc -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/powerpc -I../sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../sysdeps/unix/sysv/linux/powerpc -I../sysdeps/unix/sysv/linux -I.. /sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/powerpc -I../sysdep s/unix -I../sysdeps/posix -I../sysdeps/powerpc/powerpc32/fpu -I../sysdeps/powerpc/powerpc32 -I../sysdeps/wordsize-32 -I../sysdeps/powerpc/soft-f p -I../sysdeps/powerpc/fpu -I../sysdeps/powerpc -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generi c/elf -I../sysdeps/generic -nostdinc -isystem /usr/lib/gcc/powerpc-linux/3.4.4/include -isystem /home/benh/glibc-2.3.5/debian/include -D_LIBC_RE ENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DSHARED -DNOT_IN_libc=1 -DNOT_IN_libc -o /home/benh/glibc-2.3.5/build-tre e/powerpc-nptl/nptl/tst-fini1mod.os -MD -MP -MF /home/benh/glibc-2.3.5/build-tree/powerpc-nptl/nptl/tst-fini1mod.os.dt -MT /home/benh/glibc-2.3. 5/build-tree/powerpc-nptl/nptl/tst-fini1mod.os ../elf/tst-execstack-mod.c: In function `tryme': ../elf/tst-execstack-mod.c:24: internal compiler error: in gen_subprogram_die, at dwarf2out.c:10913 Looks like our gcc-3.4 isn't quite there yet ... I suppose I should do a new bug report against gcc Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307985: libc6: 2.3.5-1 ppc built lacks GLIBC_2.3.3 version in libpthread
On Sat, 2005-05-07 at 02:39 -0400, Daniel Jacobowitz wrote: Looks like our gcc-3.4 isn't quite there yet ... Huh. I've never seen that one before; yeah, file a bug, I suppose. Just did, it's debian bug #307993 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307984: Acknowledgement (libc6: 2.3.5 ppc built without NPTL)
Bug 307985 is actually caused by this lack of NTPL. I've tried building it here but got a gcc ICE, see comments in that other bug. This one can probably be marked as dup. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307993: CE in gen_subprogram_die at dwarf2out.c:10913 building glibc 2.3.5 with nptl
On Sat, 2005-05-07 at 09:05 +0200, Matthias Klose wrote: Ubuntu currently builds glibc-2.3.5 with gcc-3.4 CVS 20050209, that's older than the Debian gcc-3.4 CVS 20050314. Jeff, any hints? I'll update gcc-3.4 to the current CVS once -13 enters testing. OK. It would be interesting if ubuntu also tried enabling nptl/tls for powerpc btw. There is really no good reason not to do it nowadays :) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307984: libc6: 2.3.5 ppc built without NPTL
Package: libc6 Version: 2.3.5-1 Severity: normal glibc should be built with TLS/NPTL for ppc nowadays, since we finally get a recent enough version (it was implemented upstream years ago and other major distros had it for some time now). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 2.6.12-rc3-gack Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307985: libc6: 2.3.5-1 ppc built lacks GLIBC_2.3.3 version in libpthread
Package: libc6 Version: 2.3.5-1 Severity: normal The 2.3.5-1 ppc build present in experimental has a problem with libpthread-0.10.so binary. For some reason I haven't been able to explain, it lacks the version GLIBC_2.3.3 symbol (it does have 2.3.2 and 2.3.4 and libc6 itself has them all). This prevents running some binaries built on other distros like fedora Here is some readelf output: Version definition section '.gnu.version_d' contains 11 entries: Addr: 0x3740 Offset: 0x003740 Link: 4 (.dynstr) 00: Rev: 1 Flags: BASE Index: 1 Cnt: 1 Name: libpthread.so.0 0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: GLIBC_2.0 0x0038: Rev: 1 Flags: none Index: 3 Cnt: 2 Name: GLIBC_2.1 0x0054: Parent 1: GLIBC_2.0 0x005c: Rev: 1 Flags: none Index: 4 Cnt: 2 Name: GLIBC_2.1.1 0x0078: Parent 1: GLIBC_2.1 0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: GLIBC_2.1.2 0x009c: Parent 1: GLIBC_2.1.1 0x00a4: Rev: 1 Flags: none Index: 6 Cnt: 2 Name: GLIBC_2.2 0x00c0: Parent 1: GLIBC_2.1.2 0x00c8: Rev: 1 Flags: none Index: 7 Cnt: 2 Name: GLIBC_2.2.3 0x00e4: Parent 1: GLIBC_2.2 0x00ec: Rev: 1 Flags: none Index: 8 Cnt: 2 Name: GLIBC_2.2.6 0x0108: Parent 1: GLIBC_2.2.3 0x0110: Rev: 1 Flags: none Index: 9 Cnt: 2 Name: GLIBC_2.3.2 0x012c: Parent 1: GLIBC_2.2.6 0x0134: Rev: 1 Flags: none Index: 10 Cnt: 2 Name: GLIBC_2.3.4 0x0150: Parent 1: GLIBC_2.3.2 0x0158: Rev: 1 Flags: none Index: 11 Cnt: 2 Name: GLIBC_PRIVATE 0x0174: Parent 1: GLIBC_2.3.4 -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 2.6.12-rc3-gack Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307985: libc6: 2.3.5-1 ppc built lacks GLIBC_2.3.3 version in libpthread
On Fri, 2005-05-06 at 23:09 -0400, Daniel Jacobowitz wrote: On Sat, May 07, 2005 at 12:42:02PM +1000, Benjamin Herrenschmidt wrote: Package: libc6 Version: 2.3.5-1 Severity: normal The 2.3.5-1 ppc build present in experimental has a problem with libpthread-0.10.so binary. For some reason I haven't been able to explain, it lacks the version GLIBC_2.3.3 symbol (it does have 2.3.2 and 2.3.4 and libc6 itself has them all). This prevents running some binaries built on other distros like fedora And what GLIBC_2.3.3 symbols does Fedora have? Hi Daniel ! I was trying to use their build of openoffice 2, and got that: [EMAIL PROTECTED]:~$ oowriter /usr/lib/openoffice.org1.9.100/program/javaldx: /lib/libpthread.so.0: version `GLIBC_2.3.3' not found (required by /usr/lib/openoffice.org1.9.100/program/libuno_sal.so.3) /usr/lib/openoffice.org1.9.100/program/soffice.bin: /lib/libpthread.so.0: version `GLIBC_2.3.3' not found (required by /usr/lib/openoffice.org1.9.100/program/libuno_sal.so.3) and I get that: [EMAIL PROTECTED]:~$ readelf -a /usr/lib/openoffice.org1.9.100/program/libuno_sal.so.3 | grep 2.3.3 339: 44 FUNCGLOBAL DEFAULT UND [EMAIL PROTECTED] (18) 667: 72 FUNCWEAK DEFAULT UND [EMAIL PROTECTED] (18) 682: 28 FUNCGLOBAL DEFAULT UND [EMAIL PROTECTED] (18) 150: 2 (UDK_3_0_0) 2 (UDK_3_0_0) 2 (UDK_3_0_0)12 (GLIBC_2.3.3) 298: a (GLIBC_2.0) 2 (UDK_3_0_0) 2 (UDK_3_0_0)12 (GLIBC_2.3.3) 2a8: 2 (UDK_3_0_0) a (GLIBC_2.0)12 (GLIBC_2.3.3) 2 (UDK_3_0_0) 0x00d0: Name: GLIBC_2.3.3 Flags: none Version: 18 The underscores makes me think that it's a problem with openoffice trying to use some glibc private symbols, but then, I'm not glibc expert so I can't be too sure... If it's indeed a problem with openoffice, let me know close this bug, I'll go bother the fedora folks to get it fixed in their build :) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307985: libc6: 2.3.5-1 ppc built lacks GLIBC_2.3.3 version in libpthread
These symbols are part of NPTL cancellation handling. They won't work unless you run with NPTL. I figured that out yes. NPTL isn't enabled for powerpc glibc, it should be with 2.3.5. I'm trying to make a build, but my lack of knowledge of the debian package build files don't make that simple :) What I did for now was to add a powerpc.mk that contains (quickly copied from i348 basically) GLIBC_PASSES += nptl libc_extra_config_options = $(extra_config_options) --with-tls --with-__thread Is that correct ? It's building for now, but that takes ages on this machine so it will be a while before I can test Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307985: libc6: 2.3.5-1 ppc built lacks GLIBC_2.3.3 version in libpthread
/usr/bin/gcc still doesn't have PPC TLS support. Does glibc default to using 3.4 nowadays? Smart choice I guess. I got bitten by that :) glibc package rule is hard coded to gcc-3.3 which doesn't do __thread. I just changed it to gcc-3.4 and restarted the build, news in about 1h... I think that's right but I haven't looked at the packaging in about a year now. Ok, thanks. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304493: powerpc-utils: nvsetvol Performa 6400/200, nothing happens
On Mon, 2005-04-25 at 12:17 +0200, Michael Schmitz wrote: offset 0 rc 16 buf.sig 90 buf.len 2 buf.name nvram offset 32 rc 16 buf.sig 95 buf.len 62 buf.name system offset 1024 rc 16 buf.sig 112 buf.len 193 buf.name common offset 4112 rc 16 buf.sig 160 buf.len 82 buf.name APL,MacOS75 PRAM found at offset: 4112 1010 How is the startup volume encoded in the oldworld nvram? Hrm.. I don't remember at the top of my head, have you tried using the ioctl to request the kernel to tell you where the pram here ? on old world, the startup volume can either be the OF boot device, which is a normal OF partition (nvsetenv works on oldworld afaik), or you can try to encode the MacOS boot volume but that's a very complicated story... Oops, the term 'startup volume' was ill chosen :-) What I meant is the volume setting of the startup boing sound. That one seems to be encoded somewhat past the APL,MacOS75 resource in nw. Yah, it's in the pram part. Normally, you should be able to use an ioctl to get that zone. But I did that code a long time ago, may not be that good anymore. Best is to look what Darwin does. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304493: powerpc-utils: nvsetvol Performa 6400/200, nothing happens
On Fri, 2005-04-22 at 18:41 +0200, Michael Schmitz wrote:
Hi,
Here is the output of lsprop /proc/device-tree
name device-tree
modelPower Macintosh
compatible AAPL,e407
MacRISC
/proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]:
name nvram
device_type nvram
reg 0006 0002
existing 2000
linux,phandleff8376c0
That's more or less what I have ... the nvram hangs off mac-io or ohare on
the oldworld macs. On newworld macs it appears as a node in the device
tree directly.
and the output of the modified nvsetvol :
--
mac:~# ./nvsetvol
offset 3839 rc 16 buf.sig 0 buf.len 237 buf.name boot /AAP
offset: 7631 1dcf
no PRAM found: Success
mac:~# ./nvsetvol 4
offset 3839 rc 16 buf.sig 0 buf.len 237 buf.name boot /AAP
offset: 7631 1dcf
no PRAM found: Success
--
BenH: the above debug output prints some of the fields of the nvram header
struct:
typedef struct {
unsigned char sig;
unsigned char cksum;
unsigned short len;
char name[12];
} header;
which, on oldworld, doesn't seem to work at all. Hence, the search for a
header holding the string APL,MacOS75 fails. On my Powerbook, the output
is:
offset 0 rc 16 buf.sig 90 buf.len 2 buf.name nvram
offset 32 rc 16 buf.sig 95 buf.len 62 buf.name system
offset 1024 rc 16 buf.sig 112 buf.len 193 buf.name common
offset 4112 rc 16 buf.sig 160 buf.len 82 buf.name APL,MacOS75
PRAM found at offset: 4112 1010
How is the startup volume encoded in the oldworld nvram?
Hrm.. I don't remember at the top of my head, have you tried using the
ioctl to request the kernel to tell you where the pram here ? on old
world, the startup volume can either be the OF boot device, which is a
normal OF partition (nvsetenv works on oldworld afaik), or you can try
to encode the MacOS boot volume but that's a very complicated story...
Ben.
Bug#263743: [Debian-ppc64-devel] Call For Help - Please support the ppc64 architecture
On Wed, 2005-03-16 at 20:27 +0100, Andreas Jochens wrote: Hello, This is a call for help from the 'ppc64' porters. On 05-Mar-14 16:14, Martin Michlmayr wrote: Also, as with the amd64 port, there is disagreement about the name. While ppc64 would be nicer and in line with the LSB, our current PowerPC port is called powerpc and therefore it would make more sense to call the 64 bit port powerpc64. There has been a decision of the Debian Technical Committee concerning the name of the amd64 port which basically says that the porting team should decide on the architecture name generally (see [1]). The ppc64 porters decided to use the name 'ppc64' as the package name a few month ago. .../... It's a fully 64 bits setup as it seems ? That is rather inefficient. Have we any proper way of doing multiarch setups ? The proper way to do ppc64 is to have both archs libs and 32 bits userland for most things, as ppc64 native code is slightly slower. I have repeated that over and over again but it seems I have been ignored so far... Also make sure the compiler is biarch as the kernel build will soon require this. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263743: [Debian-ppc64-devel] Re: Bug#263743: Call For Help - Please support the ppc64 architecture
Anyway, the biarch approach will also need a 'dpkg' which supports separate 64-bit ppc64 packages in the end. What are your concerns? Do you refuse to support a native 64-bit powerpc64/ppc64 port? Or do you want a different name for it? I think there is not real point in doing so, or mostly academic, but feel free to do it anyway. I'd rather see more efforts be put in the biarch port for now though. And as I wrote earlier, just beware that the compiler has to be biarch in both cases or you'll have a hard time building kernels. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263743: [Debian-ppc64-devel] Re: Bug#263743: Call For Help - Please support the ppc64 architecture
However, I still do not understand why you and/or the Project Leader want to override the decision of the porters and choose a different name than the LSB specifies. I am not saying that Debian should always follow the LSB blindly, but I cannot see a good reason for deviating from the LSB in this case. Me neither... especially since all other distros, afaik, call it ppc64... Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263743: [Debian-ppc64-devel] Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Wed, 2005-03-16 at 22:24 +, Scott James Remnant wrote: On Wed, 2005-03-16 at 23:14 +0100, Andreas Jochens wrote: On 05-Mar-16 22:01, Scott James Remnant wrote: On Wed, 2005-03-16 at 22:48 +0100, Andreas Jochens wrote: My concern is the same as that of the Project Leader, that the existing powerpc port is called powerpc -- and that we should at least try to be consistent with already chosen architecture names. So you would add 'powerpc64' support to dpkg if the port changes its package name accordingly? Yes, that'd be applied to the 1.13 branch straight away. However, I still do not understand why you and/or the Project Leader want to override the decision of the porters and choose a different name than the LSB specifies. I am not saying that Debian should always follow the LSB blindly, but I cannot see a good reason for deviating from the LSB in this case. Because it's a 64-bit version of an already supported architecture. Having ppc and ppc64 would be fine, as would having powerpc and powerpc64. Having powerpc and ppc64 is inconsistent. Then fix powerpc :) And use alias tricks if you can to keep the old name. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263743: [Debian-ppc64-devel] Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Thu, 2005-03-17 at 01:07 +, Scott James Remnant wrote: On Thu, 2005-03-17 at 01:57 +0100, Andreas Jochens wrote: On 05-Mar-17 00:10, Scott James Remnant wrote: No, I would just prefer consistency. You've deliberately chosen an architecture name that's jarringly different from your 32-bit variant; that's a rather bold thing to do, and I think you need to justify that. The decision to use the name 'ppc64' is based on the LSB and it is consistent with the decision of all other distributions I know of. But it isn't consistent with Debian's previous decision on the PowerPC port. In particular, the LSB mandates ppc32 for what we call powerpc. Ok, so if I follow you: We did it wrong for powerpc, and that justifies doing it wrong again for ppc64 ? Hrm... Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298581: [Netboot] Ethernet Driver on 1.8GHz G5?
On Wed, 2005-03-09 at 09:07 +, Francois wrote: On Tue, 2005-03-08 at 22:48, Benjamin Herrenschmidt wrote: On Tue, 2005-03-08 at 17:04 +, Francois wrote: thanks for your help. I've tried again and I've explicitly selected sungen, but with no success. The strange thing is I do see an Ethernet device in the pci tree (from /proc/pci): This is one of the newer single-CPU G5s, they have the same chipset as the iMac G5, the kernel is missing the proper PCI ID for the ethernet (among others). Try the iMac G5 kernel. Thanks for the information. Is your page at penguinppc.org the right place to get an iMac G5 kernel? I've never compiled a netboot enabled kernel before. Is there an howto available to help me start? (Or should I switch to a simpler approach, if there is one?) No, I don't distribute kernels anymore. The iMac G5 patches haven't been merged yet, but I think there are some debian packages available. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271080: gworldclock cpu usage
On Thu, 2005-02-24 at 22:53 +1100, Drew Parsons wrote: I can't get any handle on how to reduce gworldclock's resource usage. My system tells me (via top) cpu usage is at 0.3%. Updating the timer command from gtk_timer_add to g_timer_add makes no difference. Manipulating the timer's priority using g_source_set_priority, to G_PRIORITY_DEFAULT_IDLE or G_PRIORITY_LOW does not seem to help (top still reports cpu usage at 0.3%). I don't think I can make any further progress here without assistance. I'll see what I can find. I'm a bit busy atm... With regards to memory, top reports 13MB virtual, of which 5.4MB is shared. The only obvious place I can think of offhand to reduce the memory footprint is to use a lightweight xml library instead of libxml2, but since libxml2 is shared memory, the gain would not, I think, be real. Drew -- Benjamin Herrenschmidt [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295597: emacs21: incorrect modifier key behaviour (ISO_Level3_Shift vs. Meta)
On Sat, 2005-02-19 at 15:01 +0100, Denis Barbier wrote:
[Sorry for breaking this thread, but I am back from vacation and
the nameserver for my mail is down for the whole weekend]
Benjamin, I cannot reproduce this bug; as emacs does not handle
ISO_Level3_Shift, my only bet is that something is wrong with
your modifiers. Can you please run
$ xkbcomp :0
and send me the server-0.xkb file generated by this command?
And what does xev display when you press ISO_Level3_Shift+q?
Ok, thanks for the tip using xkbcomp that way, I think I found the
problem, though it is still strange that xemacs behaves differently...
My home made macintosh/fr keymap has:
key LALT { [ ISO_Level3_Shift ] };
However, the rules includes both the us keymap and then the fr
keymap, and the macintosh/us ones contains:
key LALT { [ Alt_L, Meta_L ] };
(Which sounds bogus btw).
The problem is that when the fr stuff overrides the us stuff, the
second entry is not removed, and thus, the resulting map in the server
looks like (from server-0.xkb):
key LALT { [ ISO_Level3_Shift, Meta_L ] };
Which causes emacs to interpret that key as an additional Meta instead
of the other Meta key... Commenting out the stuff in the us keymap
fixes it.
Cheers,
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295597: emacs21: incorrect modifier key behaviour (ISO_Level3_Shift vs. Meta)
On Fri, 2005-02-18 at 08:59 +0100, Jérôme Marant wrote: Quoting Benjamin Herrenschmidt [EMAIL PROTECTED]: Ok, I tried 21.3+1-6 (-7 wasn't built for ppc it seems) and the problem is the same. My ISO_Level3_Shift key is sort-of interpreted by emacs as beeing another Meta and it will refuse symbols generated with it. Dunno what's wrong, but that basically makes it unuseable. I don't understand why it does that as it has already a perfectly working Meta key on Mod1 Thanks for trying. Denis has not replied to my call for help yet. By chance, would you know anyone who can help us with this issue? Very few people on earth have some knowledge of XKB. I guess there is a reason why you wanted to swtich from XEmacs to Emacs? :-) We don't want to lose a new user :-) Ok, Denis gave me a tip that allowed me to find the problem (it was indeed a config issue, though it's weird that xemacs and emacs react differently). I have some other problems with emacs and xkb, but I'll come back later with those. It's almost impossible to make a Mac fr keymap that reacts like in MacOS due to Alt beeing both Alt and used to generate various symbols basically... To reply to your other question: I'm not a long time (x)emacs user, since I come from a MacOS background. I started slowly with xemacs about 2 years ago because a co-worker of mine was helping me getting up to speed with it and I wanted to get used to something I could find easily on any linux box, instead of jcc that I had been using on linux for a while before that which had the interest of having the exact same key shortcuts as CodeWarrior (which I used for years on MacOS), but became non-free. I'm now wanting to switch to emacs because xemacs is slower, the tabs stuff is totally buggy, and it's easier to find emacs than xemacs on an existing install you are ssh'ing to :) Ben.
Bug#295597: emacs21: incorrect modifier key behaviour (ISO_Level3_Shift vs. Meta)
On Thu, 2005-02-17 at 09:00 +0100, Jérôme Marant wrote:
Quoting Benjamin Herrenschmidt [EMAIL PROTECTED]:
What exactly is ISO_Level3_Shift?
I use it to obtain additional symbols, I map it to the left Alt key
(which I don't map to Alt of course), that's how MacOS obtains the
|,{,},etc... on intl keyboards (read: non-us).
It sort-of is the new way to do it instead of switching groups with
Mode_switch. A bunch of intl keymaps are supposed to use it nowadays, I
suspect AltGr will be defined as that in the future.
Something related to xkb has changed in recent debian-patched Xfree releases
as well as in Xorg 6.8.1+ that made necessary to apply the patch I mentioned
to Emacs.
Hrm... I'm using Xorg CVS HEAD...
That is, I can't obtain the symbols that are normally obtained with an
ISO_Level3_Shift + key combo. Emacs interprets it apparently as
Meta-key.
When did this bug first show up? We applied a patch recently which
was related to xkb map. It has not been applied to XEmacs yet.
Ah, could be ! I think it didn't happen before my upgrade a few days
ago, but then, I'm also just switching from xemacs to emacs so it's a
bit difficult to say. I suppose I could be emacs myself without the
patch to confirm that, but I would need some help I suppose, as I've
never been close to trying to build that monster before :)
The patch was introduced in 21.3+1-8. Could you please grab 21.3+1-7
from snapshot.debian.net and tell us if it changes anything?
Ok, it wasn't in the pool, I'll try to find it there. It could be a bug
in the patch.
That said, I suspect you could have to change your settings for this
new compliance. Unfortunately, I have zero knowledge about xkb but the
originator of the said patch might help us.
I don't think I _can_ find a set of settings that will work given the
way emacs is reacting but I'll investigate with the xkb folks.
Ben.
Bug#295597: emacs21: incorrect modifier key behaviour (ISO_Level3_Shift vs. Meta)
Ok, I tried 21.3+1-6 (-7 wasn't built for ppc it seems) and the problem is the same. My ISO_Level3_Shift key is sort-of interpreted by emacs as beeing another Meta and it will refuse symbols generated with it. Dunno what's wrong, but that basically makes it unuseable. I don't understand why it does that as it has already a perfectly working Meta key on Mod1 Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295597: emacs21: incorrect modifier key behaviour (ISO_Level3_Shift vs. Meta)
On Fri, 2005-02-18 at 11:41 +1100, Benjamin Herrenschmidt wrote: Ok, I tried 21.3+1-6 (-7 wasn't built for ppc it seems) and the problem is the same. My ISO_Level3_Shift key is sort-of interpreted by emacs as beeing another Meta and it will refuse symbols generated with it. Dunno what's wrong, but that basically makes it unuseable. I don't understand why it does that as it has already a perfectly working Meta key on Mod1 Additionally, I tried mapping ISO_Level3_Shift to Mod2, and same result... I wonder how it works with AltGr on peecees ... Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295597: emacs21: incorrect modifier key behaviour (ISO_Level3_Shift vs. Meta)
Package: emacs21
Version: 21.3+1-9
Severity: important
Hi !
My xkb modifier map looks like:
modifier_map Shift { Shift_L , Shift_R };
modifier_map Lock { Caps_Lock };
modifier_map Control{ Control_L, Control_R };
modifier_map Mod1 { Meta_L, Meta_R };
modifier_map Mod3 { Alt_R };
modifier_map Mod4 { ISO_Level3_Shift };
modifier_map Mod2 { Num_Lock };
modifier_map Mod5 { Scroll_Lock };
For some reason, in X (works in console, and works fine with xemacs
too), emacs keeps considering my ISO_Level3_Shift as another Meta.
That is, I can't obtain the symbols that are normally obtained with an
ISO_Level3_Shift + key combo. Emacs interprets it apparently as
Meta-key.
This basically prevents me from typing |,{,} and other things totally
useless to a C programmer :)
Ben.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.11-rc4-gack
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages emacs21 depends on:
ii emacs21-bin-common 21.3+1-9The GNU Emacs editor's shared, arc
ii libc62.3.2.ds1-20GNU C Library: Shared libraries an
ii libice6 4.3.0.dfsg.1-11 Inter-Client Exchange library
ii libjpeg626b-9The Independent JPEG Group's JPEG
ii libncurses5 5.4-4 Shared libraries for terminal hand
ii libpng12-0 1.2.8rel-1 PNG library - runtime
ii libsm6 4.3.0.dfsg.1-11 X Window System Session Management
ii libtiff4 3.7.1-3 Tag Image File Format (TIFF) libra
ii libungif4g 4.1.3-1 shared library for GIF images (run
ii libx11-6 4.3.0.dfsg.1-11 X Window System protocol client li
ii libxext6 4.3.0.dfsg.1-11 X Window System miscellaneous exte
ii libxmu6 4.3.0.dfsg.1-11 X Window System miscellaneous util
ii libxpm4 4.3.0.dfsg.1-11 X pixmap library
ii libxt6 4.3.0.dfsg.1-11 X Toolkit Intrinsics
ii xaw3dg 1.5+E-8 Xaw3d widget set
ii xlibs4.3.0.dfsg.1-11 X Keyboard Extension (XKB) configu
ii zlib1g 1:1.2.2-4 compression library - runtime
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295597: emacs21: incorrect modifier key behaviour (ISO_Level3_Shift vs. Meta)
On Wed, 2005-02-16 at 23:19 +0100, Jérôme Marant wrote:
For some reason, in X (works in console, and works fine with xemacs
too), emacs keeps considering my ISO_Level3_Shift as another Meta.
What exactly is ISO_Level3_Shift?
I use it to obtain additional symbols, I map it to the left Alt key
(which I don't map to Alt of course), that's how MacOS obtains the
|,{,},etc... on intl keyboards (read: non-us).
It sort-of is the new way to do it instead of switching groups with
Mode_switch. A bunch of intl keymaps are supposed to use it nowadays, I
suspect AltGr will be defined as that in the future.
That is, I can't obtain the symbols that are normally obtained with an
ISO_Level3_Shift + key combo. Emacs interprets it apparently as
Meta-key.
When did this bug first show up? We applied a patch recently which
was related to xkb map. It has not been applied to XEmacs yet.
Ah, could be ! I think it didn't happen before my upgrade a few days
ago, but then, I'm also just switching from xemacs to emacs so it's a
bit difficult to say. I suppose I could be emacs myself without the
patch to confirm that, but I would need some help I suppose, as I've
never been close to trying to build that monster before :)
This basically prevents me from typing |,{,} and other things totally
useless to a C programmer :)
:-P
--
Benjamin Herrenschmidt [EMAIL PROTECTED]
Bug#295597: emacs21: incorrect modifier key behaviour (ISO_Level3_Shift vs. Meta)
On Wed, 2005-02-16 at 23:19 +0100, Jérôme Marant wrote: When did this bug first show up? We applied a patch recently which was related to xkb map. It has not been applied to XEmacs yet. Hrm... I just reverted to the October version of emacs (21.3+1-8 instead of 21.3+1-9) and the problem is the same... Ben.
