2:50 p.m.
----- "Dave Anderson" <anderson(a)redhat.com> wrote:
----- "Bob Montgomery" <bob.montgomery(a)hp.com>
wrote:
> On Fri, 2009-06-05 at 14:53 +0000, Dave Anderson wrote:
>
> >
> > I've attached what I'm going with. I've added the capability of
getting
> > the file_operations from the cdev_map when necessary. The block device
> > code was also suffering from bit-rot as well, and so I put in a new
> > collector function that uses the bdev_map as well.
>
> Dave, this looks good. Two issues:
>
> 1) Add "-f" to dev help? (What does it mean to still be a
"(none)" device?)
It means that a pointer to a file_operations either doesn't exist
(or that I have no clue how to find it...) For the hell of it I
added that -f flag to show those devices in case somebody's
interested.
>
> 2) The old code found the block extended device number (a feature added
> to the kernel by a 25 Aug 2008 patch from Tejun Heo):
>
> 259 blkext (unknown)
>
> Also shown in /proc/devices:
> ...
> Block devices:
> 1 ramdisk
> 259 blkext
> 7 loop
> 11 sr
> 104 cciss0
>
> Deliberate omission?
I did see that, and I forget now how the old code found it (although the
function still exists), but the structures being used now are bdev_map.probes[]
and major_names[]:
crash> whatis struct kobj_map
struct kobj_map {
struct probe *probes[255];
struct mutex *lock;
}
SIZE: 2048
crash> whatis major_names
struct blk_major_name *major_names[255];
crash>
where the kernel's kobj_map.probes[] array size is just hardwired to 255,
and the major_names[] array size is BLKDEV_MAJOR_HASH_SIZE which is 255.
So obviously 259 won't be found.
Correction -- it does appear in the major_names[] array, in a 2.6.30
kernel for example, like this:
crash> p * major_names[4]
$51 = {
next = 0x0,
major = 259,
name = "blkext\000\000\000\000\000\000\000\000\000"
}
where it appears to be the only major_names[] entry whose "major" value
doesn't equal the index into the array (i.e., 259 != 4). But the
bdev_map.probes[4] entry is unused.
Dave
If you want to figure out how to show it, send me a patch.
At this point I'm about ready to deprecate the whole command... ;-)
Dave
>
> Thanks for cleaning this up,
> Bob Montgomery
3:14 p.m.
New subject: dev command deteriorates with new kernels
On Mon, 2009-06-08 at 19:50 +0000, Dave Anderson wrote:
Regarding blkext 259
Correction -- it does appear in the major_names[] array, in a 2.6.30
kernel for example, like this:
crash> p * major_names[4]
$51 = {
next = 0x0,
major = 259,
name = "blkext\000\000\000\000\000\000\000\000\000"
}
where it appears to be the only major_names[] entry whose "major" value
doesn't equal the index into the array (i.e., 259 != 4). But the
bdev_map.probes[4] entry is unused.
The blkext is supposed to get used as soon as someone wants to put more
than 15 partitions on an sd disk. (Explanation at
http://thread.gmane.org/gmane.linux.kernel/701825)
Then the upper partitions will appear as minors of 259. When that
starts happening more, having a way to see it might (*might*) be
interesting.
> At this point I'm about ready to deprecate the whole
command... ;-)
And at this point I couldn't really argue much :-) I obviously hadn't
used the command for a while. I was casting around, hoping it would
maybe help me find the diskstats stuff for the block devices. I was
trying to answer a question like "How much disk activity was going on
before this crashed?"
When I tried the dev command and it bombed at the chrdev stuff before
getting to the blkdev stuff, I was motivated to get it going enough to
see if it would help answer my question, but it doesn't print anything
(like hd_struct pointers) that could help me with my problem. But I
figured someone had once wanted that device info, so it might as well
work...
Bob Montgomery
3:37 p.m.
New subject: dev command deteriorates with new kernels
----- "Bob Montgomery" <bob.montgomery(a)hp.com> wrote:
When I tried the dev command and it bombed at the chrdev stuff
before
getting to the blkdev stuff, I was motivated to get it going enough to
see if it would help answer my question, but it doesn't print anything
(like hd_struct pointers) that could help me with my problem. But I
figured someone had once wanted that device info, so it might as well
work...
Re: your quest to find an hd_struct, perhaps the command could be made a
bit more useful in that respect as well.
For character devices, the cdev_map.probes[255] probe structure's
"data" field points to a cdev structure, where the file_operations
pointer is found.
For block devices, the bdev_map.probes[255] probe structure's
"data" field points to a gendisk structure, where the file_operations
pointer is found. But the gendisk structure also has an embedded
hd_struct, which is presumably what you were looking for?
If that's the case, then maybe the command should display the address
of the cdev or gendisk structures associated with the device?
Dave
4:47 p.m.
New subject: dev command deteriorates with new kernels
On Mon, 2009-06-08 at 20:37 +0000, Dave Anderson wrote:
----- "Bob Montgomery" <bob.montgomery(a)hp.com>
wrote:
> When I tried the dev command and it bombed at the chrdev stuff before
> getting to the blkdev stuff, I was motivated to get it going enough to
> see if it would help answer my question, but it doesn't print anything
> (like hd_struct pointers) that could help me with my problem. But I
> figured someone had once wanted that device info, so it might as well
> work...
Re: your quest to find an hd_struct, perhaps the command could be made a
bit more useful in that respect as well.
For character devices, the cdev_map.probes[255] probe structure's
"data" field points to a cdev structure, where the file_operations
pointer is found.
For block devices, the bdev_map.probes[255] probe structure's
"data" field points to a gendisk structure, where the file_operations
pointer is found. But the gendisk structure also has an embedded
hd_struct, which is presumably what you were looking for?
If that's the case, then maybe the command should display the address
of the cdev or gendisk structures associated with the device?
Dave
That would certainly make the command a lot more useful for digging
around. I ended up using "list -o 0xa0 -H all_bdevs -s block_device"
and pulling the (struct hd_struct *)bd_part field out of all the struct
block_device's in the list. By doing that I eventually found 3
hd_structs for partition 0, 1, and 5 of the disk of interest. The
gendisk struct for the disk would give me the part0 hd_struct and the
part_tbl pointer should get me to all the others. That would be a lot
easier.
Thanks,
Bob Montgomery
5500
days inactive
5500
days old
devel@lists.crash-utility.osci.io
3 comments
2 participants
participants (2)
-
Bob Montgomery -
Dave Anderson