headers
Chandru | 1 May 2008 13:28
Picon

udev rules for kdump

Hi,

On a powerpc box  when memory or cpu DLPAR operations (memory,cpu  
addition/deletion) are performed, the /proc/device-tree changes.  
kexec-tools use the contents of  /proc/device-tree and pass some of the 
information in it to the second kernel while loading the kdump ( second 
) kernel.  If kdump kernel was loaded in to memory before the dlpar 
operations, then it's likely that the second kernel will lose the 
information about the changes in the device tree. Hence restarting kdump 
service on every dlpar operations will help kdump kernel become aware of 
the changes in the /proc/device-tree.  Following were two lines that may 
do this job. I tested them and they were working. Pls let me know your 
thoughts on them.

SUBSYSTEM=="cpu", PROGRAM="/etc/init.d/kdump restart"
SUBSYSTEM=="memory", PROGRAM="/etc/init.d/kdump restart"

Thanks,
Chandru

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Greg KH | 2 May 2008 00:00
Gravatar

Re: udev rules for kdump

On Thu, May 01, 2008 at 04:58:31PM +0530, Chandru wrote:
> Hi,
>
> On a powerpc box  when memory or cpu DLPAR operations (memory,cpu  
> addition/deletion) are performed, the /proc/device-tree changes.  
> kexec-tools use the contents of  /proc/device-tree and pass some of the 
> information in it to the second kernel while loading the kdump ( second ) 
> kernel.  If kdump kernel was loaded in to memory before the dlpar 
> operations, then it's likely that the second kernel will lose the 
> information about the changes in the device tree. Hence restarting kdump 
> service on every dlpar operations will help kdump kernel become aware of 
> the changes in the /proc/device-tree.  Following were two lines that may do 
> this job. I tested them and they were working. Pls let me know your 
> thoughts on them.
>
> SUBSYSTEM=="cpu", PROGRAM="/etc/init.d/kdump restart"
> SUBSYSTEM=="memory", PROGRAM="/etc/init.d/kdump restart"

So anytime udev sees these subsystems, you want to run the kdump
service?  I really don't think you mean it this way :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 3 comments |
headers
John Huttley | 2 May 2008 04:45
Picon

[PATCH] Fixed persistent-tape.rules


The existing rules from udev-120

has this line, (unwrapped)

KERNEL=="nst[0-9]", SUBSYSTEMS=="scsi", IMPORT{program}="scsi_id 
--export --whitelisted --fallback-to-sysfs -s %p -d $tempnode", 
SYMLINK+="tape/by-id/$env{ID_BUS}-$env{ID_SERIAL}-nst"

It looks ok, except when scsi_id fails, when it then creates a null 
link. (yes, that _is_ happening to me, which is why i got looking at this)

It has this line.

KERNEL=="st[0-9]*", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id 
--export --whitelisted --fallback-to-sysfs -s %p -d $tempnode"

Which won't create a null link, but   st[0-9]*  matches  st0, st0a, 
st0l, st0m.  All but the first are irrelevant so we are doing 4 times 
the work required.

The correct match is  st[0-9]   for the first 10 tape drives and
st[0-9][0-9]  for the remaining 90. (!!)

A fixed file is attached.

Regards,

John
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sagar Borikar | 2 May 2008 08:21

udev exits with bus error

Folks, 

I am facing a sort of strange error with udev 101 as well as udev 120.
I am currently working on NAS system developed in 2.6.18 kernel with
mips processor. One of the test case 
We have observed that udev 101 gives BUS error sometimes during startup
of the udev. When checked the state of the system, none of the device
nodes were present unde /dev filesystem. Before starting udevd, devfs
was mounted properly but as the udevd started, the devfs becomes empty.
Unfortunately the system behaves in this manner once in 100 reboots. The
reproducibilty of this bug is 1% .  Enabled the core dump but was in
vein.
            When tried to integrate udev 120, I observed segmentation
fault occuring infrequently. so I am bit confused.

Any pointers?

Thanks in advance
Sagar
end
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Chandru | 2 May 2008 15:13
Picon

Re: udev rules for kdump

Greg KH wrote:
> On Thu, May 01, 2008 at 04:58:31PM +0530, Chandru wrote:
>   
>> Hi,
>>
>> On a powerpc box  when memory or cpu DLPAR operations (memory,cpu  
>> addition/deletion) are performed, the /proc/device-tree changes.  
>> kexec-tools use the contents of  /proc/device-tree and pass some of the 
>> information in it to the second kernel while loading the kdump ( second ) 
>> kernel.  If kdump kernel was loaded in to memory before the dlpar 
>> operations, then it's likely that the second kernel will lose the 
>> information about the changes in the device tree. Hence restarting kdump 
>> service on every dlpar operations will help kdump kernel become aware of 
>> the changes in the /proc/device-tree.  Following were two lines that may do 
>> this job. I tested them and they were working. Pls let me know your 
>> thoughts on them.
>>
>> SUBSYSTEM=="cpu", PROGRAM="/etc/init.d/kdump restart"
>> SUBSYSTEM=="memory", PROGRAM="/etc/init.d/kdump restart"
>>     
>
> So anytime udev sees these subsystems, you want to run the kdump
> service?  I really don't think you mean it this way :)
>
> thanks,
>
> greg k-h
>   
Thanks for replying.  I added the action key to the rules now.  I 
initially had tested with this key too, but left it out assuming uevents
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg KH | 2 May 2008 17:32
Gravatar

