Re: blocksizes
On Thu, Feb 04, 2010 at 12:15:15AM +0100, Michael van Elst wrote: The original adosfs has been used on media with differnet block sizes. That doesn't say anything about our implementation, but different block sizes have been designed in from the beginning. I seem to recall having used adosfs on MO with 2048 bytes/sector from NetBSD. Regards, -is -- seal your e-mail: http://www.gnupg.org/ pgp5xxzHwndX0.pgp Description: PGP signature
Re: regression (crash) in sysmon/acpiacad
On Thu, 4 Feb 2010, Matthias Drochner wrote: Hi - my laptop (running -current) now crashes as soon as the battery reaches warning level. This is due to a jump to NULL in sysmon_envsys_events.c, line 891 - an indirect call to sme-sme_refresh. This is indeed 0 for acpiacad now, since the refresh method was removed recently. How is this intended to work? Ooops. The refresh routine was removed because we're now relying on the notify code to actually work. But unfortunately we forgot to set the flag to avoid the call-back. Either Jukka or I will get this fixed up shortly. - | Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: regression (crash) in sysmon/acpiacad
On Thu, 4 Feb 2010, Paul Goyette wrote: On Thu, 4 Feb 2010, Matthias Drochner wrote: my laptop (running -current) now crashes as soon as the battery reaches warning level. This is due to a jump to NULL in sysmon_envsys_events.c, line 891 - an indirect call to sme-sme_refresh. This is indeed 0 for acpiacad now, since the refresh method was removed recently. How is this intended to work? Ooops. The refresh routine was removed because we're now relying on the notify code to actually work. But unfortunately we forgot to set the flag to avoid the call-back. Either Jukka or I will get this fixed up shortly. Actually, Jukka _did_ set the SME_DISABLE_REFRESH flag. Unfortunately, it was not being checked in one of the call-backs. I have just added the missing check. Please update to rev 1.78 of src/sys/dev/sysmon/sysmon_envsys_events.c and try again. Thanks for finding this, and please accept my apologies for the breakage. - | Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: regression (crash) in sysmon/acpiacad
On Thu, 4 Feb 2010, Matthias Drochner wrote: p...@whooppee.com said: Please update to rev 1.78 of src/sys/dev/sysmon/sysmon_envsys_events.c and try again. Thanks -- I just managed to run low on battery with a new kernel. I can confirm that the problem is fixed, the box runs well until graceful shutdown by the sensor_battery script. But -- since my battery was low anyway I did another test, whether it behaves well if the userland powerd is not running. It does not. I'd expect it to hit the cpu_reboot() call in sysmon_penvsys_event() eventually, but it did not. It didn't even update the charge value visible in envstat(8) -- this stayed at 6.00% (this is where I killed powerd) even when the red battery LED on my (Dell) laptop started to light permanently, which happens below 3% (the low cap limit). This used to work, so there is another regression. OK, we'll look into it. Since the charge value was not updating, it might be that the ACPI Notify isn't working here. Perhaps we should not rely on this, and put the refresh() routine back... Since I don't have any battery-powered devices, I'll defer to Jukka to see what we can do. - | Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: regression (crash) in sysmon/acpiacad
p...@whooppee.com said: Since the charge value was not updating, it might be that the ACPI Notify isn't working here. For the critical shutdown, a call to _BTP might help. But anyway, from my limited experience with process control (SCADA) systems, it makes sense to maintain a timestamp for the last data value read (or delivered by asynchronous notification) and force a fresh read if it is older than a limit defined by the provider (and possibly overridden by the consumer). best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: regression (crash) in sysmon/acpiacad
On Thu, Feb 04, 2010 at 10:15:03PM +0100, Matthias Drochner wrote: p...@whooppee.com said: Since the charge value was not updating, it might be that the ACPI Notify isn't working here. Since this involved running on battery power, I doubt it is about the removal of the refresh routine in acpiacad(4). If the sensor value changes when one plugs/unplugs the AC, it is easily verified to be working. For the critical shutdown, a call to _BTP might help. The _BTP is just a custom warning trip-point that triggers a Notify once reached. It is probably there to provide user space applications some control over the limits, and to possibly avoid polling of the values. Note though that nothing has changed in acpibat(4) with regards to the refresh routine or the sensors generally. But anyway, from my limited experience with process control (SCADA) systems, it makes sense to maintain a timestamp for the last data value read (or delivered by asynchronous notification) and force a fresh read if it is older than a limit defined by the provider (and possibly overridden by the consumer). Something like is already done in acpibat(4). - Jukka.
