The Answer Gang

By Jim Dennis, Karl-Heinz Herrmann, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!

We have guidelines for asking and answering questions. Linux questions only, please.
We make no guarantees about answers, but you can be anonymous on request.
See also: The Answer Gang's Knowledge Base and the LG Search Engine

---

Contents:

¶: Greetings From Heather Stern

Redhat + scsi RAID = Excedrin headache #459

howto

Wireless networking

---

Greetings from Heather Stern

Greetings dear readers, and welcome once more to the wild and whacky world of The Answer Gang. Sorry the workshop's a mess. Even sorrier we took so long to clear out the sawdust and get these bits to you. However, I hope you find the threads a little more readable.

Which brings me to thoughts of the next battle ahead. Upgradability has always been something I care about; thence my careful management of my distros, whichever they are, and a particular fondness for Debian's apt-get feature. (I look forward to trying yum when I have Copious Free Time^tm to try Fedora, and recommend urpmi to Mandrake fans.) Still, the main thing that gives any distro is the policies its maintainers apply. RPM based distros are unique because of how the dependencies are laid out - if they're good, installs of new software - even source based softare, are easy, and if not, then upgrades are just hellish. In other words, these maintainers... they are your sysadmin, until you take the reins in your hands to do it yourself - and even then, the tools they make handiest to help you with that also apply policy, at least about where the control files go.

As Linux is increasingly being taken up by people who care about what they're going to do with it, rather than folks who really care what their OS is at all under the hood - this is getting more important. The paper zines have been muttering under their breath for years "not ready for the enterprise" - what they mean is we dunno, as in Ghostbusters, "who ya gonna call?"

Nobody claims that's the problem anymore, all the big names are well known and pretty much Joe User have now heard of mailing lists and blogs. Still they resist, so the next chain to yank is "it's too hard to switch" - oops, GUI and web admin interfaces abound. Can't lean on that one too much anymore. What else? Well, change manaegement is the real problem - a problem about people, not about technology - and that's about policy.

But what about when your fought-for-and-won distro of choice changes its policies? What if you don't like them anymore? Whoops. Of course the mswin folk have dealt with the changing winds from Redmond every other season, but we've grown rather fond of having a choice... and it upsets our applecart when the spirit of a distro changes. I've watched it over the years. Slackware was one of the earliest distros at all - only had 3 or 4 competitors and you may not have even heard of them if you're new to the game - and being a distro proper made life easy. Slackware has its loyal followers everywhere - but you won't find them saying it's because they wanted to have their hand held, no way. Red Hat put together the system for the ordinary guy, the average Joe... and around the time those Caldera people were looking good for a good standing in the business world, decided that was their new definition of Joe. Their trend toward the business world has gone so far they will barely accept money from Joe's buddy out here on the street anymore. What? and have to answer his phone calls?? They run and hide. Much more fun to accept money by the industrial size barrel for the occasional call now and then from a corporate contact. The community that had grown to be fond of them takes this two ways:

1. a personal challenge, after all the whole point of the GPL and other free licenses is for projects to continue when the original folk bail on it;
2. vote with their feet, especially if any other policies of basic set up are annoying them. There's a lot more distros to pick from now, maybe it's time to go shopping.

That's where the Fedora plan came in. Of course, I've got my clients, and I heard diddly squat from them about the Fedora Legacy project - to keep RH consumer distros in security patches at least; lots more about considering the offers of Progeny or other consulting vendors to keep them in good health. Fedora's lifeblood will be the people who took the challenge seriously and though their first burst of energy was a painful birth, I think the kid's coming along nicely.

