RE: pcmcia + acpi + suspend2 seems impossible...
> -Original Message- > From: Martin Hauser [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 15, 2005 2:20 AM > To: debian-laptop@lists.debian.org > Subject: Re: pcmcia + acpi + suspend2 seems impossible... -snip- > > So far I haven't been able to get all three of these together in one > > kernel. Suspend2 doesn't appear to be a problem -- though after I > > apply the suspend2 patch I generally have to uncheck a bunch of > > extraneous module options in menuconfig. Suspend2 + pcmcia almost > > works for me; currently my main problem is that, *SOMETIMES*, after > > suspension, I get this: > > > > kernel: unregister_netdevice: waiting for eth0 to become free. Usage > > count = 5 > > > > after which eth0 (a pcmcia NIC) is dead till reboot, and in fact even > > rebooting is blocked by this persistent message, which fills up my > > kernel log at intervals of 1 to 15 seconds. > > > > Hmm, interesting. Probably you should get your 'hibernate' script to > forcefully unload the pcmcia modules and the cardbus modules + probably > hack it so it does and /etc/init.d/pcmcia stop before it goes to sleep. > That way it'd probably be working back once you're resumed. You then > just push back in the modules, restart pcmcia and there you go. If you > need detailed instructions on how to do that, let me know. I have the same laptop running Debian and can confirm that you have to write some shell scripts to unload the PCMCIA drivers for suspend and resume to work. In addition to the PCMCIA drivers I also had to remove all the audio drivers for sound to work after resume. For me the magic combination was down the network, unload the WLAN, unload the audio, unload the PCMCIA, and then suspend. On resume it was; load audio, load PCMCIA, then load WLAN, and then fire up DHCP... Net result was a machine that suspended, but took nearly as long as shutting it down and restarting it. I don't recall using any kernel patches to do any of this, but as this is my sons laptop it has been a long while... so I could very well be wrong... as I do remember being leery to mess with ACPI as it's horribly broke on this machine and has been known to render them useless. E
Debian RC2 on an IBM ThinkPad 600e
Hello list I’ve been reading for a while and now I have a question. I know you all saw the IBM TP 600e and groaned, but this more of a success story with a general Debian question… I thought I would ask here because I’m subscribed. I’ve got a TP 600e with a mostly successful install, everything works so far (I haven’t dove into the APM stuff yet). My question is about hotplug and kernel modules… I have got my sound to work, but right now it is a kludge… after load up I run a little shell script I wrote to remove all the cs46xx modules and then load my cs4232 modules… the thing is, although it works it is less than elegant. How can I get it to QUIT loading cs46xx on boot up, I’ve tried blacklisting it… but it loads before that apparently… when I do a lspci the audio card is identified incorrectly (as a PCI card, even though I’ve been told it is an ISA card). The card is NOT PNP… I know I probably could just rename the .ko, but I’m trying to actually understand how the boot process works. Anyone have any really handy links of kernel startup and/or hotplug. Am I missing something really simple? TIA for any pointers. Eric G. van der Paardt Systems Administrator 715-485.9312x3198 Bishop Fixture & Millwork 101 Eagle Dr. Balsam Lake, WI 54801
RE: Debian RC2 on an IBM ThinkPad 600e
Ahh! a clue... discover... I haven't played with that at all... I blacklisted in hotplug for the record, I am familiar with the legacy modules stuff but am trying to covert my way of thinking to the new way, so my /etc/modules is empty and /etc/modules.conf is created via update-modules... I'll check discover when I get home to play with it. -Original Message- From: Frans Pop [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 12:57 PM To: [EMAIL PROTECTED] Subject: Re: Debian RC2 on an IBM ThinkPad 600e -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 23 November 2004 16:58, Eric van der Paardt wrote: > How can I get it to QUIT loading cs46xx on boot up, I've tried > blacklisting it... but it loads before that apparently... when I do a > lspci the audio card is identified incorrectly (as a PCI card, even > though I've been told it is an ISA card). The card is NOT PNP... I know > I probably could just rename the .ko, but I'm trying to actually > understand how the boot process works. Where did you blacklist it? Hotplug or discover? If you are running both, you may need to blacklist in both. Also check /etc/modules. Cheers, FJP -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBo4gXgm/Kwh6ICoQRAtQ/AJ95Xd0zI86Fg0I+Iivjb16PakJX6ACgmy8T +fgfzzi1+Q+i4ja6YBYWuCE= =8ykK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: MIC's loud and Speaker screams when sound module loads. Why?
I had a different sound issue, where my blacklisted modules where being loaded by 'discover' long before I wanted them to be. Adding the line 'skip modulename' to /etc/discover.conf was all I needed to get the module to quit loading... For my sound to work I had to actually load it from an init script last (right before kdm). I also call aumix at this time to restore my mixer settings. This might be a solution for you as well... if the same script loaded you sound modules and called aumix on success... I would also check to see if there is a module option you can load the module with that would set your levels. Best of luck, E -Original Message- From: Benedek Frank [mailto:[EMAIL PROTECTED] Sent: Friday, December 03, 2004 10:51 AM To: p; [EMAIL PROTECTED] Subject: Re: MIC's loud and Speaker screams when sound module loads. Why? On Friday 03 December 2004 05:52, p wrote: > On Thu, Dec 02, 2004 at 01:11:43PM -0800, Benedek Frank wrote: > > __deletia__ > > > Can you tell me, when the recompile is done, what do I do? How do I > > insert the module late, when KDM starts? Write a little script like > > > > modprobe esssolo1 > > > > ??? > > // > > insmod > > kthxbye. > > b. > > // Hi I got somewhat further. Now, I established that aumix in fact works, just not early enough. If I set the name of the file under /etc/rd.2/S20aumix to S10aumix, it will load sooner, and the screaming goes away sooner too. It is almost acceptable now. However I would still very much like to know what loads the esssolo1 module. I blacklisted it, and I blacklisted all the other sound related things, snd_es1938. Now, the snd_es1938 wont load, and that is half success. However the esssolo1 loads, even blacklisted. Upon boot, it shows, that essolo1 and e100 (ethernet) are the only two modules that load prior to Hotplug's execution. What on earth loads those two modules? It says "Hardware detection" right before they are loaded. THanks Bence -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
what's the best way to deal with a disconnect eth0?
I’m setting up a laptop for my companies president. He likes techy things and asked me to setup a linux/winxp dual boot for him to play with and compare. So I have it all setup, I’ve got a nearly apples to apples setup running (except the windows partition is available under Linux but not vice versa). The biggest thing holding me back is eth0, w/o a cable connected you get a bunch of ugly DHCP connection junk on startup and it takes a long time to time out. This will almost NEVER be connected, but I don’t want to just remove the auto setup for that interface in case someday he does plug it into something… So is there a way with the /etc/interfaces stuff to only try to auto-configure eth0 if there is a cable plugged in? Eric G. van der Paardt Systems Administrator 715-485.9312x3198 Bishop Fixture & Millwork 101 Eagle Dr. Balsam Lake, WI 54801
RE: what's the best way to deal with a disconnect eth0?
-snip Have a look at ifplugd; I guess it does exactly what you're looking for. Koen Thanks Koen it works great... still pauses, but not nearly as long as waiting for that DHCP timeout, and was easy as could be to setup. E
