as though the poll support for pipes is somehow returning
'readable' when no data is available.
Of course there might be some uninitialised memory lurking.
David
--
David Laight: da...@l8s.co.uk
at the minumum sleep time is met.
Otherwise the sleep will be too short if called just before s tick.
David
--
David Laight: da...@l8s.co.uk
almost certainly needed for lfs because the cleaner might
move /boot to different sectors.
David
--
David Laight: da...@l8s.co.uk
e other object files.
That ensures the version (and build date) is always correct.
David
--
David Laight: da...@l8s.co.uk
getting this beast booted into NetBSD?
Boot from USB?
you might find the bios will boot a cd image written to a usb memory stick.
David
--
David Laight: da...@l8s.co.uk
e machine resources, such as the amount of memory available.
The 'hard' ulimit values also need reducing.
But yes, most of the 'system wide' limits (even processes for root)
could be usefully replaced my checks against free kva, swap and physical
memory.
The problem is picking the values.
Look at what MAXYSERS does :-)
David
--
David Laight: da...@l8s.co.uk
Maybe a gpt disk has space for a larger boot image?
In which case it might be possible to have more code to find /boot.
David
--
David Laight: da...@l8s.co.uk
aligned and that the fragment
and block sizes are large.
But remember the boot code doesn't have enough memory for very large blocks.
David
--
David Laight: da...@l8s.co.uk
xgetbv is available, but when it is executes
there cpu faults.
Clearly that shouldn't happen.
IIRC qemu is buggy - is that bare metal?
David
--
David Laight: da...@l8s.co.uk
't cross 64k address boundaries.
3) The end of a ring segment must happen at the end of a USB packet.
David
--
David Laight: da...@l8s.co.uk
nd i386 in my case.
There is some code for xhci, but I wouldn't stress it.
I've only looked at enough to add some comments where it is clearly buggy
or needs some TLC in order to operate with certain host controllers.
Even the Linux xhci driver isn't in very good shape.
David
--
David Laight: da...@l8s.co.uk
On Mon, Apr 14, 2014 at 11:45:27PM +0900, Masao Uebayashi wrote:
> On Thu, Apr 10, 2014 at 3:40 AM, David Laight wrote:
> > On Wed, Apr 09, 2014 at 09:10:42AM -0500, John D. Baker wrote:
> >> On Wed, 9 Apr 2014, John D. Baker wrote:
> >>
> >> > disk, the l
magnitude longer to do the same.
Not for at least a couple of weeks.
David
--
David Laight: da...@l8s.co.uk
The calls are all from assembler and are followed by a bios call
and then a call to real_to_prot.
If that were done the /boot code itself could probably be linked with a
virtual base address of 1MB and run with virtual == physical removing
the confusing offset.
David
--
David Laight: da...@l8s.co.uk
On Wed, Mar 26, 2014 at 02:57:15PM -0700, Paul Goyette wrote:
> On Wed, 26 Mar 2014, David Laight wrote:
>
> >Actually, I wonder, have you rebuilt qemu since jeorg changed the
> >default x87 precision to 80bits?
> >That might be the difference between your tests and gso
cale'
instructions on both i386 and amd64.
I do need to do a clock-count comparison for 'f2xm1', but I expect it
to be faster than the table lookup and 5th degree polynomial.
Intel claim these functions are monatonic, I bet the polynomial
version isn't.
David
--
David Laight: da...@l8s.co.uk
s in ftxf86.pico
I've not checked the .a from a working build, but since a .so is
being generated it ought to contain the .pico versions.
I wonder how that is supposed to happen?
Maybe a parallel make happened to leave the wrong file lurking?
David
--
David Laight: da...@l8s.co.uk
tconfig/src
> 1 error
Can you find the command line used to compile ftxf86.o ?
and/or extract the object file from the library and feed it through
'objdump -dr' to find the relocation (and to see if it looks
like PIC code at all).
David
--
David Laight: da...@l8s.co.uk
partition and inode?).
This didn't help you find the entry - but it would tell you when
you'd found the correct one.
OTOH ttyname(3) is probably best implemented with a pair of ioctls.
Although chroot() probably complicates things.
David
--
David Laight: da...@l8s.co.uk
To generate a diff of this commit:
> cvs rdiff -u -r1.2 -r1.3 src/sys/external/bsd/drm2/include/linux/kernel.h
I'd add a 'default' to the switch statement.
gcc doesn't detect when switch statements have case terms for
all possible values of a masked value.
David
--
David Laight: da...@l8s.co.uk
> depending on whether it's an amd64/i386 PAE build or a plain i386
> build.
((uint64_t)0xul << 32 | 0x)
works for both.
David
--
David Laight: da...@l8s.co.uk
On Tue, Mar 11, 2014 at 08:51:06PM +, Alexander Nasonov wrote:
> David Laight wrote:
> > I've committed code to the amd64 and i386 kernels that enables
> > AVX for userspace.
> > In particular the high ymm registers should be saved on context switches.
> >
>
mber what the throw() is about - especially on
a function with a C interface.
David
--
David Laight: da...@l8s.co.uk
CPPFLAGS, but I'm
> not sure if it's entirely correct.
If the tools compiler doesn't have a hard default of $DESTDIR/usr/include
then specifying it by --sysroot is probably correct.
So quite likely CPPFLAGS is the correct beast.
David
--
David Laight: da...@l8s.co.uk
ternal/cddl.
> opensolaris_init in external/cddl/osnet/sys/kern/opensolaris.c
> is a good place to assign, I think.
Using 'void *' causes problems with knowing which pointer is valid
for a given call.
There is no problem using 'struct foo *' without the contents of
'struct foo' being visible.
David
--
David Laight: da...@l8s.co.uk
ct instruction.
The failing instruction is probably xsetbv.
The code is probably trying to enable the avx instructions - because
the cpuid instruction indicated that it is available.
This might be a bug in the linux kvm code, not netbsd.
David
--
David Laight: da...@l8s.co.uk
> Interestingly, there seems to be no requirement that the second number
> in a range is at least as large as the first number. Is the range x-y
> functionally equivalent to y-x ?
Try it 'cut -f 3-1' gives lots of blank lines ...
David
--
David Laight: da...@l8s.co.uk
ft on device
> Populating `ramdisk.fs.tmp'
Which architecture ?
David
--
David Laight: da...@l8s.co.uk
h stealing
another 2k from the kernel stack might cause problems!
David
--
David Laight: da...@l8s.co.uk
On Sun, Feb 23, 2014 at 10:26:21PM +, David Laight wrote:
> On Sun, Feb 23, 2014 at 09:56:55PM +0100, Thomas Klausner wrote:
> > On Sun, Feb 23, 2014 at 10:34:32AM +, Nick Hudson wrote:
> > > On 02/23/14 09:41, Thomas Klausner wrote:
> >
> > > Also, x/i in
n usually work out the source lines from that.
(gdb's 'disas usb_allocmem_flags' probably gives the same lines.)
David
--
David Laight: da...@l8s.co.uk
' panics.
Might be worth looking for a latter working kernel.
Or look through the commits for something suspicious and try the other
side of it.
To even attempt to diagnose the crash we'd need a working kernel dump.
(Do those work on amd64 at the moment - if you are willing to wait
for the hours it takes to write out 16GB ...)
David
David
--
David Laight: da...@l8s.co.uk
. .
> > . . . . . .
> > . . . . .
>
>
> I noticed that as "ls | more" giving a different result to "ls".
"ls | more" implies "ls -1 | more".
I'm not sure you can actually get the terminal output into a file
(without using something like script).
David
--
David Laight: da...@l8s.co.uk
ght.
David
--
David Laight: da...@l8s.co.uk
d it fine...
David
--
David Laight: da...@l8s.co.uk
ust be possible to about having to edit so many files...
David
--
David Laight: da...@l8s.co.uk
On Wed, Feb 12, 2014 at 07:06:18PM +, David Laight wrote:
>
> *** Check failed: /test-bed/src/tests/lib/libm/t_fmod.c:53:
>fabs(fmod(1.0, 0.1) - 0.1) <= 55 * DBL_EPSILON not met
Actually, why is that expected to succeed at all.
Surely fmod(1.0, 0.1) is either slight
ns falls back on the fmod()
library function.
David
--
David Laight: da...@l8s.co.uk
y.
I'll add it it.
David
--
David Laight: da...@l8s.co.uk
he instruction in kern_exec.s and then finding
> the source line to kern_exec.c?
objdump -r -d kern_exec.o will lookup the relocations for you.
But I'd guess that the backtrace has missed a function and the fault
is somewhere inside check_exec().
The address 807d428e printed by the fault code is probbaly correct.
Try 'objdump -d /netbsd' and sort out which function it is in.
David
--
David Laight: da...@l8s.co.uk
gt; > test the amd64 case myself).
> >
> > this should be fixed now, please update and give it a try.
>
> Works! Thanks very much, you can close the PR as far as I'm concerned.
>
> And now on to that firefox 27 compile error . :-)
If that is the one to do with fxs
e not really looked at the virtual memory layout that closely.
About the first thing the kernl must do is setup some mmu page table
entries that map low physical memory to address 0xc000 and then
enable the mmu and jump to the virtual address.
It might be that you need to increase the size of th
On Sun, Jan 19, 2014 at 11:16:27AM -0800, Paul Goyette wrote:
> On Sun, 19 Jan 2014, David Laight wrote:
>
> >The module can't do its own refcounting.
> >Think about what happens in the 'close' code on the last close.
> >The driver will decrement the ref
ode calling
into the module holds a reference (possibly indirectly) that ensures
the module won't go away.
David
--
David Laight: da...@l8s.co.uk
6MB limit.
Loading any higher would require a low memory 'bouce' buffer.
David
--
David Laight: da...@l8s.co.uk
> statclock() (and then hardclock()) must return with the ipl higher.
I'd have thought that acquiring a mutex would increase the count.
So a count of -1 would indicate and extra release.
Or does this counter have silly values?
David
--
David Laight: da...@l8s.co.uk
is unlikely to be used twice).
David
--
David Laight: da...@l8s.co.uk
do?
If you link a program with -lcurses you don't want a DT_NEEDED entry
for libtemcap.so whether or not the program directly references
anything in libtermcap.so.
David
--
David Laight: da...@l8s.co.uk
e linker makes all the symbols available
you can't have multiple copies of the same library loaded anyway.
The really oughgt to have added a new variant of DT_NEEDED that indicated
that the symbols should not be made visible.
David
--
David Laight: da...@l8s.co.uk
-d -P -I ! -I CVS -I .#*
checkout -P
diff -u -p
You definitely need the -P, a bit of compression seems to stop massive
amounts of data being sent to the cvs server.
David
--
David Laight: da...@l8s.co.uk
x27; token is inserted.
So you should only see one non-make fail for each possible parralel task.
(Of course, it could be buggy!)
David
--
David Laight: da...@l8s.co.uk
51 matches
Mail list logo
