RE: Disk scheduling in FreeBSD
Mike, I don't have the test, but I've built a generic performance testing framework for FreeBSD over the past couple of months that would make running such a test trivial. I'd post a link but the page has no permanent home yet. When it gets one I can follow it up with a link. For now, the application called "boot_tester" allows the user to run a set of commands (usually performance tests) on boot. The framework optionally creates a new filesystem work area and outputs in a standard format. The commands are run for n iterations (one per boot) over an array of kernels. If used with the diskless testbed setup I've started developing to use with it, running tests over arbitrary worlds as well as kernels is trivial and can be automated. If anyone's interested, contact me. Like I said, I'll put up a link when I get a home for the pages. > > On Fri, 28 Feb 2003, Paul Robinson wrote: > >> Well, I'm just a hanger-on without a commit bit, so I'll >> work on making it production ready in the next few weeks, >> post up a patch and if somebody wants to commit it, great. >> At the moment it's all based on 4.3-RELEASE and isn't really >> production ready. It does look worth doing though. > > Make an easy to run testbench which should show the > performance > improvements / disadvantages of a new IO scheduler first; > that's really the first step. > > Mike "Silby" Silbersack > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Adam Migus - Research Scientist Network Associates Laboratories (http://www.nailabs.com) TrustedBSD (http://www.trustedbsd.org) FreeBSD (http://www.freebsd.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/40611 linux compatibility fix
> I didn't know there're so many people running linux apps under emulation. > I've a couple of other linux related patches for -stable, among them > backport of linux ptrace from -current, anyone interested? yes, it would be good to have 'ptrace' backport already in 4.8-R, if not too late (good to have breakpoints working in Linux 'gdb') 04.03.2003; 22:56:26 [SorAlx] http://cydem.org.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: D_KQFILTER & ltmdm: Patch for review?
On Wed, 2003-03-05 at 14:01, Michael Edenfield wrote: > I finally broke down and put the patch online instead of pasting into the > email every time: > > http://www.kutulu.org/ltmdm.patch > > (By the time I get this right the maintainer will probably have fixed it > anyway :\ ) He might possibly ;) I will hopefully look at your patch tonight so I can nag someone into committing it.. -- 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 - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD/x86-64 Mailing List.
Please subscribe me to the FreeBSD/x86-64 mailing list. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: D_KQFILTER & ltmdm: Patch for review?
- Original Message -
From: "M. Warner Losh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, March 04, 2003 9:49 PM
Subject: Re: D_KQFILTER & ltmdm: Patch for review?
> In message: <[EMAIL PROTECTED]>
> "Mike Edenfield" <[EMAIL PROTECTED]> writes:
> : From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
> : Sent: Tuesday, March 04, 2003 5:39 PM
> :
> : > But your patch is wrong. Please format the initialization like
> : > you see in all the other device drivers:
> :
> : I now see what you meant about the formatting. It was the whole reason
to
> : reorder the fields, sorry I missed that. I also removed the redundant
> : initializations.
> :
> : Do you (well, does anyone) have a moment to eyeball this patch before I
send
> : it off to the maintainer?
> :
> : Thanks again,
> :
> : --Mike
> :
> : --- sys/dev/ltmdm/ltmdmsio.c.orig Tue Mar 4 19:49:57 2003
> : +++ sys/dev/ltmdm/ltmdmsio.cTue Mar 4 20:17:16 2003
> : @@ -360,6 +360,18 @@
> : #endif
> :
> : static struct cdevsw sio_cdevsw = {
> : +#if __FreeBSD_version >= 500104 /* >= 20030303 */
>
> This syntax works even for old versions of FreeBSD. You can make it
> safe by including all the noFoo functions. phk got rid of them
> because it is safe in >= 500104 to do that. Since you want to run on
> multiple versions, it would be better/safer to do that.
Alright, I did all that. I also eliminated some duplicated code by breaking
the conditions up into 4 seperate blocks instead of 4 nested blocks, but I'm
not sure if that is correct from a style standpoint. The resulting file is
a couple lines smaller and easier to read (for me anyway), but it's not the
style of the original code. It also made the patch slightly larger. I
didn't see anything in style(9) pointing either way, is this an issue?
I finally broke down and put the patch online instead of pasting into the
email every time:
http://www.kutulu.org/ltmdm.patch
(By the time I get this right the maintainer will probably have fixed it
anyway :\ )
--Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: D_KQFILTER & ltmdm: Patch for review?
In message: <[EMAIL PROTECTED]>
"M. Warner Losh" <[EMAIL PROTECTED]> writes:
: : static struct cdevsw sio_cdevsw = {
: : +#if __FreeBSD_version >= 500104 /* >= 20030303 */
:
: This syntax works even for old versions of FreeBSD. You can make it
: safe by including all the noFoo functions. phk got rid of them
: because it is safe in >= 500104 to do that. Since you want to run on
: multiple versions, it would be better/safer to do that.
Eg, here's what I'd do to sys/pccard if I had to MFC it before MFCing
the nofoo patches:
#if __FreeBSD_version < 500104
#define CDEV_MAJOR 50
#else
#define CDEV_MAJOR MAJOR_AUTO
#endif
static struct cdevsw crd_cdevsw = {
.d_open = crdopen,
.d_close = crdclose,
.d_read = crdread,
.d_write = crdwrite,
.d_ioctl = crdioctl,
.d_poll = crdpoll,
.d_mmap = nommap,
.d_strategy = nostrategy,
.d_name = "crd",
.d_maj = CDEV_MAJOR,
.d_dump = nodump,
.d_flags = 0,
.d_kqfilter = nokqfilter;
#if __FreeBSD_version < 500104
.d_psize = nopsize,
#endif
};
It is a little ugly, and phk wouldn't like it, but it would be
portable back to about FreeBSD 4.2 or so for those drivers that try to
do that. Well, I'm not 100% sure about 4.2, but I know that 4.5's
compiler groks the above. However, I plan on merging the NULL patches
soon (after the thaw), so it could become the following:
static struct cdevsw crd_cdevsw = {
.d_open = crdopen,
.d_close = crdclose,
.d_read = crdread,
.d_write = crdwrite,
.d_ioctl = crdioctl,
.d_poll = crdpoll,
.d_strategy = nostrategy,
.d_name = "crd",
.d_maj = CDEV_MAJOR,
};
but would work only on 4.8+a little and newer (which for my purposes
is fine).
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: D_KQFILTER & ltmdm: Patch for review?
In message: <[EMAIL PROTECTED]>
"Mike Edenfield" <[EMAIL PROTECTED]> writes:
: From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
: Sent: Tuesday, March 04, 2003 5:39 PM
:
: > But your patch is wrong. Please format the initialization like
: > you see in all the other device drivers:
:
: I now see what you meant about the formatting. It was the whole reason to
: reorder the fields, sorry I missed that. I also removed the redundant
: initializations.
:
: Do you (well, does anyone) have a moment to eyeball this patch before I send
: it off to the maintainer?
:
: Thanks again,
:
: --Mike
:
: --- sys/dev/ltmdm/ltmdmsio.c.orig Tue Mar 4 19:49:57 2003
: +++ sys/dev/ltmdm/ltmdmsio.cTue Mar 4 20:17:16 2003
: @@ -360,6 +360,18 @@
: #endif
:
: static struct cdevsw sio_cdevsw = {
: +#if __FreeBSD_version >= 500104 /* >= 20030303 */
This syntax works even for old versions of FreeBSD. You can make it
safe by including all the noFoo functions. phk got rid of them
because it is safe in >= 500104 to do that. Since you want to run on
multiple versions, it would be better/safer to do that.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
auto login gdm help
hi,all: how can i do to make machine boot up and auto login to X as special users ? don't know how to pass the authentications with gdm. Thanks in advance, any responses are welcome. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
D_KQFILTER & ltmdm: Patch for review?
From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
Sent: Tuesday, March 04, 2003 5:39 PM
> But your patch is wrong. Please format the initialization like
> you see in all the other device drivers:
I now see what you meant about the formatting. It was the whole reason to
reorder the fields, sorry I missed that. I also removed the redundant
initializations.
Do you (well, does anyone) have a moment to eyeball this patch before I send
it off to the maintainer?
Thanks again,
--Mike
--- sys/dev/ltmdm/ltmdmsio.c.orig Tue Mar 4 19:49:57 2003
+++ sys/dev/ltmdm/ltmdmsio.cTue Mar 4 20:17:16 2003
@@ -360,6 +360,18 @@
#endif
static struct cdevsw sio_cdevsw = {
+#if __FreeBSD_version >= 500104 /* >= 20030303 */
+ .d_maj = MAJOR_AUTO,
+ .d_flags = D_TTY,
+ .d_name = driver_name,
+ .d_open = sioopen,
+ .d_close = sioclose,
+ .d_read = sioread,
+ .d_write = siowrite,
+ .d_ioctl = sioioctl,
+ .d_poll = ttypoll,
+ .d_kqfilter = ttykqfilter
+#else
/* open */ sioopen,
/* close */ sioclose,
/* read */ sioread,
@@ -389,6 +401,7 @@
/* kqfilter */ ttykqfilter,
#endif
#endif
+#endif /* __FreeBSD_version >= 500104 */
};
static u_int com_events; /* input chars + weighted output completions */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: D_KQFILTER & ltmdm.
From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
Sent: Tuesday, March 04, 2003 5:39 PM
Subject: Re: D_KQFILTER & ltmdm.
> >2) The patch, which I've included below, only works for -CURRENT with
> >rev1.170 of conf.h. I wasn't sure how to get the preprocessor to
> >differentiate between -CURRENT before and after this specific revision of
a
> >specific file. What is the correct way to do this? Or, alternatively,
> >should the patch simply assume FreeBSD 5 is the latest -CURRENT and not
> >worry about the imcompatibility w/ 5.0-RELEASE?
>
> I have bumped __FreeBSD_version so you can test for this.
Will do. Where do I look to find the version numbers?
> But your patch is wrong. Please format the initialization like
> you see in all the other device drivers:
>
> static struct cdevsw sio_cdevsw = {
> .d_maj = MAJOR_AUTO,
> .d_flags = D_TTY,
> .d_open = sioopen
> etc
> etc
Ok. I didn't choose that formatting, it was the existing ltmdm code. I
simply moved the lines around to match the correct order. But I will change
this before I submit a new patch.
Thanks!
--Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: 'ticks' in kernel.
David Malone wrote: On Tue, Mar 04, 2003 at 02:00:02PM -0500, Jan Knepper wrote: How would they return me the 'value' of 'ticks'? The problem is... I have a value's somewhere that has been assigned from 'ticks', like: ptr -> value = ticks; Maybe it would help to explain what you are doing at a higher level? It seems odd that you need to do anything like this at all... Well, what I started doing is patching 'netstat' with the idea that I can display: - Time a TCP connection was setup. - Age of a TCP connection. the 'tcpcb' seems to have a member 't_starttime' which could be used for this. However, t_starttime is being initialized from 'ticks'. So to get an result that would make sense to a user I would have to do something like: const time_t boottime; time_t tcptime; tcptime = boottime + ( ticks - tcpcb -> t_starttime ) / FACTOR; The missing part... 'ticks'... Thanks! Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tape mark error on LTO drive/tapes - SCSI problem ?
NOTE
cc'd to freebsd-hackers also
please check /var/log/messages extract at end
On Wed, 5 Mar 2003 10:15, Joshua Baker-LePain wrote:
> On Wed, 5 Mar 2003 at 9:19am, Murray Taylor wrote
>
> > *** A TAPE ERROR OCCURRED: [[writing filemark: Input/output error]].
> >
> > It seems to be related to a long pause in the cycles as the
> > last halfcut partition is dumped prior to taping
>
> What do you mean by "long pause in the cycles"?
I think that the small partitions dump and tape, then there is a longer time gap as
the larger partition dumps before it runs the taper
>
> > taper: tape Daily001 kb 6512800 fm 9 writing filemark: Input/output
> > error
>
> You're only getting about 6.5MB on a tape, before the OS throws an I/O
> error. Do you have any messages in your system logs? What OS are we
> talking here? Have you tested the tape drive w/o amanda?
Operating system
# uname -a
FreeBSD svlto.dand02.au.bytecraft.au.com 4.7-STABLE FreeBSD 4.7-STABLE #0: Mon Oct 28
10:03:20 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
I have run the tape drive with a series of tar dumps to try to bust it and it seems to
happily chug along
This error does not happen every time I run Amanda .. we just did a full level 0 on
all machine last friday OK using amadmin daily force for
each of the three machines.
The Amanda log from the failed dump
# more log.20030304.1
START driver date 20030304
DISK planner halfcut da0s2a
DISK planner halfcut da0s3f
DISK planner halfcut da0s2f
DISK planner wombat.bytecraft.au.com da0s2a
DISK planner wombat.bytecraft.au.com da0s3f
DISK planner wombat.bytecraft.au.com da0s2f
DISK planner spyder.bytecraft.au.com da0s2a
DISK planner spyder.bytecraft.au.com da0s4e
DISK planner spyder.bytecraft.au.com da0s3g
DISK planner spyder.bytecraft.au.com da0s2f
START planner date 20030304
START taper datestamp 20030304 label Daily001 tape 0
INFO planner Incremental of wombat.bytecraft.au.com:da0s3f bumped to level 2.
INFO planner Full dump of spyder.bytecraft.au.com:da0s4e promoted from 3 days ahead.
INFO planner Full dump of spyder.bytecraft.au.com:da0s3g promoted from 3 days ahead.
INFO planner Full dump of halfcut:da0s2f promoted from 3 days ahead.
INFO planner Full dump of halfcut:da0s2a promoted from 3 days ahead.
INFO planner Full dump of spyder.bytecraft.au.com:da0s2f promoted from 3 days ahead.
INFO planner Full dump of wombat.bytecraft.au.com:da0s2a promoted from 3 days ahead.
INFO planner Full dump of wombat.bytecraft.au.com:da0s2f promoted from 3 days ahead.
INFO planner Full dump of spyder.bytecraft.au.com:da0s2a promoted from 3 days ahead.
FINISH planner date 20030304
STATS driver startup time 5117.457
SUCCESS dumper spyder.bytecraft.au.com da0s3g 20030304 0 [sec 0.244 kb 170 kps 696.3
orig-kb 820]
SUCCESS taper spyder.bytecraft.au.com da0s3g 20030304 0 [sec 2.148 kb 224 kps 104.2
{wr: writers 7 rdwait 0.000 wrwait 0.016 filemark 2.130}
]
SUCCESS dumper halfcut da0s2a 20030304 0 [sec 15.259 kb 19910 kps 1304.8 orig-kb 59380]
SUCCESS taper halfcut da0s2a 20030304 0 [sec 7.687 kb 19968 kps 2597.4 {wr: writers
624 rdwait 0.000 wrwait 4.196 filemark 3.325}]
SUCCESS dumper wombat.bytecraft.au.com da0s2a 20030304 0 [sec 44.356 kb 38718 kps
872.9 orig-kb 79410]
SUCCESS taper wombat.bytecraft.au.com da0s2a 20030304 0 [sec 10.387 kb 38752 kps
3730.8 {wr: writers 1211 rdwait 0.000 wrwait 6.378 filemark
3.545}]
SUCCESS dumper spyder.bytecraft.au.com da0s2a 20030304 0 [sec 57.663 kb 97841 kps
1696.8 orig-kb 122080]
SUCCESS taper spyder.bytecraft.au.com da0s2a 20030304 0 [sec 18.013 kb 97888 kps
5434.3 {wr: writers 3059 rdwait 0.000 wrwait 13.760 filemar
k 3.306}]
SUCCESS dumper spyder.bytecraft.au.com da0s4e 20030304 0 [sec 121.065 kb 174826 kps
1444.1 orig-kb 216370]
SUCCESS dumper halfcut da0s2f 20030304 0 [sec 197.644 kb 188594 kps 954.2 orig-kb
483220]
SUCCESS taper spyder.bytecraft.au.com da0s4e 20030304 0 [sec 28.180 kb 174880 kps
6205.7 {wr: writers 5465 rdwait 0.000 wrwait 22.132 filema
rk 3.485}]
SUCCESS taper halfcut da0s2f 20030304 0 [sec 28.171 kb 188640 kps 6696.1 {wr: writers
5895 rdwait 0.380 wrwait 23.982 filemark 1.810}]
SUCCESS dumper spyder.bytecraft.au.com da0s2f 20030304 0 [sec 148.851 kb 159882 kps
1074.1 orig-kb 637700]
SUCCESS taper spyder.bytecraft.au.com da0s2f 20030304 0 [sec 26.088 kb 159936 kps
6130.4 {wr: writers 4998 rdwait 0.000 wrwait 21.400 filema
rk 3.532}]
SUCCESS dumper wombat.bytecraft.au.com da0s2f 20030304 0 [sec 331.741 kb 112827 kps
340.1 orig-kb 299500]
SUCCESS taper wombat.bytecraft.au.com da0s2f 20030304 0 [sec 20.114 kb 112864 kps
5611.1 {wr: writers 3527 rdwait 0.000 wrwait 15.914 filema
rk 3.515}]
SUCCESS dumper wombat.bytecraft.au.com da0s3f 20030304 2 [sec 3068.527 kb 5719606 kps
1864.0 orig-kb 11429150]
SUCCESS taper wombat.bytecraft.au.com da0s3f 20030304 2 [sec 780.814 kb 5719648 kps
7325.2 {wr: writers 178739 rdwait 0.066 wrwai
Re: 'ticks' in kernel.
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Jan Knepper <[EMAIL PROTECTED]> writes: : How would they return me the 'value' of 'ticks'? : : The problem is... I have a value's somewhere that has been assigned from : 'ticks', like: : ptr -> value = ticks; : : at an other moment I need to do something like... : : age = boottime + ( ticks - ptr -> value ) / factor; : : The problem in the second case however is that I can not seem to get to : 'ticks' as it is userland code... ptr->value should be set with getmicrotime() or microtime(). You can then do a gettimeofday in userland to figure out the age. I agree with you. Except that ptr->value is tcpcb->t_starttime which is being set in the kernel... For the rest, see my other email that I forgot (but now did) sent to the group. Thanks for the help though. Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'ticks' in kernel.
In message: <[EMAIL PROTECTED]> Jan Knepper <[EMAIL PROTECTED]> writes: : How would they return me the 'value' of 'ticks'? : : The problem is... I have a value's somewhere that has been assigned from : 'ticks', like: : ptr -> value = ticks; : : at an other moment I need to do something like... : : age = boottime + ( ticks - ptr -> value ) / factor; : : The problem in the second case however is that I can not seem to get to : 'ticks' as it is userland code... ptr->value should be set with getmicrotime() or microtime(). You can then do a gettimeofday in userland to figure out the age. MICROTIME(9) FreeBSD Kernel Developer's Manual MICROTIME(9) NAME microtime, getmicrotime, nanotime, getnanotime - get the current time SYNOPSIS #include void microtime(struct timeval *tv); void getmicrotime(struct timeval *tv); void nanotime(struct timespec *ts); void getnanotime(struct timespec *tsp); DESCRIPTION The microtime() and getmicrotime() functions store the system time as a struct timeval at the address specified by tv. The nanotime() and getnanotime() functions perform the same utility, but record the time as a struct timespec instead. Microtime() and nanotime() always query the timecounter to return the current time as precisely as possible. Whereas getmicrotime() and getnanotime() functions are abstractions which return a less precise, but faster to obtain, time. The intent of the getmicrotime() and getnanotime() functions is to enforce the user's preference for timer accuracy versus execution time. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: D_KQFILTER & ltmdm.
In message <[EMAIL PROTECTED]>, "Mike Edenfield
" writes:
>I'm working up a patch to the ltmdm to accomodate phk's recent changes to
>cdevsw. I've gotten the module to build and load, but I have two questions
>before I go ahead and submit a pr.
>
>1) I simply removed D_KQFILTER from the list of flags. Based on phk's
>commit message I assumed the flag was simply not needed, and that removing
>it would not break anything. Is this assumption correct? Thus far the
>module is working (it loaded w/out a panic anyway) but I haven't tested it
>very much.
correct. D_KQFILTER was added so that we wouldn't dereference the
d_kqfilter pointer in case it was not there (ie: if the driver was
binary and compiled before the d_kqfilter pointer was added to
cdevsw). It's hacks like this we avoid now.
>2) The patch, which I've included below, only works for -CURRENT with
>rev1.170 of conf.h. I wasn't sure how to get the preprocessor to
>differentiate between -CURRENT before and after this specific revision of a
>specific file. What is the correct way to do this? Or, alternatively,
>should the patch simply assume FreeBSD 5 is the latest -CURRENT and not
>worry about the imcompatibility w/ 5.0-RELEASE?
I have bumped __FreeBSD_version so you can test for this.
But your patch is wrong. Please format the initialization like
you see in all the other device drivers:
static struct cdevsw sio_cdevsw = {
.d_maj =MAJOR_AUTO,
.d_flags = D_TTY,
.d_open = sioopen
etc
etc
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
D_KQFILTER & ltmdm.
I'm working up a patch to the ltmdm to accomodate phk's recent changes to
cdevsw. I've gotten the module to build and load, but I have two questions
before I go ahead and submit a pr.
1) I simply removed D_KQFILTER from the list of flags. Based on phk's
commit message I assumed the flag was simply not needed, and that removing
it would not break anything. Is this assumption correct? Thus far the
module is working (it loaded w/out a panic anyway) but I haven't tested it
very much.
2) The patch, which I've included below, only works for -CURRENT with
rev1.170 of conf.h. I wasn't sure how to get the preprocessor to
differentiate between -CURRENT before and after this specific revision of a
specific file. What is the correct way to do this? Or, alternatively,
should the patch simply assume FreeBSD 5 is the latest -CURRENT and not
worry about the imcompatibility w/ 5.0-RELEASE?
Anyway, for those of you w/ ltmdm, the following patch, applied to
sys/dev/ltmdm/ltmdmsio.c in the port's work directory, should get the module
building and loading.
--Mike
--- work/sys/dev/ltmdm/ltmdmsio.c Tue Mar 4 17:23:10 2003
+++ ltmdmsio.c Tue Mar 4 17:18:01 2003
@@ -360,6 +360,9 @@
#endif
static struct cdevsw sio_cdevsw = {
+/* maj */ MAJOR_AUTO,
+/* flags */ D_TTY,
+/* name */ driver_name,
/* open */ sioopen,
/* close */ sioclose,
/* read */ sioread,
@@ -368,27 +371,8 @@
/* poll */ ttypoll,
/* mmap */ nommap,
/* strategy */ nostrategy,
-/* name */ driver_name,
-#ifdef MAJOR_AUTO
-/* maj */ MAJOR_AUTO,
-#else
-/* maj */ CDEV_MAJOR,
-#endif
/* dump */ nodump,
-/* psize */ nopsize,
-#if __FreeBSD_version < 43
-/* flags */ D_TTY,
-/* bmaj */ -1,
-#else
-#if __FreeBSD_version < 50
-/* flags */ D_TTY | D_KQFILTER,
-/* bmaj */ -1,
-/* kqfilter */ ttykqfilter,
-#else /* __FreeBSD_version >= 50 */
-/* flags */ D_TTY | D_KQFILTER,
-/* kqfilter */ ttykqfilter,
-#endif
-#endif
+/* kqfilter */ ttykqfilter
};
static u_int com_events; /* input chars + weighted output completions */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: 'ticks' in kernel.
On Tue, Mar 04, 2003 at 02:00:02PM -0500, Jan Knepper wrote: > How would they return me the 'value' of 'ticks'? > > The problem is... I have a value's somewhere that has been assigned from > 'ticks', like: > ptr -> value = ticks; Maybe it would help to explain what you are doing at a higher level? It seems odd that you need to do anything like this at all... David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lpc problem with LinkSys print servers
At 11:31 AM -0600 3/3/03, Peter Elsner wrote: This particular printer is a high load printer, printing about 50 to 70 pages at a time. Occasionally, the printer just stops while printing. We have to force a 'lpc restart lsjd1p2' command several times to get the printer to restart again. You will sometimes have better luck if you 'lpc abort' the queue, wait a few seconds, and then 'lpc start' it. Of course, that doesn't solve the actual problem... I believe that lpr/lpd is not resetting after receiving a Busy/Ready (or Nack/Ack) signal. Has anyone else seen this problem before? I have not heard of it. I'd like to see some actual proof of what is happening (like a tcpdump) before assuming that it's lpd's fault. Mind you, I'm quite willing to believe it's lpd's fault, but I can't very well look into the problem unless I know what sequence of packets is causing it. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'ticks' in kernel.
How would they return me the 'value' of 'ticks'? The problem is... I have a value's somewhere that has been assigned from 'ticks', like: ptr -> value = ticks; at an other moment I need to do something like... age = boottime + ( ticks - ptr -> value ) / factor; The problem in the second case however is that I can not seem to get to 'ticks' as it is userland code... Thanks! Jan M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Jan Knepper <[EMAIL PROTECTED]> writes: : No, I have looked that those, they do not work for me as I need to be : able to compate the value if 'ticks' with a value initialized from 'ticks'. : The problems is that 'ticks' is not 'exact'. So I cannot calculate it : with the different between the boot time and the current time * a : constant factor. why doesn't tsleep work for that? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'ticks' in kernel.
In message: <[EMAIL PROTECTED]> Jan Knepper <[EMAIL PROTECTED]> writes: : No, I have looked that those, they do not work for me as I need to be : able to compate the value if 'ticks' with a value initialized from 'ticks'. : The problems is that 'ticks' is not 'exact'. So I cannot calculate it : with the different between the boot time and the current time * a : constant factor. why doesn't tsleep work for that? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'ticks' in kernel.
No, I have looked that those, they do not work for me as I need to be able to compate the value if 'ticks' with a value initialized from 'ticks'. The problems is that 'ticks' is not 'exact'. So I cannot calculate it with the different between the boot time and the current time * a constant factor. Any ideas? Might patching (adding it to) sysctl be a thing to consider or would that cause security issue's? Thanks! Jan M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Jan Knepper <[EMAIL PROTECTED]> writes: : Any one have an idea how to pull the value for 'ticks' (kern_clock.c) : from the kernel? : I have looked into sysctl, but could not find "how to". : I am overlooking something? Why? You'll likely want to look at one of: getmicrouptime tsleep msleep getmicrotime Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'ticks' in kernel.
In message: <[EMAIL PROTECTED]> Jan Knepper <[EMAIL PROTECTED]> writes: : Any one have an idea how to pull the value for 'ticks' (kern_clock.c) : from the kernel? : I have looked into sysctl, but could not find "how to". : I am overlooking something? Why? You'll likely want to look at one of: getmicrouptime tsleep msleep getmicrotime Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/40611 linux compatibility fix
On Fri, Feb 28, 2003 at 04:47:42PM -0800, Brooks Davis wrote: > On Fri, Feb 28, 2003 at 11:47:42AM -0800, Luoqi Chen wrote: > > > Dear Hackers, > > > > > > Is there any chance that the patch given in kern/40611 could be > > > committed to the 4-STABLE tree? It has the desirable effect of making > > > eg. the linux-sun-jdk14 port usable as a non-root user. This would > > > appear to my untutored eye to be a sub-set of the differences already > > > existing between the HEAD and RELENG_4 versions of > > > src/sys/posix4/p1003_1b.c > > > > > I've a similar but more complete patch. It handles both get and set cases, > > and also takes into account jailed environment. It should have identical > > semantics to -current (except for the see_other_uids flag), at least at > > the time when I created the patch. You may inspect the patch at > > http://people.freebsd.org/~luoqi/p1003_1b.diff > > The following is also require for that one to compile. > > -- Brooks > > --- posix4.h27 Dec 1999 10:22:09 - 1.6 > +++ posix4.h1 Mar 2003 00:00:42 - > @@ -61,8 +61,6 @@ MALLOC_DECLARE(M_P31B); > #define p31b_malloc(SIZE) malloc((SIZE), M_P31B, M_WAITOK) > #define p31b_free(P) free((P), M_P31B) > > -int p31b_proc __P((struct proc *, pid_t, struct proc **)); > - > void p31b_setcfg __P((int, int)); > > #ifdef _KPOSIX_PRIORITY_SCHEDULING > Seeing as I had to recompile anyhow because of the sendmail fun'n'games, I decided to give Books' and Luoqi's patches a spin. Happy to say, everything works fine and I have the linux-sun-jdk14 port running happily as non-root both in a jail and under the host environment using 4.8-RC as of yesterday. Is it too late to get these patches into 4.8-RELEASE ? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
(no subject)
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
