or
>was the CAM switchover, so that I didn't have to do everything twice.
Yeah, and together with Terrys VFS patches that would have made Microsoft
bankrupt overnight.
Sure...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBS
In message <[EMAIL PROTECTED]>, Ju
lian Elischer writes:
>
>
>On Fri, 17 Aug 2001, Terry Lambert wrote:
>
>> Poul-Henning Kamp wrote:
>> > Julian Elischer writes:
>> >
>> > >Well you timed them out without askling the developer what he had
ev /dev_
mkdir /dev
chmod 755 /dev
reboot
...
rm -rf /dev_
--
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
(at least until better heuristics for default operation has
been devised.)
--
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 i
visible place and advertise them on
-current, -arch and -smp.
Once at least 5 developers have publically said "I'm running these
patches on my -current machine(s) and it doesn't totally hose me"
and at least 3 of those machines are SMP and one is non-i386
architecture, then ca
ple as the overall morphology
of the two drivers are the same.
--
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 Unsubsc
ff those boxes.
Without that last item I'm against, no matter what.
--
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 incomp
ng "almost cloning).
WARNING: Not tested!
Wed Aug 30 23:27:05 CEST 2000
---
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to
ci0
...
ad0: 17206MB [34960/16/63] at ata0-master UDMA66
ad1: 14664MB [29795/16/63] at ata1-master tagged UDMA66
If I enable it on ad0, without without enabling it on ad1 it chokes.
ad1 seems to be stable.
Is there any way to read the firmware rev on ATA disks ?
--
Poul-Henning Kamp | U
=1
Works with tagged queueing:
ad1: ATA-4 disk at ata1-master
ad1: 14664MB (30033360 sectors), 29795 cyls, 16 heads, 63 S/T, 512 B/S
ad1: 16 secs/int, 31 depth queue, tagged UDMA66
ad1: piomode=4 dmamode=2 udmamode=4 cblid=1
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
9846/16/63] at ata0-master using UDMA66
Mounting root from ufs:/dev/ad0s1a
ttt#
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by
In message <[EMAIL PROTECTED]>, John Baldwin writes:
>Poul-Henning Kamp wrote:
>>
>> If I boot this machine on a -current kernel, it doesn't find the
>> fxp#'s at all:
>
>Do you have Peter's latest commits to pci/pci.c pci/pcisupport.c and
>i3
"i8254" /* name */
};
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
o the base installation and perhaps even referenced by
>the conf file.
>
>
>What does everyone think?
Make it a port...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never att
TAILQs.
Various nitpicking here and there.
The patch to i386/include/atomic.h is taken from SMPng to which
I added atomic_cmpset_ptr().
--
With this patch DEVFS has the features and properties it should
have with respect to the "main mount".
--
Poul-Henning Kamp
ius /kernel: pcm0: hwptr went backwards 8208 -> 8192
>
>etc.
>
>Joe
>
>FreeBSD genius.systems.pavilion.net 5.0-CURRENT FreeBSD 5.0-CURRENT #11: Tue Sep 5
>12:45:45 BST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENIUS
>i386
>
>On Mon, Sep 04, 2000 at 06:41:14P
re negative numbers coming in from both the i8254 and in a
few cases from the TSC. NTIMECOUNTER may be too low for certain
systems, I'm still waiting for some feedback on that.
Either way, I have a patch which I need to burn in in my lab, but
right now I have a hard time getting my SMP box to
On -current trying to do
fdwrite < kern.flp
I get
panic: isa_dmastart: bad bounce buffer
Can anybody confirm/deny this is a general problem ?
The machine is a K7 with 512M RAM
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP si
sys/compile/GENERIC
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 231776789 Hz
...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attr
itimate need.
If anything I would propose we ditch it...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To
In message <[EMAIL PROTECTED]>, Ben Smithurs
t writes:
>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 w
My tough luck, huh?
./-
Very few programs understand the filename "-" unless it is special
cased to mean stdin/stdout
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to m
d thing about the new DEVFS: it
>appears to enshrine things like this in the kernel...
Yes, this is a bad thing, but it is the best compromise solution.
You can either manually or with a future general devd(8) fix this.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTEC
that nobody reported it (my
>problems appeeared when procmail changed perms of /dev/null :))
>
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3
motely logged in was fatal because a ^C (character, not signal)
>to kill the process couldn't be delivered.
I can confirm this one, ntpd has for a long time pointlessly raised
it's priority to the absolute maximum, and if during debugging it
went into a spin it would freeze the sys
if=/dev/random of=/dev/null bs=large" does
>several bad things.
Yes, we are royally hosed right now with respect to interrupt service.
It's a testimony to the robustness of the majority of our drivers that
they don't explode more often than they do.
--
Poul-Henning Kamp
vm/vm_glue.c
vm/vm_page.c
vm/vm_pager.c
vm/vm_swap.c
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3
file has.
Well,
According to src/tools/tools/kerninclude that include is not even
needed.
I'm not claiming that every single line is dogmatically true, but
at least it merits some amount of investigation...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/
file has.
Oh, forgot to say: it could also be indicative of options not
excercised by NOTES/LINT...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately
cannot test on alpha
and there are various bogosities which can give false positives
on this list.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be
ticular it doesn't during then 10-20 seconds we probe/attach
devices.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by in
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <94952.969433843@critter> Poul-Henning Kamp writes:
>: Oh, forgot to say: it could also be indicative of options not
>: excercised by NOTES/LINT...
>
>There are a few NEWCARD/OLDCARD issues that you catch h
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>I would like to have review especially on the changes in
>i386/isa/clock.c for counting delay loop numbers,
Could you explain the functionality you need here ? We already
have a DELAY() macro/function in the kernel...
--
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>From: Poul-Henning Kamp <[EMAIL PROTECTED]>
>Date: Wed, 27 Sep 2000 15:01:13 +0200
>> >I would like to have review especially on the changes in
>> >i386/isa/clock.c for counting delay loop nu
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>From: Poul-Henning Kamp <[EMAIL PROTECTED]>
>Date: Wed, 27 Sep 2000 15:13:27 +0200
>> >And we initialize the delaycount in clock.c.
>>
>> This is called "busy polling" and there
generic "devd" which finds out that devices have appeared,
set their perms (if needed/wanted) and executes any commands needed
(getty, mount, etc etc) by the device.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam membe
In message <[EMAIL PROTECTED]>, Alexander Langer write
s:
>Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
>
>> You guys are overlooking something about DEVFS: devices may appear
>> post-boot.
>
>Ah, yes.
>
>BTW: Devices don't disappear if you unloa
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <11056.970344237@critter> Poul-Henning Kamp writes:
>: We need a generic "devd" which finds out that devices have appeared,
>: set their perms (if needed/wanted) and executes any commands needed
&g
just pulls in and have
#include ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to
In message <[EMAIL PROTECTED]>, Jeremy Lea writes:
>> Is the correct thing not to mv to , create
>> a which just pulls in and have
>> #include ?
>
>This breaks several other ports (like BitchX).
I think this breaks all IRC's which are cloned from the sa
ttys:
cksum (2486739860, 2798556681)
bla:
extra
malloc.conf:
permissions (0755, 0777)
./objformat:
missing
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
size (was 1234, should be 5678)
> cksum (was 42424242, should be 69696969)
>
>...so that it's clear what the meaning of the numbers is.
In that case I think I would like to loose the ',' also.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
to be aware of devfs. Does anyone have any
>other (preferably cleaner) ways to fix this?
Yes, I'm working on a patch for all pseudo devices so that they
go away (entirely) when no longer used.
That's the problem with cloning devices: you need a way to get
rid of them again or you h
ns.
I don't change the md5-grammar, only the output when it verifies
a filesystem against a file (containing a spec in the usual grammar).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Ne
Are you sure your tree is entirely in sync ?
I can't reproduce your problem here with the NOTES/LINT kernel...
> Version 1.16 of src/sys/dev/syscons/scvesactl.c, removing
> broke the kernel build for me. Attached is the
>relevant log, and my kernel file.
--
Pou
In message <[EMAIL PROTECTED]>, Doug Barton writes:
>Poul-Henning Kamp wrote:
>>
>> Are you sure your tree is entirely in sync ?
>
> Yes... I've checked it several times.
>
>> I can't reproduce your problem here with the NOTES/LINT kernel..
log in
mv /dev/something /dev/other
# devname(3) gives wrong output
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be expla
http://phk.freebsd.dk/patch/DELAY.patch
Move DELAY() and sysbeep() from to
and remove unneeded #includes of
--
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
ea?
To reduce the number of cut&paste mistakes in .
I blive about 200 instances of #include are removed
by that patch.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attr
.c
--- net/ppp_deflate.c 1999/08/28 00:48:26 1.12
+++ net/ppp_deflate.c 2000/10/13 12:39:41
@@ -29,6 +29,7 @@
* OR MODIFICATIONS.
*/
+#include "opt_ppp.h"
#include
#include
#include
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] |
me etc etc.
Submit changes to the maintainer of the file (if any) or
with send-pr.
Junior committers are encouraged to review and commit these
PR's as they arrive
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since
>Who knows about the ATM stuff in the kernel?
We have two ATM stacks:
* The minimalist "chuck" stack.
* The full-blown HARP stack.
Neither support netgraph.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RF
In message <[EMAIL PROTECTED]
lting.com>, "Brian Smith" writes:
>On Sun, 22 Oct 2000 03:16:38 +0200, Poul-Henning Kamp wrote:
>
>>
>>>Who knows about the ATM stuff in the kernel?
>>
>>We have two ATM stacks:
>> * The minimalist "chu
people will review this patch and verify that
LINT & GENERIC kernels compile the same, we're set for commit...
--
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 mal
/netinet6/icmp6.c
Index: sys/netinet6/in6_gif.c
Index: sys/netinet6/in6_proto.c
Index: sys/netinet6/raw_ip6.c
Index: sys/netkey/key.c
Index: sys/pc98/i386/machdep.c
Index: sys/sys/queue.h
Index: sys/sys/types.h
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP
iles are flagged by
>"/* for offsetof */".
Right, in fact there are many such, and they should be cleaned up
as well, but right now I want to keep this patch at a manageable
impact.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP sin
../../i386/isa/rc.c:187: syntax error before `rcpoll'
../../i386/isa/rc.c:187: warning: type defaults to `int' in declaration of `rcpoll'
[...]
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD sinc
ing a very
>long time to scp the snap to internat.
Try disabling newreno in both ends:
sysctl -w net.inet.tcp.newreno=0
On my laptop with Wavelan cards this increases TCP throughput by a
factor of 5.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
UGE difference. I only did it on the current box.
>Internat is still running 4.x and don't have it. I think it made more
>than a factor of 5 difference here. :-)
I sent packet traces to yan some time back, but have not heard from him
since. I wonder if we should disable newrene for now.
during device-probe/attach as possible.
I don't really care that much how good my random bits are right after
boot, but I do care about my machine coming up quickly.
Add a /etc/rc.conf knob which says
wait_until_entropy_collected=YES
which people who care a lot about randomness
In message <[EMAIL PROTECTED]
om>, Wesley Morgan writes:
>On Thu, 26 Oct 2000, Poul-Henning Kamp wrote:
>
>> I don't really care that much how good my random bits are right after
>> boot, but I do care about my machine coming up quickly.
>
>I don't know ab
if
>> # if __FreeBSD__ < 3
>> # include
>>
>>
>> --
>> "The dead cannot be seduced."
>> - Kai, "Lexx"
>>
>> Do YOU Yahoo!?
>>
>>
>>
>>
>
>
>
>To Unsubscri
the kernel doesn't link -
>they need the include also.
You are confusing my changes with the current acpi related breakage.
strip these lines out of NOTES:
device acpi
optionsACPI_DEBUG
optionsAML_DEBUG
And the LINT kernel links just fine.
-
piles fine.
Can you send me your kernel config file ? LINT compiles here and it
includes all of our ATM code as far as I know, there must be some
option which makes this interract strangely...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
Fre
p->dev & 0xFF);
>+ if (vfinddev(dev, VCHR, &vp)) {
>if (vp->v_mount == NULL)
>return (EINVAL);
>stat = &(vp->v_mount->mnt_stat);
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROT
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes:
>Poul-Henning Kamp wrote:
>>
>> I was just looking at that piece of code, and I couldn't entirely
>> make out what it was even trying to do. Can somebody more
>> linuxolator savy explain what the fu
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes:
>Poul-Henning Kamp wrote:
>>
>> >In short: given the (u)dev_t, get the FS statistics and return the
>> >number of free blocks and inodes of the FS on that device.
>>
>> But the udev
bogus though...
>
>Yes. A more dynamic solution needs to be used that creates mappings (and
>dev_t values) on the fly.
I guess you're right, but the thought makes me want to barf...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC
I lied! Actually `ls /compat/linux/dev' panics at: vfinddev()
><-- addaliasu() <-- ufs_vinit(). Seems I was 100% confused looking
>alternatively at source and ddb console.
Yes, this is my bad. I'm looking at it right now.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
abled.
Anybody interested in studying the problem can find two packet
captures at:
http://phk.freebsd.dk/newreno
--
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 wha
rmed linux ls didn't cause panic, so the culprit should belong
>somewhere else. Hopefully phk will catch it for us. :)
I hope I just did. Please report back if this has or hasn't solve
the problem.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/
<= NODEV
Just fixed in current (I hope)
--
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 Uns
server 212.242.40.181 offset -4.163177 sec
Nov 13 23:52:00 [...] step time server 212.242.40.181 offset -7.449300 sec
This is on a laptop with APM enabled btw.
You should be able to force the use of the i8254 timecounter by
sysctl -w kern.timecounter.hardware=i8254
--
Poul-Henning Kamp
.
yes.
sigpvc.
Not that I know off.
PS: anyone looking to buy a bunch of these please contact me, I may know
of a source for some cheap cards if bought in (minor) quantities.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD commit
I have two reports about machines with 384MB RAM panicing when
the floppies are accessed. I don't have the message right now
except for a report that "it said something about bouncebuffers"
Can somebody with 384MB ram check if the floppy works under
current ?
--
Poul-Henning Ka
tion has exhibited apparently arbitrary lock-ups since the advent
>: of SMPng.
>
>You can also short IOCHK to ground to get an NMI which kicks you into
>the debugger, even in an interrupt context.
Bad news for you warner: On a too large sample of my newer
motherboards this doesn
f the malloc failed. I presume
>this is the opposit of the intended sense. I'll fix it up if you also
>think it looks wrong.
If nobody have noticed in "17 months, 2 weeks ago" (as cvs-web says)
that labpc doesn't work, the labpc driver should be killed, not fixed.
Ob
aying:
"If nobody have noticed in "17 months, 2 weeks ago" (as cvs-web says)
that labpc doesn't work, the labpc driver should be killed, not fixed."
That's 1.5 year Julian, and if nobody *who is using it* objects it goes.
--
Poul-Henning Kamp | UNIX si
if (consbuffer[i] == '\n') {
+ nlf = 0;
+ logwakeup();
+ }
+ }
+ }
+ }
+ if (nlf)
+ msglogchar(
In message <[EMAIL PROTECTED]>, Dan Nelson writes:
>In the last episode (Nov 22), Poul-Henning Kamp said:
>> The attached patch is a "proof-of-concept" on which I would like to
>> get some comments:
>>
>> It bugs me big time that the output from /etc/rc
: chn_init() for (play:2) failed
pcm0: offset 0xfefb5000 exceeds limit. pcm0: chn_init() for (play:3) failed
--
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
already been
>revoke()d, so they no longer have access to the real console.
I don't know what you consider "the real console", but opening
"/dev/console" and barfing on it works all the time. (Well,
*almost* all the time, not if you have foobar'ed your serial
consol
console code to be more sanely (or even just at
all) layered that is a "Sigh.. wouldn't it be nice if..." kind of
item.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Ne
AJ
>CWlmIChkZXZfc3RkY2xvbmUobmFtZSwgTlVMTCwgZGV2aWNlX25hbWUsICZ1
>bml0KSAhPSAxKQorIAkJCXJldHVybjsKKyAKKyAJCW1pbm9yID0gKHVuaXQg
>fCAgVk1ORVRfREVWX01BU0spOworIAl9CisgCWVsc2UKKyAJCW1pbm9yID0g
>dW5pdDsKKyAKKyAJKmRldiA9IG1ha2VfZGV2KCZ0YXBfY2RldnN3LCBtaW5v
>ciwgVUlEX1JPT1QsIEdJRF9XSEVFTCwgMDYwMCwgIiVzJWQiLAorIAkJCWRl
>dmljZV9u
).
|
| Obtained from:msmith
|
| Revision ChangesPath
| 1.21 +1 -11 src/sys/pci/ohci_pci.c
| 1.32 +1 -11 src/sys/pci/uhci_pci.c
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
whatever initialisation the driver is currently missing out on.
Right, that is what I did once I realized that this particular commit
was the culprit.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-taho
-
malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg
../../dev/ichsmb/ichsmb_pci.c
In file included from ../../dev/ichsmb/ichsmb_pci.c:63:
../../dev/ichsmb/ichsmb_var.h:67: field `mutex' has incomplete type
*** Error code 1
--
Poul-Henning Kamp | UNIX since Zilog Zeus
really an excellent diagram. That should be in an FAQ
>somewhere. Doc committers?
Except it is not actually correct. The BSD disklabel is usually
inside the 'a' partition and certainly inside the 'c'
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
f -u -r1.130 systm.h
--- sys/systm.h 2000/12/06 07:09:08 1.130
+++ sys/systm.h 2000/12/17 10:37:24
@@ -107,7 +107,7 @@
intkvprintf __P((char const *, void (*)(int, void*), void *, int,
_BSD_VA_LIST_)) __printflike(1, 0);
void log __P((int, const char *, ...)) __printflike(2, 3);
ourse one could add timeouts and what's not, but then imagine
the case of two programs writing on /dev/console at the same time...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never a
In message <[EMAIL PROTECTED]>, John Baldwin writes:
>
>On 17-Dec-00 Poul-Henning Kamp wrote:
>>
>> This patch is for the printf(9), log(9) & /dev/console stuff.
>> The result is that you can watch the output from /etc/rc in
>> your /var/log/messages.
&
9).
I played with this, and I was not happy with the result, if somebody
else can do it better, I'm open for patches...
--
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
ams writing on /dev/console at the same time...
>
> *nod* I wasn't sure that the buffering was the best suggestion, which
>is why I preferred making the messages from /etc/rc* more meaningful. :)
Just for the record: There is no support for green "OK" messages in
my patch :-)
-
In message <[EMAIL PROTECTED]>, Tomasz Paszkowski writes:
>
> How to open && read file from kernel space. I have seen VOP_[READ,OPEN]
> but i think there's something easiest ?
VOP_* is the way to go.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
In message <[EMAIL PROTECTED]>, Tomasz Paszkowski writes:
>On Wed, Dec 20, 2000 at 10:52:05PM +0100, Poul-Henning Kamp wrote:
>> > How to open && read file from kernel space. I have seen VOP_[READ,OPEN]
>> > but i think there's something easiest ?
>&g
I have added a couple of tasks over at
http://phantom.cris.net/freebsd/projects/projects.php
which are good candidates for people looking for a good and simple
task to do for FreeBSD.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC
In message <[EMAIL PROTECTED]>, "Dan Langille" writes:
>On 28 Dec 2000, at 9:36, Poul-Henning Kamp wrote:
>
>> which are good candidates for people looking for a good and simple
>> task to do for FreeBSD.
>
>How do we know which are the "good and sim
0,d2f5df48) at spec_vnoperate+0x15
bawrite(cbb336b0,0,cbb336b0) at bawrite+0x32
spec_fsync(d2f5df7c,d2f5df9c,c01857be,d2f5df7c,0) at spec_fsync+0x141
spec_vnoperate(d2f5df7c) at spec_vnoperate+0x15
sched_sync(0) at sched_sync+0x13e
fork_trampoline() at fork_trampoline+0x15
db>
--
Poul-Henning Kamp
#x27;
>restart code and looping on the same buffer... which can happen if
>the bawrite() is being turned into a bdwrite(). It looks like
>spec_fsync() is in an infinite loop.
There is no other signs of trouble, processes hang when they attempt
some (but maybe not all) kind o
I am totally unable to complete a
cd /usr/src
cvs -q update -P -d -A
on any of my two -current systems.
The systems stalls as described in my email yesterday.
CCD is now out of the equation.
-
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
601 - 700 of 1791 matches
Mail list logo
