Re: buildkernel error
On Wed, Feb 23, 2011 at 02:24:05PM +0900, mmats...@cybernet.co.jp wrote: > From: Garrett Cooper > Date: Tue, 22 Feb 2011 21:04:24 -0800 > ::On Tue, Feb 22, 2011 at 7:54 PM, wrote: > ::> From: Dimitry Andric > ::> Date: Tue, 22 Feb 2011 13:39:31 +0100 > ::> ::On 2011-02-22 08:30, gnehzuil wrote: > ::> ::> I updated my kernel source code and try to make a new kernel using > make > ::> ::> buildkernel command. But I got an error as follow: > ::> ::... > ::> ::> ld:/usr/src/sys/conf/ldscript.i386:66: syntax error > ::> :: > ::> ::Your /usr/bin/ld is still at version 2.15, which is too old to parse the > ::> ::kernel linker script. In this case, first run "make buildworld", or at > ::> ::least "make kernel-toolchain" before you attempt to build any kernels. > ::> > ::> Hello, > ::> > ::> Does it mean we have no-way of source upgrading from 8.X? > ::> We need newest world to build 9.x kernel, and need 9.x kernel to run > ::> newest world, and... > :: > ::No; you have to do something like the following: > :: > ::[kernel-]toolchain buildworld buildkernel. > :: > ::A plus side of doing this is that I do kernel-toolchain at -j12 > ::and then do buildworld buildkernel at -j12 as well. It's much quicker > ::than buildworld buildkernel at -j1, and less error prone than doing it > ::at any other -j value in parallel. > ::The handbook just says buildworld buildkernel ( > ::http://www.freebsd.org/doc/handbook/makeworld.html ), and UPDATING > ::just says kernel-toolchain buildkernel installkernel (look for "To > ::build a kernel"), but there aren't any official directions in the > ::quick to find spots that mention those above steps. > > Ahh, thanks for pointers. > I was just reading the "To upgrade in-place from 8.x-stable to current" > from UPDATING, which does not say anything about [kernel-]toolchain. > May by that part, and some others, also needs updating. You do not need to do anything with kernel-toolchain. THe proper procedure of buildworld/buildkernel just works. pgpnzJHiiKAHt.pgp Description: PGP signature
Re: buildkernel error
Dimitry Andric wrote: > On 2011-02-22 08:30, gnehzuil wrote: > > I updated my kernel source code and try to make a new kernel > > using make buildkernel command. But I got an error as follow: > ... > > ld:/usr/src/sys/conf/ldscript.i386:66: syntax error > > Your /usr/bin/ld is still at version 2.15, which is too old to > parse the kernel linker script. In this case, first run "make > buildworld", or at least "make kernel-toolchain" before you > attempt to build any kernels. Will either "make buildworld" or "make kernel-toolchain" accomplish anything if, as the OP said, s/he only updated the _kernel_ sources? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: buildkernel error
From: Kostik Belousov Date: Wed, 23 Feb 2011 10:25:32 +0200 ::On Wed, Feb 23, 2011 at 02:24:05PM +0900, mmats...@cybernet.co.jp wrote: ::> From: Garrett Cooper ::> Date: Tue, 22 Feb 2011 21:04:24 -0800 ::> ::On Tue, Feb 22, 2011 at 7:54 PM, wrote: ::> ::> From: Dimitry Andric ::> ::> Date: Tue, 22 Feb 2011 13:39:31 +0100 ::> ::> ::On 2011-02-22 08:30, gnehzuil wrote: ::> ::> ::> I updated my kernel source code and try to make a new kernel using make ::> ::> ::> buildkernel command. But I got an error as follow: ::> ::> ::... ::> ::> ::> ld:/usr/src/sys/conf/ldscript.i386:66: syntax error ::> ::> :: ::> ::> ::Your /usr/bin/ld is still at version 2.15, which is too old to parse the ::> ::> ::kernel linker script. In this case, first run "make buildworld", or at ::> ::> ::least "make kernel-toolchain" before you attempt to build any kernels. ::> ::> ::> ::> Hello, ::> ::> ::> ::> Does it mean we have no-way of source upgrading from 8.X? ::> ::> We need newest world to build 9.x kernel, and need 9.x kernel to run ::> ::> newest world, and... ::> :: ::> ::No; you have to do something like the following: ::> :: ::> ::[kernel-]toolchain buildworld buildkernel. ::> :: ::> ::A plus side of doing this is that I do kernel-toolchain at -j12 ::> ::and then do buildworld buildkernel at -j12 as well. It's much quicker ::> ::than buildworld buildkernel at -j1, and less error prone than doing it ::> ::at any other -j value in parallel. ::> ::The handbook just says buildworld buildkernel ( ::> ::http://www.freebsd.org/doc/handbook/makeworld.html ), and UPDATING ::> ::just says kernel-toolchain buildkernel installkernel (look for "To ::> ::build a kernel"), but there aren't any official directions in the ::> ::quick to find spots that mention those above steps. ::> ::> Ahh, thanks for pointers. ::> I was just reading the "To upgrade in-place from 8.x-stable to current" ::> from UPDATING, which does not say anything about [kernel-]toolchain. ::> May by that part, and some others, also needs updating. ::You do not need to do anything with kernel-toolchain. THe proper ::procedure of buildworld/buildkernel just works. OK. Thanks for the confirmation. Haro ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[patch] off by one issue in sys/kern/kern_thr.c
hi there,
i think the following should be changed. with
kern.threads.max_threads_per_proc=N, a process should be able to maintain
N threads and not N-1.
to verify simply use tools/test/pthread_vfork.
cheers.
alex
--
a13x
diff --git a/sys/kern/kern_thr.c b/sys/kern/kern_thr.c
index 75656f0..63bf1bc 100644
--- a/sys/kern/kern_thr.c
+++ b/sys/kern/kern_thr.c
@@ -153,7 +153,7 @@ create_thread(struct thread *td, mcontext_t *ctx,
p = td->td_proc;
/* Have race condition but it is cheap. */
- if (p->p_numthreads >= max_threads_per_proc) {
+ if (p->p_numthreads > max_threads_per_proc) {
++max_threads_hits;
return (EPROCLIM);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: buildkernel error
On 2011-02-23 10:00, per...@pluto.rain.com wrote: Will either "make buildworld" or "make kernel-toolchain" accomplish anything if, as the OP said, s/he only updated the _kernel_ sources? No. You must update all sources atomically, or there is no guarantee it will build. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: spontaneous reboot - ptrace
As it happens the NMI was caused by attempting to access memory mapped PCI address space. The HBA associated with the mapped PCI address space generated a PERR. Thanks for the help. - Original Message From: Kostik Belousov To: Dr. Baud Cc: freebsd-hackers@freebsd.org Sent: Fri, February 18, 2011 6:21:36 AM Subject: Re: spontaneous reboot - ptrace On Fri, Feb 18, 2011 at 03:58:05AM -0800, Dr. Baud wrote: > > > > First, do you have a console output during the run ? Is it possible > > that machine paniced ? If not, were there any kernel messages before> > > reboot ? > > > > Second, what is the process you are dumping ? Can you show at least > > the procstat -v output for the process ? > > Sorry for this late response but my earlier response appears to have been > consumed by the email reflector. > > I'm getting an NMI. And the trouble appears to be when trying to > read via ptrace memory segments of type KVME_TYPE_DEVICE. The app in > quesion allocates a large number of large memory buffers and maps them > into virtual address space. Not all segments cause the NMI however. > Small sampling of the virtual memory map. You did not provided exact console output on the panic, despite requested. What is the device that was mmaped ? Obviously, this is your problem. Can you gather all required information ? > > PID STARTEND PRT RES PRES REF SHD FL TP PATH > 931 0x40 0x1773000 r-x 4239 5053 2 1 CN vn >/mnt/dia > g/problemchild > 931 0x1872000 0x2ef2000 rw- 4160 1 0 C- vn >/mnt/dia > g/problemchld > 931 0x2ef2000 0x670 rw- 117650 1 0 C- df > 9310x8018720000x8018a2000 r-x 480 57 28 CN vn >/libexec > /ld-elf.so.1 > 9310x8018a20000x8018b3000 rw- 150 1 0 C- df > 9310x8018b30000x801924000 rw- 1130 1698 0 -- dv > 9310x8019240000x801925000 rw-10 1698 0 -- dv > 9310x8019250000x801926000 rw-10 1698 0 -- dv > 9310x8019260000x801927000 rw-10 1698 0 -- dv > 9310x8019270000x801928000 rw-10 1698 0 -- dv > 9310x8019280000x80192a000 rw-20 1698 0 -- dv > 9310x80192a0000x80192b000 rw-10 1698 0 -- dv > 9310x80192b0000x80192c000 rw-10 1698 0 -- dv > 9310x80192c0000x80192d000 rw-10 1698 0 -- dv > 9310x80192d0000x80192e000 rw-10 1698 0 -- dv > 9310x80192e0000x80193 rw-20 1698 0 -- dv > 9310x801930x801932000 rw-20 1698 0 -- dv > 9310x8019320000x801993000 rw- 970 1698 0 -- dv > 9310x8019930000x8019a rw- 130 1698 0 -- dv > 9310x8019a0x8019a1000 rw-10 1698 0 -- dv > > > > 9310x802ab70000x802bb7000 ---00 1 0 CN df > 9310x0x802bb700x0x802bd6000 rw- 170 1 0 C- vn >/lib/lib > c.so.7 > 9310x802bd60000x802bf1000 rw- 180 1 0 C- df > 9310x802bf10000x802bfd000 r-x9 14 2 1 CN vn >/lib/lib > gcc_s.so.1 > 9310x802bfd0000x802cfc000 ---00 1 0 CN df > 9310x802cfc0000x802cfe000 rw-20 1 0 CN vn >/lib/lib > gcc_s.so.1 > 9310x802cfe0000x802cff000 rw-10 1698 0 -- dv > 9310x802cff0000x802d0 rw-10 1698 0 -- dv > 9310x802d00x802e0 rw- 1320 1 0 C- df > 9310x802e00x802f0 rw- 1090 1 0 C- df > 9310x802f00x802f91000 rw- 1450 1698 0 -- dv > 9310x802f910000x802fb2000 rw- 330 1698 0 -- dv > 9310x802fb20000x802fd3000 rw- 330 1698 0 -- dv > 9310x802fd30000x802ff5000 rw- 340 1698 0 -- dv > 9310x802ff50000x802ff6000 rw-10 1698 0 -- dv > > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Super pages
In general, is it unadvisable to disable super pages? Dr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ichsmb - correct locking strategy?
On Tue, Feb 22, 2011 at 3:37 PM, John Baldwin wrote: > On Friday, February 18, 2011 9:10:47 am Svatopluk Kraus wrote: >> Hi, >> >> I try to figure out locking strategy in FreeBSD and found 'ichsmb' >> device. There is a mutex which protects smb bus (ichsmb device). For >> example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is >> locked and a command is written to bus, then unbounded (but with >> timeout) sleep is done (mutex is unlocked during sleep). After sleep a >> word is read from bus and the mutex is unlocked. >> >> 1. If an use of the device IS NOT serialized by layers around then >> more calls to this function (or others) can be started or even done >> before the first one is finished. The mutex don't protect sms bus. >> >> 2. If an use of the device IS serialized by layers around then the >> mutex is useless. >> >> Moreover, I don't mension interrupt routine which uses the mutex and >> smb bus too. >> >> Am I right? Or did I miss something? > > Hmm, the mutex could be useful if you have an smb controller with an interrupt > handler (I think ichsmb or maybe intpm can support an interrupt handler) to > prevent concurrent access to device registers. That is the purpose of the > mutex at least. There is a separate locking layer in smbus itself in (see > smbus_request_bus(), etc.). > > -- > John Baldwin > I see. So, multiple accesses to bus are protected by upper smbus layer itself. And the mutex encloses each single access in respect of interrupt. I.e., an interrupt can be assigned to a command (bus is either command processing or idle) and a wait to command result can be done atomically (no wakeup is missed). Am I right? BTW, a mutex priority propagation isn't too much exploited here. Maybe, it will be better for me to not take this feature into account when thinking about locking strategy and just take a mutex in most cases as a low level locking primitive which is indeed. Well, it seems that things become more clear. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Super pages
On 23/02/2011 14:03, Dr. Baud wrote: In general, is it unadvisable to disable super pages? I don't think there would be any effect on the stability of operation if you disable superpages, but generally (except in cases of CPU bugs) you would not need to. Your system should operate a bit faster with superpages enabled. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Super pages
> On 23/02/2011 14:03, Dr. Baud wrote:
> >
> > In general, is it unadvisable to disable super pages?
>
> I don't think there would be any effect on the stability of operation if
> you disable superpages, but generally (except in cases of CPU bugs) you
> would not need to. Your system should operate a bit faster with
> superpages enabled.
When is the memory allocated via contigmalloc freed? I have a test kernel
module that allocates memory in 8MB chucks until contigmalloc says enough (the
ginormous.c/Makefile attachment). I also have a bash script that displays the
interesting memory related kernel state variables (the mem attachement).
When I load and unload the kernel module and display the VM pages stats I
never see the wired pages nor free pages change:
vm.pmap.pg_ps_enabled: 1
SYSTEM MEMORY INFORMATION:
mem_phys:= 2138693632 ( 2039MB)Physical memory tunable
mem_user:= 2107297792 ( 2009MB)User space memory available
mem_real:= 2146893824 ( 2047MB)Maximum physical pages
mem_all: = 2075402240 ( 1979MB) [100%] Virual memory pages
mem_cache: =0 ( 0MB) [ 0%] Cached: almost avail. to allocat
mem_inactive:= 7360512 ( 7MB) [ 0%] Inactive: recently unreferenced
mem_active: + 8765440 ( 8MB) [ 0%] Active: recently referenced
mem_wire: 31395840 ( 29MB) [ 1%] Wired: disabled for paging out
mem_free:+ 2027589632 ( 1933MB) [ 97%] Free: fully available
-- ---
mem_hw: = 2147483648 ( 2048MB)Virual memory (cached, etc.)
kldload /sys/modules/ginormous/ginormous.ko
Ginormous module loading
Ginormous contigmalloc failed(229):
SYSTEM MEMORY INFORMATION:
mem_phys:= 2138693632 ( 2039MB)Physical memory tunable
mem_user:=180330496 (171MB)User space memory available
mem_real:= 2146893824 ( 2047MB)Maximum physical pages
mem_all: = 2075402240 ( 1979MB) [100%] Virual memory pages
mem_cache: = 22237184 ( 21MB) [ 1%] Cached: almost avail. to allocat
mem_inactive:= 253952 ( 0MB) [ 0%] Inactive: recently unreferenced
mem_active: + 2387968 ( 2MB) [ 0%] Active: recently referenced
mem_wire:1958363136 ( 1867MB) [ 94%] Wired: disabled for paging out
mem_free:+ 91795456 ( 87MB) [ 4%] Free: fully available
-- ---
mem_hw: = 2147483648 ( 2048MB)Virual memory (cached, etc.)
kldunload ginormous
Ginormous module unloading
Warning: memory type GINORMOUS leaked memory on destroy (229 allocations,
1920991232 bytes leaked).
SYSTEM MEMORY INFORMATION:
mem_phys:= 2138693632 ( 2039MB)Physical memory tunable
mem_user:=180314112 (171MB)User space memory available
mem_real:= 2146893824 ( 2047MB)Maximum physical pages
mem_all: = 2075402240 ( 1979MB) [100%] Virual memory pages
mem_cache: = 21565440 ( 20MB) [ 1%] Cached: almost avail. to allocat
mem_inactive:= 413696 ( 0MB) [ 0%] Inactive: recently unreferenced
mem_active: + 2842624 ( 2MB) [ 0%] Active: recently referenced
mem_wire:1958379520 ( 1867MB) [ 94%] Wired: disabled for paging out
mem_free:+ 91807744 ( 87MB) [ 4%] Free: fully available
-- ---
mem_hw: = 2147483648 ( 2048MB)Virual memory (cached, etc.)
Note that this behavior occurs whether superpages are enabled or not.
Anyone
have
and explanation?
Dr.
#include
#include
#include
#include /* uprintf */
#include /* defines used in kernel.h */
#include /* types used in module initialization */
#include/* cdevsw struct */
MALLOC_DEFINE(M_GINORMOUS, "GINORMOUS", "Ginormous Kernel Module");
#define BUFSIZE (8*1024*1024)
#define NMALLOCS 241
static int
ginormous_loader(struct module *m, int what, void *arg)
{
int err = 0;
void *mem[NMALLOCS];
switch (what)
{
case MOD_LOAD:/* kldload */
{
int i;
printf("Ginormous module loading\n");
for (i = 0; i < NMALLOCS; i++) {
if ((mem[i] = contigmalloc( BUFSIZE,
M_GINORMOUS,
0,
0UL,
~0UL,
PAGE_SIZE,
0)) == NULL) {
printf("Ginormous contigmalloc failed(%d):\n", i);
break;
}
}
}
break;
case MOD_UNLOAD:
printf("Ginormous module unloading\n");
break;
default:
err = EINVAL;
break;
}
return(err);
}
DEV_MODULE(ginormous, ginormous_loader, NULL);
Makefile
Description: Binary data
mem
Description: Binary data
Re: Super pages
On Wednesday, February 23, 2011 11:54:59 am Dr. Baud wrote: > > On 23/02/2011 14:03, Dr. Baud wrote: > > > > > > In general, is it unadvisable to disable super pages? > > > > I don't think there would be any effect on the stability of operation if > > you disable superpages, but generally (except in cases of CPU bugs) you > > would not need to. Your system should operate a bit faster with > > superpages enabled. > > When is the memory allocated via contigmalloc freed? I have a test kernel > module that allocates memory in 8MB chucks until contigmalloc says enough > (the > ginormous.c/Makefile attachment). I also have a bash script that displays the > interesting memory related kernel state variables (the mem attachement). > When I load and unload the kernel module and display the VM pages stats I > never see the wired pages nor free pages change: Err, it's freed when you call contigfree(). If you leak the memory when you do a kldunload, it is just lost until you reboot. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: seeking into /dev/{null,zero}
On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: >> (Please bottom post) >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote: >>> I thought seeking past EOF was valid; writing something creates a file > with a hole in it. I always assumed that was standard semantics. >> >>That's with SET_HOLE/SET_DATA though, correct? If so, outside of >> that functionality I would assume relatively standard POSIX semantics. > > Err, no, you can always seek past EOF and then call write(2) to extend a file > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are different, > they are just used to discover sparse regions within a file. > > From the manpage: > > The lseek() system call allows the file offset to be set beyond the end > of the existing end-of-file of the file. If data is later written at > this point, subsequent reads of the data in the gap return bytes of zeros > (until data is actually written into the gap). You're correct. Linux (Fedora 13) isn't POSIX compliant (this is from the official POSIX text): The lseek ( ) function shall allow the file offset to be set beyond the end of the existing data in the file. If data is later written at this point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap. Thanks! -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: seeking into /dev/{null,zero}
On Wed Feb 23 11, Garrett Cooper wrote:
> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote:
>
> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote:
> >> (Please bottom post)
> >>
> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote:
> >>> I thought seeking past EOF was valid; writing something creates a file
> > with a hole in it. I always assumed that was standard semantics.
> >>
> >>That's with SET_HOLE/SET_DATA though, correct? If so, outside of
> >> that functionality I would assume relatively standard POSIX semantics.
> >
> > Err, no, you can always seek past EOF and then call write(2) to extend a
> > file
> > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are different,
> > they are just used to discover sparse regions within a file.
> >
> > From the manpage:
> >
> > The lseek() system call allows the file offset to be set beyond the end
> > of the existing end-of-file of the file. If data is later written at
> > this point, subsequent reads of the data in the gap return bytes of
> > zeros
> > (until data is actually written into the gap).
>
> You're correct. Linux (Fedora 13) isn't POSIX compliant (this is from
> the official POSIX text):
>
> The lseek ( ) function shall allow the file offset to be set beyond the end
> of the existing data in the file. If data is later written at this point,
> subsequent reads of data in the gap shall return bytes with the value 0 until
> data is actually written into the gap.
so except for reading from /dev/zero freebsd also isn't posix compliant, right?
will this patch fix writing to /dev/{zero,null}?
diff --git a/sys/dev/null/null.c b/sys/dev/null/null.c
index 3005c19..aa9fa87 100644
--- a/sys/dev/null/null.c
+++ b/sys/dev/null/null.c
@@ -71,6 +71,7 @@ static void *zbuf;
static int
null_write(struct cdev *dev __unused, struct uio *uio, int flags __unused)
{
+ uio->uio_offset += uio->uio_resid;
uio->uio_resid = 0;
return (0);
cheers.
alex
>
> Thanks!
> -Garrett
--
a13x
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: seeking into /dev/{null,zero}
On Wed Feb 23 11, Garrett Cooper wrote:
> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote:
>
> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote:
> >> (Please bottom post)
> >>
> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote:
> >>> I thought seeking past EOF was valid; writing something creates a file
> > with a hole in it. I always assumed that was standard semantics.
> >>
> >>That's with SET_HOLE/SET_DATA though, correct? If so, outside of
> >> that functionality I would assume relatively standard POSIX semantics.
> >
> > Err, no, you can always seek past EOF and then call write(2) to extend a
> > file
> > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are different,
> > they are just used to discover sparse regions within a file.
on the other hand POSIX says:
"The behavior of lseek() on devices which are incapable of seeking is
implementation-defined.
The value of the file offset associated with such a device is undefined."
...if we define /dev/{zero,null} as incapable of seeking the current
implementation should be ok.
> >
> > From the manpage:
> >
> > The lseek() system call allows the file offset to be set beyond the end
> > of the existing end-of-file of the file. If data is later written at
> > this point, subsequent reads of the data in the gap return bytes of
> > zeros
> > (until data is actually written into the gap).
>
> You're correct. Linux (Fedora 13) isn't POSIX compliant (this is from
> the official POSIX text):
>
> The lseek ( ) function shall allow the file offset to be set beyond the end
> of the existing data in the file. If data is later written at this point,
> subsequent reads of data in the gap shall return bytes with the value 0 until
> data is actually written into the gap.
>
> Thanks!
> -Garrett
--
a13x
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: seeking into /dev/{null,zero}
On Wed, Feb 23, 2011 at 3:36 PM, Alexander Best wrote: > On Wed Feb 23 11, Garrett Cooper wrote: >> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: >> >> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: >> >> (Please bottom post) >> >> >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote: >> >>> I thought seeking past EOF was valid; writing something creates a file >> > with a hole in it. I always assumed that was standard semantics. >> >> >> >> That's with SET_HOLE/SET_DATA though, correct? If so, outside of >> >> that functionality I would assume relatively standard POSIX semantics. >> > >> > Err, no, you can always seek past EOF and then call write(2) to extend a >> > file >> > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are different, >> > they are just used to discover sparse regions within a file. >> > >> > From the manpage: >> > >> > The lseek() system call allows the file offset to be set beyond the end >> > of the existing end-of-file of the file. If data is later written at >> > this point, subsequent reads of the data in the gap return bytes of >> > zeros >> > (until data is actually written into the gap). >> >> You're correct. Linux (Fedora 13) isn't POSIX compliant (this is from >> the official POSIX text): >> >> The lseek ( ) function shall allow the file offset to be set beyond the end >> of the existing data in the file. If data is later written at this point, >> subsequent reads of data in the gap shall return bytes with the value 0 >> until data is actually written into the gap. > > so except for reading from /dev/zero freebsd also isn't posix compliant, > right? Huh...? Please better explain what you mean here. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: seeking into /dev/{null,zero}
On Wed, Feb 23, 2011 at 3:53 PM, Alexander Best wrote:
> On Wed Feb 23 11, Garrett Cooper wrote:
>> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote:
>>
>> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote:
>> >> (Please bottom post)
>> >>
>> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wrote:
>> >>> I thought seeking past EOF was valid; writing something creates a file
>> > with a hole in it. I always assumed that was standard semantics.
>> >>
>> >> That's with SET_HOLE/SET_DATA though, correct? If so, outside of
>> >> that functionality I would assume relatively standard POSIX semantics.
>> >
>> > Err, no, you can always seek past EOF and then call write(2) to extend a
>> > file
>> > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are different,
>> > they are just used to discover sparse regions within a file.
>
> on the other hand POSIX says:
>
> "The behavior of lseek() on devices which are incapable of seeking is
> implementation-defined.
> The value of the file offset associated with such a device is undefined."
>
> ...if we define /dev/{zero,null} as incapable of seeking the current
> implementation should be ok.
>
>> >
>> > From the manpage:
>> >
>> > The lseek() system call allows the file offset to be set beyond the end
>> > of the existing end-of-file of the file. If data is later written at
>> > this point, subsequent reads of the data in the gap return bytes of
>> > zeros
>> > (until data is actually written into the gap).
>>
>> You're correct. Linux (Fedora 13) isn't POSIX compliant (this is from
>> the official POSIX text):
>>
>> The lseek ( ) function shall allow the file offset to be set beyond the end
>> of the existing data in the file. If data is later written at this point,
>> subsequent reads of data in the gap shall return bytes with the value 0
>> until data is actually written into the gap.
Yes, but look at how it's defined by POSIX before you do that
(yes, there's a section for null/zero IIRC).
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: seeking into /dev/{null,zero}
On Wed Feb 23 11, Garrett Cooper wrote:
> On Wed, Feb 23, 2011 at 3:36 PM, Alexander Best wrote:
> > On Wed Feb 23 11, Garrett Cooper wrote:
> >> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote:
> >>
> >> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote:
> >> >> (Please bottom post)
> >> >>
> >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane
> >> >> wrote:
> >> >>> I thought seeking past EOF was valid; writing something creates a file
> >> > with a hole in it. I always assumed that was standard semantics.
> >> >>
> >> >> That's with SET_HOLE/SET_DATA though, correct? If so, outside of
> >> >> that functionality I would assume relatively standard POSIX semantics.
> >> >
> >> > Err, no, you can always seek past EOF and then call write(2) to extend a
> >> > file
> >> > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are
> >> > different,
> >> > they are just used to discover sparse regions within a file.
> >> >
> >> > From the manpage:
> >> >
> >> > The lseek() system call allows the file offset to be set beyond the
> >> > end
> >> > of the existing end-of-file of the file. If data is later written at
> >> > this point, subsequent reads of the data in the gap return bytes of
> >> > zeros
> >> > (until data is actually written into the gap).
> >>
> >> You're correct. Linux (Fedora 13) isn't POSIX compliant (this is
> >> from the official POSIX text):
> >>
> >> The lseek ( ) function shall allow the file offset to be set beyond the
> >> end of the existing data in the file. If data is later written at this
> >> point, subsequent reads of data in the gap shall return bytes with the
> >> value 0 until data is actually written into the gap.
> >
> > so except for reading from /dev/zero freebsd also isn't posix compliant,
> > right?
>
> Huh...? Please better explain what you mean here.
if i got this right when reading from /dev/{zero,null} and writing to
/dev/{zero,null} seeking past EOF should take place.
right now only reading from /dev/zero seeks correctly. writing to /dev/zero
and reading/writing to/from /dev/null will not seek, but remain at offset 0.
cheers.
alex
> Thanks,
> -Garrett
--
a13x
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: seeking into /dev/{null,zero}
On Wed Feb 23 11, Garrett Cooper wrote:
> On Wed, Feb 23, 2011 at 3:36 PM, Alexander Best wrote:
> > On Wed Feb 23 11, Garrett Cooper wrote:
> >> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote:
> >>
> >> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote:
> >> >> (Please bottom post)
> >> >>
> >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane
> >> >> wrote:
> >> >>> I thought seeking past EOF was valid; writing something creates a file
> >> > with a hole in it. I always assumed that was standard semantics.
> >> >>
> >> >> That's with SET_HOLE/SET_DATA though, correct? If so, outside of
> >> >> that functionality I would assume relatively standard POSIX semantics.
> >> >
> >> > Err, no, you can always seek past EOF and then call write(2) to extend a
> >> > file
> >> > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are
> >> > different,
> >> > they are just used to discover sparse regions within a file.
> >> >
> >> > From the manpage:
> >> >
> >> > The lseek() system call allows the file offset to be set beyond the
> >> > end
> >> > of the existing end-of-file of the file. If data is later written at
> >> > this point, subsequent reads of the data in the gap return bytes of
> >> > zeros
> >> > (until data is actually written into the gap).
> >>
> >> You're correct. Linux (Fedora 13) isn't POSIX compliant (this is
> >> from the official POSIX text):
> >>
> >> The lseek ( ) function shall allow the file offset to be set beyond the
> >> end of the existing data in the file. If data is later written at this
> >> point, subsequent reads of data in the gap shall return bytes with the
> >> value 0 until data is actually written into the gap.
> >
> > so except for reading from /dev/zero freebsd also isn't posix compliant,
> > right?
>
> Huh...? Please better explain what you mean here.
this patch should make things a bit clearer.
cheers.
alex
> Thanks,
> -Garrett
--
a13x
diff --git a/sys/dev/null/null.c b/sys/dev/null/null.c
index 3005c19..a83be6f 100644
--- a/sys/dev/null/null.c
+++ b/sys/dev/null/null.c
@@ -47,11 +47,12 @@ static struct cdev *zero_dev;
static d_write_t null_write;
static d_ioctl_t null_ioctl;
+static d_read_t null_read;
static d_read_t zero_read;
static struct cdevsw null_cdevsw = {
.d_version =D_VERSION,
- .d_read = (d_read_t *)nullop,
+ .d_read = null_read,
.d_write = null_write,
.d_ioctl = null_ioctl,
.d_name = "null",
@@ -71,6 +72,19 @@ static void *zbuf;
static int
null_write(struct cdev *dev __unused, struct uio *uio, int flags __unused)
{
+
+ uio->uio_offset += uio->uio_resid;
+ uio->uio_resid = 0;
+
+ return (0);
+}
+
+/* ARGSUSED */
+static int
+null_read(struct cdev *dev __unused, struct uio *uio, int flags __unused)
+{
+
+ uio->uio_offset += uio->uio_resid;
uio->uio_resid = 0;
return (0);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: buildkernel error
Hi all, I have rebuilt my world and it works well. Thanks Best regards, lz On 02/22/2011 08:39 PM, Dimitry Andric wrote: On 2011-02-22 08:30, gnehzuil wrote: I updated my kernel source code and try to make a new kernel using make buildkernel command. But I got an error as follow: ... ld:/usr/src/sys/conf/ldscript.i386:66: syntax error Your /usr/bin/ld is still at version 2.15, which is too old to parse the kernel linker script. In this case, first run "make buildworld", or at least "make kernel-toolchain" before you attempt to build any kernels. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Scheduler question
On 04/02/2011, at 13:26, Daniel O'Connor wrote: > I am writing a program which reads from a data acquisition chassis connected > to a radar via USB. The interface is a Cypress FX2 and I am communicating via > libusb. I ended up writing a kernel driver (thank you hps for usb_fifo_*!) and it has greatly improved things which is good news for me :) I will some of the tests suggested by various people soon, I have to wait for a new PC to do them though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