Mind you, the Linux users of the tinkering spirit, with their off brand distros and literally a pile of Debian derivitives, are not safe from the winds of change - they need to learn to set their sails too. The Debian project just went through a vote that changed some minor wording in their core document, the Debian Social Contract... and oh, the flame wars that have arisen if one interprets the new word they chose a bit more broadly. It's not that bad folks, it just isn't - but people who thought they were standing on solid ground got mildly dizzy when the bandwagon shifted even a little bit. The purists who want to know that "free means free" will feel a bit happier setting sail this way. Those who wail that it may vastly slow down the Sarge release are probably wrong; yeah, it's slow but what I have learned to view as signs of impending release with the next few months - breakage for brief times now and then of core dependencies and thence the install of core packages - have been happening of late, and I've just learned to keep an ear flapping in the wind for the howling of their Bug Tracking System entries. The really painful ones get FAQ status in freenode's #debian channel by being listed in the topic you read as you enter. Luckily they also get dealt with rather quickly, but I wouldn't exactly update via cronjob these days; I like to keep a closer eye on things.

That's just a couple of examples. Now that the word "Linux" gets a few less glassy stares I also hear the hiss of people zipping their hand back with burnt fingers everywhere. The good news is there are at least as many varieties of burn cream as there are hot stoves to touch or hot sidewalks to stroll along. The bad news - good news in disguise - is there are so many choices!

That's the way it is in the Open Source world, though, folks. For anything big enough - the world is their beta tester. If we aren't - then the result will not be up to a world of users. Take your choice when to take a plunge - but Summer is here. Enjoy your time at poolside, soak in some rays or lay the Sunblock 2000 as thick as you feel you need to in all its designer colors - but the time will come to dive in. Serves millions. Enjoy.

---

Redhat + scsi RAID = Excedrin headache #459

From Faber Fedor

Answered By: Faber Fedor, Benjamin A. Okopnik, Kapil Hari Paranjape, Jim Dennis

Hey Gang,

I've got a problem that I've fixed three other times in different enviroments, but this time it's driving me nuts.

The short of it is this: I've got a newly upgraded RedHat 9 on a PII 400 MHz box running RAID 5 using LSI Logic MegaRAID 500 SCSI. When the system boots, I get the following panic:

    creating boot device
    creating root device
    mounting root filesystem
    mount: error 6 mounting ext3
    pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2
    umount /initrd/proc failed: 2
    Freeing unused kernel memory: 132K freed
    Kernel panic: No init found.  Try passing init= option to kernel

