Re: Debugging/fixing a kernel stalled not crashing
>> If it's an issue picking up the root filesystem, you could boot an >> INSTALL type kernel with a built in ramdisk with dhcpcd and sshd >> enabled, [...] > Yes, I plan to test this also, depending on [...] This reminds me of a case I had, once. I wanted to test-boot a particular kernel version on a machine which had no disk interface or network supported by that kernel. (It had USB 3 USB, and the kernel in question didn't support anything past USB 2; and the network interfaces weren't supported either. The kernel was old compared to the hardware.) The machine's ROM code, though, could boot a kernel off a USB thumbdrive just fine. I ended up building a kernel that booted with a SLIPpish interface configured on the console serial port, at an address specified at kernel config time. Running diskless over SLIP on a serial line...well, it was painful, but it worked. If I'd ended up wanting to use that kernel on that hardware more extensively, I probably would have used that kernel to support porting either USB support or Ethernet support, but the desire disappeared before I made any significant progress beyond getting it to boot and run - or, perhaps more accurately, crawl - diskless. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Debugging/fixing a kernel stalled not crashing
Hello, Le Fri, Aug 19, 2022 at 02:36:33PM +0100, David Brownlee a écrit : > Tangentially... > > If it's an issue picking up the root filesystem, you could boot an > INSTALL type kernel with a built in ramdisk with dhcpcd and sshd > enabled, and see if you can ssh into the box (I think someone had > pre-built arm images which did just that, so the code should be out > there :) Yes, I plan to test this also, depending on at what stage my reboot tactics indicates where the problem is. The aim being to be able to connect to a running kernel. When it will be achieved, the harder will have been made. I have already built a custom kernel (with acpismbus* added since the machine has IvyBridge and it is related, and it's not in GENERIC) and will start to debug tomorrow. Best, -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: Devices without power management support
On Fri, Aug 19, 2022 at 01:52:47AM +, Taylor R Campbell wrote:
> All that said: What is the failure mode you're seeing for ihidev that
> blocks suspend?
It fails to read HID descriptor. The ihidev device remains unfunctionnal
and breaks suspend.
I thought about this workaround:
--- sys/dev/i2c/ihidev.c.orig
+++ sys/dev/i2c/ihidev.c
@@ -161,8 +163,17 @@
sc->sc_tag = ia->ia_tag;
sc->sc_addr = ia->ia_addr;
mutex_init(>sc_lock, MUTEX_DEFAULT, IPL_NONE);
+ /*
+* We register null handlers so that a failed attachement
+* does not result in a device that breaks suspend.
+* The real handler are registered at the end of this
+* function on success.
+*/
+ if (!pmf_device_register(self, NULL, NULL))
+ aprint_error_dev(self, "couldn't establish power handler\n");
+
sc->sc_phandle = ia->ia_cookie;
if (ia->ia_cookietype != I2C_COOKIE_ACPI) {
aprint_error(": unsupported device tree type\n");
return;
--
Emmanuel Dreyfus
m...@netbsd.org
Re: Debugging/fixing a kernel stalled not crashing
Tangentially... If it's an issue picking up the root filesystem, you could boot an INSTALL type kernel with a built in ramdisk with dhcpcd and sshd enabled, and see if you can ssh into the box (I think someone had pre-built arm images which did just that, so the code should be out there :) David
Re: Adding ESRT and EFI vars support for fwupd
Date:Fri, 19 Aug 2022 12:40:11 +0200 From:=?UTF-8?Q?Pawe=c5=82_Cichowski?= Message-ID: <56898e46-7714-200b-4528-afffddd6d...@3mdeb.com> | I've built the kernel and release for evbarm aarch64 from the latest | sources and ran it on QEMU. Unfortunately, /dev/efi wasn't present on | the system. That's just because it is not installed by default - as it currently exists (with no tools to use it yet committed) there is little point. However /dev/MAKEDEV should be able to make it, just "sh /dev/MAKEDEV efi" | Is it linked to the issue you talked about (no conversion | between EFI device paths and disks)? No, that's missing userland code. That is, an EFI boot variable (or driver variable) will contain strings which (perhaps indirectly) reference the busses, port numbers, unit numbers, using EFI terminology. A disk name is something more like /dev/wd0e (or NAME=wedge). For the user interface, we'd like to be able to reference devices and partitions using unix style names, not EFI paths. | How should I approach implementing it? As above, that is all it should take (I have done it before). | Or is making a device node manually using mknod the case (I thought | MAKEDEV.tmpl should've added it automatically)? You could also use mknod if you prefer, /sbin/mknod /dev/efi c 361 0 Add options to set the uid/gid/perms if you need (or apply chown[/chgrp] and chmod after, or just accept the default). | Additionally, what ways to debug kernel drivers would you recommend? | `printk` or `aprint_debug`? Depends what the issue is, but in general, while it does need some minor work, that driver works I thing, for as much as it does. | - get table - returns table address by uuid (efi_ops) | - copy table - copies the table from memory to a variable passed by | reference (efi_ops) | - get table size - helper function, returns size of table in bytes | - other operations on efi vars are a second priority, since the main | task is to support ESRT That all sounds reasonable to me. | I reckon these not only need to be added to /dev/efi, but efi_runtime | too (so they become machine dependent). If you have a different view or | any other ideas to extend the implementation please let me know. That I will leave for Jared or someone else to comment on. kre
Re: Adding ESRT and EFI vars support for fwupd
First of all, thank you for your detailed response to my previous message. I have conducted some more research on how to extend EFI support and general kernel hacking. I would like to ask you some more questions, mainly concerning modifying the kernel, since this is my first time trying it. I've built the kernel and release for evbarm aarch64 from the latest sources and ran it on QEMU. Unfortunately, /dev/efi wasn't present on the system. Is it linked to the issue you talked about (no conversion between EFI device paths and disks)? How should I approach implementing it? Or is making a device node manually using mknod the case (I thought MAKEDEV.tmpl should've added it automatically)? Additionally, what ways to debug kernel drivers would you recommend? `printk` or `aprint_debug`? I would also like to know your opinion on the following implementation. My general plan is to extend on the work you've done on EFI rt and /dev/efi and use the existing code as a guideline, while implementing features from FreeBSD (https://reviews.freebsd.org/rGd12d651f8692cfcaf6fd0a6e8264c29547f644c9) - get table - returns table address by uuid (efi_ops) - copy table - copies the table from memory to a variable passed by reference (efi_ops) - get table size - helper function, returns size of table in bytes - other operations on efi vars are a second priority, since the main task is to support ESRT I reckon these not only need to be added to /dev/efi, but efi_runtime too (so they become machine dependent). If you have a different view or any other ideas to extend the implementation please let me know. Apologies for an exhaustive list of questions and have a great day, Paweł On 17.08.2022 18:17, Jared McNeill wrote: Hi Paweł -- After introducing /dev/efi I ported libefi and efivar from FreeBSD, at least enough to work with EFI vars, but there were some things left to do -- notably, all of the logic to convert between EFI device paths and disks needs to be sorted out. No geom on NetBSD, and the current state of things is a bit of a mess IMHO, so I didn't get around to tackling it. I think extending /dev/efi to support this feature is reasonable, and it makes sense to keep compatibility with the FreeBSD APIs here. We have other platforms that use EFI today (armv7 and aarch64), with more in the pipeline (riscv) so whatever solution you come up with should be MI. So sys/dev/efi.c makes sense, probably with a new MD hook added to struct efi_ops. I realize that this doesn't cover x86 today -- as far as I'm aware, the x86 based NetBSD ports don't support UEFI runtime services at all. But when they do, this is how support will be added. Hope this helps, and feel free to reach out if you have any follow up questions. Take care, Jared
Re: Devices without power management support
p...@whooppee.com (Paul Goyette) writes: >Don't forget to deregister the device if the xxx_attach() later exits... I think the point was to not do this, so that a failed attach doesn't prevent the system from entering sleep mode. Here, calling pmf_register first on attachment is then required, but then you have to think on how to handle failures of pmf_register. You wouldn't want the device to fail attachment in that case, but rather accept that you cannot suspend in that situation. You also have to think about drivers that are left only partially configured after a failed attachment. That is already unsafe with drivers that only do a dummy pmf registration, but what about hardware that actually needs support routines ? Registering these for a partially configured driver may not work either. Unregister again and register dummy routines ? An easy solution would be to make attach actually fail, autoconf could then detached the driver immediately and it won't interfere with pmf. N.B. if autoconf API is changed, you could also integrate pmf into cfattach.
