Kubuntu/Ubuntu does not remove everything from memory at shutdown

[Steve Morris]

On 14/03/10 23:46, Reinhold Rumberger wrote:
> On Sunday 14 March 2010, Steve Morris wrote:
>    
>> On 13/03/10 22:41, Reinhold Rumberger wrote:
>>      
>>> On Saturday 13 March 2010, Steve Morris wrote:
>>>        
>>>> This script is very similar to what
>>>> you have listed above, but as far as I can see it is issuing
>>>> invalid killall5 commands that are invalid.
>>>>          
>>> Hmm, looking through sendsigs, I can't confirm that the commands
>>> are invalid. Why would you think so?
>>>        
>> In S20sendsigs the command being issued is  killall5 -18
>> $OMITPIDS.  If I issue the command   killall5 --help
>>      
> Look at man killall5
>
>    
>> I get the
>> message that killall5 only supports 1 parameter, so how does
>> killall5 -18 $OMITPIDS actually function?
>>      
> It supports a first parameter which specifies the signal and an
> arbitrary number of parameters like "-o<PID>", specifying which PIDs
> not to kill.
>    
Okay so the help info in the command itself is deficient and needs to be 
enhanced. To see what I am referring to compare the commands killall5 
--help and killall --help.
> <snippage>
>    
>>> Funnily, we're right back where we started: your win driver
>>> isn't properly initialising the hardware.
>>>        
>> Not as I understand things. It is my understanding the first thing
>> the driver is going to do is ask the device what it is,
>>      
> If that is how it works, you have your first problem right here. The
> first thing it should do is make sure the device is in a predefined
> state so that the next query actually produces useful results
> (something that both the Mandriva and the Ubuntu drivers apparently
> do). It cannot assume that, on boot, the device will already be in
> the state it needs to be in.
>    
I don't agree. Admittedly I am not an expert, but drivers are written 
for specific hardware and will not function if the hardware installed 
does not match what it expects, hence the first check of asking the 
device what it is. Windows lists the sound card as a SoundBlaster Audigy 
and according to Win 7 the driver I am using is functioning correctly 
for the card (the driver was installed from the software CD supplied 
with the card). Now Mandriva and Kubuntu both list the card as a 
SoundBlaster Audigy SE, so potentially these OS's are interpreting the 
device as a different version of the SoundBlaster Audigy and setting up 
accordingly. It is also the responsibility of the driver to set things 
back to the factory defaults if it has changed things to suit what it 
supports, which Mandriva appears to be doing and Kubuntu does not.
>    
>> then ask
>> what it supports, then set itself up accordingly, possibly also
>> setting states in the hardware for how it wants to run according
>> to the features its supplies. I thought my soundcard was a
>> SoundBlaster Audigy LE, but Ubuntu and Mandriva are both treating
>> is as a SoundBlaster Audigy SE, so what I think is happening is
>> that at shutdown Mandriva is setting the card back to the
>> "factory defaults" whereas Ubuntu is not, which is where I think
>> the problem is.
>>      
> Three things:
> a) Just because you use another software interface of a backwards
>     compatible hardware device does not make it identify itself as
>     that earlier model.
> b) Have you ever tried setting up Windows to use the SE driver/treat
>     the card as an Audigy SE?
>    
I tried that before using the Win XP driver by downloading the vendor 
supplied driver that had the SoundBlaster Audigy SE as one of its listed 
supported devices, but it refused to install on the grounds that there 
was no supported hardware connected.
> c) It isn't required to "set the card back to factory defaults". As
>     has been explained before, that just would take too much time.
>     (Would you like to wait 5 minutes for the shutdown part of a
>     reboot just because every bit of hardware needs to be re-
>     initialised?) That is something a driver that needs this has to
>     do itself. Initialising hardware is one of the main points of
>     booting, after all.
>    
Again I don't know what the kubuntu driver is doing internally, but if 
the driver is changing settings in the hardware at startup it is the 
responsibility of the driver to undo those changes at shutdown, 
especially if the shutdown is for a warm start, as one of the other 
respondents to this thread said that hardware does not get reinitialised 
on a warm boot.

regards,
Steve

>
>    --Reinhold
>
>    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samorris.vcf
Type: text/x-vcard
Size: 126 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kubuntu-users/attachments/20100315/383f4cce/attachment.vcf>