Re: please review alsaconf patch
To be honest, I just copied that line from the powermac code. Wrong move it seems. I'll replace it with find as suggested. Thanks, Martin On Mon, Oct 31, 2005 at 02:43:57PM +0100, Frans Pop wrote: On Monday 31 October 2005 14:11, Martin Habets wrote: + /sbin/modprobe -a -l | grep 'snd-sun-' | \ Hmmm. Is -a -l correct for modprobe? -l is supposed to list modules, -a to insert (load) them... I doubt that the intention here is to try to actually load all modules available on the system, so why -a? Or am I missing something? From the manpage, -l takes a wildcard, thus why not just use modprobe -l snd-sun-* ? Also from the manpage it looks like both the -a and the -l options are deprecated and using something like find /lib/modules/$(uname -r)/kernel/ -name snd-sun-* is suggested instead. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please review alsaconf patch
On Tue, Nov 01, 2005 at 01:45:56PM +0100, Roland Stigge wrote:
Hi,
Martin Habets wrote:
Thanks for the info. I guess you must have an audio device on the
ebus then, and I failed to check for that in my original patch.
Could you try the patch attached in stead of the original one, please?
Unfortunately, it didn't work out-of-the-box. With a bit of polishing I
could at least make it run (see attached incremental patch to your changes).
Some comments to the respective changes:
(1) $PROCFS was not defined, so I set it manually. I didn't know where
you intended it to come from so I just set it in the beginning of the
patch to /proc.
It is set at line 30 of the script. Maybe you are using an old version of
alsconf?
(2) I guess you meant mounting openpromfs in case /proc/openprom exists?
Therefore instead of ||.
I meant to mount it if it has not been mounted yet. Fixed the code for this.
(3) Under /proc/openprom/[EMAIL PROTECTED],470/[EMAIL PROTECTED], I have
a directory
called [EMAIL PROTECTED],20. Therefore, I needed to search for audio*
instead of audio.
(4) The file compatible contains: 'SUNW,CS4231' (with single
quotes). I needed to remove them.
Now, alsaconf detects the device fine. (Also consider FJP's comments on
using modprobe.)
Thanks for testing and for the fixes.
However, there are some issues left with my CS4231: On bootup, the
modules are not loaded automatically (even hotplug doesn't care about
them). So I need to put snd-sun-cs4231 into /etc/modules. Further,
when I want to play something (e.g., with xmms), I often (unpredictably)
get (white?) noise. Retrying helps every 3rd or 4th time. Maybe
alignment or endianess issues. But these are different issues and not
related to alsaconf I think. If noone else has experienced this yet, I
will need to dive into the driver myself later.
What kernel version are you on? A number of patches have been submitted
on the sparclinux list in the last 2 months, the last one on october 29th.
If you have those, it is best to follow up with Georg Chini on this.
Thanks,
Martin
---
--- alsaconf.orig 2005-10-31 13:02:07.0 +
+++ alsaconf2005-11-02 08:16:08.0 +
@@ -688,7 +688,8 @@
# PowerMac
#
if grep -q MacRISC $PROCFS/cpuinfo; then
- /sbin/modprobe -a -l | grep 'snd-powermac' | \
+ MODDIR=/lib/modules/`uname -r`
+ find $MODDIR -name 'snd-powermac' -print | \
while read i; do
i=${i##*/}
i=${i%%.o}
@@ -701,19 +702,22 @@
# Sparc
#
if grep -q Sparc $PROCFS/cpuinfo; then
- test -r $PROCFS/openprom || /bin/mount -t openpromfs none
$PROCFS/openprom /dev/null 21
+ test -r $PROCFS/openprom/name || /bin/mount -t openpromfs none
$PROCFS/openprom /dev/null 21
# Check for an audio device
audio=
compat=
if test -r $PROCFS/openprom; then
- audio=`find $PROCFS/openprom -follow -type d -name audio -print`
+ audio=`find $PROCFS/openprom -follow -type d -name audio* -print`
fi
if test -n $audio; then
compat=`cat $audio/compatible`
+ compat=${compat#\'}
+ compat=${compat%\'}
compat=${compat#SUNW,}
fi
# Go through all cards we have
- /sbin/modprobe -a -l | grep 'snd-sun-' | \
+ MODDIR=/lib/modules/`uname -r`
+ find $MODDIR -name 'snd-sun-*' -print | \
while read i; do
i=${i##*/}
i=${i%%.o}
@@ -1339,7 +1343,8 @@
if [ -s $FOUND ]; then
while read dev card ; do
- /sbin/modprobe -a -l | grep -q -E $card'\.(o|ko)' || continue
+ MODDIR=/lib/modules/`uname -r`
+ find $MODDIR -type f | grep -q -E $card'\.(o|ko)' || continue
cardname=`find_device_name $dev | cut -c 1-64`
if [ -z $cardname ]; then
cardname=$card
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re[3]: Приглашение - Английский Разговорный с п реподавателями из С Ш А dvadcatomu
Hi! Согласно статистике московских кадровых агенств знание английского языка повышает вероятность получить работу -начальные знания-5% -хорошие знания-на 20% -отличные знания-на 60% Мы повысим Ваши шансы на трудоустройство на 60%!!! Каждому по скидке! В Москве наши телефоны следующие: один-ноль-пять 5186 два-три-восемь-три-три-восемь-шесть dvadcatoju dvadcatuju dvadcatye dvadcatyj dvadcatym dvadcatymi dvadcatyh dvadcat' dvadcat'ju -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please review alsaconf patch
Martin Habets wrote: (1) $PROCFS was not defined, so I set it manually. I didn't know where you intended it to come from so I just set it in the beginning of the patch to /proc. It is set at line 30 of the script. Maybe you are using an old version of alsconf? The one from unstable, and indeed the experimental version sets $PROCFS. But that shouldn't make a difference for the other points. I need to stick with unstable; for my taste, it's unstable enough. ;) (2) I guess you meant mounting openpromfs in case /proc/openprom exists? Therefore instead of ||. I meant to mount it if it has not been mounted yet. Fixed the code for this. Wouldn't it even better if we leave the system in the state we found it? I.e. unmounting in the end if mounting in the beginning. bye, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SS20 and SMP using Ross modules
I have here an SS20 which has run Woody reliably for an extended period. It has 2x Ross 625 CPUs, PROM 2.25R and 256Mb RAM. It runs single-processor 2.4.27 from Sarge reliably, but attempting to boot SMP gives an interrupt 15/watchdog error. If it is given this sequence of commands: reset ross625 ibuf-off 2 switch-cpu ibuf-off 0 switch-cpu boot it will boot into SMP, but eventually fails with a wrong magic error. If the Ross modules are replaced by Suns then it will boot either single processor or SMP successfully, and run reliably. Reverting to Ross modules, if I build a standalone kernel I find it's too large to boot from disc, but I can boot it over the LAN (boot net root=/dev/sda2) and the system runs SMP reliably. However I notice that while the BogoMIPS rating of a single CPU is 150 when running SMP it's dropped to 104 per processor- I thought this was calibrated using a tight loop? I'm assuming that none of the core developers will be looking at this because of the age of the hardware, and I don't have the hardware information to even start making sense of this sort of problem. However as a workaround can anybody point me at the documentation that describes the Debian/SPARC-specific kernel rebuild procedure- running the standard make vmlinux gives me a kernel image of around 2Mb. My position is that I'm keen on promoting Sun kit for in-house use, but having to boot over the LAN makes it difficult to argue that they are a viable alternative to PCs, and if I'm not confident making that argument I'm not going to put my neck on the block and ask for money for newer systems. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
the keyboard and the installer
Hi All, I'm using the latest 2.6 stable netboot install via tftp on a SunBlade 100. Whenever I choose a keymap, American English, it turns out wacked. The 0 key is Enter, the Backslash key is tab, etc. It's quite a mess. Has anyone else experienced this? If so, is there a way around it? I've tried a Sun, Mac, Dell keyboard. -- Sincerely, Matt Dunford Unix Systems Administrator DOE Joint Genome Institute url: http://www.jgi.doe.gov email: [EMAIL PROTECTED] phone: 925-296-5844 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SS20 and SMP using Ross modules
On Wed, Nov 02, 2005 at 10:38:11PM +, Mark Morgan Lloyd wrote: I have here an SS20 which has run Woody reliably for an extended period. It has 2x Ross 625 CPUs, PROM 2.25R and 256Mb RAM. It runs single-processor 2.4.27 from Sarge reliably, but attempting to boot SMP gives an interrupt 15/watchdog error. If it is given this sequence of commands: reset ross625 ibuf-off 2 switch-cpu ibuf-off 0 switch-cpu boot bizarre. it will boot into SMP, but eventually fails with a wrong magic error. eventually fails in what way? during boot? after running for two weeks? If the Ross modules are replaced by Suns then it will boot either single processor or SMP successfully, and run reliably. Reverting to Ross modules, if I build a standalone kernel I find it's too large to boot from disc, but I can boot it over the LAN (boot net root=/dev/sda2) and the system runs SMP reliably. However I notice that while the BogoMIPS rating of a single CPU is 150 when running SMP it's dropped to 104 per processor- I thought this was calibrated using a tight loop? I'm assuming that none of the core developers will be looking at this because of the age of the hardware, and I don't have the hardware information to even start making sense of this sort of problem. However as a workaround can anybody point me at the documentation that describes the Debian/SPARC-specific kernel rebuild procedure- running the standard make vmlinux gives me a kernel image of around 2Mb. My position is that I'm keen on promoting Sun kit for in-house use, but having to boot over the LAN makes it difficult to argue that they are a viable alternative to PCs, and if I'm not confident making that argument I'm not going to put my neck on the block and ask for money for newer systems. Well, try configuring a smaller kernel, with more things defined as modules. Failing that, try using an initrd image for boot time module use. These troubles don't really translate to being apropos to the question, however, as experience with this ancient hardware isn't typical of experience with US2 or US3, or, dare I say it, US4 processors. I don't know if anyone has even tried to fire up Linux on a US4 box. My opinion, while possibly inaccurate, is that US2 based machines are the best supported by Linux these days. Cheers, a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SS20 and SMP using Ross modules
On Wed, 2 Nov 2005, Andrew Sharp wrote: it will boot into SMP, but eventually fails with a wrong magic error. eventually fails in what way? during boot? after running for two weeks? It's probably cramfs: wrong magic, typical failure message when the kernel cannot find the initrd (identified by some 4-byte magic number) in the expected place. It might be that there is still some breakage in the memory copying routines, which I've hit before. Reverting to Ross modules, if I build a standalone kernel I find it's too large to boot from disc, but I can boot it over the LAN (boot net root=/dev/sda2) and the system runs SMP reliably. However I notice that while the BogoMIPS rating of a single CPU is 150 when running SMP it's dropped to 104 per processor- I thought this was calibrated using a tight loop? The old trick to reduce the size of the image on sparc32 to acceptable one is to run the following command on the image after the build: strip -R .comment -R .note -K sun4u_init -K _end -K _start image This strips it of non-essential sections, decreasing its size quite dramatically. I'm assuming that none of the core developers will be looking at this because of the age of the hardware, and I don't have the hardware information to even start making sense of this sort of problem. However as a workaround can anybody point me at the documentation that describes the Debian/SPARC-specific kernel rebuild procedure- running the standard make vmlinux gives me a kernel image of around 2Mb. My position is that I'm keen on promoting Sun kit for in-house use, but having to boot over the LAN makes it difficult to argue that they are a viable alternative to PCs, and if I'm not confident making that argument I'm not going to put my neck on the block and ask for money for newer systems. I gave up on sparc32 after multiple attempts to make 2.6.11 and 2.6.12 work reliably on my Hypersparc system failed. I've recently got myself a new SS20 with hypersparc CPUs, so I'm currently trying to figure out how 2.6.14 will behave on it. Hopefully, I'll have something definite to say about by weekend, so stay tuned :-). I am pretty sure that SMP will not work though. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
