kernel space: finding cpu usage of individual process/thread
Hi, For one of my requirements I need to find cpu usage or load_avg of an individual process or thread using "for_each_process_thread(process, thread)" where process/thread is a pointer to "task_struct". But, currently I am not able to figure out which is the right field from task_struct to get this value, or how to manipulate it. I see some fields there but I'm not sure if these values are correct. a) sched_entity -> sched_avg -> load/load_avg/load_sum/util_avg/etc. b) stime + utime : What time I get from here ? c) prev_cputime d) vtime e) acct_timexpd f) ??? It will be good if I can get some references in kernel space. When I use (a) above (load_avg) I get this value: pid=2 , comm=kthread, load=51 pid=96, comm=cat , load=1024 etc... When I use (stime + utime) I get: pid=2 , comm=kthread, load=3978848 pid=96, comm=cat , load=11786176 So, not sure which one is correct ? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: dm-verity: How to exactly use the dm-mod.create with verity-metadata append
On Tue, 23 Nov 2021 at 22:13, Will Drewry wrote: > > On Tue, Nov 23, 2021 at 4:36 AM Pintu Agarwal wrote: > > > > Hi, > > > > For rootfs dm-verity I am trying to pass dm-mod.create from our > > bootloader but it seems not working for me. > > So, I need some guidance on the parameters that we pass here. > > The documentation also does not seem to help much. > > > > Kernel: 4.14 (with dm-init patch backported) > > Target: Arm-32 / NAND / Simple Busybox / Bootloader (edk2) > > Build: Ubuntu-18.04 / Yocto 2.6 > > > > Steps I followed: > > 1) First I am trying to generate the root hash for our rootfs using > > the veritysetup command: > > $ ls -l system.img > > 64172032 ==> IMAGE_SIZE > > $ veritysetup format system.img dm-init-verity.img > > UUID: eca62b73-b66a-4249-834b-471e83fc382c > > Hash type: 1 > > Data blocks:15667 > > Data block size:4096 > > Hash block size:4096 > > Hash algorithm: sha256 > > Salt: > > 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b > > Root hash: > > 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af > > > > 2) Then I am trying to append the verity with the system image itself: > > $ cat dm-init-verity.img >> system.img > > > > 3) After that I am trying to pass dm-mod.create parameter like this: > > dm-mod.create=\"system,,,ro, 0 IMAGE_SIZE/512 verity 1 > > /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 DATA_BLOCKS 1 sha256 > > 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af > > 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b\" > > > > 4) The Kernel command line seems to be updated properly: > > [0.00] Kernel command line:.. rootfstype=squashfs > > ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/ubiblock0_0 > > dm-mod.create="system,,,ro, 0 125336 verity 1 /dev/ubiblock0_0 > > /dev/ubiblock0_0 4096 4096 15667 1 sha256 > > 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af > > 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b" > > > > But it does not seem to work as expected. > > It gives below errors: > > > > [4.747708] block ubiblock0_0: created from ubi0:0(system) > > [4.752313] device-mapper: init: waiting for all devices to be > > available before creating mapped devices > > [4.752313] > > [4.766061] device-mapper: verity: sha256 using implementation > > "sha256-generic" > > [4.776178] device-mapper: ioctl: dm-0 (system) is ready > > [4.848886] md: Skipping autodetection of RAID arrays. > > (raid=autodetect will force) > > [4.849288] VFS: Cannot open root device "ubiblock0_0" or > > unknown-block(252,0): error -16 > > I'd start with changing your root device to point to the device mapper > one you've just created. E.g., root=/dev/dm-0 Then see how it goes > from there. Yes I tried this already but it seems the problem was something else. > > > > I followed almost the same example from dm-init document: > > "verity": > > dm-verity,,4,ro, > > 0 1638400 verity 1 8:1 8:2 4096 4096 204800 1 sha256 > > fb1a5a0f00deb908d8b53cb270858975e76cf64105d412ce764225d53b8f3cfd > > 51934789604d1b92399c52e7cb149d1b3a1b74bbbcb103b2a0aaacbed5c08584 > > > > But this seems only refer to system and verity on a different blocks. > > I am not sure what parameter should be changed if my verity metadata > > is part of system image itself. > > Also, I don't know how 1638400;204800;1 is calculated here based on image > > size ? > > It's the range of sectors covered by the device 0 to size_in_sectors: > (data_blocks * block_size)/sector_size > (15667 * 4096)/512 > 125336 > which you have in your entry already. > Now I made it working using both dmsetup first and then using dm-mod.create with the same parameters. There is slightly a different step when appending metadata to the system image itself. First, we need to adjust the hash offset for metadata location. Then we need to specify the offset in terms of number of blocks. This is still fine. But the problem is to specify the hash_start which is (number of blocks + 1). So, I used like this: veritysetup format --hash-offset= system.img system.img (The metadata will be appended automatically at the end of system.img) This will give the data blocks as well. dm-mod.create=\"system,,,ro, 0 125336 verity 1 /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 15667 15668 sha256 39438d7915f2af8532752d78ce0cc08dc9d23b9e7176518310bc65de5c226c7d 56413cf91ccc9e32ec5b2d36b54e61114ab92a345d8547a194fc86ff4437896c\" So, this worked for me. Thank you so much! Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
dm-verity: How to exactly use the dm-mod.create with verity-metadata append
Hi, For rootfs dm-verity I am trying to pass dm-mod.create from our bootloader but it seems not working for me. So, I need some guidance on the parameters that we pass here. The documentation also does not seem to help much. Kernel: 4.14 (with dm-init patch backported) Target: Arm-32 / NAND / Simple Busybox / Bootloader (edk2) Build: Ubuntu-18.04 / Yocto 2.6 Steps I followed: 1) First I am trying to generate the root hash for our rootfs using the veritysetup command: $ ls -l system.img 64172032 ==> IMAGE_SIZE $ veritysetup format system.img dm-init-verity.img UUID: eca62b73-b66a-4249-834b-471e83fc382c Hash type: 1 Data blocks:15667 Data block size:4096 Hash block size:4096 Hash algorithm: sha256 Salt: 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b Root hash: 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af 2) Then I am trying to append the verity with the system image itself: $ cat dm-init-verity.img >> system.img 3) After that I am trying to pass dm-mod.create parameter like this: dm-mod.create=\"system,,,ro, 0 IMAGE_SIZE/512 verity 1 /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 DATA_BLOCKS 1 sha256 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b\" 4) The Kernel command line seems to be updated properly: [0.00] Kernel command line:.. rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/ubiblock0_0 dm-mod.create="system,,,ro, 0 125336 verity 1 /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 15667 1 sha256 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b" But it does not seem to work as expected. It gives below errors: [4.747708] block ubiblock0_0: created from ubi0:0(system) [4.752313] device-mapper: init: waiting for all devices to be available before creating mapped devices [4.752313] [4.766061] device-mapper: verity: sha256 using implementation "sha256-generic" [4.776178] device-mapper: ioctl: dm-0 (system) is ready [4.848886] md: Skipping autodetection of RAID arrays. (raid=autodetect will force) [4.849288] VFS: Cannot open root device "ubiblock0_0" or unknown-block(252,0): error -16 I followed almost the same example from dm-init document: "verity": dm-verity,,4,ro, 0 1638400 verity 1 8:1 8:2 4096 4096 204800 1 sha256 fb1a5a0f00deb908d8b53cb270858975e76cf64105d412ce764225d53b8f3cfd 51934789604d1b92399c52e7cb149d1b3a1b74bbbcb103b2a0aaacbed5c08584 But this seems only refer to system and verity on a different blocks. I am not sure what parameter should be changed if my verity metadata is part of system image itself. Also, I don't know how 1638400;204800;1 is calculated here based on image size ? So, people who have made this working successfully, please share the correct parameter to be used for the same block device. Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MTD: How to get actual image size from MTD partition
Hi,
On Fri, 29 Oct 2021 at 22:18, Ezequiel Garcia
wrote:
>
> On Fri, 29 Oct 2021 at 13:13, Pintu Agarwal wrote:
> >
> > Hi All,
> >
> > On Mon, 30 Aug 2021 at 21:28, Pintu Agarwal wrote:
> > >
> > > On Sun, 22 Aug 2021 at 19:51, Ezequiel Garcia
> > > wrote:
> > >
> > > > In other words, IMO it's best to expose the NAND through UBI
> > > > for both read-only and read-write access, using a single UBI device,
> > > > and then creating UBI volumes as needed. This will allow UBI
> > > > to spread wear leveling across the whole device, which is expected
> > > > to increase the flash lifetime.
> > > >
> > > > For instance, just as some silly example, you could have something like
> > > > this:
> > > >
> > > >| RootFS SquashFS |
> > > >| UBI block| UBIFS User R-W area
> > > >
> > > > Kernel A | Kernel B | RootFS A | RootFS B | User
> > > >
> > > > UBIX
> > > >
> > > > /dev/mtdX
> > > >
> > > > This setup allows safe kernel and rootfs upgrading. The RootFS is
> > > > read-only
> > > > via SquashFS and there's a read-write user area. UBI is supporting all
> > > > the volumes, handling bad blocks and wear leveling.
> > > >
> > > Dear Ezequiel,
> > > Thank you so much for your reply.
> > >
> > > This is exactly what we are also doing :)
> > > In our system we have a mix of raw and ubi partitions.
> > > The ubi partitioning is done almost exactly the same way.
> > > Only for the rootfs (squashfs) I see we were using /mtd/block to
> > > mount the rootfs.
> > > Now, I understood we should change it to use /dev/ubiblock
> > > This might have several benefits, but one most important could be,
> > > using ubiblock can handle bad-blocks/wear-leveling automatically,
> > > whereas mtdblocks access the flash directly ?
> > > I found some references for these..
> > > So, this seems good for my proposal.
> > >
> > > Another thing that is still open for us is:
> > > How do we calculate the exact image size from a raw mtd partition ?
> > > For example, support for one of the raw nand partitions, the size is
> > > defined as 15MB but we flash the actual image of size only 2.5MB.
> > > So, in the runtime how to determine the image size as ~2.5MB (at least
> > > roughly) ?
> > > Is it still possible ?
> > >
> >
> > I am happy to inform you that using "ubiblock" for squashfs mounting
> > seems very helpful for us.
> > We have seen almost the double performance boost when using ubiblock
> > for rootfs as well as other read-only volume mounting.
> >
> > However, we have found few issues while defining the read only volume as
> > STATIC.
> > With static volume we see that OTA update is failing during "fsync".
> > That is ota_fsync is failing from here:
> > https://gerrit.pixelexperience.org/plugins/gitiles/bootable_recovery/+/ff6df890a2a01bf3bf56d3f430b17a5ef69055cf%5E%21/otafault/ota_io.cpp
> > int status = fsync(fd);
> > if (status == -1 && errno == EIO)
> > *
> > { have_eio_error = true; }
> > *
> > return status;
> > }
> >
> > Is this the known issue with static volume?
> >
>
> I don't know exactly how you are updating your volume,
> the right way is using UBI_IOCVOLUP.
>
> See http://www.linux-mtd.infradead.org/doc/ubi.html#L_volupdate
>
> If you google around I'm sure you'll find some articles about this,
> but I'm not sure if they'll go into details and subtleties.
>
> There are probably a few different ways to do firmware upgrade
> when you are on top of static volumes (and you want to be on top
> of static volumes if it's read-only, because AFAIK they give you an
> extra data-integrity guarantee).
>
> One way, would be to have two static volumes A/B. The system
> uses normally the A volume, and then you doUBI_IOCVOLUP
> (or ubiupdatevol) to update the B volume. After the update is succesful
> you run the atomic volume rename and flip A->B, B->A.
>
> (If you don't have enough space to hold two A/B volumes
> ... you'll have to find some other solution, I have no idea about that.)
>
Yes, this is what we are also doing exactly.
But, currently we are running into this issue right now:
1) The FOTA update is failing if we use static volume (building and
flashing the static image is fine)
It works fine, if we use the volume as dynamic (even for RO type
with squashfs)
But with dynamic type we end up using the entire volume as image size.
So, we wanted to know if there is any other way to get volume image
size at runtime ?
Thanks,
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MTD: How to get actual image size from MTD partition
Hi All,
On Mon, 30 Aug 2021 at 21:28, Pintu Agarwal wrote:
>
> On Sun, 22 Aug 2021 at 19:51, Ezequiel Garcia
> wrote:
>
> > In other words, IMO it's best to expose the NAND through UBI
> > for both read-only and read-write access, using a single UBI device,
> > and then creating UBI volumes as needed. This will allow UBI
> > to spread wear leveling across the whole device, which is expected
> > to increase the flash lifetime.
> >
> > For instance, just as some silly example, you could have something like
> > this:
> >
> >| RootFS SquashFS |
> >| UBI block| UBIFS User R-W area
> >
> > Kernel A | Kernel B | RootFS A | RootFS B | User
> >
> > UBIX
> >
> > /dev/mtdX
> >
> > This setup allows safe kernel and rootfs upgrading. The RootFS is read-only
> > via SquashFS and there's a read-write user area. UBI is supporting all
> > the volumes, handling bad blocks and wear leveling.
> >
> Dear Ezequiel,
> Thank you so much for your reply.
>
> This is exactly what we are also doing :)
> In our system we have a mix of raw and ubi partitions.
> The ubi partitioning is done almost exactly the same way.
> Only for the rootfs (squashfs) I see we were using /mtd/block to
> mount the rootfs.
> Now, I understood we should change it to use /dev/ubiblock
> This might have several benefits, but one most important could be,
> using ubiblock can handle bad-blocks/wear-leveling automatically,
> whereas mtdblocks access the flash directly ?
> I found some references for these..
> So, this seems good for my proposal.
>
> Another thing that is still open for us is:
> How do we calculate the exact image size from a raw mtd partition ?
> For example, support for one of the raw nand partitions, the size is
> defined as 15MB but we flash the actual image of size only 2.5MB.
> So, in the runtime how to determine the image size as ~2.5MB (at least
> roughly) ?
> Is it still possible ?
>
I am happy to inform you that using "ubiblock" for squashfs mounting
seems very helpful for us.
We have seen almost the double performance boost when using ubiblock
for rootfs as well as other read-only volume mounting.
However, we have found few issues while defining the read only volume as STATIC.
With static volume we see that OTA update is failing during "fsync".
That is ota_fsync is failing from here:
https://gerrit.pixelexperience.org/plugins/gitiles/bootable_recovery/+/ff6df890a2a01bf3bf56d3f430b17a5ef69055cf%5E%21/otafault/ota_io.cpp
int status = fsync(fd);
if (status == -1 && errno == EIO)
*
{ have_eio_error = true; }
*
return status;
}
Is this the known issue with static volume?
For now we are using dynamic volume itself but the problem is that
with dynamic volume we cannot get the exact image size from:
$ cat /sys/class/ubi/ubi0_0/data_bytes
==> In case of dynamic volume this will return the total volume size.
==> Thus our md5 integrity check does not match exactly with the
flashed image size.
Is there an alternate way to handle this issue ?
Thanks,
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
Hi All, On Wed, 8 Sept 2021 at 17:38, Greg KH wrote: > > > > > No, but you can backport it easily. Back at > > > > > http://lists.infradead.org/pipermail/openwrt-devel/2019-November/025967.html > > > > > I provided backports of this feature to OpenWrt, for the 4.14 and 4.19 > > > > > kernels. > > > > Can you please let me know where to get the below patches for > > backporting to our kernel: > > create mode 100644 > > target/linux/generic/backport-4.14/390-dm-add-support-to-directly-boot-to-a-mapped-device.patch > > create mode 100644 > > target/linux/generic/backport-4.14/391-dm-init-fix-max-devices-targets-checks.patch > > create mode 100644 > > target/linux/generic/backport-4.14/392-dm-ioctl-fix-hang-in-early-create-error-condition.patch > > create mode 100644 > > target/linux/generic/backport-4.14/393-Documentation-dm-init-fix-multi-device-example.patch > > If you are stuck on an older kernel version, then you need to get > support from the vendor that is forcing you to be on that kernel > version, as you are already paying them for support. Please take > advantage of that, as no one knows what is really in "your kernel". > This is to update this thread that now I am able to successfully bring-up dm-verity with NAND+ubiblock+squashfs on our 4.14 kernel itself without backporting the patches. Now, I am able to boot dm-verity using both initramfs and bootloader approach. The initramfs booting issue was our internal issue which was related to Kernel size configuration in UEFI. The bootloader approach issue was related to system image size issue, where we need to pass the exact image size to find the verity-metadata offset at the end of system image. However, I felt that dm-verity documentation still needs to be enhanced further with a better example. With the 5.4 Kernel, I may further explore the option of using dm-mod.create option, then I might get more clarity on how best to use it. Thank you all for your help and support! Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
Hi, On Mon, 6 Sept 2021 at 21:58, Pintu Agarwal wrote: > On Tue, 31 Aug 2021 at 18:49, Pintu Agarwal wrote: > > > > No, but you can backport it easily. Back at > > > http://lists.infradead.org/pipermail/openwrt-devel/2019-November/025967.html > > > I provided backports of this feature to OpenWrt, for the 4.14 and 4.19 > > > kernels. Can you please let me know where to get the below patches for backporting to our kernel: create mode 100644 target/linux/generic/backport-4.14/390-dm-add-support-to-directly-boot-to-a-mapped-device.patch create mode 100644 target/linux/generic/backport-4.14/391-dm-init-fix-max-devices-targets-checks.patch create mode 100644 target/linux/generic/backport-4.14/392-dm-ioctl-fix-hang-in-early-create-error-condition.patch create mode 100644 target/linux/generic/backport-4.14/393-Documentation-dm-init-fix-multi-device-example.patch ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
Dear Thomas, Mikulas, Need your help in root causing my dm-verity issue with squashfs. Please see my comments inline. On Tue, 31 Aug 2021 at 18:49, Pintu Agarwal wrote: > > No, but you can backport it easily. Back at > > http://lists.infradead.org/pipermail/openwrt-devel/2019-November/025967.html > > I provided backports of this feature to OpenWrt, for the 4.14 and 4.19 > > kernels. > > > Yes, I can backport it to our 4.14 Kernel. > Can you share the list of patches to be backported to make it work on 4.14 ? > If it's backported also I need to report to our internal kernel, but > it might be slightly easier. > Please share the details. > I am interested to backport dm-mod.create related patches to our 4.14 kernel. Please let me know where can I find all the patches ? Is it already part of mainline 4.14 ? Please share the list of commits (from mainline) that we need to pull and backport. > > > Here is our kernel command line: > > > > > > [0.00] Kernel command line: ro rootwait > > > console=ttyMSM0,115200,n8 verity="95384 11923 > > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 12026 > > > " rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0 > > > init=/sbin/init root=/dev/dm-0 dm="rootfs none ro,0 95384 verity > > > 1 /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256 > > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 > > > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10 > > > restart_on_corruption ignore_zero_blocks use_fec_from_device > > > /dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026" ... > > > > I don't see how this can work without the dm-mod.create feature. Are > > you sure the verity= and dm= kernel arguments exist? > I checked a little further and yes there is "dm=" command line in kernel available. This is already working with ext4 glue, but was never tried with squashfs. I think it is mainline derived from Android. https://patchwork.kernel.org/project/dm-devel/patch/2c01b2a43a46fab760208d7af3a7af37eec8c41a.1537936397.git.helen.ko...@collabora.com/ https://github.com/projectceladon/device-androidia-kernel/blob/master/init/do_mounts_dm.c Mostly, this is the main repo where our source might be derived: https://github.com/android-linux-stable/msm-4.14 Can we backport the patches here ? If I get the list I can try it. > > Also, you mentioned: > >>> Here, it definitely worked to append the hash tree to the squashfs > >>> image and store them in the same partition. > Can you share some details about it ? > How it can be done since squashfs is readonly. Can you share your reference, how are you appending the hash tree ? Let me try the same. But it seems like the underlying concept is the same for both "dm-mod.create" and "dm=". However, I am not sure if there are any changes required for squashfs as block device.. Errors: Currently, we are getting this in boot logs: [4.962188] device-mapper: init: attempting early device configuration. [4.969699] device-mapper: init: created device '253:0' [4.975503] device-mapper: init: adding target '0 95384 verity 1 /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256 8fc2e4bb751f4b3145a486a0f4f1b58149ba3eedc2a67312f31fbee131380dab aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10 restart_on_corruption ignore_zero_blocks use_fec_from_device /dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026' [4.992323] device-mapper: verity: sha256 using implementation "sha256-generic" [5.015568] device-mapper: init: dm-0 is ready [ 10.080065] prepare_namespace: dm_run_setup - done [ 10.080093] prepare_namespace: saved_root_name: /dev/dm-0 [ 10.083903] prepare_namespace: Inside: name_to_dev_t [ 10.089605] prepare_namespace: Calling - mount_root() ... [ 10.094519] [PINTU]: mount_block_root: called with input name: /dev/root, fs_names: squashfs [ 10.263510] [PINTU]: do_mount_root: sys_mount failed: err: -22 [ 10.263544] [PINTU]: mount_block_root: do_mount_root: err: -22, p: squashfs, flags: 32769, root_mount_data: (null) [..] [ 10.745672] No filesystem could mount root, tried: [ 10.745676] squashfs [ 10.748015] [ 10.755232] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(253,0) It seems the rootfs could not mount due to invalid arguments. Not sure which arguments are invalid here... Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
Hi,
On Tue, 31 Aug 2021 at 00:42, Thomas Petazzoni
wrote:
>
> Hello,
>
> On Mon, 30 Aug 2021 23:48:40 +0530
> Pintu Agarwal wrote:
>
> > ohh that means we already have a working reference.
> > If possible can you share the details, even 4.19 or higher will be
> > also a good reference.
> >
> > > > Or, another option is to use the new concept from 5.1 kernel that is:
> > > > dm-mod.create = ?
> > > How are you doing it today without dm-mod.create ?
> > I think in 4.14 we don't have dm-mod.create right ?
>
> No, but you can backport it easily. Back at
> http://lists.infradead.org/pipermail/openwrt-devel/2019-November/025967.html
> I provided backports of this feature to OpenWrt, for the 4.14 and 4.19
> kernels.
>
Yes, I can backport it to our 4.14 Kernel.
Can you share the list of patches to be backported to make it work on 4.14 ?
If it's backported also I need to report to our internal kernel, but
it might be slightly easier.
Please share the details.
> > Here is our kernel command line:
> >
> > [0.00] Kernel command line: ro rootwait
> > console=ttyMSM0,115200,n8 verity="95384 11923
> > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 12026
> > " rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0
> > init=/sbin/init root=/dev/dm-0 dm="rootfs none ro,0 95384 verity
> > 1 /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256
> > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3
> > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10
> > restart_on_corruption ignore_zero_blocks use_fec_from_device
> > /dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026" ...
>
> I don't see how this can work without the dm-mod.create feature. Are
> you sure the verity= and dm= kernel arguments exist?
Sorry, I am not a security guy and this was done by someone from the
security team.
But, I know that this is already working with ext4.
The moment we change to squashfs, it does not work.
The only difference with squashfs are:
=> verity metadata are kept on separate volume
=> The rootfstype and related stuff are different
=> verity command line related stuff are almost the same.
Also, you mentioned:
>>> Here, it definitely worked to append the hash tree to the squashfs
>>> image and store them in the same partition.
Can you share some details about it ?
How it can be done since squashfs is readonly.
Do, we need to change some parameters during squashfs image generation ?
{
$(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \
- -nopad -noappend -root-owned \
+ -noappend -root-owned \
}
Also, for the above cmdline, is there any problem with the block size ?
As @Mikulas said before that the block size could be the issue
Also, for squashfs we are passing like this for root=. Is it fine ?
rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0
I see that dm-0 is already passed elsewhere so do we really need it ?
I suspect it is not required as a block device.
Thanks,
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
On Mon, 30 Aug 2021 at 22:25, Thomas Petazzoni
wrote:
>
> Hello,
>
> On Mon, 30 Aug 2021 21:55:19 +0530
> Pintu Agarwal wrote:
>
> > Sorry for coming back to this again..
> > Unfortunately, none of the options is working for us with squashfs
> > (bootloader, initramfs).
> > initramfs have different kinds of challenges because of the partition
> > size issue.
> > So, our preferred option is still the bootloader command line approach..
> >
> > Is there a proven and working solution of dm-verity with squashfs ?
> > If yes, please share some references.
> >
> > The current problem with squashfs is that we could not append the
> > verity-metadata to squashfs, so we store it on a separate volume and
> > access it.
>
> Here, it definitely worked to append the hash tree to the squashfs
> image and store them in the same partition.
>
> > By specifying it like : /dev/mtdblock53
> >
> > Then we get the error like this:
> > {
> > [4.950276] device-mapper: init: attempting early device configuration.
> > [4.957577] device-mapper: init: adding target '0 95384 verity 1
> > /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256
> > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3
> > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10
> > restart_on_corruption ignore_zero_blocks use_fec_from_device
> > /dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026'
> > [4.975283] device-mapper: verity: sha256 using implementation
> > "sha256-generic"
> > [4.998728] device-mapper: init: dm-0 is ready
>
> Could you show the full kernel command line ?
Shared below
> > Do you see any other problem here with dm-verity cmdline or with squashfs ?
> >
> > Is squashfs ever proved to be working with dm-verity on higher kernel
> > version ?
> > Currently our kernel version is 4.14.
>
> I confirm we used squashfs on dm-verity successfully. For sure on 4.19,
> perhaps on older kernels as well.
ohh that means we already have a working reference.
If possible can you share the details, even 4.19 or higher will be
also a good reference.
> > Or, another option is to use the new concept from 5.1 kernel that is:
> > dm-mod.create = ?
> How are you doing it today without dm-mod.create ?
I think in 4.14 we don't have dm-mod.create right ?
> Again, please give your complete kernel command line.
>
Here is our kernel command line:
[0.00] Kernel command line: ro rootwait
console=ttyMSM0,115200,n8 verity="95384 11923
16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 12026
" rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0
init=/sbin/init root=/dev/dm-0 dm="rootfs none ro,0 95384 verity
1 /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256
16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3
aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10
restart_on_corruption ignore_zero_blocks use_fec_from_device
/dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026" ...
Do you see any issue here ?
Can you share your command line for squashfs to compare ?
Thank you,
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
On Wed, 21 Jul 2021 at 22:59, Pintu Agarwal wrote:
>
> On Wed, 21 Jul 2021 at 22:40, Mikulas Patocka wrote:
>
> > > >
> > > > Try to set up dm-verity with block size 512 bytes.
> > > >
> > > > I don't know what block size does squashfs use, but if the filesystem
> > > > block size is smaller than dm-verity block size, it doesn't work.
> > > >
> > > Okay thank you so much for this clue,
> > > It seems we are using 65536 as the squashfs block size:
> >
> > 65536 is the compression block size - it is unrelated to I/O block size.
> >
> > There's a config option SQUASHFS_4K_DEVBLK_SIZE. The documentation says
> > that it uses by default 1K block size and if you enable this option, it
> > uses 4K block size.
> >
> Okay it seems this config is set in our case:
> CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y
> So, with this the squashfs and dm-verity block size exactly matches (4K)
>
> > So, try to set it. Or try to reduce dm-verity block size down to 1K.
> >
Hi,
Sorry for coming back to this again..
Unfortunately, none of the options is working for us with squashfs
(bootloader, initramfs).
initramfs have different kinds of challenges because of the partition
size issue.
So, our preferred option is still the bootloader command line approach..
Is there a proven and working solution of dm-verity with squashfs ?
If yes, please share some references.
The current problem with squashfs is that we could not append the
verity-metadata to squashfs, so we store it on a separate volume and
access it.
By specifying it like : /dev/mtdblock53
Then we get the error like this:
{
[4.950276] device-mapper: init: attempting early device configuration.
[4.957577] device-mapper: init: adding target '0 95384 verity 1
/dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256
16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3
aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10
restart_on_corruption ignore_zero_blocks use_fec_from_device
/dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026'
[4.975283] device-mapper: verity: sha256 using implementation
"sha256-generic"
[4.998728] device-mapper: init: dm-0 is ready
[5.614498] 1f351736 mtdblock53
[5.614502] (driver?)
[5.621098] fc00 61504 ubiblock0_0
[5.621102] (driver?)
[5.627661] fd00 47692 dm-0
[5.627665] (driver?)
[5.633663] No filesystem could mount root, tried:
[5.633667] squashfs
[5.636009]
[5.643215] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(253,0)
}
Do you see any other problem here with dm-verity cmdline or with squashfs ?
Is squashfs ever proved to be working with dm-verity on higher kernel version ?
Currently our kernel version is 4.14.
Or, another option is to use the new concept from 5.1 kernel that is:
dm-mod.create = ?
But, currently I don't know how to use it with squashfs either...
Any reference example will be helpful..
Thanks,
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MTD: How to get actual image size from MTD partition
On Sun, 22 Aug 2021 at 19:51, Ezequiel Garcia wrote: > In other words, IMO it's best to expose the NAND through UBI > for both read-only and read-write access, using a single UBI device, > and then creating UBI volumes as needed. This will allow UBI > to spread wear leveling across the whole device, which is expected > to increase the flash lifetime. > > For instance, just as some silly example, you could have something like this: > >| RootFS SquashFS | >| UBI block| UBIFS User R-W area > > Kernel A | Kernel B | RootFS A | RootFS B | User > > UBIX > > /dev/mtdX > > This setup allows safe kernel and rootfs upgrading. The RootFS is read-only > via SquashFS and there's a read-write user area. UBI is supporting all > the volumes, handling bad blocks and wear leveling. > Dear Ezequiel, Thank you so much for your reply. This is exactly what we are also doing :) In our system we have a mix of raw and ubi partitions. The ubi partitioning is done almost exactly the same way. Only for the rootfs (squashfs) I see we were using /mtd/block to mount the rootfs. Now, I understood we should change it to use /dev/ubiblock This might have several benefits, but one most important could be, using ubiblock can handle bad-blocks/wear-leveling automatically, whereas mtdblocks access the flash directly ? I found some references for these.. So, this seems good for my proposal. Another thing that is still open for us is: How do we calculate the exact image size from a raw mtd partition ? For example, support for one of the raw nand partitions, the size is defined as 15MB but we flash the actual image of size only 2.5MB. So, in the runtime how to determine the image size as ~2.5MB (at least roughly) ? Is it still possible ? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MTD: How to get actual image size from MTD partition
On Thu, 29 Jul 2021 at 22:41, Pintu Agarwal wrote: > > On Thu, 29 Jul 2021 at 17:33, Ezequiel Garcia > wrote: > > > > On Thu, 29 Jul 2021 at 08:45, Richard Weinberger wrote: > > > > > > Ezequiel, > > > > > > - Ursprüngliche Mail - > > > > [snip] > > > > > > > > Ouch, so surprised that after all these years someone is doing > > > > squashfs/mtdblock > > > > instead of using ubiblock :-) > > > > > > > > Can we patch either Kconfig or add some warn_once on mtdblock > > > > usage, suggesting to use ubiblock instead? > > > > > > a hint in Kconfig makes IMHO sense. Do you want to send a patch? > > > A warning is too much since on some tiny embedded system with NOR flash > > > mtdblock is still > > > a good choice. > > > ubiblock is mostly useful for NAND flash. > > > > > > > I remember there was still some use case(s) for mtdblock but I can't > > > > remember > > > > now what was it, perhaps we should document the expectations? > > > > (Is that for JFFS2 to mount?) > > > > > > a long time ago mount didn't accept character devices, so you had to pass > > > mtdblockX to mount > > > JFFS2. > > > This limitation is gone. > > > Hi, Just a further follow-up on this discussion. Whether to use /dev/mtdblock or /dev/ubiblock for rootfs (squashfs) mounting during boot. As suggested here: Instead of using this in kernel command line: [0.00] Kernel command line: ... rootfstype=squashfs root=/dev/mtdblock44 ubi.mtd=40,0,30 ... I used this: [0.00] Kernel command line: ... rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/ubiblock0_0 ... The device is booting fine with ubiblock as well. But, per say, I could not find any visible difference. I just observed a slight improvement in boot time, but I need to double-check on this, with few more reboot cycles. Apart from this what are the other visible benefits of using ubiblock which can be explained to be management or internal team ? I could not find any documentation explaining the difference, except this one: http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock Can someone also point me to the respective driver code in case of using /dev/mtdblock and /dev/ubiblock ? Apart from theory I also want to check the impact at the code level.. Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MTD: How to get actual image size from MTD partition
On Thu, 29 Jul 2021 at 17:33, Ezequiel Garcia wrote: > > On Thu, 29 Jul 2021 at 08:45, Richard Weinberger wrote: > > > > Ezequiel, > > > > - Ursprüngliche Mail - > > > [snip] > > > > > > Ouch, so surprised that after all these years someone is doing > > > squashfs/mtdblock > > > instead of using ubiblock :-) > > > > > > Can we patch either Kconfig or add some warn_once on mtdblock > > > usage, suggesting to use ubiblock instead? > > > > a hint in Kconfig makes IMHO sense. Do you want to send a patch? > > A warning is too much since on some tiny embedded system with NOR flash > > mtdblock is still > > a good choice. > > ubiblock is mostly useful for NAND flash. > > > > > I remember there was still some use case(s) for mtdblock but I can't > > > remember > > > now what was it, perhaps we should document the expectations? > > > (Is that for JFFS2 to mount?) > > > > a long time ago mount didn't accept character devices, so you had to pass > > mtdblockX to mount > > JFFS2. > > This limitation is gone. > > > > OK, let me try to cook a patch for you. > Dear Eze and Richard, First of all, thank you so much for all your replies so far. Sorry, I have limited knowledge about NAND, MTD, UBI layers, but my current work involves all these so I am here. But I will surely share this information to our internal team about using ubiblock instead of mtdblock. However, I still fail to understand the problem and consequences of using mtdblock for rootfs instead of ubiblock. Last time, for my squashfs test, when I tried to replace the command line with ubiblock, I could not see any difference. How to visibly see the difference so that I can easily understand and explain the difference internally? Or, is there a document available somewhere to highlight the difference between the two? BTW, we have few raw nand partitions and few ubi volumes [including rootfs(squashfs), data(ubifs, rw)] So, I guess we should use ubiblock for all ubi volumes? Regarding Kconfig, I have few opinions. Yes, adding more description in Kconfig is a good choice. But I see that most of the time these kernel config options remains (as default) and platform developers never cares about the description. So, how to better create awareness among them, not to make these mistakes? One option is to capture these details as part of Kernel documentation. Right now when I search I could not find anything. Another option is to add a few (critical) warnings in kernel bootup logs to give some hint to the developer that there is probably something wrong. This will directly be visible to all and some developers will not like to ignore it. Or, maybe adding both options is also good. Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MTD: How to get actual image size from MTD partition
On Thu, 22 Jul 2021 at 02:24, Richard Weinberger wrote: > > - Ursprüngliche Mail - > >> But let me advertise ubiblock a second time. > > Sorry, I could not understand about the ubiblock request. Is it > > possible to elaborate little more ? > > We are already using squashfs on top of our UBI volumes (including > > rootfs mounting). > > This is the kernel command line we pass: > > rootfstype=squashfs root=/dev/mtdblock44 ubi.mtd=40,0,30 > > And CONFIG_MTD_UBI_BLOCK=y is already enabled in our kernel. > > Do we need to do something different for ubiblock ? > > From that command line I understand that you are *not* using squashfs on top > of UBI. > You use mtdblock. ubiblock is a mechanism to turn an UBI volume into a > read-only > block device. > See: http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock > Okay, you mean to say, we should use this ? ubi.mtd=5 ubi.block=0,0 root=/dev/ubiblock0_0 Instead of this: root=/dev/mtdblock44 ubi.mtd=40,0,30 Okay I will discuss this internally and check.. > >> If you place your squashfs on a UBI static volume, UBI knows the exact > >> length > >> and you can checksum it > >> more easily. > > Yes, we use squashfs on UBI volumes, but our volume type is still dynamic. > > Also, you said, UBI knows the exact length, you mean the whole image length > > ? > > How can we get this length at runtime ? > > You need a static volume for that. If you update a static volume the length is > known by UBI. > Thank you so much for your reply! Sorry, I could not get this part. How static volume can give image len ? You mean there is some interface available in kernel to get actual image len ? > > Also, how can we get the checksum of the entire UBI volume content > > (ignoring the erased/empty/bad block content) ? > > Just read from the volume. /dev/ubiX_Y. > I think this also will give the entire volume size, but we still don't know how many pages have real data ? For example: Suppose, my raw partition/volume is of size 10MB But my actual data inside it is of size ~3MB (may be split across?) Then, how can we get the actual size of the data content ? You mean to say: /dev/ubiX_Y should contain only data blocks ? > > Or, you mean to say, the whole checksum logic is in-built inside the > > UBI layer and users don't need to worry about the integrity at all ? > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
On Wed, 21 Jul 2021 at 22:40, Mikulas Patocka wrote: > > > > > > Try to set up dm-verity with block size 512 bytes. > > > > > > I don't know what block size does squashfs use, but if the filesystem > > > block size is smaller than dm-verity block size, it doesn't work. > > > > > Okay thank you so much for this clue, > > It seems we are using 65536 as the squashfs block size: > > 65536 is the compression block size - it is unrelated to I/O block size. > > There's a config option SQUASHFS_4K_DEVBLK_SIZE. The documentation says > that it uses by default 1K block size and if you enable this option, it > uses 4K block size. > Okay it seems this config is set in our case: CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y So, with this the squashfs and dm-verity block size exactly matches (4K) > So, try to set it. Or try to reduce dm-verity block size down to 1K. > Okay we are trying this. Thank you so much!! Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
On Tue, 20 Jul 2021 at 17:12, Mikulas Patocka wrote: > > Hi > > Try to set up dm-verity with block size 512 bytes. > > I don't know what block size does squashfs use, but if the filesystem > block size is smaller than dm-verity block size, it doesn't work. > Okay thank you so much for this clue, It seems we are using 65536 as the squashfs block size: ==> mksquashfs [...] - comp xz -Xdict-size 32K -noI -Xbcj arm -b 65536 -processors 1 But for dm-verity we are giving block size of 4096 ==> [0.00] Kernel command line:[..] verity="96160 12020 d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 0 " rootfstype=squashfs root=/dev/mtdblock34 ubi.mtd=30,0,30 [...] root=/dev/dm-0 dm="system none ro,0 96160 verity 1 /dev/mtdblock34 /dev/mtdblock39 4096 4096 12020 8 sha256 d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7" Now, we are checking by giving squashfs block size also as 4096 In case, if this does not work, what else could be the other option ? Can we try with initramfs approach ? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
Hi, Our ARM32 Linux embedded system consists of these: * Linux Kernel: 4.14 * Processor: Qualcomm Arm32 Cortex-A7 * Storage: NAND 512MB * Platform: Simple busybox * Filesystem: UBIFS, Squashfs * Consists of nand raw partitions, squashfs ubi volumes. My requirement: We wanted to use dm-verity at boot time to check the integrity of squashfs-rootfs before mounting. Problem: dm-0 is not able to locate and mount the squash fs rootfs block. The same approach is working when emulating with ext4 but fails with squashfs. Logs: [] [0.00] Kernel command line: [...] verity="96160 12020 d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 0 " rootfstype=squashfs root=/dev/mtdblock34 ubi.mtd=30,0,30 [...] root=/dev/dm-0 dm="system none ro,0 96160 verity 1 /dev/mtdblock34 /dev/mtdblock39 4096 4096 12020 8 sha256 d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7" [] [4.693620] vreg_conn_pa: disa▒[4.700662] md: Skipping autodetection of RAID arrays. (raid=autodetect will force) [4.700713] device-mapper: init: attempting early device configuration. [4.708224] device-mapper: init: adding target '0 96160 verity 1 /dev/mtdblock34 /dev/mtdblock39 4096 4096 12020 8 sha256 d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7' [4.714979] device-mapper: verity: sha256 using implementation "sha256-generic" [4.737808] device-mapper: init: dm-0 is ready [] [5.278103] No filesystem could mount root, tried: [5.278107] squashfs [5.280477] [5.287627] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(253,0) [...] Not sure, why is it still locating block "253" here which seems like a MAJOR number ? Working logs on ext4: [] [4.529822] v▒[4.534035] md: Skipping autodetection of RAID arrays. (raid=autodetect will force) [4.534087] device-mapper: init: attempting early device configuration. [4.550316] device-mapper: init: adding target '0 384440 verity 1 /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 48055 48063 sha256 a02e0c13afb31e99b999c64aae6f4644c24addbc58db5689902cc5ba0be2d15b aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10 restart_on_corruption ignore_zero_blocks use_fec_from_device /dev/ubiblock0_0 fec_roots 2 fec_blocks 48443 fec_start 48443' [4.572215] device-mapper: verity: sha256 using implementation "sha256-generic" [4.610692] device-mapper: init: dm-0 is ready [4.720174] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [4.720438] VFS: Mounted root (ext4 filesystem) readonly on device 253:0. [4.737256] devtmpfs: mounted [] Questions: a) Is dm-verity supposed to work on squashfs block devices ? b) Are there any known issues with dm-verity on Kernel 4.14 ? c) Are there any patches that we are missing ? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MTD: How to get actual image size from MTD partition
On Tue, 20 Jul 2021 at 12:10, Richard Weinberger wrote: > > Anyways, I will create a separate thread for dm-verity issue and keep > > this thread still open for UBI image size issue. > > We may use dm-verify for rootfs during booting, but still we need to > > perform integrity check for other nand partitions and UBI volumes. > > > > So, instead of calculating the checksum for the entire partition, is > > it possible to perform checksum only based on the image size ? > > Right now, we are still exploring what are the best possible > > mechanisms available for this. > > I still don't fully understand what you are trying to achieve. > Is it about cryptographic integrity of your storage or detecting > errors after the flashing process? > Yes, it is about md5 checksum verification for every partition to check its integrity before updates. > But let me advertise ubiblock a second time. Sorry, I could not understand about the ubiblock request. Is it possible to elaborate little more ? We are already using squashfs on top of our UBI volumes (including rootfs mounting). This is the kernel command line we pass: rootfstype=squashfs root=/dev/mtdblock44 ubi.mtd=40,0,30 And CONFIG_MTD_UBI_BLOCK=y is already enabled in our kernel. Do we need to do something different for ubiblock ? > If you place your squashfs on a UBI static volume, UBI knows the exact length > and you can checksum it > more easily. Yes, we use squashfs on UBI volumes, but our volume type is still dynamic. Also, you said, UBI knows the exact length, you mean the whole image length ? How can we get this length at runtime ? Also, how can we get the checksum of the entire UBI volume content (ignoring the erased/empty/bad block content) ? Or, you mean to say, the whole checksum logic is in-built inside the UBI layer and users don't need to worry about the integrity at all ? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MTD: How to get actual image size from MTD partition
On Mon, 19 Jul 2021 at 14:58, Richard Weinberger wrote: > > - Ursprüngliche Mail - > > Von: "Pintu Agarwal" > > An: "richard" > > CC: "Greg KH" , "linux-kernel" > > , "linux-mtd" > > , "linux-fsdevel" > > , "Phillip Lougher" > > , "Sean Nyekjaer" , > > "Kernelnewbies" > > Gesendet: Montag, 19. Juli 2021 11:09:46 > > Betreff: Re: MTD: How to get actual image size from MTD partition > > > On Fri, 16 Jul 2021 at 21:56, Richard Weinberger wrote: > > > >> >> My requirement: > >> >> To find the checksum of a real image in runtime which is flashed in an > >> >> MTD partition. > >> > > >> > Try using the dm-verity module for ensuring that a block device really > >> > is properly signed before mounting it. That's what it was designed for > >> > and is independent of the block device type. > >> > >> MTDs are not block devices. :-) > >> > > Is it possible to use dm-verity with squashfs ? > > We are using squashfs for our rootfs which is an MTD block /dev/mtdblock44 > > Well, if you emulate a block device using mtdblock, you can use dm-verity and > friends. > Also consider using ubiblock. It offers better performance and wear leveling > support. > Okay thank you. We have tried dm-verity with squashfs (for our rootfs) but we are facing some mounting issues. [...] [4.697757] device-mapper: init: adding target '0 96160 verity 1 /dev/mtdblock34 /dev/mtdblock39 4096 4096 12020 8 sha256 d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7' [4.704771] device-mapper: verity: sha256 using implementation "sha256-generic" [...] [4.727366] device-mapper: init: dm-0 is ready [4.912558] VFS: Cannot open root device "dm-0" or unknown-block(253,0): error -5 The same works with ext4 emulation. So, not sure if there are any changes missing w.r.t. squashfs on 4.14 kernel ? Anyways, I will create a separate thread for dm-verity issue and keep this thread still open for UBI image size issue. We may use dm-verify for rootfs during booting, but still we need to perform integrity check for other nand partitions and UBI volumes. So, instead of calculating the checksum for the entire partition, is it possible to perform checksum only based on the image size ? Right now, we are still exploring what are the best possible mechanisms available for this. Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MTD: How to get actual image size from MTD partition
On Fri, 16 Jul 2021 at 21:56, Richard Weinberger wrote: > >> My requirement: > >> To find the checksum of a real image in runtime which is flashed in an > >> MTD partition. > > > > Try using the dm-verity module for ensuring that a block device really > > is properly signed before mounting it. That's what it was designed for > > and is independent of the block device type. > > MTDs are not block devices. :-) > Is it possible to use dm-verity with squashfs ? We are using squashfs for our rootfs which is an MTD block /dev/mtdblock44 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
MTD: How to get actual image size from MTD partition
Hi, Our ARM32 Linux embedded system consists of these: * Linux Kernel: 4.14 * Processor: Qualcomm Arm32 Cortex-A7 * Storage: NAND 512MB * Platform: Simple busybox * Filesystem: UBIFS, Squashfs * Consists of nand raw partitions, squashfs ubi volumes. My requirement: To find the checksum of a real image in runtime which is flashed in an MTD partition. Problem: Currently, to find the checksum, we are using: $ md5sum /dev/mtd14 This returns the proper checksum of the entire partition. But we wanted to find the checksum only for the actual image data which will be used by our C utility to validate the image. Here, we don't know the actual image size. We only know the "partition-size" and "erasesize". So, is there a mechanism to somehow find the image size at runtime? Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Query: UBIFS: How to detect empty volumes
On Sun, 27 Jun 2021 at 14:12, Richard Weinberger wrote: > > On Thu, Jun 24, 2021 at 6:09 PM Pintu Agarwal wrote: > > I have one basic query related to UBIFS volumes on a system with NAND > > partition. > > There is no such thing as a UBIFS volume. Do you mean UBI volumes? > Yes I mean the ubi volumes which are created using the ubinize config file. > > In short, how to detect a particular empty volume inside a system > > partition while flashing the partition image? > > What do you mean by system partition? A MTD partition? By this I mean the entire UBI partition that contains the magic header "UBI#" > > > Suppose I have one big system partition that consists of 4-5 ubi > > volumes inside it with varying sizes. > > Lets say: > > -- System Partition (ubi image) > > - rootfs volume (ro, squashfs) > > - data volume (rw, ubifs) > > - firmware volume (ro, ubifs) > > - some-other volume (ro, squashfs) > > So by system partition you mean the MTD partition that hosts UBI itself? > Yes the entire UBI partition that contains UBI volumes > > Consider that all these could be flashed together as part of > > system.ubi image in a single shot from the bootloader. > > Now, suppose, one of the volume image (say firmware) is missing or > > remains empty (as you know we can have empty volumes). > > > > So, during system image flashing, we wanted to detect if one of the > > volume (firmware) is empty. > > Since this is an important volume, so we wanted to detect if this > > volume is empty/missing we will abort flashing the system partition. > > As there is no point in booting the system without this partition. > > > > So, I am exploring options, how can this be detected ? > > Read from the volume after flashing. If you get only 0xFF bytes it is empty. > I mean, without flashing the image, is it possible to determine/guess from the image content/header that a volume in the image is empty. If it is empty then do not allow to flash the image. > > I mean is there any kind of magic number or header information which > > we can read to detect a particular empty volume ? > > Can we get any information from just "system.ubi" image to indicate > > about the volume information ? > > You'll need to perform a proper UBI scan on all blocks. > If for the sad volume no LEBs have been found it is empty. > hmm, this seems reasonable. We have something called "ubi_scan_partition" that scans for bad blocks, during "ubi_open". And we also have ubi_find_volume that checks for vtbl record in an incoming image. Let me check about the LEB option here. > > Also it could be possible that 2 or more volumes are empty, but we are > > only concerned about one particular volume (firmware), so how to > > detect particular volume ? > > I don't understand the use case. Is your image creation process so error prone > that you can't be sure whether critical parts got included or not? > Actually our UBI creation process contains multiple volumes, in which one volume contains firmware image, that comes from another subsystem. So, it requires copying that firmware image manually before building the etire yocto image. But, it might be possible that some developer may miss/skip this firmware copying part, thus the resulting image may end up is having an empty firmware volume. However, this firmware volume is an important volume, without which the modem may not boot up. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Query: UBIFS: How to detect empty volumes
Hi, I have one basic query related to UBIFS volumes on a system with NAND partition. In short, how to detect a particular empty volume inside a system partition while flashing the partition image? Suppose I have one big system partition that consists of 4-5 ubi volumes inside it with varying sizes. Lets say: -- System Partition (ubi image) - rootfs volume (ro, squashfs) - data volume (rw, ubifs) - firmware volume (ro, ubifs) - some-other volume (ro, squashfs) Consider that all these could be flashed together as part of system.ubi image in a single shot from the bootloader. Now, suppose, one of the volume image (say firmware) is missing or remains empty (as you know we can have empty volumes). So, during system image flashing, we wanted to detect if one of the volume (firmware) is empty. Since this is an important volume, so we wanted to detect if this volume is empty/missing we will abort flashing the system partition. As there is no point in booting the system without this partition. So, I am exploring options, how can this be detected ? I mean is there any kind of magic number or header information which we can read to detect a particular empty volume ? Can we get any information from just "system.ubi" image to indicate about the volume information ? Also it could be possible that 2 or more volumes are empty, but we are only concerned about one particular volume (firmware), so how to detect particular volume ? If anyone has any thoughts about this requirement, please share your opinion. Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Query: UBIFS: How to detect empty volumes
Hi, I have one basic query related to UBIFS volumes on a system with NAND partition. In short, how to detect a particular empty volume inside a system partition while flashing the partition image? Suppose I have one big system partition that consists of 4-5 ubi volumes inside it with varying sizes. Lets say: -- System Partition (ubi image) - rootfs volume (ro, squashfs) - data volume (rw, ubifs) - firmware volume (ro, ubifs) - some-other volume (ro, squashfs) Consider that all these could be flashed together as part of system.ubi image in a single shot from the bootloader. Now, suppose, one of the volume image (say firmware) is missing or remains empty (as you know we can have empty volumes). So, during system image flashing, we wanted to detect if one of the volume (firmware) is empty. Since this is an important volume, so we wanted to detect if this volume is empty/missing we will abort flashing the system partition. As there is no point in booting the system without this partition. So, I am exploring options, how can this be detected ? I mean is there any kind of magic number or header information which we can read to detect a particular empty volume ? Can we get any information from just "system.ubi" image to indicate about the volume information ? Also it could be possible that 2 or more volumes are empty, but we are only concerned about one particular volume (firmware), so how to detect particular volume ? If anyone has any thoughts about this requirement, please share your opinion. Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: KASLR support on ARM with Kernel 4.9 and 4.14
On Tue, 29 Sep 2020 at 01:20, Kees Cook wrote: > Note that I still can't explain what you're seeing. /proc/kallsyms > shouldn't be affected by these patches -- I would expect it to either > report the true value or 00s. > > > I will disable kptr_restrict and check or, I will enable > > CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS and check. > > I would start with kptr_restrict=0 and see if that changes the contents > of /proc/kallsyms. If it does, then it is the hashing. If it doesn't, > well, we're back to square one. :) Actually in that board, the kptr_restrict=0 already in both case: 4.9 and 4.14 Kernel boards. In another board with 4.14 and kptr_restrict=2, I see that the addresses are 00 always. I further checked that when I enable this config: CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS, then the addresses are remaining the same in every boot. But this particular config is not present in 4.9 Kernel. So, I think it is controlled using this config. -- Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: KASLR support on ARM with Kernel 4.9 and 4.14
On Mon, 28 Sep 2020 at 19:15, Pintu Agarwal wrote:
>
> On Sat, 26 Sep 2020 at 22:10, Kees Cook wrote:
>
> > > >> I wonder if this is an Android Common kernel?
> > > It uses the below kernel for 4.14:
> > > https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5 (or
> > > similar branch).
> >
> > Okay, so yes. And this appears to have the hashing of %p backported. I
> > cannot, however, explain why it's showing hashed pointers instead of
> > just NULL, though.
> >
> > It might be related to these commits but they're not in that kernel:
> > 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
> > 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers")
> >
> > > ==> The case where symbol addresses are changing.
> > >
> > > kptr_restrict is set to 2 by default:
> > > / # cat /proc/sys/kernel/kptr_restrict
> > > 2
> > >
> > > Basically, the goal is:
> > > * To understand how addresses are changing in 4.14 Kernel (without
> > > KASLR support)?
> > > * Is it possible to support the same in 4.9 Kernel ?
> >
> > Try setting kptr_restrict to 0 and see if the symbol addresses change? I
> > suspect Ard is correct: there's no KASLR here, just hashed pointers
> > behaving weird on an old non-stock kernel. :)
> >
>
> Okay. Thank you so much for your comments and suggestions.
> You mean to say, setting kptr_restrict to 0 may avoid changing symbol
> addresses in 4.14 ?
> And, sorry, I could not understand the thing about this "hashed pointers".
> How can I check this behavior in source code to understand better?
> Is it possible to give some reference ?
> I wanted to disable this hash pointer on 4.14 kernel and check the behavior.
> Also if possible, we would like to make this similar change on 4.9
> kernel as well.
>
Okay, I found these changes in 4.14 kernel:
https://gitlab.com/quicla/kernel/msm-4.14/-/commit/e63732dbfe017aa0dbabac9d096b5fde8afbd395
Are we talking about this?
I cound not find this in 4.9 kernel.
I will disable kptr_restrict and check or, I will enable
CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS and check.
Thanks,
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: KASLR support on ARM with Kernel 4.9 and 4.14
On Sat, 26 Sep 2020 at 22:10, Kees Cook wrote:
> > >> I wonder if this is an Android Common kernel?
> > It uses the below kernel for 4.14:
> > https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5 (or
> > similar branch).
>
> Okay, so yes. And this appears to have the hashing of %p backported. I
> cannot, however, explain why it's showing hashed pointers instead of
> just NULL, though.
>
> It might be related to these commits but they're not in that kernel:
> 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
> 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers")
>
> > ==> The case where symbol addresses are changing.
> >
> > kptr_restrict is set to 2 by default:
> > / # cat /proc/sys/kernel/kptr_restrict
> > 2
> >
> > Basically, the goal is:
> > * To understand how addresses are changing in 4.14 Kernel (without
> > KASLR support)?
> > * Is it possible to support the same in 4.9 Kernel ?
>
> Try setting kptr_restrict to 0 and see if the symbol addresses change? I
> suspect Ard is correct: there's no KASLR here, just hashed pointers
> behaving weird on an old non-stock kernel. :)
>
Okay. Thank you so much for your comments and suggestions.
You mean to say, setting kptr_restrict to 0 may avoid changing symbol
addresses in 4.14 ?
And, sorry, I could not understand the thing about this "hashed pointers".
How can I check this behavior in source code to understand better?
Is it possible to give some reference ?
I wanted to disable this hash pointer on 4.14 kernel and check the behavior.
Also if possible, we would like to make this similar change on 4.9
kernel as well.
Thanks,
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: KASLR support on ARM with Kernel 4.9 and 4.14
On Sat, 26 Sep 2020 at 05:17, Kees Cook wrote: > > > > For a 3/1 split ARM kernel of the typical size, all kernel virtual > > addresses start with 0xc0, and given that the kernel is located at the > > start of the linear map, those addresses cannot change even if you > > move the kernel around in physical memory. > > I wonder if this is an Android Common kernel? I think there was %p > hashing in there before v4.15, but with a different implementation... > Hi, Thank you all for all your reply and comments so far! Here are some follow-up replies. >> What device is this? Is it a stock kernel? This is a Qualcomm Snapdragon Automotive board one with Linux Kernel 4.9 and one with 4.14. >> Is the boot loader changing the base address? (What boot loader are you >> using?) Ohh I did not knew that the bootloader can also change the base address. I think it uses UEFI. How to check if bootloader is doing this ? BTW, both 4.9 board and 4.14 board, uses same bootloader. >> I wonder if this is an Android Common kernel? It uses the below kernel for 4.14: https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5 (or similar branch). ==> The case where symbol addresses are changing. kptr_restrict is set to 2 by default: / # cat /proc/sys/kernel/kptr_restrict 2 Basically, the goal is: * To understand how addresses are changing in 4.14 Kernel (without KASLR support)? * Is it possible to support the same in 4.9 Kernel ? -- Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
KASLR support on ARM with Kernel 4.9 and 4.14
Hi All, This is regarding the KASLR feature support on ARM for the kernel version 4.9 and 4.14. Is KASLR supported on ARM-32 Linux 4.9 and above ? Is it dependent on CONFIG_RANDOMIZE_BASE or /proc/sys/kernel/randomize_va_space ? Is there any relation between these two? Is the changing kernel symbols (in every boot), only possible if KASLR is enabled, or there is another way it can happen? I have these queries because, In one of the arm-32 devices with Kernel 4.14, I observed that CONFIG_RANDOMIZE_BASE is not available. But /proc/sys/kernel/randomize_va_space is set to 2. However, I also observed that symbol addresses are changing in every boot. 1st boot cycle: [root ~]# cat /proc/kallsyms | grep "sys_open" a5b4de92 T sys_open [root@sa515m ~]# 2nd boot cycle: [root ~]# cat /proc/kallsyms | grep "sys_open" f546ed66 T sys_open So, I am wondering how this is possible without KASLR (CONFIG_RANDOMIZE_BASE) support in Kernel ? Similarly, with Kernel 4.9 and CONFIG_RANDOMIZE_BASE is not available but /proc/sys/kernel/randomize_va_space is set to 2. But here, the addresses are remaining same. 1st Run: [root~]# cat /proc/kallsyms | grep "sys_open" c01ed68c T sys_open [root ~]# *** reboot *** [root ~]# cat /proc/kallsyms | grep "sys_open" c01ed68c T sys_open Is there any other difference between these two kernel versions with respect to changing symbol addresses ? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Generic way for verifying GPIO wakeup capability
On Tue, 9 Jun 2020 at 23:06, Pintu Agarwal wrote: > > Hi All, > > I am looking for ways to wakeup any devices (from sleep) using any > arbitrary gpio wakeup method in a generic way (either from user space > or kernel space) that should work on any kernel version (starting from > 4.14 onwards). > > What are the options available right now ? > I wanted to experiment with all of them and decide which is best for us. > > Is /sys/class/gpio/ method still valid with the latest kernel ? > Or is there any other method to do it from user space ? > > One option I know is to use enable/disable_irq_wake() API from kernel > driver suspend/resume path. > Just like this: > https://lwn.net/Articles/569027/ > > But this requires an additional kernel driver and device-tree changes > for each gpio wakeup, which the end-user needs to implement on their > own. > > Is there any other existing generic mechanism? > https://embeddedbits.org/new-linux-kernel-gpio-user-space-interface/ Is it possible to achieve this using this new interface ? And I think another option is to use gpio-keys defined in device-tree. Will this method work for any wake-capable gpio ? How to verify this for any arbitrary gpio ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Generic way for verifying GPIO wakeup capability
Hi All, I am looking for ways to wakeup any devices (from sleep) using any arbitrary gpio wakeup method in a generic way (either from user space or kernel space) that should work on any kernel version (starting from 4.14 onwards). What are the options available right now ? I wanted to experiment with all of them and decide which is best for us. Is /sys/class/gpio/ method still valid with the latest kernel ? Or is there any other method to do it from user space ? One option I know is to use enable/disable_irq_wake() API from kernel driver suspend/resume path. Just like this: https://lwn.net/Articles/569027/ But this requires an additional kernel driver and device-tree changes for each gpio wakeup, which the end-user needs to implement on their own. Is there any other existing generic mechanism? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Estimating total memory usage in any Linux system
On Wed, 20 May 2020 at 11:02, Valdis Klētnieks wrote: > > On Wed, 20 May 2020 10:26:50 +0530, Pintu Agarwal said: > > I know it is weird to manually arrive a MemTotal from the values of meminfo. > > But I am actually looking for general formula. > > You missed the point - the "general formula" has probably changed over the > years. > > > With this I could arrive to some result, but I have some doubts: > > * Is Mapped already included in Active/Inactive (file) ? Because > > mapped is coming from NR_FILE_MAPPED. > > And that's the sort of question that can have different answers for 3.18 and > 5.7. > I am okay for even the latest kernel. I am even trying to get this on 5.5 kernel or higher. But my questions remains the same. What will be the equation for even 5.7 kerne ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Estimating total memory usage in any Linux system
On Wed, 20 May 2020 at 09:31, Valdis Klētnieks wrote: > > On Tue, 19 May 2020 22:33:15 +0530, Pintu Agarwal said: > > > > Below are some data taken from a small embedded arm32 device with 512MB > > > RAM: > > > > > > > Sorry, I forgot to mention the kernel version. Here it is 3.18 Kernel > > That's a kernel from 2014. You don't seriously expect us to remember how > all those counters worked back then, do you? > Actually I don't care about the kernel version. This was just for reference. I know it is weird to manually arrive a MemTotal from the values of meminfo. But I am actually looking for general formula. I could get some of the answers by tracing the kernel code for each counters. But still there are some gaps which I want to clarify. As I see there are several ways to total it: i.e; (PSS way), (Buffers, Cached), (Active, Inactive) According to me, MemTotal = MemFree + Active + Inactive + SwapCached + Mapped + Shmem + Slab + KernelStack + PageTables + (Init Freed from boot) + (alloc pages) + (min_free_bytes + user_reserve_bytes) Did I miss anything here ? With this I could arrive to some result, but I have some doubts: * Is Mapped already included in Active/Inactive (file) ? Because mapped is coming from NR_FILE_MAPPED. ==> I see that it is accounted from mm/rmap.c * Do we also need to incude VmallocUsed here ? I see in some cases people include it too. ==> But I think vmalloc internally calls kmalloc and use page tables, so it should be already accounted in Slab and PageTables ?? ==> Do I still need to include these values from /proc/vmallocinfo ?? * Is it valid to include min_free_kbytes and user_reserve_kbytes here ? Its kind of reserve for internal purpose but still it contributes to the total. * Is kernel internal allocation (alloc_pages) statistics accounted somewhere ? ==> I can see that some counters like (pgalloc_normal, etc. and pgfree) are available as part of /proc/vmstat ===> But this is like overall allocation and free stats. * Apart from these, do we also need to consider Graphics/3D allocation separately ? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Estimating total memory usage in any Linux system
On Mon, 18 May 2020 at 23:27, Pintu Agarwal wrote:
>
> Hi,
>
> I was just trying to manually calculate the total memory available in
> a system to match up the MemTotal shown in /proc/meminfo
> I know "free -m" command will give the vary high level usage, but I
> wanted to breakdown the MemTotal numbers to see usage in each
> category.
>
> I am looking for a common formula that should match on almost all systems.
> So, I came up with below fields from meminfo to closely match the total.
> ~Total = {MemFree + Active + Inactive + Shmem + Mapped + Slab +
> KernelStack + PageTables + (init freed) + (Boot Diff) + (low
> watermarks)}
>
> But I am not sure if these fields are correct at least for arm32 system.
> In some boards I could able to match up these figures, but some not.
>
> So I have some doubts:
> * Is "Mapped" (NR_MAPPED_PAGES) already part of Active pages ?
> * Is Kernel allocation (alloc_pages, etc.) accounted somewhere ? Is it
> part of Anon pages ?
> * What about vmalloc / ioremap pages ? Do we also need to consider
> VmallocUsed ?
> ==> In my opinion vmalloc internally used kmalloc and page tables, so
> I guess it should be already part of Slab or PageTables ??
>
> Below are some data taken from a small embedded arm32 device with 512MB RAM:
>
Sorry, I forgot to mention the kernel version. Here it is 3.18 Kernel
> Kernel Boot Logs:
> Memory: 99244K/254976K available (10720K kernel code, 1336K rwdata,
> 4792K rodata, 400K init, 1602K bss, 135252K reserved, 20480K
> cma-reserved)
> Total = 99244 + 400 (init) + 20480 (cma) = 120124
> Boot Diff = 121204 - 120124 => 1080 kB
>
> MemTotal: 121204 kB
> MemFree: 2540 kB
> MemAvailable: 51924 kB
> Buffers: 0 kB
> Cached: 47492 kB
> SwapCached: 0 kB
> Active: 42604 kB
> Inactive: 24308 kB
> Active(anon): 19476 kB
> Inactive(anon): 92 kB
> Active(file): 23128 kB
> Inactive(file): 24216 kB
> Unevictable: 0 kB
> Mlocked: 0 kB
> SwapTotal: 0 kB
> SwapFree: 0 kB
> Dirty: 8 kB
> Writeback: 0 kB
> AnonPages: 19452 kB
> Mapped: 12644 kB
> Shmem: 148 kB
> Slab: 27560 kB
> SReclaimable: 7224 kB
> SUnreclaim: 20336 kB
> KernelStack: 3104 kB
> PageTables: 1896 kB
> NFS_Unstable: 0 kB
> Bounce: 0 kB
> WritebackTmp: 0 kB
> CommitLimit: 60600 kB
> Committed_AS: 1576740 kB
> VmallocTotal: 777216 kB
> VmallocUsed: 53696 kB
> VmallocChunk: 689148 kB
>
>
> These are my calculations from the above fields.
> -
> MemFree 2540
> Active 42604
> Inactive 24308
> Mapped 12644
> Slab 27560
> KernelStack 3104
> PageTables 1896
> Shmem 148
> init freed 400
> Diff from boot total 1080
> min_free_kbytes 1384
> user_reserve_kbytes 3537
> My Total ==> 121205 (add all the above)
>
> As you can see "My Total" closely matches with the MemTotal from /proc/meminfo
>
> But on some systems it does not match.
> So, I wanted to understand if there is something wrong in my
> calculation, or there is something wrong in the system itself (like
> leaks etc,)
>
> Note: I don't want to use any tools or utilize for these, but I wanted
> to manually understand it.
>
> I am also trying to explore every vm counter that populates these fields.
>
> But if you have any other opinion about it please let me know.
>
>
> Thanks,
> Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Estimating total memory usage in any Linux system
Hi,
I was just trying to manually calculate the total memory available in
a system to match up the MemTotal shown in /proc/meminfo
I know "free -m" command will give the vary high level usage, but I
wanted to breakdown the MemTotal numbers to see usage in each
category.
I am looking for a common formula that should match on almost all systems.
So, I came up with below fields from meminfo to closely match the total.
~Total = {MemFree + Active + Inactive + Shmem + Mapped + Slab +
KernelStack + PageTables + (init freed) + (Boot Diff) + (low
watermarks)}
But I am not sure if these fields are correct at least for arm32 system.
In some boards I could able to match up these figures, but some not.
So I have some doubts:
* Is "Mapped" (NR_MAPPED_PAGES) already part of Active pages ?
* Is Kernel allocation (alloc_pages, etc.) accounted somewhere ? Is it
part of Anon pages ?
* What about vmalloc / ioremap pages ? Do we also need to consider VmallocUsed ?
==> In my opinion vmalloc internally used kmalloc and page tables, so
I guess it should be already part of Slab or PageTables ??
Below are some data taken from a small embedded arm32 device with 512MB RAM:
Kernel Boot Logs:
Memory: 99244K/254976K available (10720K kernel code, 1336K rwdata,
4792K rodata, 400K init, 1602K bss, 135252K reserved, 20480K
cma-reserved)
Total = 99244 + 400 (init) + 20480 (cma) = 120124
Boot Diff = 121204 - 120124 => 1080 kB
MemTotal: 121204 kB
MemFree: 2540 kB
MemAvailable: 51924 kB
Buffers: 0 kB
Cached: 47492 kB
SwapCached: 0 kB
Active: 42604 kB
Inactive: 24308 kB
Active(anon): 19476 kB
Inactive(anon): 92 kB
Active(file): 23128 kB
Inactive(file): 24216 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 8 kB
Writeback: 0 kB
AnonPages: 19452 kB
Mapped: 12644 kB
Shmem: 148 kB
Slab: 27560 kB
SReclaimable: 7224 kB
SUnreclaim: 20336 kB
KernelStack: 3104 kB
PageTables: 1896 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 60600 kB
Committed_AS: 1576740 kB
VmallocTotal: 777216 kB
VmallocUsed: 53696 kB
VmallocChunk: 689148 kB
These are my calculations from the above fields.
-
MemFree 2540
Active 42604
Inactive 24308
Mapped 12644
Slab 27560
KernelStack 3104
PageTables 1896
Shmem 148
init freed 400
Diff from boot total 1080
min_free_kbytes 1384
user_reserve_kbytes 3537
My Total ==> 121205 (add all the above)
As you can see "My Total" closely matches with the MemTotal from /proc/meminfo
But on some systems it does not match.
So, I wanted to understand if there is something wrong in my
calculation, or there is something wrong in the system itself (like
leaks etc,)
Note: I don't want to use any tools or utilize for these, but I wanted
to manually understand it.
I am also trying to explore every vm counter that populates these fields.
But if you have any other opinion about it please let me know.
Thanks,
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interrupt handler not getting called after resume
Dear Anish, On Thu, 5 Dec 2019 at 00:55, anish singh wrote: > > On Wed, Dec 4, 2019 at 1:49 AM Pintu Agarwal wrote: > > > > On Wed, 4 Dec 2019 at 00:28, anish singh > > wrote: > > > > > > On Tue, Dec 3, 2019 at 6:12 AM Pintu Agarwal wrote: > > > > > > > > Hi All, > > > > > > > > I have one general query. > > > > > > > > If an interrupt handler is NOT getting called (for one device) after > > > > the system resume (from snapshot image), then what could be the issue? > > > > > > Most likely during resume the interrupt was not enabled. So check > > > irq status registers to see in the working and non working case. > > > > > Oh sorry, I forgot to mention one thing. > > After resume, I can see that the interrupts are visible under > > /proc/interrupts. > > # cat /proc/interrupts > >CPU0 CPU1 > > [...] > > 416: 1 0 IPU (null) > > 417: 0 0 IPU (null) > > 418: 0 0 IPU imx_drm ===> HDMI > > 419: 2242 2 IPU imx_drm ===> LCD > > [...] > > > > The interrupts are coming only for LCD display and thus its irq > > handler is getting called. > > But the interrupts are not coming for HDMI case, thus HDMI gives > > "vblank timeout issue". Just wanted to update you that I have resolved the "vblank timeout issue" for HDMI (by restoring clock data during resume path). Now the ipu-v3 interrupts are coming even for HDMI crtc. But HDMI display is still not working. May be this is another issue. Anyways, thank you so much for your support :) Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interrupt handler not getting called after resume
On Wed, 4 Dec 2019 at 00:28, anish singh wrote: > > On Tue, Dec 3, 2019 at 6:12 AM Pintu Agarwal wrote: > > > > Hi All, > > > > I have one general query. > > > > If an interrupt handler is NOT getting called (for one device) after > > the system resume (from snapshot image), then what could be the issue? > > Most likely during resume the interrupt was not enabled. So check > irq status registers to see in the working and non working case. > Oh sorry, I forgot to mention one thing. After resume, I can see that the interrupts are visible under /proc/interrupts. # cat /proc/interrupts CPU0 CPU1 [...] 416: 1 0 IPU (null) 417: 0 0 IPU (null) 418: 0 0 IPU imx_drm ===> HDMI 419: 2242 2 IPU imx_drm ===> LCD [...] The interrupts are coming only for LCD display and thus its irq handler is getting called. But the interrupts are not coming for HDMI case, thus HDMI gives "vblank timeout issue". Apart from this I also tried calling enable_irq(irq) after resume, but it did not help much. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
interrupt handler not getting called after resume
Hi All, I have one general query. If an interrupt handler is NOT getting called (for one device) after the system resume (from snapshot image), then what could be the issue? Note: * The suspend worked perfectly fine. * The runtime suspend/resume of the system is also working fine. If anybody have experienced this situation and fixed it, please let us know. It will be a great input for further debugging. Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
interrupt handler not getting called after resume
Hi All, I have one general query. If an interrupt handler is NOT getting called (for one device) after the system resume (from snapshot image), then what could be the issue? Note: * The suspend worked perfectly fine. * The runtime suspend/resume of the system is also working fine. If anybody have experienced this situation and fixed it, please let us know. It will be a great input for further debugging. Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [IMX] [DRM]: help in analyzing clock_summary rate difference
Hi, I need one general help in analyzing difference in clock_summary rate before and after the system resume. I am using custom IMX7 board with 4.9 Kernel. With this I am trying to support some functionality during suspend/resume. I am trying to analyze clk_summary from: # cat /sys/kernel/debug/clk/clk_summary I observed that there are difference in "clock rate" after system resume and module install. However the enable/prepare count remains the same. Since I am not much familiar with clock framework, I am looking for some help to analyze this issue. It's an internal issue. May be someone which is familiar with clock analysis or fixed the similar issue earlier can give me some guidance. What does the difference in clock rate indicates? What analysis can be done to narrow down the root cause? Any example of reference could be helpful to understand. Thank You! Regards, Pintu
Re: [IMX] [DRM]: suspend/resume support
On Sat, Jun 22, 2019 at 1:43 PM Pintu Agarwal wrote:
>
> On Fri, Jun 21, 2019 at 9:09 PM Fabio Estevam wrote:
> >
> > On Fri, Jun 21, 2019 at 12:13 PM Pintu Agarwal wrote:
> >
> > > Okay there is some update on the 2nd part.
> > > Now I am able to successfully install all imx modules after the resume
> > > (no hang).
> > > But, I got some errors after install finish:
> > > [drm] disabling vblank on crtc 1
> > > [IMX]: imx_drm_disable_vblank - called
> > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0]
> > > flip_done timed out
> > >
> > > Also I am able to start the weston successfully.
> > > But I see LCD/HDMI display is not working (only some backlight is
> > > visible).
> > >
> > > And, I noticed, weston also reports the following errors:
> > > imx-ipuv3 240.ipu: DC stop timeout after 50 ms
> > > [IMX]: drm_crtc_vblank_off - called
> > > [IMX]: imx_drm_disable_vblank - called
> > > INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0,
> > > t=6002 jiffies, g=289, c=288, q=8)
> > > Task dump for CPU 1:
> > > weston R running 0 306 1 0x
> > > [] (__schedule) from [<00080193>] (0x80193)
> > >
> > > Do you have any clue about these errors ?
> >
> > Which kernel version is this?
>
Now, I am using Kernel 4.9 (custom) with some internal changes.
After the hibernate-resume, I am trying to install the modules in
following order:
insmod imxdrm.ko
insmod parallel-display.ko
insmod dw-hdmi.ko
insmod dw_hdmi-imx.ko
insmod imx-ipu-v3.ko
insmod imx-ipuv3-crtc.ko
insmod imx-ldb.ko
I noticed that if I don't install the "crtc" or "ldb" module at last,
then system will hang.
Otherwise, the modules are installed successfully.
But, I get following errors:
[drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:24:crtc-0]
flip_done timed out
[drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0]
flip_done timed out
But, hdmi could be detected from the logs:
dwhdmi-imx 12.hdmi: Detected HDMI controller 0x13:0x1a:0xa0:0xc1
However, after I start weston, there is no display in LCD and HDMI.
I can only see the backlight.
One more thing, I observed that, there was a huge delay after
component_bind_all():
[IMX]: imx_drm_driver_load - component_bind_all - DONE
<-- delay --->
Then we get flip_done timeout.
So, my question is:
1) If we have to test hibernation on iMX6/7 then which is the suitable way?
2) Is it possible to support this feature by performing module
installation after resume?
3) If yes, then which modules should be chosen as loadable, and which
can be in-built?
(So, we don't have to implement suspend/resume for each module)
4) I also compared clock_summary in normal boot and after resume (with
module installed).
I found below difference in clock frequency (pll5, pll4)
Example:
-pll51 1118807
+pll51 1104015
what does this indicates? Is there any issue?
Re: [IMX] [DRM]: suspend/resume support
On Fri, Jun 21, 2019 at 9:09 PM Fabio Estevam wrote:
>
> On Fri, Jun 21, 2019 at 12:13 PM Pintu Agarwal wrote:
>
> > Okay there is some update on the 2nd part.
> > Now I am able to successfully install all imx modules after the resume
> > (no hang).
> > But, I got some errors after install finish:
> > [drm] disabling vblank on crtc 1
> > [IMX]: imx_drm_disable_vblank - called
> > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0]
> > flip_done timed out
> >
> > Also I am able to start the weston successfully.
> > But I see LCD/HDMI display is not working (only some backlight is visible).
> >
> > And, I noticed, weston also reports the following errors:
> > imx-ipuv3 240.ipu: DC stop timeout after 50 ms
> > [IMX]: drm_crtc_vblank_off - called
> > [IMX]: imx_drm_disable_vblank - called
> > INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0,
> > t=6002 jiffies, g=289, c=288, q=8)
> > Task dump for CPU 1:
> > weston R running 0 306 1 0x
> > [] (__schedule) from [<00080193>] (0x80193)
> >
> > Do you have any clue about these errors ?
>
> Which kernel version is this?
Please let me know in which version this issue is fixed.
I will try that.
I think I saw some commit that mentions about it, but I forgot.
Anyways, I am checking again.
Thanks!
Re: [IMX] [DRM]: suspend/resume support
On Wed, Jun 19, 2019 at 8:59 PM Pintu Agarwal wrote:
> > > This scenario is not with suspend/resume.
> > > This hang is, when we make hdmi as a loadable module (.ko) and trying
> > > to install it after resume.
> > > In this case, suspend/resume will not come into picture. Not sure why
> > > it still hangs.
> > > Do you have any clue for this scenario?
> >
> > I haven't tried this one.
> >
Okay there is some update on the 2nd part.
Now I am able to successfully install all imx modules after the resume
(no hang).
But, I got some errors after install finish:
[drm] disabling vblank on crtc 1
[IMX]: imx_drm_disable_vblank - called
[drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0]
flip_done timed out
Also I am able to start the weston successfully.
But I see LCD/HDMI display is not working (only some backlight is visible).
And, I noticed, weston also reports the following errors:
imx-ipuv3 240.ipu: DC stop timeout after 50 ms
[IMX]: drm_crtc_vblank_off - called
[IMX]: imx_drm_disable_vblank - called
INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0,
t=6002 jiffies, g=289, c=288, q=8)
Task dump for CPU 1:
weston R running 0 306 1 0x
[] (__schedule) from [<00080193>] (0x80193)
Do you have any clue about these errors ?
Thanks,
Pintu
Re: [IMX] [DRM]: suspend/resume support
On Wed, Jun 19, 2019 at 9:56 PM Valdis Klētnieks wrote: > > On Wed, 19 Jun 2019 20:47:34 +0530, Pintu Agarwal said: > > > No I mean to say, there are lots of features and customization already > > done on this version and stabilized. > > Upgrading again may require months of effort. > > This is what happens when you don't upstream your local changes. > > And no, saying "But we're a small company and nobody cares" isn't an > excuse - Linux carried the entire Voyager architecture around for several > years > for 2 machines. Not two models, 2 physical machines, the last 2 operational > systems of the product line. > > (Not the Xubuntu-based Voyage distribution either - the Voyager was a mid-80s > SMP fault-tolerant system from NCR with up to 32 486/586 cores and 4G of > memory, which was a honking big system for the day...) > > https://kernel.googlesource.com/pub/scm/linux/kernel/git/rzhang/linux/+/v2.6.20-rc1/Documentation/voyager.txt > > The architecture was finally dropped in 2009 when enough hardware failures > had happened that James Bottomley was unable to create a bootable > system from the parts from both... > > So if your production run is several thousand systems, that's *plenty* big > enough for patches and drivers (especially since drivers for hardware you > included in your several-thousand system run are also likely applicable to > a half dozen other vendors who made several thousand systems using the > same chipset Yes, I agree, but unfortunately I don't have any control. I normally keep finding things, which seems interesting for me and propose for upstream (even if it is very small). And, I completely agree that system should be designed such a way that it can be easily up-gradable. But, as I said, its not fully in our hand :( Also, I think this case is slightly different. Here, even if I try with latest kernel, there is no use, since hibernation feature is not fully support for IMX. And I think that is already known. I came here looking for some pointers and help and get some clue to proceed further. If I succeed in making it I will definitely like to contribute upstream :) Thank You! Regards, Pintu
Re: [IMX] [DRM]: suspend/resume support
On Wed, Jun 19, 2019 at 8:41 PM Fabio Estevam wrote: > > > > Then you can test suspend/resume and see if HDMI hangs or not. > > > > > By this suspend/resume, you mean "suspend-to-ram" or "suspend-to-disk" ? > > I tested with "echo mem > /sys/power/state" > hmm. That's what I said. This is runtime suspend, and it works for me also. I am talking about hibernation: # echo disk > /sys/power/state (with some customization) > > This scenario is not with suspend/resume. > > This hang is, when we make hdmi as a loadable module (.ko) and trying > > to install it after resume. > > In this case, suspend/resume will not come into picture. Not sure why > > it still hangs. > > Do you have any clue for this scenario? > > I haven't tried this one. > > Please test it with 5.1.11 and if it fails, please report. Okay will check this on latest kernel. Thanks.
Re: [IMX] [DRM]: suspend/resume support
On Wed, Jun 19, 2019 at 8:34 PM Greg KH wrote: > > On Wed, Jun 19, 2019 at 07:03:39PM +0530, Pintu Agarwal wrote: > > You can think that the version I am using right now is almost 4.9 itself. > > Upgrading again to higher kernel version is again difficult, also > > customer does not want it. > > They don't want a secure and supported kernel over the lifetime of their > device? That sounds really odd. No I mean to say, there are lots of features and customization already done on this version and stabilized. Upgrading again may require months of effort. Of course upgrading is planned for later products. > Never create a new device using the 4.9.y kernel tree unless you have someone > else doing the support for it > (i.e. a SoC vendor that you are paying support from). > Actually, this is not a new device. Its an older device itself. This is an experimental activity.
Re: [IMX] [DRM]: suspend/resume support
On Wed, Jun 19, 2019 at 7:14 PM Fabio Estevam wrote:
>
> On Wed, Jun 19, 2019 at 10:33 AM Pintu Agarwal wrote:
>
> > You can think that the version I am using right now is almost 4.9 itself.
>
> "almost 4.9" does not help, sorry.
>
> > Upgrading again to higher kernel version is again difficult, also
> > customer does not want it.
>
> dw-hdmi is well supported on i.MX6 with mainline, so you could simply try
> that.
>
> Try booting 5.1.11 on your custom board with a very minimal dts with
> HDMI support.
>
Okay. I will surely try it on another IMX6 fresh board.
With 5.1.11 you mean the kernel from mainline kernel.org
Or, is there a separate kernel repo for imx6. If yes, please let me know.
> Then you can test suspend/resume and see if HDMI hangs or not.
>
By this suspend/resume, you mean "suspend-to-ram" or "suspend-to-disk" ?
> > Another approach I tried is, installing hdmi {dw-hdmi.ko,
> > dw_hdmi-imx.ko} as a module, just after the resume.
> > With this also system hangs during installation of dw_hdmi-imx.ko at
> > below location:
> >
> > imx_drm_driver_load(..)
> > |
> > |--> component_bind_all(...)
> > |
> > |-> component_bind(ipu)
> > |
> > |
> > ipu_drm_bind(..)
> > |
> > |-> ipu_crtc_init(..)
> > |
> > |-> ipu_plane_irq(..)
> > |
> > | > << __HANGS HERE__ >>
>
> I am not able to reproduce this hang. As I mentioned yesterday
> suspend/resume is working just fine.
>
This scenario is not with suspend/resume.
This hang is, when we make hdmi as a loadable module (.ko) and trying
to install it after resume.
In this case, suspend/resume will not come into picture. Not sure why
it still hangs.
Do you have any clue for this scenario?
Re: [IMX] [DRM]: suspend/resume support
On Tue, Jun 18, 2019 at 8:39 PM Fabio Estevam wrote:
>
> On Tue, Jun 18, 2019 at 11:46 AM Pintu Agarwal wrote:
>
> > Thank you so much for your reply.
> > Yes, I already checked the latest mainline kernel changes until 5.2-**.
> > I see that there are many cleanup related changes, but still I see
> > that suspend/resume functions are missing in dw_hdmi-imx driver.
>
> Please see this recently submitted patch:
> https://lore.kernel.org/patchwork/patch/1084057/
>
Okay. Thank you for this reference. This can be definitely helpful.
But a quick look may be feel, this is slightly different.
Anyways, I will have a deeper look.
> > So, I am trying to implement myself.
> > Also, I see that suspend/resume is missing even in :
> > drivers/gpu/drm/imx/ipuv3-crtc.c
> > I am trying this also (not sure if we need this as well).
> >
> > Can you point out some specific patches which can be helpful ?
> >
> > Currently, what I observed is that hdmi bind() functions are not getting
> > called.
> > Not sure who is responsible for triggering this bind function.
> > Or, irq remains disabled after resume, and we need to enable it back
> > again (but how ?)
> > Or, we may need to enable vblank events and thus irqs can be enabled.
> >
> > So, I am exploring many possibilities.
> > If you have any suggestions please let me know.
>
> The suggestion I have is to try to use latest mainline kernel. If you
> see any issues with it, please report.
>
> The combination you mentioned in a prior thread (kernel 3.10 +
> backported drm patches 4.9) is not really something the community can
> help you.
You can think that the version I am using right now is almost 4.9 itself.
Upgrading again to higher kernel version is again difficult, also
customer does not want it.
BTW, I am not talking about runtime suspend/resume.
I know it works normally.
I just need some approach and pointers.
Like someone said rightly, I may need to re-implement bind() function
again in resume path.
I already tried doing hdmi_power_on/off and with that I could invoke
hdmi_setup() function, but the system hang after that.
Another approach I tried is, installing hdmi {dw-hdmi.ko,
dw_hdmi-imx.ko} as a module, just after the resume.
With this also system hangs during installation of dw_hdmi-imx.ko at
below location:
imx_drm_driver_load(..)
|
|--> component_bind_all(...)
|
|-> component_bind(ipu)
|
|
ipu_drm_bind(..)
|
|-> ipu_crtc_init(..)
|
|-> ipu_plane_irq(..)
|
| > << __HANGS HERE__ >>
|
|-> devm_request_irq(ipu_irq_handler)
So, ipu_drm_bind() never returns, and hangs.
--
So, my question is, which approach is better (as a first trial):
1) Installing hdmi as a module, after resume ?
2) Or, implementing the suspend/resume itself ?
Re: [IMX] [DRM]: suspend/resume support
On Tue, Jun 18, 2019 at 7:32 PM Fabio Estevam wrote: > > Hi Pintu, > > On Mon, Jun 17, 2019 at 10:50 AM Pintu Agarwal wrote: > > > > Hi All, > > > > I am trying to implement suspend/resume functionality to to imx-hdmi driver: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/imx/dw_hdmi-imx.c?h=v4.9.181 > > Please test a recent kernel, such as 5.1.11. I recall that last time > you reported an issue with the dw hdmi you were running kernel 3.10 > with backported patches from 4.9. > > Just tried suspend/resume on a imx6q board and HDMI behaves correctly. Thank you so much for your reply. Yes, I already checked the latest mainline kernel changes until 5.2-**. I see that there are many cleanup related changes, but still I see that suspend/resume functions are missing in dw_hdmi-imx driver. So, I am trying to implement myself. Also, I see that suspend/resume is missing even in : drivers/gpu/drm/imx/ipuv3-crtc.c I am trying this also (not sure if we need this as well). Can you point out some specific patches which can be helpful ? Currently, what I observed is that hdmi bind() functions are not getting called. Not sure who is responsible for triggering this bind function. Or, irq remains disabled after resume, and we need to enable it back again (but how ?) Or, we may need to enable vblank events and thus irqs can be enabled. So, I am exploring many possibilities. If you have any suggestions please let me know. Thanks, Pintu
[IMX] [DRM]: suspend/resume support
Hi All, I am trying to implement suspend/resume functionality to to imx-hdmi driver: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/imx/dw_hdmi-imx.c?h=v4.9.181 So, I need some help about this. I logged the request in imx community, but it seems they are not responding. Firstly I expect nxp community members to support (if anybody here). Otherwise, I guess, people who are experts here and have prior experience in implementing suspend/resume for their drivers, should be able to give me some guidance. Currently, I am trying to understand what needs to be taken care during suspend/resume. With some reference, I figured out that hdmi power off/on needs to be done during suspend/resume. But after resume, system is hanging. It seems like vblank events are not getting triggered after the resume. May be irq remains disabled after resume, I need to figure out some way to enable the all the irqs again. Even if I try to install hdmi driver as a dynamic loadable module, still I get the same issue. So, I wonder, what is the right way to handle suspend/resume for any driver. Some clue/reference should help me to keep going... Regards, Pintu
Re: Pause a process execution from external program
On Fri, Jun 14, 2019 at 1:13 AM Valdis Klētnieks wrote: > > On Thu, 13 Jun 2019 13:22:12 +0530, Shyam Saini said: > > > from command line we use ctrl-z to stop execution of a foreground > > process but you can program > > SIGTSTP signal handler in your application code to do the same. > > Note that if you simply fail to include a signal handler for SIGSTOP and > SIGCONT, it will Do The Right Thing. The only programs that need worry about > SIGTSTP are ones like 'vi' that may want to do something (like restore the > terminal state from raw to cooked mode, etc) before they stop. That's why you > can control-z /bin/cat without it having to include a signal handler for it. > > % kill -STOP `pidof process-to-stop` # stop it > % kill -CONT `pidof process-to-stop` # and make it run again. > > No source code modifications needed. No source needed. > > Now, if you want to make it stop at a *specific point*, then you're into > ptrace territory, and source will be helpful. > Yes, I think ptrace can serve our purpose. Thank you so much. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Pause a process execution from external program
On Thu, Jun 13, 2019 at 8:52 PM Elias Kouskoumvekakis wrote: > > On Thu, Jun 13, 2019 at 10:45 AM Pintu Agarwal wrote: > > > > For some reason, I want to halt/pause the execution (for some > > specified time) of a running process/thread (at some location), > > without modified the source, may be by firing some events/signals from > > an another external program, by specifying the address location or a > > line number. > > > > Is this possible ? > > Hi Pintu, > > have you looked at the CRIU project which can do a checkpoint / restore of a > running process? > > https://criu.org/Main_Page > > I think it's what you need, although I've never used it myself. > OK. Thank you so much I will surely look into it. Currently, we are exploring using ptrace. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Pause a process execution from external program
On Thu, Jun 13, 2019 at 1:22 PM Shyam Saini wrote: > > Hi Pintu, > > > > Hi All, > > I was just wondering if this is possible in the Linux world. > > My requirement is: > > For some reason, I want to halt/pause the execution (for some > > specified time) of a running process/thread (at some location), > > without modified the source, may be by firing some events/signals from > > an another external program, by specifying the address location or a > > line number. > > > > Is this possible ? > > May be by using some system call, or other mechanism using the process PID. > > Assume that its a debugging system with all root privileges. > > > > Basically, its just like how "gdb" is able to set the break-point in a > > program, and able to stop its execution exactly at that location. > > I am wondering what mechanism "gdb" uses to do this? > > gdb uses ptrace system call, may you can explore ptrace? > oh thank you so much. Yes, ptrace is going to be very helpful. I will explore more on this and come back if required. > > I tried to check here, but could find the exact place, where this is > > handled: > > https://github.com/bminor/binutils-gdb/blob/master/gdb/breakpoint.c > > from command line we use ctrl-z to stop execution of a foreground > process but you can program > SIGTSTP signal handler in your application code to do the same. > > is that you want ? > This required source code modification in the target program, so I don't want this. > Thanks a lot, > Shyam ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Pause a process execution from external program
Hi All, I was just wondering if this is possible in the Linux world. My requirement is: For some reason, I want to halt/pause the execution (for some specified time) of a running process/thread (at some location), without modified the source, may be by firing some events/signals from an another external program, by specifying the address location or a line number. Is this possible ? May be by using some system call, or other mechanism using the process PID. Assume that its a debugging system with all root privileges. Basically, its just like how "gdb" is able to set the break-point in a program, and able to stop its execution exactly at that location. I am wondering what mechanism "gdb" uses to do this? I tried to check here, but could find the exact place, where this is handled: https://github.com/bminor/binutils-gdb/blob/master/gdb/breakpoint.c Unfortunately, I cannot use "gdb", but I wanted to borrow this mechanism only to serve my purpose. If anyone is aware, please let me know. I will share my findings here, after I get some useful results of my experimentation. Thank you for your help! Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Building and cross-compiling kernel source on Mac OS
Hi, I have a Mac Book Pro with macOS High Sierra 10.13.x installed (with Mac OS Extended (Journaled, Encrypted)). I also have the Xcode installed so I can compile a C program using gcc. Now, I wanted to build linux kernel code (cross compile for arm or risc-v) on Mac OS. I know this is possible, but I am not familiar with the steps. If somebody have the step by step guide, please share. If this works, then I don't need to use Virtual Box inside MAC to build the kernel code. Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: ssh session with qemu-arm using busybox
On Tue, Mar 12, 2019 at 7:41 PM Suzuki K Poulose wrote: > > > > On 12/03/2019 14:02, Pintu Agarwal wrote: > >> > >> -netdev user,id=unet,hostfwd=tcp::-:22 \ > >> -net user \ > >> > >> and you 'll get guest's port 22 to be forwarded to hosts port , so > >> you can do > >> > >> ssh root@localhost: > >> > >> from the host. > >> > > > > I tried many different options, but unfortunately none worked for me. > > 1) > > qemu-system-arm -M vexpress-a9 -m 1024M -kernel > > ../KERNEL/linux/arch/arm/boot/zImage -dtb > > ../KERNEL/linux/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -initrd > > rootfs.img.gz -append "console=ttyAMA0 root=/dev/ram rdinit=/sbin/init > > ip=dhcp" -nographic -smp 4 -netdev user,id=unet,hostfwd=tcp::-:22 > > -net user > > > > With this the eth0 interface is removed, and I see this message > > (although login works): > > qemu-system-arm: warning: hub 0 with no nics > > qemu-system-arm: warning: netdev unet has no peer > > Booting Linux on physical CPU 0x0 > > > > NET: Registered protocol family 17 > > > > Run /sbin/init as init process > > ifconfig: SIOCSIFADDR: No such device > > route: SIOCADDRT: Network is unreachable > > > > But, ssh is still not working. > > ssh root@localhost: > > ssh: Could not resolve hostname localhost:: Name or service not known > > man ssh > > + > > Make sure you have sshd in your custom rootfs and has been stared. > My busybox is a very minimal rootfs. It hardly contains any commands. Is there any precompiled busybox for arm (cpio image), available (with ssh, scp and networking in-built), which I can use directly to boot ? what else I am missing to make ssh/scp working on qemu ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: ssh session with qemu-arm using busybox
> > -netdev user,id=unet,hostfwd=tcp::-:22 \ > -net user \ > > and you 'll get guest's port 22 to be forwarded to hosts port , so > you can do > > ssh root@localhost: > > from the host. > I tried many different options, but unfortunately none worked for me. 1) qemu-system-arm -M vexpress-a9 -m 1024M -kernel ../KERNEL/linux/arch/arm/boot/zImage -dtb ../KERNEL/linux/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -initrd rootfs.img.gz -append "console=ttyAMA0 root=/dev/ram rdinit=/sbin/init ip=dhcp" -nographic -smp 4 -netdev user,id=unet,hostfwd=tcp::-:22 -net user With this the eth0 interface is removed, and I see this message (although login works): qemu-system-arm: warning: hub 0 with no nics qemu-system-arm: warning: netdev unet has no peer Booting Linux on physical CPU 0x0 NET: Registered protocol family 17 Run /sbin/init as init process ifconfig: SIOCSIFADDR: No such device route: SIOCADDRT: Network is unreachable But, ssh is still not working. ssh root@localhost: ssh: Could not resolve hostname localhost:: Name or service not known 2) if I give "-net nic" I get eth0 interface but still ssh does not work. qemu-system-arm: warning: netdev unet has no peer Booting Linux on physical CPU 0x0 3) With this there is no error, but still ssh not working qemu-system-arm -M vexpress-a9 -m 1024M -kernel ../KERNEL/linux/arch/arm/boot/zImage -dtb ../KERNEL/linux/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -initrd rootfs.img.gz -append "console=ttyAMA0 root=/dev/ram rdinit=/sbin/init" -nographic -netdev user,id=net0,hostfwd=tcp::-:22 -device virtio-net-device,netdev=net0 -net user -net nic ssh root@localhost: ssh: Could not resolve hostname localhost:: Name or service not known 4) I also followed the steps mentioned in the below document, but its same result: https://wiki.qemu.org/Documentation/Networking - So, I have some doubts: - Do, I need anything to be configured on host PC as well ? I am using Ubuntu 16.04 desktop, and it is connected to only one office LAN network - Do I need any network configuration changes on host ? - Do I need to enable any thing in kernel side ? - I am using minimal busybox and I see there is no "ssh" command there. Do I need a different busybox or a dropbear ? - Will it work easily with buildroot ? - Is there any precompiled arm32-rootfs image present somewhere, which which ssh can work by default ? Because, I really don't care much about user side, so any arm-rootfs should be fine for me - I haven't really explored "bridge/tap" network yet. Is that worth to try in these conditions. Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
ssh session with qemu-arm using busybox
Hi, I have a qemu-arm setup with busybox which I normally use to test my kernel changes. I use this command to boot it: QEMU-ARM$ qemu-system-arm -M vexpress-a9 -m 1024M -kernel ../KERNEL/linux/arch/arm/boot/zImage -dtb ../KERNEL/linux/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -initrd rootfs.img.gz -append "console=ttyAMA0 root=/dev/ram rdinit=/sbin/init ip=dhcp" -nographic -smp 4 This includes, my own custom kernel and rootfs build. For rootfs I use busybox and create cpio image and use it as initrd. But, every time, if I have to copy some files inside qemu, I need to create create roofs image. This is painful. So, now I am exploring how to transfer files from my ubuntu pc to qemu-session using "ssh". I know this is possible, but I am still not successful, and bit lazy to explore these. I am sure, many of you people would have explored already "how to use ssh over qemu" and found a easy method. So, if anybody have easy setup please share with me. I could see that after adding "ip=dhcp" I get the eth0 interface like this: / # ifconfig eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1180 (1.1 KiB) TX bytes:1180 (1.1 KiB) Interrupt:22 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) But I could not ping it from ubuntu PC. Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: arm64 Kernel build for qemu-system-aarch64 ?
On Fri, Feb 22, 2019 at 7:41 PM Mark Rutland wrote:
>
> On Fri, Feb 22, 2019 at 07:17:00PM +0530, Pintu Agarwal wrote:
> > Hi All,
>
> Hi,
>
> > I want to build Linux Kernel 4.20 for arm64 and use it on qemu-arm64.
> > I see that there is a defconfig available in arch/arm64/configs/defconfig
> > But I am not sure whether it will work for qemu-arm64, and by default
> > which machine type is supported.
> >
> > I already have working setup for qemu-arm for both versatile and
> > vexpress machine. There is already a defconfig available for these
> > under arch/arm.
> > So I can build the kernel for it.
> >
> > But, whether these defconfig are supported for arm64 ?
> > If anybody have setup for qemu-arm64 kernel, please share the steps.
> > About rootfs, I am planning to use the arm32 version of busybox itself.
>
> The arm64 defconfig is intended to work for all platforms.
>
> I use that with qemu's '-machine virt'. Assuming you use virtio-net and
> virtio-block, no additional drivers are required.
>
> For example, I can boot a defconfig kernel using the followign QEMU options:
>
> qemu-system-aarch64 \
> -m 2048 -smp 4 \
> -net nic \
> -net user,host=10.0.2.10,hostfwd=tcp::65022-:22 \
> -nographic \
> -no-reboot \
> -machine virt,accel=kvm,gic_version=host \
> -cpu host \
> -hda ${FILESYSTEM} \
> -snapshot \
> -kernel ${KERNEL} \
> -append "earlycon root=/dev/vda panic_on_warn"
>
> Thanks,
> Mark.
oh thank you so much for your information.
I was exactly looking for this option.
Let me try it on Monday.
Thanks
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
arm64 Kernel build for qemu-system-aarch64 ?
Hi All, I want to build Linux Kernel 4.20 for arm64 and use it on qemu-arm64. I see that there is a defconfig available in arch/arm64/configs/defconfig But I am not sure whether it will work for qemu-arm64, and by default which machine type is supported. I already have working setup for qemu-arm for both versatile and vexpress machine. There is already a defconfig available for these under arch/arm. So I can build the kernel for it. But, whether these defconfig are supported for arm64 ? If anybody have setup for qemu-arm64 kernel, please share the steps. About rootfs, I am planning to use the arm32 version of busybox itself. Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Need help: how to locate failure from irq_chip subsystem
On Fri, Jan 18, 2019 at 5:23 PM Sai Prakash Ranjan wrote: > > On 1/18/2019 4:50 PM, Pintu Agarwal wrote: > >>>> Could you please tell which QCOM SoC this board is based on? > >>>> > >>> > >>> Snapdragon 845 with kernel 4.9.x > >>> I want to know from which subsystem it is triggered:drivers/soc/qcom/ > >>> > >> > >> Irqchip driver is "drivers/irqchip/irq-gic-v3.c". The kernel you are > >> using is msm-4.9 I suppose or some other kernel? > >> > > Yes, I am using customized version of msm-4.9 kernel based on Android. > > And yes the irqchip driver is: irq-gic-v3, which I can see from config. > > > > But, what I wanted to know is, how to find out which driver module > > (hopefully under: /drivers/soc/qcom/) that register with this > > irq_chip, is getting triggered at the time of crash ? > > So, that I can implement irq_hold function for it, which is the cause of > > crash. > > > > Hmm, since this is a bootup crash, *initcall_debug* should help. > Add "initcall_debug ignore_loglevel" to kernel commandline and > check the last log before crash. > OK thanks Sai, for your suggestions. Yes, I already tried that, but it did not help much. Anyways, I could finally find the culprit driver, from where null reference is coming. So, that issue is fixed. But, now I am looking into another issue. If required, I will post further... Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Need help: how to locate failure from irq_chip subsystem
> >> Could you please tell which QCOM SoC this board is based on? > >> > > > > Snapdragon 845 with kernel 4.9.x > > I want to know from which subsystem it is triggered:drivers/soc/qcom/ > > > > Irqchip driver is "drivers/irqchip/irq-gic-v3.c". The kernel you are > using is msm-4.9 I suppose or some other kernel? > Yes, I am using customized version of msm-4.9 kernel based on Android. And yes the irqchip driver is: irq-gic-v3, which I can see from config. But, what I wanted to know is, how to find out which driver module (hopefully under: /drivers/soc/qcom/) that register with this irq_chip, is getting triggered at the time of crash ? So, that I can implement irq_hold function for it, which is the cause of crash. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Need help: how to locate failure from irq_chip subsystem
On Fri, Jan 18, 2019 at 3:54 PM Sai Prakash Ranjan wrote: > > Hi Pintu-san, > > On 1/18/2019 3:38 PM, Pintu Agarwal wrote: > > Hi All, > > > > Currently, I am trying to debug a boot up crash on some qualcomm > > snapdragon arm64 board with kernel 4.9. > > I could find the cause of the failure, but I am unable to locate from > > which subsystem/drivers this is getting triggered. > > If you have any ideas or suggestions to locate the issue, please let me > > know. > > > > This is the snapshot of crash logs: > > [6.907065] Unable to handle kernel NULL pointer dereference at > > virtual address > > [6.973938] PC is at 0x0 > > [6.976503] LR is at __ipipe_ack_fasteoi_irq+0x28/0x38 > > [7.151078] Process qmp_aop (pid: 24, stack limit = 0xfffbedc18000) > > [7.242668] [< (null)>] (null) > > [7.247416] [] __ipipe_dispatch_irq+0x78/0x340 > > [7.253469] [] __ipipe_grab_irq+0x5c/0xd0 > > [7.341538] [] gic_handle_irq+0xc0/0x154 > > > > [6.288581] [PINTU]: __ipipe_ack_fasteoi_irq - called > > [6.293698] [PINTU]: __ipipe_ack_fasteoi_irq: > > desc->irq_data.chip->irq_hold is NULL > > > > When I check, I found that the irq_hold implementation is missing in > > one of the irq_chip driver (expected by ipipe), which I am supposed to > > implement. > > > > But I am unable to locate which irq_chip driver. > > If there are any good techniques to locate this in kernel, please help. > > > > Could you please tell which QCOM SoC this board is based on? > Snapdragon 845 with kernel 4.9.x I want to know from which subsystem it is triggered:drivers/soc/qcom/ > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Need help: how to locate failure from irq_chip subsystem
Hi All, Currently, I am trying to debug a boot up crash on some qualcomm snapdragon arm64 board with kernel 4.9. I could find the cause of the failure, but I am unable to locate from which subsystem/drivers this is getting triggered. If you have any ideas or suggestions to locate the issue, please let me know. This is the snapshot of crash logs: [6.907065] Unable to handle kernel NULL pointer dereference at virtual address [6.973938] PC is at 0x0 [6.976503] LR is at __ipipe_ack_fasteoi_irq+0x28/0x38 [7.151078] Process qmp_aop (pid: 24, stack limit = 0xfffbedc18000) [7.242668] [< (null)>] (null) [7.247416] [] __ipipe_dispatch_irq+0x78/0x340 [7.253469] [] __ipipe_grab_irq+0x5c/0xd0 [7.341538] [] gic_handle_irq+0xc0/0x154 [6.288581] [PINTU]: __ipipe_ack_fasteoi_irq - called [6.293698] [PINTU]: __ipipe_ack_fasteoi_irq: desc->irq_data.chip->irq_hold is NULL When I check, I found that the irq_hold implementation is missing in one of the irq_chip driver (expected by ipipe), which I am supposed to implement. But I am unable to locate which irq_chip driver. If there are any good techniques to locate this in kernel, please help. Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [ARM64] Printing IRQ stack usage information
On Sat, Nov 17, 2018 at 6:36 PM Pintu Agarwal wrote:
>
> On Sat, Nov 17, 2018 at 12:02 AM wrote:
> >
> > > But my concern is that if I dump it from irq handler, I will get
> > > information only for the current cpu.
> > > How do I store and get the information for all the cpu from the boot time
> > > ?
> >
> > Make the high-water mark a per-cpu variable.
> >
> > > From where do I call my dump_irq_stack_info() [some where during the
> > > entry/exit part of the irq handler], so that I could dump information
> > > for all the handler at boot time itself ?
> >
> > No, you don't do a dump-stack during entry/exit. You just maintain a
> > high-water
> > value in the exit,
>
> Which is the right place to keep track of this
> high-water-irq-stack-usage (per_cpu)
> in arch/arm64/* ?
>
I tried to create a per-cpu irq_stack_usage variable like this in :
arch/arm64/include/asm/hardirq.h
+DECLARE_PER_CPU(unsigned int, irq_stack_usage);
But, I could not figure out, from where to fill these variable for irq
stack usage.
+ sp = current_stack_pointer;
+ if (on_irq_stack(sp, cpu)) {
+ stack_start = (unsigned long)per_cpu(irq_stack, cpu);
+ last_usage = per_cpu(irq_stack_usage, cpu);
+ curr_usage = sp - stack_start;
+ pr_info("cpu:%d : sp: %lu, stack_start: %lu, usage: %lu\n",
cpu, sp, stack_start, (sp - stack_start));
+ if (curr_usage > last_usage)
+ per_cpu(irq_stack_usage, cpu) = curr_usage;
+ }
Which is the best place to invoke this ?
I have the following option:
1. kernel/softirq.c => __do_softirq()
2. arch/arm64/kernel/smp.c => handle_IPI()
3. kernel/softirq.c => irq_exit()
4. ???
Please let me know.
Thank You!
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [ARM64] Printing IRQ stack usage information
On Sat, Nov 17, 2018 at 12:02 AM wrote: > > On Fri, 16 Nov 2018 23:13:48 +0530, Pintu Agarwal said: > > On Fri, Nov 16, 2018 at 10:16 PM wrote: > > > > Congrats. You just re-invented DEBUG_STACK_USAGE, which just keeps a > > > high-water mark > > > for stack usage. > > > > So, you mean to say, my implementation is good enough to get the > > irq_stack usage, from the interrupt handler ? > > No - your code doesn't keep a high-water mark (which should probably be > hooked into the IRQ exit code. > > > But my concern is that if I dump it from irq handler, I will get > > information only for the current cpu. > > How do I store and get the information for all the cpu from the boot time ? > > Make the high-water mark a per-cpu variable. > > > From where do I call my dump_irq_stack_info() [some where during the > > entry/exit part of the irq handler], so that I could dump information > > for all the handler at boot time itself ? > > No, you don't do a dump-stack during entry/exit. You just maintain a > high-water > value in the exit, Which is the right place to keep track of this high-water-irq-stack-usage (per_cpu) in arch/arm64/* ? > and then you create a /proc/something or similar that when > read does a 'foreach CPU do print_high_water_irq'. > Ok got it. > > Like I would to capture these information: > > - What was the name of the handler ? > > - Which cpu was executing it ? > > - How much irq stack (max value, same like high water mark) were used > > at that time ? > > First, do the easy part and find out if you even *care* once you see actual > numbers. If your IRQ stack is 8K but you never use more than 2500 bytes, > do you *really* care about the name of the handler anymore? > Hmm, yes, getting the name of the handler is not so important in the first run. > Also, see the code for /proc/interrupts to see how it keeps track of the > interrupts per CPU - maybe all you need to do is change each entry from > a 'count' to 'count, highwater'. Ok thanks, thats a good pointer. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [ARM64] Printing IRQ stack usage information
On Fri, Nov 16, 2018 at 10:16 PM wrote: > > On Fri, 16 Nov 2018 20:10:28 +0530, Pintu Agarwal said: > > > > Look at the code controlled by '#ifdef CONFIG_DEBUG_STACK_USAGE' > > > For example: is it possible to keep storing the irq_stack_usage (for > > each cpu in a variable) information from boot time, and then use this > > variable to dump the irq_stack information, after the system booted, > > may be from proc entry ? > > Congrats. You just re-invented DEBUG_STACK_USAGE, which just keeps a > high-water mark > for stack usage. So, you mean to say, my implementation is good enough to get the irq_stack usage, from the interrupt handler ? But my concern is that if I dump it from irq handler, I will get information only for the current cpu. How do I store and get the information for all the cpu from the boot time ? >From where do I call my dump_irq_stack_info() [some where during the entry/exit part of the irq handler], so that I could dump information for all the handler at boot time itself ? Like I would to capture these information: - What was the name of the handler ? - Which cpu was executing it ? - How much irq stack (max value, same like high water mark) were used at that time ? Where can I collect these information from the boot time ? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [ARM64] Printing IRQ stack usage information
On Fri, Nov 16, 2018 at 5:03 PM wrote:
>
> On Fri, 16 Nov 2018 11:44:36 +0530, Pintu Agarwal said:
>
> > > If your question is "Did one
> > > of the CPUs blow out its IRQ stack (or come close to doing so)?" there's
> > > better
> > > approaches.
> > >
> > Yes, exactly, this is what the main intention.
> > If you have any better idea about this approach, please refer me.
> > It will be of great help.
>
> Look at the code controlled by '#ifdef CONFIG_DEBUG_STACK_USAGE'
> which does the same thing for process stacks, or CONFIG_SCHED_STACK_END_CHECK
> or the use of guard pages for detecting stack overrun
Hi,
Thank you so much for your reference.
Yes, I have already gone through the process stack usage, which I
found slightly different.
However, I will go through it in more detail, and see if I can gain
some ideas from there.
I found a similar irq_stack_usage implementation in parisc architecture:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/parisc/kernel/irq.c?h=v4.19.1
I have also gone through the unwind_frame() part in arch/arm64/stacktrace.c:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/kernel/stacktrace.c?h=v4.9.137
By referring to these, I tried to make a similar approach for arm64:
I created a new function: dump_irq_stack_info()
[arch/arm64/kernel/traps.c], and called it as part of show_stack().
This is the experimental patch I created.
Note: This is just for my experiment purpose. I know this is ugly and
in very bad shape right now.
It is only to get some idea about irq stack usage.
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 11e5eae..6ac855d 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -214,9 +214,39 @@ static void dump_backtrace(struct pt_regs *regs,
struct task_struct *tsk)
}
}
+void dump_irq_stack_info(void)
+{
+int cpu, actual;
+unsigned long irq_stack_ptr;
+unsigned long stack_start;
+unsigned long free_stack;
+
+actual = IRQ_STACK_SIZE;
+free_stack = 0;
+pr_info("CPU UNUSED-STACK ACTUAL-STACK\n");
+
+ for_each_present_cpu(cpu) {
+ unsigned long sp;
+ irq_stack_ptr = IRQ_STACK_PTR(cpu);
+ sp = current_stack_pointer;
+ //sp = IRQ_STACK_TO_TASK_STACK(irq_stack_ptr);
+ stack_start = (unsigned long)per_cpu(irq_stack, cpu);
+ if (on_irq_stack(sp, cpu)) {
+ pr_info("cpu:%d : sp: on irq_stack\n", cpu);
+ free_stack = sp - stack_start;
+ } else {
+ free_stack = irq_stack_ptr - stack_start;
+ }
+ pr_info("%2d %10lu %10d\n", cpu, free_stack, actual);
+ }
+}
+
void show_stack(struct task_struct *tsk, unsigned long *sp)
{
dump_backtrace(NULL, tsk);
+ dump_irq_stack_info();
barrier();
}
Then, I developed a sample kernel module for timer handler
(timerirq.c) and called the dump_stack() function from inside my timer
interrupt handler.
The dump_stack() will internally call show_stack(), which will then
call our function: dump_irq_stack_info().
/* From interrupt context */
static void my_timer_irq_handler(unsigned long ptr)
{
int i;
unsigned long flags;
if (in_interrupt()) {
pr_info("[timerirq]: %s: in interrupt context, count: %d\n",
__func__, count);
spin_lock_irqsave(&mylock, flags);
+ dump_stack();
spin_unlock_irqrestore(&mylock, flags);
} else {
/* This is not needed here*/
}
tasklet_schedule(&my_tasklet);
}
OUTPUT:
With this, I got the below output as part of dump_stack() and backtrace:
[ 43.267923] CPU UNUSED-STACK ACTUAL-STACK
[ 43.271925] 0 16368 16384
[ 43.275493] 1 16368 16384
[ 43.279061] 2 16368 16384
[ 43.282628] cpu:3 : sp: on irq_stack
[ 43.286195] 3 15616 16384
[ 43.289762] 4 16368 16384
[ 43.293330] 5 16368 16384
[ 43.296898] 6 16368 16384
[ 43.300465] 7 16368 16384
So, I observed that my interrupt handler was executed by cpu3, and
it's irq_stack usage is shown:
3 15616 16384
With this information, I can know that which interrupt handler is
using how much irq_stack ?
Is this approach valid ?
Or still there is much better way to dump the information ?
For example: is it possible to keep storing the irq_stack_usage (for
each cpu in a variable) information from boot time, and then use this
variable to dump the irq_stack information, after the system booted,
may be from proc entry ?
Thanks,
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [ARM64] Printing IRQ stack usage information
On Thu, 15 Nov 2018, 10:19 pm
> On Thu, 15 Nov 2018 18:52:39 +0530, Pintu Agarwal said:
>
> > Currently, when I tested this (as a proc interface), I got the below output:
> > CPUUNUSED-STACKACTUAL-STACK
> > 0 16368 16384
>
> > 3) How should I test it to get the different usage values for unused stack ?
> > Can I get these values by implementing a sample interrupt handler,
> > and printing information from there?
>
> Hint 1: If you're in a state where seq_printf() is legal, how many IRQ's are
> on this processor's IRQ stack?
>
> Hint 2: What are the chances that some other CPU is currently in an IRQ?
> (run 'top' and look for what percent of time that's happening)
>
> Hint 3: what are the chances that the value of irq_stack_ptr is already stale
> by the time seq_printf() finishes running?
>
> Hint 4: what happens to the validity of your output if you get rescheduled
> in the middle of that for_each loop?
>
> (In other words, this code is terribly racy and is probably not going to
> answer
> whatever debugging question you were working on..
Okay. Thanks so much for your hints.
Yes, I understand that this code is horribly ugly and bad.
But this is only to understand if the below logic is fine to get the
irq stack usage:
{{{
for_each_present_cpu(cpu) {
irq_stack_ptr = IRQ_STACK_PTR(cpu);
//unsigned long sp = current_stack_pointer;
stack_start = (unsigned long)per_cpu(irq_stack, cpu);
free_stack = irq_stack_ptr - stack_start;
seq_printf(m, "%2d %10lu %10d\n", cpu, free_stack, actual);
}
}}}
Of course, final plan is not the proc entry, but to find a relevant
place to invoke it, probably during boot time, or during backtrace.
> If your question is "Did one
> of the CPUs blow out its IRQ stack (or come close to doing so)?" there's
> better
> approaches.
>
Yes, exactly, this is what the main intention.
If you have any better idea about this approach, please refer me.
It will be of great help.
Thank You!
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[ARM64] Printing IRQ stack usage information
Hi All,
I have a requirement in printing irq stack usage information for each cpu.
I am using the following:
Linux Kernel: 4.9.x
Board: hikey620 (arm64, armv8 with 8 cores)
Platform: Ubuntu 14 debian
As a vague idea, I tried to implement like this:
-
static int dump_irq_stack_info(void)
{
int cpu, actual;
unsigned long irq_stack_ptr;
//unsigned long sp, sp1;
unsigned long stack_start;
unsigned long used;
actual = IRQ_STACK_SIZE;
used = 0;
pr_info("CPU UNUSED-STACK ACTUAL-STACK\n");
//seq_printf(m, "CPU UNUSED-STACK ACTUAL-STACK\n");
for_each_present_cpu(cpu) {
irq_stack_ptr = IRQ_STACK_PTR(cpu);
//sp1 = current_stack_pointer;
//sp = IRQ_STACK_TO_TASK_STACK(irq_stack_ptr);
stack_start = (unsigned long)per_cpu(irq_stack, cpu);
used = irq_stack_ptr - stack_start;
pr_info("%2d %10lu %10d\n", cpu, used, actual);
//seq_printf(m, "%2d %10lu %10d\n", cpu, used, actual);
}
return 0;
}
-
Currently, when I tested this (as a proc interface), I got the below output:
CPUUNUSED-STACKACTUAL-STACK
0 16368 16384
1 16368 16384
2 16368 16384
3 16368 16384
4 16368 16384
5 16368 16384
6 16368 16384
7 16368 16384
-
But, I have some doubts:
1) I am not sure if my implementation is in right direction, or the
logic is totally wrong.
2) Is there better way to perform the similar objective?
3) How should I test it to get the different usage values for unused stack ?
Can I get these values by implementing a sample interrupt handler,
and printing information from there?
If this works, then I want to use it as part of dump_backtrace() function.
If anybody have done a similar thing in past, or have some ideas to
share, please help me.
Note: This is required only for our internal debugging purpose.
Regards,
Pintu
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Creating compressed backing_store as swapfile
On Mon, Nov 5, 2018 at 9:37 PM Austin S. Hemmelgarn wrote: > > On 11/5/2018 10:58 AM, Adam Borowski wrote: > > On Mon, Nov 05, 2018 at 08:31:46PM +0530, Pintu Agarwal wrote: > >> Hi, > >> > >> I have one requirement: > >> I wanted to have a swapfile (64MB to 256MB) on my system. > >> But I wanted the data to be compressed and stored on the disk in my > >> swapfile. > >> [Similar to zram, but compressed data should be moved to disk, instead of > >> RAM]. > >> > >> Note: I wanted to optimize RAM space, so performance is not important > >> right now for our requirement. > >> > >> So, what are the options available, to perform this in 4.x kernel version. > >> My Kernel: 4.9.x > >> Board: any - (arm64 mostly). > >> > >> As I know, following are the choices: > >> 1) ZRAM: But it compresses and store data in RAM itself > >> 2) frontswap + zswap : Didn't explore much on this, not sure if this > >> is helpful for our case. > >> 3) Manually creating swapfile: but how to compress it ? > >> 4) Any other options ? > > > > Loop device on any filesystem that can compress (such as btrfs)? The > > performance would suck, though -- besides the indirection of loop, btrfs > > compresses in blocks of 128KB while swap wants 4KB writes. Other similar > > option is qemu-nbd -- it can use compressed disk images and expose them to a > > (local) nbd client. > > Swap on any type of a networked storage device (NBD, iSCSI, ATAoE, etc) > served from the local system is _really_ risky. The moment the local > server process for the storage device gets forced out to swap, you deadlock. > > Performance isn't _too_ bad for the BTRFS case though (I've actually > tested this before), just make sure you disable direct I/O mode on the > loop device, otherwise you run the risk of data corruption. Sorry, btrfs is not an option for us. We want something more lighter weight as our requirement is just < 200 MBs. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Creating compressed backing_store as swapfile
On Mon, Nov 5, 2018 at 9:42 PM wrote: > > On Mon, 05 Nov 2018 20:31:46 +0530, Pintu Agarwal said: > > I wanted to have a swapfile (64MB to 256MB) on my system. > > But I wanted the data to be compressed and stored on the disk in my > > swapfile. > > [Similar to zram, but compressed data should be moved to disk, instead of > > RAM]. > > What platform are you on that you're both storage constrained enough to need > swap, and also so short on disk space that compressing it makes sense? > Understanding the hardware constraints here would help in advising you. > Currently, I am using the minimal platform such as busybox for arm (kind of a ubuntu based debian platform). Also I am trying to do this on an arm based embedded board with 8 GB MMC card and 1 GB RAM. And I am using the ext4 filesystem with Linux Kernel version 4.9.x. So, with 8 GB SD card I have 2 GB left on the storage space. Out of which 64MB - 128MB would be used for swapfile. However, note that this is not the final end product requirement. I am just trying to demonstrate a prototype and use cases. Performance requirement is not that strict right now, as I don't know the end product. However, the system requirement is as minimal as this. The main requirement is, creating a RAM snapshot image, then compressing some of its data and moving to swapfile, so that snapshot image size can be reduced. I guess, ZRAM is not useful here, so I thought to explore some other option such as zswap, etc. ? BTRFS is not an option, though, as we use ext4 and vfat filesystem (only). > > Note: I wanted to optimize RAM space, so performance is not important > > right now for our requirement. > > > > So, what are the options available, to perform this in 4.x kernel version. > > My Kernel: 4.9.x > > Given that this is a greenfield development, why are you picking a kernel > that's 2 years out of date? You *do* realize that 4.9.135 does *not* contain > all the bugfixes since then, only that relatively small subset that qualify > for > 'stable' (see Documentation/process/stable-kernel-rules.rst for the gory > details). > Yes, we want to stick to 4.9 right now, as the end product might be based on this version. However, if higher kernel version have some fixes or good features, we can back port it. > One possible total hack would be to simply use a file-based swap area, > but put the file on a filesystem that supports automatic inline compression. > I know, squashfs is a compressed filesystem, but it is read-only. So its ruled out. > Note that this will probably *totally* suck on performance, because there's > no good way to find where 4K block 11,493 starts inside the compressed > file, so it would have to read/decompress from the file beginning. Also, > if you write data to a previously unused location (or even a previously used > spot that compressed the 4K page to a different length), you have a bad time > inserting it. (Note that zram can avoid most of this because it can (a) keep > a table of pointers to where each page starts and (b) it isn't constrained to > writing to 4K blocks on disk, so if the current compression takes a 4K page > down > to 1,283 bytes, it doesn't have to care *too* much if it stores that someplace > that crosses a page boundary. > > Another thing that you will need to worry about is what happens in low-memory > situations - the time you *most* need to do a swap operation, you may not have > enough memory to do the I/O. zram basically makes sure it *has* the memory > needed beforehand, and swap directly to pre-allocated disk doesn't need much > additional memory. Swap storage requirement would be mostly between 64MB to 256MB (pre-configured). Yes it can be something similar on ZRAM line, may be zram + zswap ? Not sure if this right combination ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Creating compressed backing_store as swapfile
Hi, I have one requirement: I wanted to have a swapfile (64MB to 256MB) on my system. But I wanted the data to be compressed and stored on the disk in my swapfile. [Similar to zram, but compressed data should be moved to disk, instead of RAM]. Note: I wanted to optimize RAM space, so performance is not important right now for our requirement. So, what are the options available, to perform this in 4.x kernel version. My Kernel: 4.9.x Board: any - (arm64 mostly). As I know, following are the choices: 1) ZRAM: But it compresses and store data in RAM itself 2) frontswap + zswap : Didn't explore much on this, not sure if this is helpful for our case. 3) Manually creating swapfile: but how to compress it ? 4) Any other options ? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
