Re: aio_read() broken functionality.
Alfred Perlstein wrote: > > * Dmitry Sychov <[EMAIL PROTECTED]> [001109 13:06] wrote: > > Greetings. > > > > According to manual the aio_offset field of the "aiocb" structure > > is ignored in the aio_read() call. So one can read the file only from > > beginning. Very bad for me. :-( > > > > Will this bug be fixed in FreeBSD 5.0? > > Hrm, parsing through the kernel code it looks like this is just a > bug in the manpage, basically aio_offset doesn't look like it's > ignored, can you try to use aio_offset and report if it works or > not. It was probably correct when the manpage was written. This seems to be yet another bit of doco that has not been updated along with the system. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf()
* Zhenhai Duan <[EMAIL PROTECTED]> [001109 21:09] wrote: > A simple question: > > Does the kernel function printf() flushes the output immediately, or it is > possible some data is buffered somewhere and gets lost without printing > to the console? like the corresponding funtion in the c library. It's not buffered afaik. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
printf()
A simple question: Does the kernel function printf() flushes the output immediately, or it is possible some data is buffered somewhere and gets lost without printing to the console? like the corresponding funtion in the c library. Thanks. --Zhenhai To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: "iowait" CPU state
On Fri, Nov 10, 2000 at 12:33:31PM +1000, [EMAIL PROTECTED] wrote: > On Thu, 9 Nov 2000, void wrote: > > > not how busy the disks are. I want relative data, not absolute. > > systat -vmstat? Thank you! This gets the me disk %busy, which is one of the things I was looking for. Now, can anyone tell me how to tell what percentage of processor time is being spent waiting for disk I/O to complete? -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bad hardware?
Hi guys, Just curious if anyone has come across this error before, because I haven't... Nov 9 16:05:00 peach sshd[9275]: Disconnecting: Corrupted check bytes on input. Does anyone think it could be bad ram? I'm going to cvsup and run a buildworld and see how that goes... Thanks Keith To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repeatable STL core with -pthread
James FitzGibbon wrote:
>
> The program will core after about 10 seconds, every time.
> It would appear that there is an issue with some low-level allocator in the
> STL as shipped in 4.x.
Dude. The STL implementation that ships with g++ isn't thread safe.
In fact, if you read the STL portion of the C++ specification, you will
notice that threads are not mentioned at all. The only guarantees made
by the STL are that operations will complete within certain performance
guidelines.
As a safety tip, the string implementation in the g++ implementation
isn't thread safe either. It uses a shared buffer scheme ("char*
string->rep") to reduce memory consumption & improve performance. This
is in opposition to "deep copy" style libraries, like the SGI STL, that
work in threaded environments.
Because of the way the C++ standard is written, commercial STL
implementations, such as the Rogue Wave library that comes with the Sun
C++ compiler, suffer from the same threading problems.
--
Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED]
Integratus, Inc. | http://www.integratus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
The cable is pretty decent and the fact that it does not support the call is not a problem. Nick On Thu, 9 Nov 2000, Chris Dillon wrote: > On Thu, 9 Nov 2000, Nick Hibma wrote: > > > This is not a problem as the thing works although it displays the > > message. Because it does not support the call it gives an > > indication that multi LUN devices are not supported. > > > > I have one of these cables and managed to newfs a 4Gb SCSI drive. > > > > Was anything connected to the cable when you connected it? > > I'm looking for a USB to SCSI converter myself... are there any that > are a little more well-behaved and work great with FreeBSD and Windows > (preferably one that Win98+ will see without having to carry around a > driver disk)? I doubt I'll ever attach multi-lun devices to it > either, but I don't like my options limited. :-) > > > -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] >FreeBSD: The fastest and most stable server OS on the planet. >For IA32 and Alpha architectures. IA64 and PowerPC under development. >http://www.freebsd.org > > > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
Hm, I missed the zip story. You seem to have all the bits that are necessary in your kernel. Could you compile your kernel/module with UMASS_DEBUG defined and send me the output after an attach? The 'GetMAXLUN not supported' thing does not make the driver fail, it makes it just assume that the LUN is always 0. Nick On Thu, 9 Nov 2000, James FitzGibbon wrote: > * Nick Hibma ([EMAIL PROTECTED]) [001109 14:52]: > > > > > This is not a problem as the thing works although it displays the > > message. Because it does not support the call it gives an indication > > that multi LUN devices are not supported. > > > > I have one of these cables and managed to newfs a 4Gb SCSI drive. > > > > Was anything connected to the cable when you connected it? > > Yes, I've tried with a Yahama external CDR and a Syquest Syjet drive. In > neither case did the device show up on the probe. I do have "SCSI over USB" > working on the box, since I regularly use a USB zip drive on the same > machine and it comes up as device da0 right after the 'umass-sim0' probe. > > Can you share your kernel config and/or dmesg for that 4gb drive you mention > ? > > Thanks. > > -- > j. > > James FitzGibbon [EMAIL PROTECTED] > Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
Which version of the OS? Please update to a recent release of 4-STABLE if you are not there. Did you do a camcontrol rescan 0? What does that produce? All you will need is kldload usb kldload cam kldload umass or compile with the following options (I am not sure whether the CAM module is available in stable) device scbus device da device usb device umass Hope this helps. Nick On Thu, 9 Nov 2000, James FitzGibbon wrote: > * Nick Hibma ([EMAIL PROTECTED]) [001109 14:52]: > > > > > This is not a problem as the thing works although it displays the > > message. Because it does not support the call it gives an indication > > that multi LUN devices are not supported. > > > > I have one of these cables and managed to newfs a 4Gb SCSI drive. > > > > Was anything connected to the cable when you connected it? > > Yes, I've tried with a Yahama external CDR and a Syquest Syjet drive. In > neither case did the device show up on the probe. I do have "SCSI over USB" > working on the box, since I regularly use a USB zip drive on the same > machine and it comes up as device da0 right after the 'umass-sim0' probe. > > Can you share your kernel config and/or dmesg for that 4gb drive you mention > ? > > Thanks. > > -- > j. > > James FitzGibbon [EMAIL PROTECTED] > Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying msgrcv() and msgsnd()
On Thu, Nov 09, 2000 at 04:38:35PM +0100, Bjorn Tornqvist wrote:
> I'm going to add 2 functioncalls to the kernel; msgrcv_t() msgsnd_t()
> ("t" as in timeout) where the user will be able to specify a maximum
> amount of time they are prepared to wait for a message to be sent or
> become available.
>
> I just wonder if the rest of the freebsd community is interested in
> these kinds of additions to the kernel? I'm pretty certain there is
> alot more people out there who'd like this functionality. Should I
> bother posting them to the list?
>
> As a sidenote: The main reason I need this is since I can't use
> longjmp()/setjmp() with alarm() between pthread contexts; with FreeBSD
> 5.0 this fix probably won't be necessary (but still nice to have
> though).
>
> And besides, I'd get paid to contribute to the project! =)
I think this might be better handled by a kevent filter for message
queues, if you are going to hack something in the kernel for your
application. At least then it might find some general use.
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying msgrcv() and msgsnd()
* Bjorn Tornqvist <[EMAIL PROTECTED]> [001109 13:38] wrote:
>
> Hi!
>
> I'm going to add 2 functioncalls to the kernel; msgrcv_t() msgsnd_t()
> ("t"
> as in timeout) where the user will be able to specify a maximum amount
> of
> time they are prepared to wait for a message to be sent or become
> available.
>
> I just wonder if the rest of the freebsd community is interested in
> these
> kinds of additions to the kernel? I'm pretty certain there is alot more
> people out there who'd like this functionality. Should I bother posting
> them to the list?
>
> As a sidenote: The main reason I need this is since I can't use
> longjmp()/setjmp() with alarm() between pthread contexts; with FreeBSD
> 5.0
> this fix probably won't be necessary (but still nice to have though).
>
> And besides, I'd get paid to contribute to the project! =)
Actually, what i'd like to see is kqueue filters able to attach
to sysVipc. I'm pretty sure something like msgrcv_t()/msgsnd_t()
won't make it into the kernel, however I'd take a personal interest
in having kqueue'able sysV message queues and would be happy to
assist you in getting that into the kernel.
I'm also unsure why you'd want a "timeout", although it'd be less
effecient you could effectively poll by using IPC_NOWAIT and
usleep(3) or nanosleep(2).
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Modifying msgrcv() and msgsnd()
Hi!
I'm going to add 2 functioncalls to the kernel; msgrcv_t() msgsnd_t()
("t"
as in timeout) where the user will be able to specify a maximum amount
of
time they are prepared to wait for a message to be sent or become
available.
I just wonder if the rest of the freebsd community is interested in
these
kinds of additions to the kernel? I'm pretty certain there is alot more
people out there who'd like this functionality. Should I bother posting
them to the list?
As a sidenote: The main reason I need this is since I can't use
longjmp()/setjmp() with alarm() between pthread contexts; with FreeBSD
5.0
this fix probably won't be necessary (but still nice to have though).
And besides, I'd get paid to contribute to the project! =)
Greetings,
Bjorn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: aio_read() broken functionality.
* Dmitry Sychov <[EMAIL PROTECTED]> [001109 13:06] wrote: > Greetings. > > According to manual the aio_offset field of the "aiocb" structure > is ignored in the aio_read() call. So one can read the file only from > beginning. Very bad for me. :-( > > Will this bug be fixed in FreeBSD 5.0? Hrm, parsing through the kernel code it looks like this is just a bug in the manpage, basically aio_offset doesn't look like it's ignored, can you try to use aio_offset and report if it works or not. Please submit some test code if it doesn't. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Repeatable STL core with -pthread
We're having a problem with threaded programs that use the STL. Given the
following program:
--START--
#include
#include
typedef map mymap_t;
#ifdef GLOBLOCK
pthread_mutex_t glob_mut;
#endif
void *run(void *) {
while (1) {
string f("");
#ifdef GLOBLOCK
pthread_mutex_lock(&glob_mut);
#endif
f += "adsasd";
f += "adsasd";
f += "adsasd";
#ifdef GLOBLOCK
pthread_mutex_unlock(&glob_mut);
#endif
}
}
int main () {
#define FOO 50
pthread_t thread[FOO];
for(int x =0;x
aio_read() broken functionality.
Greetings. According to manual the aio_offset field of the "aiocb" structure is ignored in the aio_read() call. So one can read the file only from beginning. Very bad for me. :-( Will this bug be fixed in FreeBSD 5.0? Thank you! Dmitry
FreeBSD Foundation: Examples of FreeBSD as teaching aid/research plat
As some of you may know, I'm working on a 501(c)3 (tax exempt/non-profit) determination for the FreeBSD Foundation. The IRS seems to be a little confused about the nature of FreeBSD and we're currenlty working on a response to an initial determination from the IRS that was not favorable. One thing that would help us to explain the nature of FreeBSD and how it is used by the public is to enumerate some specific examples of how FreeBSD is used as either a teaching aid or a research platform by educational institutions. If possible, please include a contact name, email, or phone number so we can ask additional questions if necessary. Thanks in advance for your help! Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
Hello, dear friends!!! Sorry for mistakes I am from Lithuania :-) I'm 16 years old and I can't live without FreeBSD ! I want to develope it, but I think that I have not enougth knowledge :-( In my country I can't get FreeBSD :-( And my connection speed is 16k(I can't get FreeBSD from the Internet) Would you tell me what I must to do to develope FreeBSD, and where I can get it? I haven't a lot of money, but I want to work for FREE, I want learning!!! And I want to help you!!! Please tell me what I must to know to write own OS parts? Please trust me, my life in Lithuania is very hard! And I wanna get better life! I wanna start!
Re: close call in a device ?
Thank you infinitely for all this information. It will take me a while to absorb and poke around in the right places but this is definitely extremely useful, thank you. I will most probably come back to you with more questions, in a near future time... bruno Terry Lambert wrote: > > > To add to this, the close calls can be forces; there is a flag > > > in the device structure wich can force notification. I'm not > > > sure what it does over a fork(), though: I think you really want > > > open notification. > > > > You mean that when I register my device/kernel module, I can > > explicitely request that all close calls will notify my module? > > That is exactly what I need. > > Add D_TRACKCLOSE to d_flags for your device. When the d_close() > of your device is call, the first arg is the dev. > snip ... much much more To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
* Nick Hibma ([EMAIL PROTECTED]) [001109 14:52]: > > This is not a problem as the thing works although it displays the > message. Because it does not support the call it gives an indication > that multi LUN devices are not supported. > > I have one of these cables and managed to newfs a 4Gb SCSI drive. > > Was anything connected to the cable when you connected it? Yes, I've tried with a Yahama external CDR and a Syquest Syjet drive. In neither case did the device show up on the probe. I do have "SCSI over USB" working on the box, since I regularly use a USB zip drive on the same machine and it comes up as device da0 right after the 'umass-sim0' probe. Can you share your kernel config and/or dmesg for that 4gb drive you mention ? Thanks. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
On Thu, 9 Nov 2000, Nick Hibma wrote: > This is not a problem as the thing works although it displays the > message. Because it does not support the call it gives an > indication that multi LUN devices are not supported. > > I have one of these cables and managed to newfs a 4Gb SCSI drive. > > Was anything connected to the cable when you connected it? I'm looking for a USB to SCSI converter myself... are there any that are a little more well-behaved and work great with FreeBSD and Windows (preferably one that Win98+ will see without having to carry around a driver disk)? I doubt I'll ever attach multi-lun devices to it either, but I don't like my options limited. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64 and PowerPC under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
This is not a problem as the thing works although it displays the message. Because it does not support the call it gives an indication that multi LUN devices are not supported. I have one of these cables and managed to newfs a 4Gb SCSI drive. Was anything connected to the cable when you connected it? Nick > I have a Microtech USB to SCSI converter (see > http://www.microtechint.com/qs-usbscsi.html for details). > > Under Windows (having installed the driver that comes with), everything > works without issue. Under BSD, I get this on boot: > > umass0: Microtech International, Inc. USB-SCSI-HD50, rev 1.00/1.00, addr 3 > umass0: Get Max Lun not supported (STALLED) > > Are there any known workarounds for this problem ? In my particular > application I won't be using multi-lun devices, but I don't think that > making a "maxlun=0" assumption is a good thing to do. > > Are there any known workarounds for this problem ? > > Thanks. > > -- > j. > > James FitzGibbon [EMAIL PROTECTED] > Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-scsi" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
USB-to-SCSI converter
I have a Microtech USB to SCSI converter (see http://www.microtechint.com/qs-usbscsi.html for details). Under Windows (having installed the driver that comes with), everything works without issue. Under BSD, I get this on boot: umass0: Microtech International, Inc. USB-SCSI-HD50, rev 1.00/1.00, addr 3 umass0: Get Max Lun not supported (STALLED) Are there any known workarounds for this problem ? In my particular application I won't be using multi-lun devices, but I don't think that making a "maxlun=0" assumption is a good thing to do. Are there any known workarounds for this problem ? Thanks. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OT] serial protocol analyzer
In article <3A0AF50D.16530.974B26@localhost>, Leonard den Ottolander <[EMAIL PROTECTED]> wrote: > I was wondering if somebody could point me out a serial protocol > analyzer. Maybe analyzer is too big a word for what I am looking > for (I could be the analyzer :) ). What I am thinking of is a piece > of software that listens on two serial devices, and mimics input > from either to the other, in the mean time dumping and/or analyzing > the traffic. To be concrete: I want to put a box with this piece of > software between another box and its modem to analyze the traffic. Try the "comms/snooper" port. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: close call in a device ?
> > To add to this, the close calls can be forces; there is a flag
> > in the device structure wich can force notification. I'm not
> > sure what it does over a fork(), though: I think you really want
> > open notification.
>
> You mean that when I register my device/kernel module, I can
> explicitely request that all close calls will notify my module?
> That is exactly what I need.
Add D_TRACKCLOSE to d_flags for your device. When the d_close()
of your device is call, the first arg is the dev.
Unfortunately, vcount() is used to see if the close is really a
final close, or not, and the vp is not passed into the close
itself. You will have to track closes yourself. One kludge to
get around having to so this is to modify spec_close() to do:
} else if (devsw(dev)->d_flags & D_TRACKCLOSE) {
/* Keep device updated on status */
if (vcount(vp) > 1) {
/* clear flag to signal driver of last close*/
devsw(dev)->d_flags &= ~D_TRACKCLOSE;
}
} else if (vcount(vp) > 1) {
and then as the _first_ thing in your close code:
if( !(devsw(dev)->d_flags & D_TRACKCLOSE)) {
/* magic: final close: add flag back in to keep sane*/
devsw(dev)->d_flags |= D_TRACKCLOSE;
...
}
You can find spec_close() in /sys/miscfs/specfs/spec_vnops.c.
You really probably ought to just add the flag back in in the
first open. The thing that makes this a kludge is that it very
evilly unsets a flag it shouldn't unset, and it makes it the job
of the device to fix up the damage (the interface isn't reflexive).
A secondary nit is that this is not really reentrant, while the
flag is clear, so you have to be careful.
Really, since you will be doing per-open instance housekeeping
anyway, you ought to just add a list pointer to the per-open
instance data, and keep the open instances on a linked list;
you will have tolook up the per-open instance data somehow,
anyway, and it might as well be a list traversal. When list
membership goes from 1->0, you'll know it's the last close, and
you can free global (non per-open instance) resources.
Traditionally, this is done using a minor number, but you
can't just naievely allocate an unused one, since you might
not get called.
> What do you mean by open notification ? I do get all "open" calls to my
> device, just not all the "close"
For each open, d_open() gets called. This is where you will
be creating your per open instance data. You should look at
how fd's are handled over a fork() or other call. Without a
look at this code in depth, I can't tell you today whether or
not your d_open() code will get called again for each open fd,
or not. If it doesn't, this could be a problem for you. It
used to get called, FWIW.
> > The main problem with per process resources is that the VFS that
> > implements devices, specfs, doesn't own its own vnodes.
>
> Could you develop a little ? I don't know about VFS, specfs and vnodes...
When you perform an operation on an open file, the vnode pointer
is dereferenced out of the per process open file table. The kernel
internally doesn't know from file handles (architectural bug, IMO),
and so not only is it hard to do file I/O in the kernel, but you
have this opaque handle called a vnode.
When you do an ioctl() or something else, then because this is
a special device, there is a dereference into a function table
pointed to by the vnode. This table is called "struct fileops",
and the table for special devices is spec_fileops.
So you give it a vnode, it dereferences the fcntl() function
pointer out of this table to make the call, and passes the
vnode pointer as an argument.
In the spec_fileops version of fcntl(), the device specific data
is derefenced out of the vnode; it can do this, because it knows
that any vnode of type VCHR will have one of these structures on
it. This is used by specfs to locate the correct device entry
point to call: your device.
Your device driver function is then called, with the device
private data pointer from the vnode, called "dev". It's a
pointer to your device private data.
Because the specfs does not own its own vnodes, each time you
open a device, you get the same vnode back from specfs. It
can't give you a different one, because you asked for the same
one: by the time it gets to the open, all it has is the vnode
of the parent directory, a major number, and a minor number.
So there's no way for the open to return a unique instance of
the device each time you open it, because it can only return
one vnode. This gets worse, because of fork() and other fd
managemetn behaviour. The kernel likes to give back the same
vnode to a user space process as often as possible. If one of
these calls to do this returns another reference to an existing
open isntance (say you open the same device twice from the same
program, or you call dup() or dup2()), then you
PPPD!
Hello! I try to start pppd but always receive such message when start pppd Device cuaa0 is busy... What I must do, I try to kill all pppd and then start again, but again receive such message, before rebbot everything works fine Thank you... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: "iowait" CPU state
On Tue, Nov 07, 2000 at 04:13:30PM +0100, Dag-Erling Smorgrav wrote: > void <[EMAIL PROTECTED]> writes: > > I've been using Solaris a lot lately, and I've noticed that in e.g. > > top's output, it has a distinct CPU state called "iowait", which seems > > to be a pretty good indicator of how I/O-bound a system is. Is there > > any reason that FreeBSD doesn't have such a state? > > It has several, depending on the type of I/O the process is waiting > for: biord (waiting for a read operation to complete), biowr (waiting > for a write operation to complete), select (waiting for descriptors to > become readable / writable), etc. Is there any reason top couldn't add these up and report a %iowait like Solaris'? -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: "iowait" CPU state
On Tue, Nov 07, 2000 at 12:00:22AM -0800, Brian O'Shea wrote: > > What information are you looking for specifically? %busy figures for disks, %iowait figures for processors. > $ systat -io > > Hope that helps, Like iostat, this tells me how much data is being transferred, but not how busy the disks are. I want relative data, not absolute. Thanks though. -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RPC not taking the same service twice: a bug or a security measure?
[EMAIL PROTECTED] wrote: > > On 8 Nov, Bill Paul wrote: > >> A coworker seems to have found an issue with portmap on FreeBSD. > >> Aparently, if you try and register the same service twice, but with > >> different protocols (UDP vs TCP), it doesn't work. I'm not entirely sure > >> I believe this, and I am digging for more details, but I am writing to > >> see if anyone can tell me anything that will save me having to do the > >> investigative work. :-) I'll follow up with more details as I can. > > > > No you won't, because both you and your cow-orker are smoking entirely > > too much crack. (Him for hallucinating this problem in the first place, > > and you for believing him enough to post this query here.) > > > Hey!! There is no need for this type of response. > It's obvious the person writing has good intentions, > but has not read a TCP/IP book, that's worth a damm. > I would consider it a personal favor, if this might be > responded to in a less attacking manner. No, no. He's right. We were smoking too much crack. :-) The problem turns out that we try to unregister the service before we register it. On solaris we use rpcb_unset(), which is protocol specific. On Freebsd, we use pmap_unset() which does not consider protocol. It would unregister the one we registered on the other protocol moments ago. I guess on FreeBSD there is no way to unregister selectively such as with rpcb_unset(), so we will just have to be a little more careful. :-) In my own defense, I'd like to point out that I've read lots of good TCP/IP books. It's RPC that I know very little about. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help writing a screen saver module
Dan Nelson wrote:
>
> In the last episode (Nov 07), Dag-Erling Smorgrav said:
> > Graham Wheeler <[EMAIL PROTECTED]> writes:
> > > I am trying to write a screen saver module that, when it kicks in,
> > > will switch to the first console, and then, if a key is pressed,
> > > will switch back to the one that was previously active. The idea is
> > > that the first console has something useful running on it,
> > > typically a tail -f of the logs.
> >
> > Switching consoles causes syscons to stop the screensaver, which
> > causes your code to try to switch back to the original console, which
> > causes syscons to stop the screensaver since seems to be running. In
> > other words, Don't Do That. Sorry.
>
> You can make it look like you're switched to vty 0, by making your
> screen_saver() function simply copy the contents of vty 0 to screen
> memory on every update. Just make sure both vtys are the same size
> first...
I've made some progress here. I have a function in syscons.c that should
(I thought) work. It only works partially. When the saver kicks in it
changes the contents of the screen with something that looks half-like
garbage, and half like it should. In some places every second character
is right, and these are interspersed with whitespace which shouldn't be
there, but in others this breaks down, and I might have a few
consecutive ones right or a whole sequence of garbage. (On closer
inspection, the `garbage' seems to be remnants of the original
contents). On the other hand, if I press a key, the original contents
are restored perfectly (or perhaps only the characters that were being
copied are being restored, which together with the `garbage' makes the
screen look like it used to?). I'm quite confused about why this is so.
Any ideas anyone?
Here is my additional function added to syscons.c:
/* Copy the contents of one console to another. The original contents
of the copyee are saved in a buffer, a pointer to which is returned,
iff backup==0. If backup is non-zero, and from < 0, then backup
should point to the original contents, and they will be restored,
and the memory used will be freed.
So the use is something like:
First Copy:
char *backup = CopyConsoleContents(from, to, 0);
Refresh (subsequent copies):
backup = CopyConsoleContents(from, to, backup);
or:
(void)CopyConsoleContents(from, to, backup);
Restore:
CopyConsoleContents(-1, to, backup);
If to<0 then the current console will be used
*/
u_short *CopyConsoleContents(int from, int to, u_short *backup);
u_short *CopyConsoleContents(int from, int to, u_short *backup)
{
if (to < 0) /* if to < 0 we want the current console */
to = get_scr_num();
if (to != from) /* don't waste time if source == dest */
{
scr_stat *fc, *tc = console[to];
int s = spltty(), pos, len;
/* is this a restore? */
if (from < 0 && backup)
{
/* restore from the backup and free allocated memory */
bcopy((char*)backup, (char*)tc->scr_buf,
tc->xsize*tc->ysize*sizeof(u_short));
free((char*)backup, M_DEVBUF);
backup = 0;
}
/* else this is a copy */
else if (from>=0 && from < MAXSONS) /* is the source index sane?
*/
{
fc = console[from];
/* first do some more sanity checks: non-NULL pointers and
equal console sizes */
if (fc && tc &&
fc->xsize == tc->xsize && fc->ysize == tc->ysize &&
fc->scr_buf && tc->scr_buf)
{
/* is this a first copy? if so, backup original contents
*/
if (backup == 0)
{
backup = (u_short*)malloc(
tc->xsize*tc->ysize*sizeof(u_short),
M_DEVBUF, M_NOWAIT);
if (backup)
bcopy((const char*)tc->scr_buf, (char*)backup,
tc->xsize*tc->ysize*sizeof(u_short));
}
/* copy the from console to the to console
bcopy((const char*)fc->scr_buf, (char*)tc->scr_buf,
fc->xsize*fc->ysize*sizeof(u_short));
}
}
/* update the video memory if to==current console */
if (to == get_scr_num() && tc->adp && tc->adp->va_window)
{
len = tc->ysize * tc->xsize;
for (pos = 0;
pos < len;
pos +=2)
writew(tc->adp->va_window + pos*2,
tc->scr_buf[pos]);
}
splx(s);
}
return backup;
}
Here is what the switch_saver.c looks like now:
#include
#include
#include
#include
#
Re: What about rc.shutdown.local?
This already happens... at least in rc.shutdown v1.15:
# $FreeBSD: src/etc/rc.shutdown,v 1.15 2000/10/20 20:26:05 ache Exp $
-Steve
On Thu, Nov 09, 2000 at 04:16:07PM +0100, Christoph Sold wrote:
> [ Redirected from [EMAIL PROTECTED] to [EMAIL PROTECTED] ]
>
> Jimmy Olgeni schrieb:
> >
> > It would be nice to have a /etc/rc.shutdown.local called by
> > /etc/rc.shutdown,
> > to implement custom shutdown procedures. This is currently done by
> > editing rc.shutdown, but you have to remember about it when you run
> > mergemaster.
> >
> > Just a thought :)
>
> Better still would be /usr/local/etc/rc.d/*.sh called automatically
> with parameter stop. To do so, insert
>
> for dir in ${local_startup}; do
> if [ -d "${dir}" ]; then
> for script in ${dir}/*.sh; do
> if [ -x "${script}" ]; then
> (set -T
> trap 'exit 1' 2
> ${script} stop)
> fi
> done
> fi
> done
> echo .
>
> into /etc/rc.shutdown. (Script shamelessly copied from /etc/rc), changed
> "start" to "stop".
>
> HTH
> -Christoph Sold
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: What about rc.shutdown.local?
[ Redirected from [EMAIL PROTECTED] to [EMAIL PROTECTED] ]
Jimmy Olgeni schrieb:
>
> It would be nice to have a /etc/rc.shutdown.local called by
> /etc/rc.shutdown,
> to implement custom shutdown procedures. This is currently done by
> editing rc.shutdown, but you have to remember about it when you run
> mergemaster.
>
> Just a thought :)
Better still would be /usr/local/etc/rc.d/*.sh called automatically
with parameter stop. To do so, insert
for dir in ${local_startup}; do
if [ -d "${dir}" ]; then
for script in ${dir}/*.sh; do
if [ -x "${script}" ]; then
(set -T
trap 'exit 1' 2
${script} stop)
fi
done
fi
done
echo .
into /etc/rc.shutdown. (Script shamelessly copied from /etc/rc), changed
"start" to "stop".
HTH
-Christoph Sold
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: RPC not taking the same service twice: a bug or a security measure?
On 8 Nov, Bill Paul wrote: >> A coworker seems to have found an issue with portmap on FreeBSD. >> Aparently, if you try and register the same service twice, but with >> different protocols (UDP vs TCP), it doesn't work. I'm not entirely sure >> I believe this, and I am digging for more details, but I am writing to >> see if anyone can tell me anything that will save me having to do the >> investigative work. :-) I'll follow up with more details as I can. > > No you won't, because both you and your cow-orker are smoking entirely > too much crack. (Him for hallucinating this problem in the first place, > and you for believing him enough to post this query here.) > Hey!! There is no need for this type of response. It's obvious the person writing has good intentions, but has not read a TCP/IP book, that's worth a damm. I would consider it a personal favor, if this might be responded to in a less attacking manner. best regards, Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: post-install of kernal sources, maxusers max?
On Wed, 8 Nov 2000, Len Conrad wrote: > Sorry to bother you hackers, but -questions isn't responding, and the > handbook and Complete/Lehey don't, afaics, cover this situation > explicitly. I can't really afford to screw up this production > machine and start over from fresh disk, nor futz around for hours > guessing what magik combo of post-install choices will do the trick. > > == > > I'm working, remotely, on a 4.1 system with only a binary install from cdrom. > > Now I need to do a custom kernal. Can the /stand/systinstall > post-config option be used to put on all the developer source pkg > without bothering the current config? which choice (I don't want X, > just enough to build a custom kernal) > Install cvsup-binary from ports, and cvsup the sources. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: daemon()
Terry Lambert wrote: [snippage] > > exactly. this does not happen if I run this program from tcsh > > (but does if I run from bash 1.14.7(1) built from ports > > thanks! > All in all, bash is pretty buggy. The originator already stated that the bug doesn't appear in bash 2. Using bash 1 as an example of anything is just (pardon the pun) bash-bash'ing. I stand by my statement that no one with any sense still uses bash 1 for anything. It's documented to be broken lots of ways, and all known bugs are fixed in bash 2. If there are real bugs (not style disagreements) in bash 2, they should be reported to the maintainer, who actively responds to and fixes reported problems. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf allocation error
[ don't cross post, followups to hackers (was on stable) ] On Thu, Nov 09, 2000 at 11:23:27AM +, Kaltashkin Eugene wrote: > #netstat -m > 567/2176/4096 mbufs in use (current/peak/max): > 317 mbufs allocated to data > 250 mbufs allocated to packet headers > 296/1024/1024 mbuf clusters in use (current/peak/max) > > where i can increase amount of mbuf ? > sysctl say what this variables is readonly :( options NMBCLUSTERS=8192 or whatever in your kernel. or kern.ipc.nmbclusters="8192"# Set the number of mbuf clusters in /boot/loader.conf -- Bill Fumerola - Lame Duck, BOFH / Chimes, Inc. [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mbuf allocation error
Hi ppls Today i get message looutput: mbuf allocation error #netstat -m 567/2176/4096 mbufs in use (current/peak/max): 317 mbufs allocated to data 250 mbufs allocated to packet headers 296/1024/1024 mbuf clusters in use (current/peak/max) where i can increase amount of mbuf ? sysctl say what this variables is readonly :( Best Regards. Zhecka PS: system use Postgresql with many many records. Everynight base has been repacked. -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