Yes, the scsi drive is recognized and the appropriate drivers are loaded (I did a mkinitrd --preload scsi_mod --preload sd_mod initrd.scsi <kernel image> and verified that the modules were included in the initrd by mounting it). I also verified that the root filesystem is indeed ext3 (btw, how does the system know if the filesystem is of a particular type before it gets to /etc/fstab? I haven't figured that out yet) and it was clean.

[Ben] Presumably by reading the partition table and doing a little string comparison, just as "file" does.

From what I was able to google, one person said that the journal might have been trashed (fixed with fsck) and another said that there was no corresponding device in the initrd, which is true. But do I need to create a device for the /dev/sda in the initrd and if so, how?

[Ben] I've found that a lot of headaches can be avoided by simply deleting the journal when there's a related problem. There can be much darkness of the spirit and wailing and rending of clothes otherwise.

[Faber] Yes, it's a bash script called linuxrc. It looks pretty straightforward:

#!/bin/bash

echo "Loading scsi_mod.o module"
insmod /lib/scsi_mod.o
echo "Loading sd_mod.o module"
insmod /lib/sd_mod.o
echo "Loading ncr53c8xx.o module"
insmod /lib/ncr53c8xx.o
echo "Loading jbd.o module"
insmod /lib/jbd.o
echo "Loading ext3.o module"
insmod /lib/ext3.o
echo Mounting /proc filesystem
mount -t proc /proc /proc
echo Creating block devices
mkdevices /dev
echo Creating root device
mkrootdev /dev/root
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
umount /initrd/proc

So straight forward that they're not even using 'modprobe'! -- Thomas Adam

[Ben] Saaay... that looks interesting. What's that "mkdevices" bit, and how does it know which devices to "mk"? That's assuming that the lack of an appropriate device is the problem. I'd also add a "-v" to all those "insmod" invocations, just for grins - and maybe kill those "echo" lines.

Any other suggestion for fixing this are welcome. As I've said, I've fixed three other Red Hat/SCSI problems within the past few weeks ( 1. boot off of an IDE and mount the scsi, 2. upgrade to Red Hat 9, or 3. preload modules in initrd) but short of reinstalling the OS, I can't figure out what to try next.

[Ben] "pivotroot", IIRC, is only necessary if you want to do an "initrd"-type boot, where you fire up a RAMdisk, boot off that, then mount your partition on '/' as ext3, and away you go. Mind you, this is all from memory - it's been a long time since I did this myself, and the only reason for doing it was that I wanted to try a Debian-precompiled kernel. These days, I just make an ext3 partition from the start. However, you're talking SCSI, so it looks like you're stuck with doing it that way - unless you stick a small IDE HD in there just for booting.

What I'd run into previously is, "mkinitrd" actually uses "/etc/fstab" when building the image. I ended up having to tweak "/etc/fstab" to make it fit the machine I was building it for - as opposed to the one on which it was being built - and then untweak it after running "mkinitrd".

I've tried that as well.

[Ben] Argh. Well... let's peel it back as much as we can. It's been a mort of years since I've dealt with SCSI HDs, so I don't know how helpful this will be, though.

First off, I'd go ahead and pop in a Knoppix CD, boot with it, and see if I can detect/mount/read the SCSI - and I would watch carefully to see just how different the SCSI-related messages are during the process (i.e., do you need to try a different module?) Then, I'd make sure that the "/etc/lilo.conf" on the SCSI is trying to do The Right Thing (you are using LILO, right?) - no IDE-specific stuff in there, "root", "boot", etc. are set to the correct values (not an "hdX" in the place...) and re-run "lilo -v" just to see what the output is and make sure that it's properly set. I'd walk through the "initrd" setup to make sure that there's nothing odd in there, and particularly check that ROOT in "/etc/mkinitrd/mkinitrd.conf" is explicitly set (I just remembered having a problem with that default "probe" setting at one point; my current one says 'ROOT="/dev/hda1 ext3"'.) Also, take a look at "/etc/mkinitrd/modules".

Nothing else comes to mind at the moment.

The partition table holds filesystem information? I didn't see anything in the list of types in fdisk.

[Ben] Sorry, I should have expanded that. The kernel would read the partition table, jump to the location indicated by it, and do a string comparison on the info it finds there - mind you, I don't know that that's what it does, but it would seem like a simple way to do it. However, "mkinitrd" also reads "/etc/fstab", so that might me how it's done.

[Faber] It seems RH doesn't have an /etc/mkinitrd directory or files.

What I'm looking at is the

echo 0x0100 > /proc/sys/kernel/real-root-dev

If I read this right, it's saying the real-root-dev is device major number 01 and minor 00 which is ram0 (so maybe Kapil was right about Red Hat using two ramdisks? but I see only one pivot_root. :-?) I'm going to change it to read

echo 0x802 > /proc/sys/kernel/real-root-dev

[Ben] I assume you mean something like

disk = /dev/sda
  bios = 0x80
disk = /dev/hda
  bios = 0x81

[Ben] That would be pretty standard stuff. You could get really wild and describe the geometry of "/dev/sda" (see the LILO manual), but I don't know that it would be helpful.

[Kapil] I had a look at RedHat's mkinitrd script also. RedHat's procedure seems to be pretty straightforward (no jumping through hoops here ). The key to understanding the above script is "man nash".

Both mkdevices and mkrootdev are builtin commands for nash. Quoting from the man page:

............... mkdevices path Creates device files for all of the block devices listed in /proc/partitions in the directory spec- fied by path. mkrootdev path Makes path a block inode for the device which should be mounted as root. To determine this device nash uses the device suggested by the root= kernel command line argument (if root=LABEL is used devices are probed to find one with that label). If no root= argument is available, /proc/sys/ker- nel/real-root-dev provides the device number. ...............

Note that the line after the mkrootdev business is setting a "dummy" "real-root-dev" so just replacing "0x100" by "0x810" or some such is not likely to work.

By the way, I always thought that the way to invoke pivot_root was

cd new_root pivot_root . old_root exec chroot next_command But RedHat's script seems to bypass the "change directory" step...

Hope this helps

[Ben] That smells like it is talking about some sort of RAM based file system (CRAMFS perhaps?) which is certainly unlikely to be an ext3 filesystem.

In other words your problem may not be with the SCSI disk and its ext3 file system at all! I don't know RH's boot procedure but some of these distro boot images have some intermediate "RAM disk" in addition to the initrd and do two pivot_roots!

If you want to stick with the distro's boot procedure, your best bet is to examine this procedure in detail.

0. Check the boot command line.

1. Open up the initrd image and look at linuxrc.

Having looked at 0 and 1 for a number of distro's I have come to the conclusion that either the guys who produce these distro boot images do too many drugs or they are taking care of some really unusual eventualities or both

I seem to remember that it's either CRAMFS or something like that; I'm sure Heather knows more about it than I do. It's a "pull yourself up by your bootstraps" kind of thing: you boot a RAM-based ext2 mini-"partition" (which mounts as "/"), which then loads the appropriate ext3 modules, mounts your actual partition, and "pivots" "/" to it.

The usual reason is to avoid having to recompile the kernel - it makes more sense for RH, etc. to make ext3, jfs, jffs, reiserfs, etc. modules and let you choose which one you want to use, but the price is having to mess with the "initrd"/"pivot_root" stuff. I just compile ext3 right in, and never have to mess with it. SCSI, of course, is a different sort of animal altogether.

[Faber] Well, you can have alook at this one. The relevant parts are:

echo Creating root device
mkrootdev /dev/root
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot

I don't see anything there that would screw up because of a SCSI disk, but then again, I don't know what /proc/sys/kernel/real-root-dev is for, so I'm off to find out...

[Ben] Anybody have an idea how 0x0100 would relate to device numbers, or whatever else "/proc/sys/kernel/real-root-dev" is supposed to hold? I suspect that the above is the RAMdisk, though, and that whatever is defined as the device for "pivot_root" to "pivot" to is what matters.

[JimD]

/proc/sys/kernel/real-root-dev is documented in .../src/linux/Documentation/initrd.txt

Quoting therefrom:

............... It works by mounting the "real" root device (i.e. the one set with rdev in the kernel image or with root=... at the boot command line) as the root file system when linuxrc exits. The initrd file system is then unmounted, or, if it is still busy, moved to a directory /initrd, if such a directory exists on the new root file system. In order to use this mechanism, you do not have to specify the boot command options root, init, or rw. (If specified, they will affect the real root file system, not the initrd environment.) If /proc is mounted, the "real" root device can be changed from within linuxrc by writing the number of the new root FS device to the special file /proc/sys/kernel/real-root-dev, e.g. # echo 0x301 >/proc/sys/kernel/real-root-dev Note that the mechanism is incompatible with NFS and similar file systems. This old, deprecated mechanism is commonly called "change_root", while the new, supported mechanism is called "pivot_root". ...............

As Ben suggests this look like /dev/ram0 (The ramdisk) which seems wrong. I'd look back through the /linuxrc to figure out what logic it's using to arrive at this point. I'm guessing that it's not loading or detecting the intended rootfs (hardware) and this value is the result of a default that wasn't over-written by any more appropriate case.

---

Faber cheerfully reported back.... -- Thomas Adam

Here's what I think is happening:

(the relevant parts of initrd/linuxrc)

echo Creating root device
mkrootdev /dev/root
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
umount /proc/initrd

create the root device attach the (ram0) ram disk to it mount the ram disk to /sysroot change the system root from the initrd to the ram0 disk umount initrd

Now, that jives with the initrd on my local )non-scsi) box. The question is: is this correct behaviour for a scsi box? If so, why is the failure occuring at mounting the ramdisk? The mount error, IIRC, is "no such device".

