Re: kernel-image-2.6.16-2 on oldworld (success with a small change in config)
hans - did you put modules=dep in the config file inside the directory of etc/initramfs-tools. then run update-initramfs. may need discover package, so it can see all the modules. be careful -- the changes in initrd i have looked at for some hours, they are pretty complex. (best i can tell is some how correct digital i/o sound support is related to keep hd data safe, seems udev is involved as well) i should try 16 again. but i could not even run 15 without the above stuffs going. brian ps have seen more reports of experienced people having hd problems and for myself, with all my old machines and used disks and all am checking today with SMART - found a bad spot which would not clear with fsck -ccf; i am just going to work around it for now and keep an eye on it, this is on 2000 pismo running ATA5 disk on an ATA4 controller (just discovering myself what all this is ...) pps making backup copy of my disks with debian installer is getting (ie copy install in partitioner) pretty easy - direct raw copy is v quick, and with new initrd mechanism and other etch features it is pretty easy to get it to boot if you need it. (at least with old world, it works for me ...) --- Sven Luther [EMAIL PROTECTED] wrote: On Fri, Sep 08, 2006 at 03:20:58PM +0200, Hans Ekbrand wrote: Hi! Hi, please make sure you CC debian-kernel too on issues like this. The official debian kernels for powerpc stopped working for me with 2.6.16 (2.6.15 works fine). The 2.6.16 ones fail to mount root fs at boot, which I have reported in bug #366620 I compiled my own 2.6.16 with a minimal change in .config, and that was it, 2.6.16 now boots on my oldworld mac. The needed change in config was the following: (diff against ./boot/config-2.6.16-2-powerpc in the package linux-image-2.6.16-2-powerpc_2.6.16-18_powerpc.deb) 4c4 # Sat Aug 19 00:42:57 2006 --- # Fri Sep 8 09:14:38 2006 772c772 CONFIG_BLK_DEV_IDEDISK=m --- CONFIG_BLK_DEV_IDEDISK=y 2317c2317 CONFIG_EXT2_FS=m --- CONFIG_EXT2_FS=y 2328c2328 CONFIG_FS_MBCACHE=m --- CONFIG_FS_MBCACHE=y I think this shows that there is some problem with loading the proper modules for ide and ext2 from the initrd. As stated in the bugreport of #366620 I have tried both yaird and the other initrd creator. I don't know about the FS_MBCACHE=y thing, that must have been set automatically. Will you consider appling this patch to the config? While it is not the right solution in the long term, it would make oldworld macs run with official debian kernels again (at least the ones with IDE-drives). No, please get the ramdisk creator packages to get fixed for this one, if it is that the issue. Also, can you please try the 2.6.18-rc6 packages from : http://kernel-archive.buildserver.net/debian-kernel/pool/main/l/linux-2.6/ and see if your problem persists there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test Macintosh keyboards with xkb-data 0.8-12exp1
On Fri, Sep 08, 2006 at 07:31:47PM +0200, Yannick Roehlly wrote: Good late summer evening, (well, in southern France at least) Bin Zhang wrote: Option XkbModel ibook With the ibook layout, it was working; but I prefer to use the macintosh layout so that the keypad enter behaves as KP_Enter. As Michel pointed at, the problem was that I've half read Denis mail (well, I missed a character). Using the macintosh_old2 layout works fine. My apologies... Does this mean that new Apple keyboards have the @ and the keys inverted? See Michel's posts, the kernel tries to adapt keycodes depending on the detected keyboard. It seems that your USB keyboard is not fully recognized, so you have to select the right one by hand. Maybe in the future, the kernel could get fixed, and you would then need to modify your XkbModel again. I try to find relevant names for those Mac XkbModels in order to not confuse users even more. PS: By the way Denis, just a thought. On MacOs X, the ISO_Level3_shift key is the alt key. With xkb, it's the right alt key, ? la PC AltGr. I don't know how good would be the idea to make the alt key ISO_Level3_shift and the apple key Alt_L(R). The advantage is for people switching from MacOS to GNU/Linux keep the same keyboard habits but the problem is in program where the Alt +... shortcuts becomes Apple +... shortcuts. see my previous posts, I do not want to have this discussion before we have a better understanding on what is broken and how users should choose their XkbModel. But do not worry, we seem to be pretty close now ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mac keyboards
Denis Barbier wrote: While we're on the subject of Mac keyboards, something has gone dreadfully wrong with keyboards in sid. I've done this on 2 different machines now, a G4 laptop and a dual G5 workstation: - install etch from a nightly build CD - change the distro from etch to sid in /etc/apt/sources.list - dselect, update, install - reboot voilà, keyboard is dead. It doesn't matter which kernel I boot from (the newer sid one or the previously-working etch one). Can you please file a bugreport against xkb-data with your xorg.conf settings? I haven't even got to X. This is just the console, I can't even log in. -- Chris Burdess -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test Macintosh keyboards with xkb-data 0.8-12exp1
On Fri, Sep 08, 2006 at 12:08:10PM +0200, Michel Dänzer wrote:
[...]
I'm not sure a model will cut it either. Here's my recollection of the
problem:
The hardware keycodes of these keys can be swapped, depending on layout
and maybe other factors (IIRC it's about ISO vs. other variants of ADB
keyboards). The kernel should detect this and always generate the same
PC-style keycodes, but fails to do so in some cases. I think the
keyboard type can be deferred from
dmesg|grep 'adb devices'
but I forget how exactly.
This indeed would explain why USB keyboards have swapped keycodes.
Here are more detailed informations for those who want to understand
what is discussed here. Running
setxkbmap -model macintosh -layout fr -print
displays (with xkb-data 0.8-12exp1)
xkb_keymap {
xkb_keycodes { include macintosh(macbook)+aliases(azerty) };
xkb_types { include complete };
xkb_compat{ include complete };
xkb_symbols { include pc(pc105)+macintosh_vndr/fr+inet(apple)
};
xkb_geometry { include macintosh(macintosh) };
};
In this discussion, we are only interested in keycodes.
Now have a look at /usr/share/X11/xkb/rules/xorg
The line
! model = keycodes
tells that following lines will map model names to keycodes, in
particular
macintosh_old = macintosh(old)
macintosh_old2= macintosh
macbook = macintosh(macbook)
macintosh = macintosh(macbook)
$macs = macintosh
The $macs variable is defined at the top of this file. The right-hand
side refers to files under /usr/share/X11/xkb/keycodes.
When setting model to macintosh, setxkbmap adds macintosh(macbook) to
xkb_keycodes. The aliases(azerty) part comes from
! layout= keycodes
$azerty = +aliases(azerty)
$qwertz = +aliases(qwertz)
* = +aliases(qwerty)
but this is not important for us.
In unstable, there are 2 models: macintosh and macintosh_old.
The latter is for older kernels, and should probably be renamed into
macintosh_adb for clarity reasons.
Upstream received bug reports from MacBook users, complaining that
two keys were swapped. A macbook model has been added, but my
feeling is that it is misnamed since most Mac keyboards will need
it, not only MacBooks.
I made an experiment with 0.8-12exp1, by setting all models to
macintosh(macbook) by default (well I forgot to also modify $macs,
this is a bug), and introduced macintosh_old2 for people who need
it. In the next experimental version, I am considering using the
following rules:
macintosh_adb = macintosh(old)
macintosh_alt = macintosh
$macs = macintosh(macbook)
As explained by Michel, no name can fit the plain macintosh from
unstable, so macintosh_alt (for 'alternative') may be an option.
So maybe this should be handled via layout/variant/option.
I am afraid that this can hardly be done by layout or variant. But
this is doable by an option, so we would have 2 models (ADB and PC)
and an option would swap 2 keys. This is interesting, I will also
consider it.
Don't take my word for it though; I haven't sacrificed any neurons on
this for a couple of years, and my memory is fuzzy. I hope this will
help someone else dig out more information though.
Just to be clear, I am not a kernel guy, so if someone can indeed
confirm your words, that would be great.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test Macintosh keyboards with xkb-data 0.8-12exp1
Yves-Alexis Perez wrote: Hem, under osx, to have the |\ etc. you need to press the apple key, not the alt key (on a french keyboard at least). As Bin said, here it's the alt key which is a modifier. The apple key is used for shortcuts (apple+o = Open...). Yannick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian-ppc specific error?
I'm currently using kopete 0.11.3 with KDE 3.4 as an IM. After a while doin' something I guess, can't reproduce this at a whim; kopete hangs and funny things start happening. I got to mention that kopete does not have to be opened. It can be minimized into the dock. * keyboard hangs, ie all together nonfunctional with cap and num light non responsive. * mouse can be moved as usual, but leaves me with only one option; moving windows. every button only moves the current window. No minimize maximize close no nothing so to speak. I can at any point use ssh and kill the kopete process witch will fix the problem. After having this problem at least once every 48~ hours, I've begyn tinkering a bit with the status I found out that ( I only got a BT mouse with scroll): KDE has this inbuild resource witch will ask to terminate if a program doesn't respond to the X (close) in the widget corner. I found a method to be able to use the mouse, push down the scrollwheel and scroll while down THEN the left mouse button suddenly get a correct response from X. I push the X and repeats this mouse gesture with KDE's terminate button when it appears. I guess its kopete that has the fault. BUT why does the mouse respond like that. Good for me, without the mouse I would have to hard reboot whenever this occurs. I use a PB17 5,7. Debian testing. The only button responsive is the powerbutton. -- --- Børge Kennel Arivene http://www.arivene.net ---
Re: debian-ppc specific error?
On Saturday 09 September 2006 21:15, you wrote: This is no PPC specific. I get it sometimes on my athlon. I did not know that the solution was to kill kopete though ;-) =) yes well.. it is.!. I had to track the sucker down, it was keeping my uptime at the low. How about the mouse solution? same on yer athlon? -- --- Børge Kennel Arivene http://www.arivene.net ---
Re: debian-ppc specific error?
This is no PPC specific. I get it sometimes on my athlon. I did not know that the solution was to kill kopete though ;-) -- Sylvain Joyeux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test Macintosh keyboards with xkb-data 0.8-12exp1
On Sat, 2006-09-09 at 20:10 +0200, Yannick Roehlly wrote: As Bin said, here it's the alt key which is a modifier. The apple key is used for shortcuts (apple+o = Open...). Ah, yes, sorry :) -- Yves-Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
