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
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
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
+ 9067
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
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo
