Hi
Just got some while colleague used the bridge segment behind fxp1
interface.
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-CURRENT #0:
"Brune, Michael" wrote:
I CVSup'ed the sources today, built and installed world and everything
was fine. When I tried to compile the kernel, I recieve this error when
I do the 'make depend'
./aicasm -nostdinc -I- -I. -I../../ -I../../../include
-I../../contrib/dev/acpica/Subsystem/Include
[ -arch and -current BCC'ed for wider coverage, please direct followups to
-net and/or me ]
I have put a new copy of the zero copy sockets and NFS patches, against
-current as of early November 20th, 2000, here:
http://people.FreeBSD.ORG/~ken/zero_copy/
Questions, comments and feedback are
(just a little extra info)
Scheduler issues have been present since at least 20001112-current.
I installed the snapshot as my first venture into the current tree.
Mp3 skippage and loopage was very bad.
The box in question is an amd k6-2 300 (lower than average in this
list, i gather). Mp3
The other interface will be an enumerative interface where you can get
a callback for each CIS entry. These will be bus method based so that
they will be the same between 16-bit and 32 bit code.
I don't think the enumerative interface should be callback based. I'd
rather have something that
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes:
: The other interface will be an enumerative interface where you can get
: a callback for each CIS entry. These will be bus method based so that
: they will be the same between 16-bit and 32 bit code.
:
: I don't think the enumerative
I have a high clock drift rate.
The problem is in selecting the timecounter, at least on my machine.
Both the TSC and the i8254 timecounters are checked and, since, I
believe, TSC is last, TSC is the timecounter the kernel uses.
TSC is a horrible timer, at least on my machine. i8254 is not
That's what I mean. You call this, and it will remap the CIS (if it
has been unmapped), walk it for you and pass you a pointer to each CIS
entry one at a time to the function you specify.
Warner
I'd rather have a seek/read interface than have a callback.
--
Justin
To Unsubscribe: send mail
Hi,
Console, console, where's the console?
We are attempting to use FreeBSD 4.2-RC2 on an
AlphaServer 2000 4/233 and are running into trouble
with the console device.
When we boot from the CD, it comes up to the boot
prompt on the console where we tell it to boot from
the cd device.
The problem with a read/seek interface is that you are consuming a
resource (a memory window) while you are using it.
Yes, but this is the client's resource to use anyway.
You'd need an
open/close on top of that as well to properly map things in to start
and then free them at the end. Plus you
Grr... make that 4.2-RC1
FreeBSD 4.2-RC1 #0: Thu Nov 16 06:10:10 EST 2000
-john
- John W. De Boskey's Original Message -
Hi,
Console, console, where's the console?
We are attempting to use FreeBSD 4.2-RC2 on an
AlphaServer 2000 4/233 and are running into trouble
with
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes:
: The problem with a read/seek interface is that you are consuming a
: resource (a memory window) while you are using it.
:
: Yes, but this is the client's resource to use anyway.
IIRC, it is shared at the bridge, so the client driver needs
On Tue, Nov 21, 2000 at 12:59:56PM -0800, John W. De Boskey wrote:
Console, console, where's the console?
We are attempting to use FreeBSD 4.2-RC2 on an
AlphaServer 2000 4/233 and are running into trouble
with the console device.
When we boot from the CD, it comes up to the
What is the current state of the usbd? I keep getting messages that
complain about a host controller error and a shutdown of the usb
interface. And I don't even have any devices on my usb ports...
JAN
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the
That's what I mean. You call this, and it will remap the CIS (if it
has been unmapped), walk it for you and pass you a pointer to each CIS
entry one at a time to the function you specify.
Warner
I'd rather have a seek/read interface than have a callback.
Let's be realistic; the right
IIRC, and I haven't looked it up, the CIS entries that would be
problematical have two next pointers. One is for the next function,
while the other is for the first entry specific to this function. The
driver code could look at the CIS entry to tell what to do, and if it
was the wrong
In message [EMAIL PROTECTED] Mike Smith writes:
: That's what I mean. You call this, and it will remap the CIS (if it
: has been unmapped), walk it for you and pass you a pointer to each CIS
: entry one at a time to the function you specify.
:
: Warner
:
: I'd rather have a seek/read
: Let's be realistic; the right way to do this is going to be to use the
: ivar interface; cardbus_get_cistuple(dev, index) just like all the other
: PCI bus accessor functions. PCI will just need to pass the request
: through to its parent, assuming its parent is a cardbus bridge, or
In message [EMAIL PROTECTED] Mike Smith writes:
: No; the CIS parser should know which function it's being called on behalf
: of, and simply elide the tuples that don't relate to that function.
This isn't always the right thing to do. At least in the 16-bit
world, there are drivers that want
In message [EMAIL PROTECTED] Mike Smith writes:
: : Let's be realistic; the right way to do this is going to be to use the
: : ivar interface; cardbus_get_cistuple(dev, index) just like all the other
: : PCI bus accessor functions. PCI will just need to pass the request
: : through to its
In message [EMAIL PROTECTED] Mike Smith writes:
: No; the CIS parser should know which function it's being called on behalf
: of, and simply elide the tuples that don't relate to that function.
This isn't always the right thing to do. At least in the 16-bit
world, there are drivers that want
In message [EMAIL PROTECTED] Mike Smith writes:
: No; the CIS parser should know which function it's being called on behalf
: of, and simply elide the tuples that don't relate to that function.
This isn't always the right thing to do. At least in the 16-bit
world, there are drivers that
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes:
: The ROM BAR is only implemented for function 0 and the ROM
: contains information for all functions of the chip. So, functions
: greater than 0 must have the flexibility to activate at least the ROM
: BAR on function 0 as well as access
function its own CIS chain. These CIS chains can live in
configuration space, in memory space or the expansion ROM (which I
assume is the same thing as the ROM BAR on function 0, but maybe I'm
mistaken) and the bridge is responsible for properlly mapping the last
two.
The config space
24 matches
Mail list logo
