If I use the buildkernel target I get the following:
make: cannot open
/usr/amd/realmounts/slave/usr/current/src/sys/dev/aic7xxx/Makefile.
*** Error code 2
Stop in /usr/amd/realmounts/slave/usr/current/src.
*** Error code 1
If I use the old way, I get errors about a pointer wit
I think this thread needs to be killed. Whipping a horse that was dead 3
days ago is way too much. People have expressed thier opposition to PHK's
post and so it should end there.
For the love of cgi scripts, please keep /dev/stdin && out so that peoples
web work can be sent to && from the mass
On Sun, Sep 17, 2000 at 20:36 +0200, Peter van Dijk wrote:
> On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
> >
> >
> > [ ... how to find separating chars not used in filenames ... ]
> >
> > e.g.
> > superduperopen("file1&file2", "a+", SDO_TEEFILES)
> > superduperopen("file1&fi
On 17 Sep 2000, Jason Evans wrote:
> On Fri, Sep 15, 2000 at 03:40:12PM +0100, Konstantin Chuguev wrote:
> > Udo Schweigert wrote:
> >
> > > after a fresh build of -current openssh does not work if connecting to the
> > > root-user. For example (tested from a -stable machine, but the same from
>
On Fri, Sep 15, 2000 at 03:40:12PM +0100, Konstantin Chuguev wrote:
> Udo Schweigert wrote:
>
> > after a fresh build of -current openssh does not work if connecting to the
> > root-user. For example (tested from a -stable machine, but the same from
> > 4.1-RELEASE):
>
> Yes, I've been seeing th
Greg Lehey wrote:
> On Monday, 18 September 2000 at 1:29:34 +0200, Michael Reifenberger wrote:
> > On Mon, 18 Sep 2000, Greg Lehey wrote:
> > ...
> >> Oops, that's what comes of typing hurriedly early in the morning.
> >>
> >> p ((struct proc *)gd_curproc)->p_comm
> >> p ((struct proc *)gd_cu
On Monday, 18 September 2000 at 1:29:34 +0200, Michael Reifenberger wrote:
> On Mon, 18 Sep 2000, Greg Lehey wrote:
> ...
>> Oops, that's what comes of typing hurriedly early in the morning.
>>
>> p ((struct proc *)gd_curproc)->p_comm
>> p ((struct proc *)gd_curproc)->p_pid
> Works better:
>
On Mon, 18 Sep 2000, Greg Lehey wrote:
...
> Oops, that's what comes of typing hurriedly early in the morning.
>
> p ((struct proc *)gd_curproc)->p_comm
> p ((struct proc *)gd_curproc)->p_pid
Works better:
(kgdb) p ((struct proc *)gd_curproc)->p_comm
$6 = "irq1: atkbd0\000\000\000\000"
(kgdb)
On Monday, 18 September 2000 at 1:23:30 +0200, Michael Reifenberger wrote:
> On Mon, 18 Sep 2000, Greg Lehey wrote:
> ...
>> You could also show the content of p->p_pid. If you don't have a p
>> pointer in the frame you're looking at, use ((struct
>> *proc)gd_curproc)->p_pid and ((struct *proc)g
On Mon, 18 Sep 2000, Greg Lehey wrote:
...
> You could also show the content of p->p_pid. If you don't have a p
> pointer in the frame you're looking at, use ((struct
> *proc)gd_curproc)->p_pid and ((struct *proc)gd_curproc)->p_comm. We
> need to know what is hanging.
Sorry doesn't seem to work:
On Sun, 17 Sep 2000, Steve Kargl wrote:
> hotrats:root[211] setenv KERNEL HOTRATS
> hotrats:root[212] make buildkernel
>
> --
> >>> Rebuilding kernel(s)
> --
> ===> HOTRATS
> m
On Sunday, 17 September 2000 at 16:29:41 +0200, Michael Reifenberger wrote:
> Hi,
> ...
>> The frames above are what the system went to as the result of your
>> debugger request. I'd also be interested to see the output of the
>> 'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and
hotrats:root[211] setenv KERNEL HOTRATS
hotrats:root[212] make buildkernel
--
>>> Rebuilding kernel(s)
--
===> HOTRATS
mkdir -p /usr/obj/usr/src/sys
cd /usr/src/sys/i386/conf;
On Thu, 14 Sep 2000, Ben Smithurst wrote:
> Poul-Henning Kamp wrote:
>
> > I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
> > is bogus. It looks like something which happened "because we can" more
> > than something which has a legitimate need.
>
> You think adding
In article <[EMAIL PROTECTED]>,
Alexander Leidinger <[EMAIL PROTECTED]> wrote:
>
> Index: authfd.c
> ===
> RCS file: /big/FreeBSD-CVS/src/crypto/openssh/authfd.c,v
> retrieving revision 1.6
> diff -u -r1.6 authfd.c
> --- authfd.c 2
On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
>
>
> How much sense does it make to think about implementing tee and
> select methods this way? Like "open file1 and file2 and write to
> both of them whatever I give to you" and "give me data coming in
> from whatever file is in
I've seen these patches many times and think that it is a good idea.
This interface needs to be exported so that the pccard system sounds
don't interfere with normal systme sounds.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the messa
In message <[EMAIL PROTECTED]> Mike Meyer writes:
: Is needing to have a new loader installed to boot worth a mention in
: UPDATING?
Nah. People should be forced to puzzle it out for themselves ;-)
Warner
P.S. An entry will be committed shortly.
To Unsubscribe: send mail to [EMAIL PROTECTED
On Sun, Sep 17, 2000 at 05:31:45AM -0700, David Greenman wrote:
> >in summary: PR kern/18756 contains a patch (against -stable, alas,
> >sorry) which fixes kernel hangs in the fxp driver on some laptops
> >after a resume from suspend. while quite a few people appear to be
> >using this patch succ
/alpha/clock.c?
MAIN POINT:
static void sysbeepstop --> void sysbeepstop.
Full PC-Card melody patch is in below URL.
http://people.FreeBSD.org/~sanpei/5-current/sys-pccard-pccard_beep_melody-2917.diff
---
MIHIRA, Sanpei Yoshiro
Yokohama, Japan.
--- sys/i386/isa/clock.c.orgTue May
$B$3$N>pJs$,ITI,MW$JJ}$O:o=|$J$5$C$F2<$5$$!#(B
$B$^$?!"K|$,0l=w@-$NJ}$KFO$$$?>l9g$b?=$7$o$1$"$j$^$;$s$,:o=|$J$5$C$F2<$5$$!#(B
==
$B(BDi$B$M$C$H$O!%!%!%(B
$B!!I^7,R2p$5$l$^$7$
On 18 Sep, Bruce Evans wrote:
> dnetc presumably blocks occasionally, giving other processes a chance to
> run.
I've started dnetc without idprio (with build in "nice"), it also
displays 100% system.
And with a closer look (stopped dnetc): 0% user, 0% nice... ?
---snip---
last pid: 36437; load
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Garrett Wollman writes:
> : < said:
> : > Hmmm, they look good to me. Maybe Mark's system doesn't have group
> : > operator at gid 5. That's one bad thing about the new DEVFS: it
> : > appears to enshrine things like this in the kernel...
>
Hi,
if the order of the ps macro is correct, here the backtraces of the procs 35,36,37:
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRE
On Sun, 17 Sep 2000, Alexander Leidinger wrote:
> On 18 Sep, Bruce Evans wrote:
>
> >> >> dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
> >> >> a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
> >> >> 1.4), complete build{world,kernel}.
> >> >>
>
On 18 Sep, Bruce Evans wrote:
>> >> dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
>> >> a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
>> >> 1.4), complete build{world,kernel}.
>> >>
>> >> ---snip---
>> >> last pid: 1666; load averages: 1.10,
Jordan Hubbard wrote:
> > in summary: PR kern/18756 contains a patch (against -stable, alas,
> This PR has been explicitly assigned to David Greenman and should be
> handled by him. As I pointed out in another message, nobody but he is
> likely to touch the fxp driver under any circumstances so i
> "SK" == Steve Kargl <[EMAIL PROTECTED]> writes:
SK> I get the following with sources cvsup'd for cvsup5.freebsd.org
SK> at 10:00 pm PST on 16 Sep 00.
SK> make: cannot open /usr/src/sys/dev/aic7xxx/Makefile.
Yes, me too. It seems that the file have removed after last commit on
In message <[EMAIL PROTECTED]>, Bruce Ev
ans writes:
>> > Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
>> > other user processes from running like a system process might do:
>> >
>> >idprio 31 sh -c "while :; do :; done"
>> >
>> > System processes actually h
On Sun, 17 Sep 2000, Alexander Leidinger wrote:
> On 17 Sep, Bruce Evans wrote:
>
> >> dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
> >> a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
> >> 1.4), complete build{world,kernel}.
> >>
> >> ---snip-
On Sun, Sep 17, 2000 at 06:15:45AM -0700, David Greenman wrote:
>I've made a few changes to the patches which should address my primary
> concerns. Instead of using IFF_RUNNING, I added a new softc variable to
> track the suspended condition. Only the APM stuff should call suspend/resume,
> so
Hi,
...
> The frames above are what the system went to as the result of your
> debugger request. I'd also be interested to see the output of the
> 'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and
> 'ps' (the macro I promised above).
(kgdb) icnt
1215544*566*0 0*
I've made a few changes to the patches which should address my primary
concerns. Instead of using IFF_RUNNING, I added a new softc variable to
track the suspended condition. Only the APM stuff should call suspend/resume,
so the interrupt logic should be uneffected in non-APM machines. Please tr
>appended below is an excerpt from a message sent to -stable earlier
>tonight, containing content of a type which kris kenneway correctly
>suggested would find a more suitable audience on -current.
>
>in summary: PR kern/18756 contains a patch (against -stable, alas,
>sorry) which fixes kernel han
On 17 Sep, Bruce Evans wrote:
>> dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
>> a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
>> 1.4), complete build{world,kernel}.
>>
>> ---snip---
>> last pid: 1666; load averages: 1.10, 1.11, 1.03u
> in summary: PR kern/18756 contains a patch (against -stable, alas,
This PR has been explicitly assigned to David Greenman and should be
handled by him. As I pointed out in another message, nobody but he is
likely to touch the fxp driver under any circumstances so it basically
comes down to eit
On 16 Sep, To: [EMAIL PROTECTED] wrote:
> But I think I found some other bugs, please have a look at the attached
> diff.
Oops, sorry, wrong diff.
Bye,
Alexander.
--
To boldly go where I surely don't belong.
http://www.Leidinger.net Alexander @ Leidinger.n
On 16 Sep, John Baldwin wrote:
> None of the CPU states from vmmeter are close to accurate on UP x86
> systems at the moment because statclock() doesn't have a valid stack
> frame to work with. SMP is slightly more accurate as we get all the
> stats on the other CPU's correct. This is on the to
38 matches
Mail list logo