I was never able to fix my client's system to boot off of the SCSI drive no matter how I mucked with initrd. It was a lot of fun however and I learned more about initrd than is probably necessary.

In the end, we reinstalled RH9 from scratch. We took advantage of the new install to reconfigure some partitions and stuff, so all was not a total waste.

Interesting side note(s): the RH installer would not let us use LILO and the SCSI MBR. I could use the MBR of hda or sda1, but not the way I wanted it. So I went with GRUB.

After playing with GRUB, I must say I like it, but it has one really weird feature. All of the documentation says that GRUB refers to the first IDE drive as (hd0,0) and the fist SCSI drive as (sd0,0). Not on this system! It took me two hours (for shame!) to figure out that the SCSI drive is (hd0,0) and the first IDE drive is (hd1,0). If anyone knows why, I'd love to hear it.

Now all I have to do is recreate two years worth of customizations on this box. Good thing I have a very understanding client.

---

howto

From Guy Milliron

Answered By: Benjamin A. Okopnik, Jim Dennis

I've googled for an answer to my question, just it's too obscure for me to figure out I guess...

I'm attempting to install a new software on my RHL box. Anyhow, it's calling a program called fping (Which is pretty interesting itself, a round-robin style ping https://www.fping.com ). It says it needs to run as root (which I won't allow the calling program to run as, or needs to be "setuid".

As Ricki Ricardo would say "Splain Lucy Splain!"

[Ben] For that, see "perldoc splain" for more info. Although it's not quite smart enough to help you this time...

ben@Fenrir:~$ ls -l `which ping`
-rwsr-xr-x    1 root     root        15244 2001-11-18 17:29 /bin/ping

[Ben] "ping" has always been SUID; it needs to be in order to use ICMP - which is what "ping" does. It's a weird security model ("ICMP can be dangerous, so we'll lock it away under root privilege... but then we'll make the ICMP generator SUID so everybody can use it.") Some old, hoary, scarred and scared sysadmins remove the SUID bit from "ping" so you have to "su" in order to use it... but note that the users will complain. My guess is, user complaints are the reason that the situation exists. Of course, they could have made "ping" use TCP instead of ICMP, but then we'd be violating <Tevye the Milkman mode>TRADITION!</TtMm>.

There actually are some valid reasons for sticking with ICMP, but they're not unique to it, and are mostly doable with TCP. TCP "ping", IMO, would be a Good Thing and support a better security model.

# Net::Ping uses TCP by default
perl -MNet::Ping -wle'print"Host is ",Net::Ping->new()->ping(shift)?"up":"down"' localhost

<shrug>

[Jim] "setuid" is a special bit in the UNIX permissions. You can make your program SUID with a command like (as root):

chown root.bin `which fping` && chmod u+s `which fping`

... assuming fping in own your PATH.

You can be a little safer using commands like:

chmod root.$TRUSTEDGROUP `which fping`; chmod 4550 `which fping`

... where you create a group (such as 'staff' or 'trusted') which which will be allowed to execute this program. Then you associate this program with that group and mark it so that the owner and members of the associated group are permitted to read and execute the SUID program.

Thus if there is an exploitable bug in the program (a way to "trick" it into doing things it's not intended to do with it's root privileges) then only the owner (who's already root) and the members of the trusted group can attempt to exploit the vulnerability.

This is very basic UNIX systems administration practice that should be taught to ALL UNIX and Linux system administration professions in their first term. There is not difference between UNIX and Linux in this regard.

Note that SUID and SGID only applies to binaries --- NOT to scripts. Perl has a special helper application (sperl) which allows it to handle SUID (and SGID?) Perl scripts. It would be wise to associate sperl with a trusted group and make it non-world executable (as my second command example shows). You can make as many trusted groups as you like.

Note that SUID and SGID are the most basic forms of privilege delegation in UNIX and Linux. They allow you to write a program which acts as an agent, allowing one group of users to access some resource in a controlled and limited way (through the agent). If the program (and the libraries against which it is linked) are bug free (or "sufficiently robust") then this is a safe means of giving everyone or specific groups access to some protected resource. In the case of fping that resource is a lower level form of access to one or more of your networking interfaces. In other cases a program might be SGID "games" to allow it to update a file of high scores.

Because the likelihood of vulnerability rises dramatically as the size and complexity of a program increases, it is considered best practice to make SUID and SGID programs as small as possible --- often splitting the "agent" portion of the code into a small helper application that is called by the larger application.

A general purpose "SUID" wrapper program is called sudo. It allows you to maintain a list (even a network wide list) of users (and hostnames) and a precise list of programs, options that each user or group are permitted to run and precisely who these programs will effective run as. (There are several similar programs like super, caliph, and runas). sudo is the most commonly used choice among professional sysadmins. You control its configuration via /etc/sudoers (using the visudo wrapper to edit that; and to check your syntax as you save and exit).

Naturally I would suggest you make a sudoers group, associate sudo with that, and mark its mode to 4550 (SUID and non-world-executable) as I explained before. This will help limit the number of users that could exploit any bug found in sudo itself. Luckily sudo is one of the more widely audited bits of code on the Internet. Unfortunately it's also sufficiently well known and widespread that any cracker that does find a bug in it; or manages to pass out a trojaned copy of it, will gain LOTs of access using it (though they need to get to a local shell account first).

So it is with all SUID and SGID programs. If the agent is "vulnerable" it can become a confused deputy and give unfettered access to all resources owned by a given user or associated with a given group. (Obviously unfettered access to the root UID is also complete control of a normal UNIX or Linux system).

You can search your entire system for SUID and SGID files with a command like:

 	find / -type f -perm +6000 -ls

... this will find all SUID and SGID files. The SUID bit is meaningless on directories (at least under Linux and most forms of UNIX --- so far) and the SGID bit has some special semantics on Linux and BSD systems (which I've explained in other articles):

https://www.linuxgazette.com/issue64/lg_tips64.html#tips/18

The SUID/SGID files are also meaningless on device nodes, FIFOs (named pipes) and unix domain sockets; as well as "regular" non-executable files and most scripts (text executables). All of the permissions bits are generally ignored on symlinks.

---

Wireless networking

From Ben Okopnik

Answered By: Benjamin Okopnik, Jason Creighton, Thomas Adam

Hi, all -

I've finally had a chance to test out the wireless Ethernet on my laptop - in fact, I'm sitting at the local airport right next to their Air Port (that's a joke, dammit. You're s'posed to laugh.) The problem is, the speeds that I'm getting in Linux and Wind0ws are wildly disparate, with Linux being on the losing end. Of course, I have no way to measure the exact speed in Wind0ws (other than maybe downloading a large file and doing a little math), but the connection properties say "11Mbps" and "Quality: excellent", and the Web pages snap onto the screen like I've never seen before. Linux... [sigh] I've seen it get as high as 29kB/S during an "apt-get" operation, and Web pages crawl.

I'm using "ndiswrapper" (possibly part of the problem - like everything else on this damned Acer, the hardware (Intel PRO/Wireless LAN 2100) is unsupported), so my whole initialization sequence goes like this:

# ndiswrapper-specific stuff
modprobe ndiswrapper
loadndisdriver 8086 1043 /lib/windrivers/w70n51.sys /lib/windrivers/w70n51.inf

iwconfig wlan0 mode Managed
# Looking for a public access point
iwconfig wlan0 essid default
ifconfig wlan0 up

# get an IP via DHCP
pump -i wlan0

"ifconfig wlan0" says:

wlan0     Link encap:Ethernet  HWaddr 00:04:23:72:F5:DC
          inet addr:X.X.X.XXX  Bcast:YY.Y.Y.YYY  Mask:255.255.255.0
          inet6 addr: fe80::204:23ff:fe72:f5dc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:55417 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34901 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:81279617 (77.5 MiB)  TX bytes:2375903 (2.2 MiB)
          Interrupt:11 Memory:d0000000-d0000fff

Even my old trick of searching for the "parm" string in the module doesn't produce anything useful:

strings ndiswrapper.ko | grep parm
parm=if_name:Network interface name (default: wlan0)
parm=proc_uid:The uid of the files created in /proc (default: 0).
parm=proc_gid:The gid of the files created in /proc (default: 0).

Change the MTU, maybe? Invoke "iwconfig" in some different way? Or am I just stuck with it?

[Thomas] If you haven't done so already, Ben, make sure you have disabled apci from the kernel:

linux noapic

at the LILO prompt (by then you knew that )

[Jason] Doesn't "modinfo" do the same thing?

~$ modinfo sb
filename:    /lib/modules/2.4.20/kernel/drivers/sound/sb.o
description: "Soundblaster driver"
author:      <none>
license:     "GPL"
parm:        io int, description "Soundblaster i/o base address (0x220,0x240,0x260,0x280)"
parm:        irq int, description "IRQ (5,7,9,10)"
parm:        dma int, description "8-bit DMA channel (0,1,3)"
parm:        dma16 int, description "16-bit DMA channel (5,6,7)"
parm:        mpu_io int, description "Mpu base address"
parm:        type int, description "You can set this to specific card type"
parm:        sm_games int, description "Enable support for Logitech soundman games"
parm:        esstype int, description "ESS chip type"
parm:        acer int, description "Set this to detect cards in some ACER notebooks"
parm:        isapnp int, description "When set to 0, Plug & Play support will be disabled"
parm:        isapnpjump int, description "Jumps to a specific slot in the driver's PnP table. Use the source, Luke."
parm:        multiple int, description "When set to 0, will not search for multiple cards"
parm:        pnplegacy int, description "When set to 1, will search for a legacy SB card along with any PnP cards."
parm:        reverse int, description "When set to 1, will reverse ISAPnP search order"
parm:        uart401 int, description "When set to 1, will attempt to detect and enable the mpu on some clones"
~$

Is ACPI such an all-around evil thing that you recommend turning it off in all cases? It just doesn't seem relevant here, unless you have info to the contrary.

[Heather] I caution against confusing APIC (some sort of feature which SMP processors all do, some uniprocessors happen to do, and some CPU/motherboard combinations make poor Tux give up on herring for Lent) with ACPI (which is what APM might be is you divided it into a few levels of suspend then told each device to deal with sleepiness themselves - kind of neat from an object oriented point of view, but somewhat annoying to someone who just wants to be able to close the lid safely without knowing why it works). Both have their moments... and their times to be set on fire

[Thomas] It is a complete nightmare from start to finish. It interferes with everything. Whenever you get a HW problem such as this, I would always look at seeing if turning it off solves it.

[Ben] Well! That's quite the characterization.

[Thomas] Humour me, at least. Then you can slowly remove your sunglasses and tell me to think again

[Ben] I was actually asking in a spirit of inquiry, not doubting you. It's just these sunglasses make everyone suspicious.

I'll check it out - should be back on in a few minutes.

Just tried it. The Wi-Fi and the Bluetooth lights now stay on permanently (can't be turned off), and the speed is a bit lower if anything (I'm copying a movie file from idgames, and it's running about 26kB/S.)

---