Re: udev rules for kdump

On Fri, May 02, 2008 at 06:43:21PM +0530, Chandru wrote:
> Greg KH wrote:
>> On Thu, May 01, 2008 at 04:58:31PM +0530, Chandru wrote:
>>   
>>> Hi,
>>>
>>> On a powerpc box  when memory or cpu DLPAR operations (memory,cpu  
>>> addition/deletion) are performed, the /proc/device-tree changes.  
>>> kexec-tools use the contents of  /proc/device-tree and pass some of the 
>>> information in it to the second kernel while loading the kdump ( second ) 
>>> kernel.  If kdump kernel was loaded in to memory before the dlpar 
>>> operations, then it's likely that the second kernel will lose the 
>>> information about the changes in the device tree. Hence restarting kdump 
>>> service on every dlpar operations will help kdump kernel become aware of 
>>> the changes in the /proc/device-tree.  Following were two lines that may 
>>> do this job. I tested them and they were working. Pls let me know your 
>>> thoughts on them.
>>>
>>> SUBSYSTEM=="cpu", PROGRAM="/etc/init.d/kdump restart"
>>> SUBSYSTEM=="memory", PROGRAM="/etc/init.d/kdump restart"
>>>     
>>
>> So anytime udev sees these subsystems, you want to run the kdump
>> service?  I really don't think you mean it this way :)
>>
>> thanks,
>>
>> greg k-h
>>   
> Thanks for replying.  I added the action key to the rules now.  I initially
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kay Sievers | 2 May 2008 17:54

Re: [PATCH] Fixed persistent-tape.rules

On Fri, May 2, 2008 at 4:45 AM, John Huttley <John <at> mib-infotech.co.nz> wrote:
>
>  The existing rules from udev-120
>
>  has this line, (unwrapped)
>
>  KERNEL=="nst[0-9]", SUBSYSTEMS=="scsi", IMPORT{program}="scsi_id --export
> --whitelisted --fallback-to-sysfs -s %p -d $tempnode",
> SYMLINK+="tape/by-id/$env{ID_BUS}-$env{ID_SERIAL}-nst"
>
>
>  It looks ok, except when scsi_id fails, when it then creates a null link.
> (yes, that _is_ happening to me, which is why i got looking at this)
>
>
>
>  It has this line.
>
>  KERNEL=="st[0-9]*", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --export
> --whitelisted --fallback-to-sysfs -s %p -d $tempnode"
>
>  Which won't create a null link, but   st[0-9]*  matches  st0, st0a, st0l,
> st0m.  All but the first are irrelevant so we are doing 4 times the work
> required.
>
>
>  The correct match is  st[0-9]   for the first 10 tape drives and
>  st[0-9][0-9]  for the remaining 90. (!!)

How about st*[0-9] then?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brian Cardarella | 2 May 2008 19:01
Picon
Gravatar

Udev help

I'm sorry if this is the incorrect list to send this to but this was
the only udev related list I could find.

Anyway, I'm having an issue with Udev running a script.

I'm using Ubuntu 8.04 and am creating a rule for hotplugging a
Franklin Wireless CDU-680 usb modem.

I have the rule file number set for 99 and have the option 'last_rule'
being appended to the OPTIONS variable. It also runs a bash script I
wrote.

The issue is that my script changes the mode of the device, from
storage device to modem. However, if I run it as a script from the
rule there are usb reset issues, I believe because the device is not
fully mounted or initialized on the system. So I put a sleep command
into the script to have it wait a few more seconds, but all this does
is seem to extend the waiting time for the initialization of the
device.

So instead I replaced the sleep command with an until loop that
continuously looked to see if the file (/dev/sdb) was available yet.
This just puts the script into an infinite loop, so it seems that the
the device does not mount until the script completes or is it all of
the rules are complete?

Is there a way to postpone the start of my script until after the
device is completely available?

Thanks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Huttley | 2 May 2008 22:28
Picon

Re: [PATCH] Fixed persistent-tape.rules

Hey I didn't think of that! I guess because all the others I've seen had 
the * on the end.

If we make it scsi_tape will we still catch USB connected tape drives?

Regards,

John

Kay Sievers wrote:

> 
> How about st*[0-9] then?
> We may want to add SUBSYSTEM=="scsi_tape" too, so it will not catch
> any other devices.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Matthew Dharm | 2 May 2008 22:36

Re: [PATCH] Fixed persistent-tape.rules

On Sat, May 03, 2008 at 08:28:52AM +1200, John Huttley wrote:
> Hey I didn't think of that! I guess because all the others I've seen had 
> the * on the end.
> 
> 
> If we make it scsi_tape will we still catch USB connected tape drives?

Yes, you will.  The usb-storage driver is basically a connector between a
USB device and SCSI core.  So, scsi tape drives are driven by st_mod.

Matt

--

-- 
Matthew Dharm                              Home: mdharm-usb <at> one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

It was a new hope.
					-- Dust Puppy
User Friendly, 12/25/1998
Permalink | Reply | 0 comments |

Gmane