On Sun, 26 Mar 2000, Andrzej Bialecki wrote:
On Sun, 26 Mar 2000, Doug Rabson wrote:
On Sun, 26 Mar 2000, Andrzej Bialecki wrote:
Well, somehow the idea of overlapping subtrees sounds nice and useful
IMHO. Any suggestions how to solve these issues?
One possible way to do it
:
: In message [EMAIL PROTECTED] Mike Smith writes:
: : What about it in particular? Or are you referring to overflow handling?
:
: Yes. Well, I guess I assumed it was a circular thing, and you'd need
: to have some comparison against read index, which would be racible.
:
:Not if you think
SMP FIFO (one writer, one reader):
#define SIZE256
#define MASK(SIZE-1)
int ri;
int wi;
int fifo[SIZE];
int
fifo_read(void)
{
int r = -1;
if (ri != wi) {
int nri;
Having heard some vaguely encouraging things from the Linux world,
though, I'm considering swapping it for an Orb 2.2GB drive. Any
idea whether they're mass storage class or something proprietary?
In 2.3.99-pre2 [mumbles something about bloody lack of source
control on those source] there is
I took another look at this problem, and before I go forward with more
testing I wanted to solicit some comments. The problem is that users who
don't read blindly copy /etc/defaults/rc.conf into /etc. Because of the
recursive call at the end of /etc/defaults/rc.conf when you copy the
file
On Mon, Mar 27, 2000, Doug Barton wrote:
One solution that was experimented with a while back, and referenced
again in PR 17595 was to put a checkpoint variable in
/etc/defaults/rc.conf which would prevent it from being recursively
sourced. There are two problems with this strategy.
Hi Warner,
I notice you often copy back to the list your "see UPDATING" replies to
"current breakage" questions.
I'd like to propose that everyone confine such answers to private mail.
There are two advantages to doing it that way:
1) Folks who _do_ read UPDATING aren't further inconvenienced
Hi.
I made a patch for /sys/boot/i386/libi386/biosdisk.c (attached).
This aimed to enable /boot/loader to manage 8G-OVER-Disks.
0. you need 8G-OVER-ENABLED BIOS for your motherboard
(check whether your BIOS has Int 13 Extended Interface)
1. teach boot0 using extended BIOS (See boot0cfg(8))
It seems Jeroen Ruigrok van der Werven wrote:
the DDB trick works. And it dumps at PIO mode 4, woot!
You have to, there is no garantie that DMA and even less interrupts
is working proberly on a potentially hosed machine..
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On Sun, 26 Mar 2000, Matthew Dillon wrote:
: with supervisor execution, and allow interrupt execution concurrent
: with other interrupts. For example, two different ethernet interrupts
: could be taken concurrently with only minor spinlock controls
: on the IF queue, and
-On [2327 14:40], Soren Schmidt ([EMAIL PROTECTED]) wrote:
It seems Jeroen Ruigrok van der Werven wrote:
the DDB trick works. And it dumps at PIO mode 4, woot!
You have to, there is no garantie that DMA and even less interrupts
is working proberly on a potentially hosed machine..
I
With the current sources.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
=== sys/modules/linprocfs
@ - /src/src/sys
machine - /src/src/sys/i386/include
rm -f .depend
mkdep -f .depend -a -nostdinc -DLINPROCFS -D_KERNEL -DKLD_MODULE -I- -I. -I@
-I@/../include -I/usr/obj/src/src/i386/usr/include
/src/src/sys/modules/linprocfs/../../miscfs/linprocfs/linprocfs_misc.c
Dear Sir/Madam,
I have download 4.0 but cannot install :
Error "can not parse sbase .. then
reboot.
Is there a problem on the iso format file in your ftp site ?
Please give me information.
Thanks,
Regards,
Leo Hon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
On Sun, Mar 26, 2000 at 11:24:50PM -0700, Warner Losh wrote:
In message [EMAIL PROTECTED] Matthew Dillon writes:
: complex. For example, using fixed-length FIFOs rather then linked lists.
: The writer manipulates the write index variable, the reader manipulates
: the read index
On 27-Mar-00 Motomichi Matsuzaki wrote:
Hi.
I made a patch for /sys/boot/i386/libi386/biosdisk.c (attached).
This aimed to enable /boot/loader to manage 8G-OVER-Disks.
0. you need 8G-OVER-ENABLED BIOS for your motherboard
(check whether your BIOS has Int 13 Extended Interface)
Resup. My fault, was corrected within 10 minutes. You must have been
unlucky.
Nick
On Mon, 27 Mar 2000, Samuel Tardieu wrote:
With the current sources.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
[EMAIL PROTECTED]
What is going on with that server? It seems to be denying requests more
than accepting them these days.
[9:08am] 5 [~/FreeBSD]:cascade% ncftp3 current.freebsd.org
NcFTP 3.0.0 (March 20, 2000) by Mike Gleason ([EMAIL PROTECTED]).
Copyright (c) 1992-1999 by Mike Gleason.
All rights reserved.
At 7:33 PM -0800 2000/3/25, Doug Barton wrote:
'fsck -y /dev/da0s1a'
I had tried that already, but I'll do it again and let you see
what happens:
$ fsck -y /dev/da0s1a
Can't open /dev/da0s1a: Invalid argument
--
These are my opinions -- not
in a 4.0 kernel, teh block device doesn't exist, you always use the
character device,
so it was renamed so that /dev/da0s1a is teh name for the char device
but if you are using a device on a 3.4 disk it refers toi the block device
(which isn't in a 4.0 kernel)
On Mon, 27 Mar 2000, Brad Knowles
At 9:13 AM -0800 2000/3/27, Julian Elischer wrote:
in a 4.0 kernel, teh block device doesn't exist, you always use the
character device,
so it was renamed so that /dev/da0s1a is teh name for the char device
but if you are using a device on a 3.4 disk it refers toi the block device
: *not* preempted except when being interrupted, so there are no
: 'priorities', per say. Or, rather, the relative priority is strictly
: that the interrupt takes priority over supervisor code except when
: disabled by said supervisor code.
:
:But locks with owners wouldn't have
: *not* preempted except when being interrupted, so there are no
: 'priorities', per say. Or, rather, the relative priority is strictly
: that the interrupt takes priority over supervisor code except when
: disabled by said supervisor code.
:
:But locks with owners wouldn't
:
: : *not* preempted except when being interrupted, so there are no
: : 'priorities', per say. Or, rather, the relative priority is strictly
: : that the interrupt takes priority over supervisor code except when
: : disabled by said supervisor code.
: :
: :But locks with owners
: : *not* preempted except when being interrupted, so there are no
: : 'priorities', per say. Or, rather, the relative priority is strictly
: : that the interrupt takes priority over supervisor code except when
: : disabled by said supervisor code.
: :
: :But locks with
In message [EMAIL PROTECTED] Sheldon Hearn writes:
: I'd like to propose that everyone confine such answers to private mail.
No. I'm going to continue to do it publicly.
: 1) Folks who _do_ read UPDATING aren't further inconvenienced by
:multiple "see UPDATING" replies.
'd' works well
On Mon, 27 Mar 2000, Matthew Dillon wrote:
:
: : *not* preempted except when being interrupted, so there are no
: : 'priorities', per say. Or, rather, the relative priority is strictly
: : that the interrupt takes priority over supervisor code except when
: : disabled by
At 9:53 AM -0800 2000/3/27, Matthew Dillon wrote:
So, frankly, it is perfectly acceptable. I can't think of a single
real-life setup that would sufffer.
What about things like Adaptec 3940U2W controllers that have two
SCSI interfaces, and by default I believe will want
In message [EMAIL PROTECTED] Nate Williams writes:
: Too bad is not acceptable. If we want to support multi-function
: PCMCIA/CardBus cards, we *must* do shared interrupts, and multi-function
: cards are becoming the standard, rather than the exception.
Too bad is acceptible in this context.
In message [EMAIL PROTECTED] Nate Williams writes:
: Huh? CardBus cards are *not* slow. PCMCIA cards are, but CardBus is
: pretty dang fast.
The consequence of Matt's position is that cardbus cards won't be able
to be in their interrupt handlers at the same time. This will have a
small
:And would there still be areas of the kernel that disable multiple
:interrupts, perhaps CAM or the network stack for instance? What do
:all the splbio and splnet calls translate into in this new scheme?
:
:--
:Dan Eischen
The entire design of the kernel is currently predicated on the
:And would there still be areas of the kernel that disable multiple
:interrupts, perhaps CAM or the network stack for instance? What do
:all the splbio and splnet calls translate into in this new scheme?
:
The entire design of the kernel is currently predicated on the spl*()
* From: "R. Imura" [EMAIL PROTECTED]
* kdm determines X path as 'test -f $PATH/bin/X', so touching X is enough.
*^^^ $PATH/X
Well, I don't want to add a dysfunctional file in the tarball (what if
some port does a "test -x X"?) so I just added X
Hi,
I just moved my laptop (Thinkpad 600E) from 3.2-5.0-CURRENT.
Everything is great *except* the ethernet link is not working
correctly. If I set the interrupt to `?' (as in pccard.conf.sample)
or 10 (as worked under 3.2) the probe fails "no int?!". If I
set it to 11, then the probe works,
Matthew Dillon wrote:
:Is there any good reason why we have two different options if they can
:only be used together?
:
:Greg
I think it's so you can compile a kernel with INVARIANT_SUPPORT in
in order to support dynamic load modules which may have been compiled
with
:
:There's a paper that describes how Solaris transitioned from spl()s
:to mutexes. ISTR they created one mutex for each splxxx. I'll have
:to find this and re-read it.
:
:--
:Dan Eischen
I think we're using a slightly different mechanism... our spl*()'s
are actually interrupt bit
On Mon, 27 Mar 2000 11:22:42 MST, Warner Losh wrote:
It also tends to self regulate the UPDATING usage. As usage falls,
more messages are likely to appear on the list, to which the see
updating replies happen, which causes usage to rise again.
Two good arguments. Idea sumamrily
* Matthew Dillon [EMAIL PROTECTED] [000327 12:36] wrote:
:
:There's a paper that describes how Solaris transitioned from spl()s
:to mutexes. ISTR they created one mutex for each splxxx. I'll have
:to find this and re-read it.
:
:--
:Dan Eischen
I think we're using a slightly
: The word 'too bad' comes to mind re: shared interrupts.
:
:Too bad is not acceptable. If we want to support multi-function
:PCMCIA/CardBus cards, we *must* do shared interrupts, and multi-function
:cards are becoming the standard, rather than the exception.
First, each
Any idea?
-
INET6 -I/usr/obj/usr/src/i386/usr/include -c policy_token.c -o
policy_token.So
cc -fpic -DPIC -O -pipe -I/usr/obj/usr/src/lib/libipsec -DIPSEC_DEBUG
-DIPSEC -D
INET6 -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/lib/libipsec/ipsec_dump_po
licy.c -o
The 3940U2W has two pci devices. One for each scsi interface.
Each interface uses a separate pci interrupt.
One uses INTA the other probably uses INTB and which irq
they uses depends on your motherboard.
In message v04220817b50557761ed5@[195.238.1.121], Brad Knowles writes:
At 9:53 AM -0800
In message [EMAIL PROTECTED] Kent Hauser writes:
: I just moved my laptop (Thinkpad 600E) from 3.2-5.0-CURRENT.
: Everything is great *except* the ethernet link is not working
: correctly. If I set the interrupt to `?' (as in pccard.conf.sample)
: or 10 (as worked under 3.2) the probe fails "no
:I think you're thinking this:
:
: /-int 1
:spl int 2
: \-int 3
:
:spl messing with several mutexes, instead consider:
:
:int 1 ---\
:int 2 -- splmutex
:int 3 ---/
Problem #1: Different spl levels use different combinations of interrupts.
Some interrupts
Any idea?
-
INET6 -I/usr/obj/usr/src/i386/usr/include -c policy_token.c -o
policy_token.So
cc -fpic -DPIC -O -pipe -I/usr/obj/usr/src/lib/libipsec -DIPSEC_DEBUG
-DIPSEC -D
INET6 -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/lib/libipsec/ipsec_dump_po
licy.c -o
The SMP patch (#7) will be going into -current tonight with Jordan's
approval. After I make minor corrections to the patch (which is actually
based off of 4.x).
I'm pretty comfortable with it in -current and think in a week or two
we can MFC it into 4.x, which will allow
How can I test this with FreeBSD which is installed over-8GB area and
can't boot?
I have a PC on which Solaris7 is installed within 8GB from the start
of disk and FreeBSD 3.3-RELEASE is installed after(?) it.
The installation was successfull. But I can't boot it.
How can I install this patched
I was wondering if it would be possible to provide a library someplace for
the GNU version of getopt()? I've seen a lot of source code in the tree,
and whenever a program in /usr/src/{gnu,contrib} needs to link to the GNU
version of getopt() and getopt_long(), there were source files provided in
Donn Miller [EMAIL PROTECTED] writes:
I was wondering if it would be possible to provide a library someplace for
the GNU version of getopt()?
/usr/ports/devel/libgnugetopt.
tg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Thomas Gellekum wrote:
Donn Miller [EMAIL PROTECTED] writes:
I was wondering if it would be possible to provide a library someplace for
the GNU version of getopt()?
/usr/ports/devel/libgnugetopt.
Thanks Thomas. I wasn't aware that the port existed. Yes, I had
problems compiling
49 matches
Mail list logo
