unhooking lfs from ufs
On several occasions it's been suggested that lfs should be unhooked from ufs, on the grounds that sharing ufs between both ffs and lfs has made all three entities (but particularly lfs) gross. ffs and lfs are not similar enough structurally for this sharing to really be a good design. Nobody I've discussed this with (on the lists or in chat) has been opposed, and I think there's a general consensus that this is the right direction. Getting there, however, is going to perhaps be a bit more controversial. Since ufs does provide a lot of functionality to lfs, it seems to me that the only practical way to do this is to cut and paste a copy of ufs into lfs under a different name, hack it up so it works again, and then begin consolidating. Anything else would involve either cutting off far too much work at once or leaving lfs entirely inoperable (as opposed to merely unstable) for a lengthy period; both of these propositions seem like a worse idea than attending to and merging changes into a chunk of copied code. (In fact, I've been maintaining and syncing the copy since July, and it's not been a big deal so far.) So I think this is the best approach. The copy involves 18 files from sys/ufs/ufs (out of 21; the ones excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain 9067 lines of code. That gives the following statistics: 14988 size of lfs currently + 9067 size of copypasted ufs 24055 size of resulting uncompilable lfs - 401 result of making it compilable 23654 size of new lfs This is the size of the code in sys/ufs/lfs; the userlevel tools need patching but don't change size significantly. My guess/estimate is that after several rounds of consolidation the total size will drop to around 18000-19000 lines. Maybe less, even, but I wouldn't count on that. I'll be keeping an eye on the total size going forward. Anyway, I have done this much and it's ready to go. I will be committing it tonight, I think, unless there are sudden howls of protest. The diff (from HEAD of a couple hours ago to the new compilable lfs) is posted here: http://www.eecs.harvard.edu/~dholland/netbsd/lfs-ufs-20100207.diff I will probably commit the pasted-only uncompilable form first, and maybe some of the intermediate steps as well, for the historical record and to make future merges easier. This may make the tree temporarily unbuildable, but hopefully not for very long. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch
On Sat, Feb 06, 2010 at 01:07:08PM -0800, Paul Goyette wrote: If it matches a device, and there is also a native driver for the underlying i2c controller, then there'll be two devices accessing the same bus. Bad things (tm) will happen. This is noted in the BUGS section of the acpismbus(4) man page. On a related note, a similar warning should be probably added to aiboost(4). At least on Linux it is known to cause weird problems and lockups if the iic(4) is being accessed at the same time by a native driver (it87?). It is also a reasonable assumption that things will get worse at this front. The new ACPI 4.0 standard introduced a sensor framework of its own, and my guess is that consumer PC manufacturers will jump on the bandwagon, trying to hide these things in the abyss of ACPI. - Jukka.
Re: unhooking lfs from ufs
David Holland dholland-t...@netbsd.org wrote: The copy involves 18 files from sys/ufs/ufs (out of 21; the ones excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain 9067 lines of code. That gives the following statistics: 14988size of lfs currently + 9067size of copypasted ufs 24055size of resulting uncompilable lfs - 401result of making it compilable 23654size of new lfs How would this affect UFS side? For example, any potential code reduction and/or simplification? Anyway, I have done this much and it's ready to go. I will be committing it tonight, I think, unless there are sudden howls of protest. This involves significant changes, therefore enough time should be left for mailing list readers (~1 week at least, before committing anything). -- Mindaugas
Re: unhooking lfs from ufs
On Sun, Feb 07, 2010 at 10:10:31AM +, Mindaugas Rasiukevicius wrote: The copy involves 18 files from sys/ufs/ufs (out of 21; the ones excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain 9067 lines of code. That gives the following statistics: 14988 size of lfs currently + 9067 size of copypasted ufs 24055 size of resulting uncompilable lfs - 401 result of making it compilable 23654 size of new lfs How would this affect UFS side? For example, any potential code reduction and/or simplification? Yes. ufs_readwrite.c will become much less gross, for example. There used to be assorted LFS-only code in the ufs sources; ad@ removed the ifdefs some time ago but they could be resurrected and then used to purge the relevant code. I don't know how much code that is. As for deeper simplifications, I don't know without digging around a lot more than I have (particularly in the ext2fs code), but there should be some. Anyway, I have done this much and it's ready to go. I will be committing it tonight, I think, unless there are sudden howls of protest. This involves significant changes, therefore enough time should be left for mailing list readers (~1 week at least, before committing anything). It was discussed months ago. This is a reminder/heads-up. -- David A. Holland dholl...@netbsd.org
Re: unhooking lfs from ufs
David Holland dholland-curr...@netbsd.org wrote: How would this affect UFS side? For example, any potential code reduction and/or simplification? Yes. ufs_readwrite.c will become much less gross, for example. There used to be assorted LFS-only code in the ufs sources; ad@ removed the ifdefs some time ago but they could be resurrected and then used to purge the relevant code. I don't know how much code that is. As for deeper simplifications, I don't know without digging around a lot more than I have (particularly in the ext2fs code), but there should be some. Good, I think it would be great to look into this. This involves significant changes, therefore enough time should be left for mailing list readers (~1 week at least, before committing anything). It was discussed months ago. This is a reminder/heads-up. Where? This mailing list is a right place where such discussions (and decisions) should happen. -- Mindaugas
Re: unhooking lfs from ufs
On Sun, Feb 07, 2010 at 11:07:55AM +, Mindaugas Rasiukevicius wrote: It was discussed months ago. This is a reminder/heads-up. Where? This mailing list is a right place where such discussions (and decisions) should happen. Right here... -- David A. Holland dholl...@netbsd.org
Re: regression (crash) in sysmon/acpiacad
On Sun, 7 Feb 2010, Jukka Ruohonen wrote: On Sun, Feb 07, 2010 at 02:24:37PM +0100, Joerg Sonnenberger wrote: The point is that they have specific meaning for the hardware and as I said, are generally not changeable. For example, on my laptop, the power LED turns orange when warning cap is reached and shuts down hard on critical. You can already alter the low and warning capacity, as documented in envsys.conf(5). I am not arguing that it would be a good idea, quite the contrary. You can't necessarily change the values that the hardware monitors, but you can set the limits that are used to control the sending of event notifications to powerd. (A sensor can also set the ENVSYS_MONNOTSUPP flag to disable changing those limits.) If sme_set_limits() is omitted but sme_get_limits() is introduced, the visible change would merely imply that from $ envstat -d acpibat0 Current CritMax WarnMax WarnMin CritMin Unit warn cap: 2.511 Wh ( 5.00%) low cap: 0.200 Wh ( 0.40%) charge:50.230 Wh (100.00%) we would move to $ envstat -d acpibat0 | grep cap Current CritMax WarnMax WarnMin CritMin Unit ... charge:50.230 2.5110.200 Wh (100.00%) At least currently, sensors with the ENVSYS_FPERCENT flag display all of their limit values as percentages. So the output would be more like charge:50.230 5.000% 0.400% Wh (100.00%) Similar thing is already done in acpitz(4), sdtemp(4), and ipmi(4). The argumentation in favor of the percentages goes in similar vein. As I understand it, these callbacks were introduced specifically for those sensors that are capable of checking the limits in hardware. Supposedly this should be the case here. Yes, the primary rationale for these callbacks is to provide a means for userland to obtain (and possibly modify) the values used by the hardware device to raise alarms. At the time I was writing the sdtemp(4) driver, it seemed silly to always compare current-vs-limit in software when the chip was more than happy to do that task for us, if we would only set a threshold value for it to use! - | 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: Device page
ISTR sparc64 used bits in the physaddr_t for frambuffer mappings. If so it is well hidden (bus_space_map with LINEAR is used, but AFAICT that does nothing special to the uvm page). Thanks for clarification. Even if something abuses phys_addr, it should be easily fixed. I'll commit the uvm_page_to_phys() function and wait for a next bump to ride on. Masao
Re: need help with kern/42758 - correctly initialize W83627HF hwmon
I'll have a look. On Sun, 7 Feb 2010, Michael Stapelberg wrote: Hi, Yesterday I debugged why the temperature values seen in envstat on my mainboard looked very odd (70 degC while the bios hardware monitor shows 40 degC). As I described in the bugreport, it is a missing initialization. I also attached a patch to the bugreport, which fixes the problem to me. However, I am not a NetBSD kernel developer, so the patch very likely needs some polishing. It would be great if someone could have a look at it so that it can go into the next NetBSD release. Best regards, Michael PS: kern/42759 is related to this and a rather simple patch - it needs to be merged before debugging kern/42758 (so that the i2c is accessible on this board). PS: Please CC me, as I am not on this list. - | 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: need help with kern/42758 - correctly initialize W83627HF hwmon
Hi Paul, Thanks for your help so far. Excerpts from Paul Goyette's message of So Feb 07 22:06:23 +0100 2010: a) all W83627HF use temp sensors of type 3904, or b) the W83627HF on this board uses 3904. Any chance you can do some research in the datasheet to see if there is any mention of this? The datasheet itself does not mention any preference in regard to the type. In the wiki on lm-sensors.org I could find only one configuration which actually uses the temperature sensors of the W83627HF. This configuration also configures it to use the 3904 mode. Best regards, Michael
Re: need help with kern/42758 - correctly initialize W83627HF hwmon
On Sun, 7 Feb 2010, Michael Stapelberg wrote: Hi Paul, Thanks for your help so far. Excerpts from Paul Goyette's message of So Feb 07 22:06:23 +0100 2010: a) all W83627HF use temp sensors of type 3904, or b) the W83627HF on this board uses 3904. Any chance you can do some research in the datasheet to see if there is any mention of this? The datasheet itself does not mention any preference in regard to the type. In the wiki on lm-sensors.org I could find only one configuration which actually uses the temperature sensors of the W83627HF. This configuration also configures it to use the 3904 mode. Yes, I went through the datasheet, too, and there seems to be no way to tell what type of sensor is actually used. I think it would be OK to add a 'flags' to the config syntax, so you would say lm* at iic? addr 0xXX flags 1 to enable 2N3904 bipolar temp sensors. The default would be to keep current behavior which expects a normal thermistor. Now, I just need to figure out where the flags value gets passed into the driver! - | 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: need help with kern/42758 - correctly initialize W83627HF hwmon
On Sun, 7 Feb 2010, Paul Goyette wrote:
In the wiki on lm-sensors.org I could find only one configuration which
actually uses the temperature sensors of the W83627HF. This configuration
also configures it to use the 3904 mode.
Yes, I went through the datasheet, too, and there seems to be no way to tell
what type of sensor is actually used.
I think it would be OK to add a 'flags' to the config syntax, so you would
say
lm* at iic? addr 0xXX flags 1
to enable 2N3904 bipolar temp sensors. The default would be to keep current
behavior which expects a normal thermistor.
Now, I just need to figure out where the flags value gets passed into the
driver!
Can you try the attached diff, and set 'flags 1' in your config file?
-
| 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 |
-Index: nslm7x.c
===
RCS file: /cvsroot/src/sys/dev/ic/nslm7x.c,v
retrieving revision 1.49
diff -u -p -r1.49 nslm7x.c
--- nslm7x.c13 Oct 2008 12:44:46 - 1.49
+++ nslm7x.c7 Feb 2010 23:04:42 -
@@ -1766,7 +1766,7 @@ static int
wb_match(struct lm_softc *sc)
{
const char *model = NULL;
- int banksel, vendid, devid;
+ int banksel, vendid, devid, regval;
aprint_normal(\n);
/* Read vendor ID */
@@ -1790,6 +1790,16 @@ wb_match(struct lm_softc *sc)
case WB_CHIPID_W83627HF:
model = W83627HF;
lm_setup_sensors(sc, w83627hf_sensors);
+
+ if (device_cfdata(sc-sc_dev)-cf_flags 1) {
+ /* Switch to 2N3904 mode for the temperature sensors */
+ lm_generic_banksel(sc, WB_BANKSEL_B0);
+ (*sc-lm_writereg)(sc, WB_BANK0_RESVD1, 0x0);
+ regval = (*sc-lm_readreg)(sc, 0x5d);
+ regval |= 0xe;
+ (*sc-lm_writereg)(sc, WB_BANK0_VBAT, regval);
+ lm_generic_banksel(sc, banksel);
+ }
break;
case WB_CHIPID_W83627THF:
model = W83627THF;
Index: nslm7xvar.h
===
RCS file: /cvsroot/src/sys/dev/ic/nslm7xvar.h,v
retrieving revision 1.26
diff -u -p -r1.26 nslm7xvar.h
--- nslm7xvar.h 12 Oct 2008 13:17:28 - 1.26
+++ nslm7xvar.h 7 Feb 2010 23:04:42 -
@@ -87,6 +87,7 @@
/* Bank 0 regs */
#define WB_BANK0_CHIPID0x58/* Chip ID */
+#define WB_BANK0_RESVD10x59/* Resvd, bits 6-4 select temp sensor
mode */
#define WB_BANK0_FAN45 0x5c/* Fan 4/5 Divisor Control (W83791D only) */
#define WB_BANK0_VBAT 0x5d/* VBAT Monitor Control */
#define WB_BANK0_FAN4 0xba/* Fan 4 reading (W83791D only) */
Re: Cannot list a particular directory through NFS with UDP
On Sun, 7 Feb 2010, Martin Husemann wrote: On Sun, Feb 07, 2010 at 02:53:51PM +0100, Jeremie Le Hen wrote: FWIW, I've tried changing rsize to 1024 and I could read the entire tree. When I looked at the tcpdump you emailed me, I couldn't see anything wrong with the reply (and wireshark had decoded it all fine + confirmed that the checksums seemed ok), so I suspect the fragmentation reassembly failed somehow. Dropping the rsize to 1024 would avoid any IP fragmentation, although it also chamges the readdir replies, so that doesn't nail it down to fragmentation reassembly, but it seems the best guess? [good stuff by Martin snipped] rick
Re: need help with kern/42758 - correctly initialize W83627HF hwmon
Hi Paul, Excerpts from Paul Goyette's message of Mo Feb 08 00:14:44 +0100 2010: Can you try the attached diff, and set 'flags 1' in your config file? The patch works fine. I would suggest to use flag 2, however, to be consistent with the linux driver. Best regards, Michael
