avg pointed out the rate limiting code in vm_pageout_scan() during discussion
about PR 187594. While it certainly can contribute to the problems discussed
in that PR, a bigger problem is that it can allow the OOM killer to be
triggered even though there is plenty of reclaimable memory
On Sep 20, 2014, at 11:06 AM, Konstantin Belousov kostik...@gmail.com wrote:
On Fri, Sep 19, 2014 at 03:27:25PM -0400, John Baldwin wrote:
I suspect it was done out of reasons of being overly conservative in
interpreting RLIMIT_STACK. I think it is quite surprising behavior
though and would
On Aug 8, 2014, at 5:22 AM, Konstantin Belousov kostik...@gmail.com wrote:
…
Below is the patch which adds environment variable LIBPTHREAD_BIGSTACK_MAIN.
Setting it to any value results in the main thread stack left as is, and
other threads allocate stack below the area of RLIMIT_STACK. Try
Hartland fixes issue for me too. Thank you!
DM
DM
DM --- Исходное сообщение ---
DM От кого: Steven Hartland kill...@multiplay.co.uk
DM Дата: 18 сентября 2013, 01:53:10
DM
DM - Original Message -
DM From: Justin T. Gibbs
DM
DM ---
DM Дмитрий Макаров
DM
, Justin T. Gibbs gi...@freebsd.org wrote:
You'll have to be more specific. I don't have that email or know what list
on which to search.
Thanks,
Justin
On Oct 16, 2013, at 2:01 AM, Vitalij Satanivskij sa...@ukr.net wrote:
Hello.
Patch brocke cache functionality.
Look at's
On Oct 10, 2013, at 12:40 PM, Michael Schmiedgen schmied...@gmx.net wrote:
Hi List,
is it intended that kernel does not build if
device xenpci
is omitted in the kernel config? I get the following error:
linking kernel
gnttab.o: In function `gnttab_resume':
On Sep 17, 2013, at 4:53 PM, Steven Hartland kill...@multiplay.co.uk wrote:
- Original Message - From: Justin T. Gibbs gi...@freebsd.org
Sorry for being slow to chime in on this thread. I live in Boulder, CO and
we've had a bit of rain. :-)
Hope all is well your side, everyone
to did some more to see how ashift in cache devices is or isn't
implemented.
Regards
Steve
- Original Message - From: Dmitriy Makarov suppor...@ukr.net
To: Steven Hartland kill...@multiplay.co.uk
Cc: Borja Marcos bor...@sarenet.es; freebsd-current@freebsd.org;
Justin T. Gibbs gi
On Jan 23, 2013, at 1:39 PM, Alexander Motin m...@freebsd.org wrote:
On 23.01.2013 21:51, Jaakko Heinonen wrote:
On 2013-01-23, Vitalij Satanivskij wrote:
VS Jaakko Heinonen wrote:
VS JH I see two possible solutions for the problem.
VS JH
VS JH 1) Replace non-printable, space and '/'
On Dec 4, 2012, at 6:18 PM, Matthew Jacob m...@feral.com wrote:
On 12/4/2012 1:36 PM, Jeff Roberson wrote:
http://people.freebsd.org/~jeff/loadccb.diff
looks ok for isp. This doesn't do diddly for target mode- do you know off the
top of your head if it will break anything there?
It
Someone who has yet to confess added -Werror to the global CFLAGS
(via /etc/make.conf) for one of our systems at work. Before I
figured out that this was the cause of builds failing, I hacked up
pam_passwdc to resolve the problem. This gets the module to
WARNS=2, but to go farther, the logically
On 6/25/11 12:39 AM, Andrey Chernov wrote:
On Fri, Jun 24, 2011 at 09:09:08PM -0400, Justin T. Gibbs wrote:
No problem. I just set kern.geom.debugflags=4 in loader.conf and here is
new photo (with recent kernel, no patches):
http://img803.imageshack.us/img803/4679/25062011006.jpg
I skip all
On 6/24/11 3:35 PM, Scott Long wrote:
On Jun 23, 2011, at 11:18 PM, Scott Long wrote:
On Jun 23, 2011, at 9:01 PM, Justin T. Gibbs wrote:
On 6/22/11 4:09 PM, Kenneth D. Merry wrote:
On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
On Tue, Jun 21, 2011 at 09:54:04PM -0600
On 6/24/11 6:26 PM, Andrey Chernov wrote:
On Fri, Jun 24, 2011 at 04:20:24PM -0400, Justin T. Gibbs wrote:
Instead, I believe that either one of the GEOM taste methods is
leaking an
access reference (so cdclose() is not called), or the CD driver is
failing
to release the hold semaphore
On 6/22/11 4:09 PM, Kenneth D. Merry wrote:
On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
On Tue, Jun 21, 2011 at 09:54:04PM -0600, Kenneth D. Merry wrote:
These two are interesting:
http://img825.imageshack.us/img825/1249/21062011014m.jpg
On 6/19/11 6:19 PM, Andrey Chernov wrote:
Exactly that commit is responsible for boot hang.
Please fix.
BTW, I have MBR on SATA disk (CAM emulated), ICH9.
Since it works for me, you'll need to provide more information. Can you
at least drop into kdb to determine the likely source of the hang
On 2/5/2011 8:39 AM, Pawel Jakub Dawidek wrote:
On Fri, Feb 04, 2011 at 11:03:53AM -0700, Justin T. Gibbs wrote:
The attached patch is sufficient to allow a C++ program to use libzfs.
The motivation for these changes is work I'm doing on a ZFS fault
handling daemon that is written in C
On 2/5/2011 3:06 PM, Pawel Jakub Dawidek wrote:
On Sat, Feb 05, 2011 at 02:36:40PM -0700, Justin T. Gibbs wrote:
Perhaps IllumOS will accept these changes back? As I mentioned in the
change descriptions included with the patch, the header files already
show the intention of providing C
The attached patch is sufficient to allow a C++ program to use libzfs.
The motivation for these changes is work I'm doing on a ZFS fault
handling daemon that is written in C++. SpectraLogic's intention
is to return this work to the FreeBSD project once it is a bit more
complete.
Since these
On 9/17/2010 1:27 AM, Rui Paulo wrote:
On 17 Sep 2010, at 07:55, Rui Paulo wrote:
On 17 Sep 2010, at 02:44, Justin T. Gibbs wrote:
At Spectra Logic, we are using FreeBSD amd64 under Xen to serve storage
to other Xen domains. Over the past 9 months, we've made several changes
to FreeBSD's
At Spectra Logic, we are using FreeBSD amd64 under Xen to serve storage
to other Xen domains. Over the past 9 months, we've made several changes
to FreeBSD's Xen support. These include:
o Support for backend devices (e.g. blkback)
o Extensions to the Xen para-virtualized block API to allow
The following patches introduce the BIO_ORDERED flag for bios.
A bio tagged with the BIO_ORDERED flag has barrier semantics:
all bios queued before the BIO_ORDERED bio are executed before
the BIO_ORDERED bio and any bios queued after the BIO_ORDERED bio
are executed after the BIO_ORDERED bio.
I've got another drive now to mess about with:
da0: IBM IC35L036UWDY10-0 S23C Fixed Direct Access SCSI-3 device
And I get the same problems.
I would have to see the driver messages to verify that.
You are running down rev. firmware on this drive and early Daytona
firmware revs had some
You may have a device (USB camera, pen drive, hard drive, ...) that begins
to get errors like ... Synchronize cache failed, status 0x35.
If the Sync cache fails with a reasonable error code, then the code
that silence these errors should be enhanced rather than have a quirk
entry added.
Just
After this code is in both stable and current, current USB quirks will be
deprecated but can be re-enabled in a pinch with a kernel option.
Unfortunately, I only have contact information for the more recent quirks
that were committed and so the only way to find devices that have other
I have a Supermicro SuperServer 6013P-8, with:
ahd0: Adaptec AIC7902 Ultra320 SCSI adapter port
0x4000-0x40ff,0x4400-0x44ff mem 0xfc30-0xfc301fff irq 5 at device 2.0 on
pci3
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
ahd1: Adaptec AIC7902 Ultra320 SCSI
I'm thinking that the loop should be more like:
pcifunchigh = 0;
f = 0;
hdrtype = REG(PCIR_HEADERTYPE, 1);
if (hdrtype 0x7f 2)
continue;
My only complaint about this is that if no device is present in the
+*
+* If we don't hardware the bus down, pciconf gets confused.
*/
if (sc-secbus != 0) {
- child = device_add_child(dev, pci, -1);
+ child = device_add_child(dev, pci, sc-secbus);
if (child != NULL)
: I'm thinking that the loop should be more like:
:
: pcifunchigh = 0;
: f = 0;
: hdrtype = REG(PCIR_HEADERTYPE, 1);
: if (hdrtype 0x7f 2)
: continue;
:
: My only complaint about this is that if no device is present in the
: slot, won't
Hi,
I am running current cvsuped within this week. I have an adaptec
builtin scsi controller and a seagate drive attached to it and
after every bootup as soon as there is heavy disk activity
the drive gets disabled for 1 or 2 minutes and meanwhile all
functionality RELATED to disk I/O
Me neither but my 2642 additionally only boots from channel B.
Meaning it hangs if you attempt to boot from channel B? I really
have no feel for what the actual failure mode is yet. Do we get
timeouts? No devices are seen? What does a verbose boot print out
about the controller and its
System and kernel slice at 1200 GMT 30 Sep 2002 where
the log showed a whole series of changes to the Adaptec
drivers: kernel came up, ran for a few minutes, then
hung.
There have been no major changes to the aic7xxx driver in the last
few days. A few $Id updates, a fix to a
uhm, i just got another one. i guess the hd is broken and also managed to
cause the previous panic.
Can you do a:
cd /usr/src/sys/i386/compile/MYKERNEL
gdb -k kernel.debug
l *(ahc_dump_card_state+0x692)
and give me the output.
Thanks,
Justin
To Unsubscribe: send
Can you do a:
cd /usr/src/sys/i386/compile/MYKERNEL
gdb -k kernel.debug
l *(ahc_dump_card_state+0x692)
and give me the output.
I'm sorry but i replaced the hd and as it survided the buildworld
discarded the old one. I still have the compile-directory of the
kernel
Well, I ended up unlinking it from the build and am installing now.
Once I get a fresh world installed, I'll try and rebuild world again
to see if the problem persists. Would you like me to get a ktrace of
aicasm running before I rebuild world? -sc
That would have been interesting.
--
Today's current gave me the following error while building a new kernel
after a successful make world.
cd /usr/src/sys/modules ;
MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/PIII850N/modules
KMODDIR=/boot/kernel MACHINE=i386 make cleandir
=== 3dfx
=== accf_data
=== accf_http
=== agp
=== aha
Apparently Makefile not have aicasm target (newly created clean
building directory):
I can't reproduce this here. My kernel Makefile includes an aicasm target.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
I believe I had this conversation with Justin Gibbs earlier; he told
me that the callout consumers (network, cam) had to be aware of the
race and handle this if it matters. I don't particularly like complicating
the callout handlers as illustrated above, though, so if a better scheme
is
I think it should go away. We should malloc space to hold the segments in
the leaf dma tags and base that size on the information in the tag. The
segments would only be allocated on the first dma_map_create call on a
tag so that intermediate (i.e. non-leaf) tags never have this stuff
BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed
to do at one time'- which is wrong because MAXPHYS is larger.
If you look at the x86 implementation, BUS_SPACE_MAXSIZE is only
used in the non-GNUC case and is not referenced (I don't think)
by any driver code. Even
a single buffer. I never realized that there was such controversy
over this value... it was just put in so that I could have something
for the non-GNUC case.
Yeah, but, uh, it'll blow up in one's face.
If it gets compiled, I suppose so.
The question I have is what *should* we be using?
FWIW, Justin and I have been thinking about (for years, actually) doing
multipath support inside CAM.
Actually, the multipathing support would be in new-bus and CAM would be
one newbus client able to detect redundant paths and register them
accordingly.
The main thing to remember is that there
The API is intended for the stage-2 commit. The stage-1 commit
is intended to do all the 'hard stuff' in as straightforward
a manner as possible. The sysctl / option you talk about here
existed in my patch set 2 and a half weeks ago.
The API and getting it right is more
:I didn't have to read the patch to know that there were concerns and
:on-going discussion about the API. In this instance, the issues are
:not large and can be remedied quickly - all the more reason for the
:discussion to take place before the commit.
Again, bullshit. You should have read
:
:You came to the conclusion that only *your decision* on what was
:an appropriate proceedure was the one that mattered. That's not
:the way this project works. You can't act unilaterally. When people
:ask you to hold off (and they even asked politely!) so discussion
:can take place, that is
On Thu, 7 Mar 2002, Justin T. Gibbs wrote:
The only way it will get delayed that long is if you spend all of your
time stomping up and down, writing in all caps, and tell the rest of
us that we have to follow the proceedures you think are appropriate.
That's not how colaboration works
:stuff to change from their current model. I also think that just as it
:is too early to optimize to light weight ithread switches (sparc64 is
:going to optimize all kthread switches, not just ithreads by using a more
:general
We have very different development models, and different
What functionality is lost by this ability?
Compare the features of the ATAPI vs SCSI CD drivers..
This is exactly why I'd like to see this code merged. The hardware
changes too rapidly. The specs change too rapidly but MMC is MMC.
More of us are getting wives we need to take out to dinner
I can reproduce this at will using the following test. Note that the
machine does seem to recover from the error eventually.
According to the aic7xxx controller, the drive is not completing a
disconnected command. This is very similar to some problems with
some recent IBM firmware
How do you inform the upper layers that only 10+ byte commands are
allowed? (12 byte in the case of ATAPI).
In the long term, this would just be the nature of the exported
Protocol Type/Protocol Version and Transport Type/Transport Version
passed back in the Path Inquiry response. The
My understanding is that you need a dmamap for every buffer that you want
to map into bus space.
You need one dmamap for each independantly manageable mapping. A
single mapping may result in a long list of segments, regardless
of whether you have a single KVA buffer or multiple KVA
The fact that the data is less than a page in size matters little
to the bus dma concept. In other words, how is this packet presented
to the hardware? Does it care that all of the component pieces are
PAGE_SIZE in length? Probably not. It just wants the list of
address/length pairs
Correction.
This sample:
if (bus_dma_tag_create(pci-parent_dmat, PAGE_SIZE, lim,
BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1,
BUS_SPACE_MAXSIZE_32BIT, 0, pci-cntrol_dmat) != 0) {
isp_prt(isp, ISP_LOGERR,
Every hear the phrase you get what you pay for? The API isn't all that
clear, and we don't have a man page or document that describes in detail
how to use it properly. Rather than whining about that, I decided to
tinker with it and Use The Source, Luke (tm). This is the result.
Fair enough.
My
John Baldwin wrote:
Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try
this: find the ahc driver's interrupt handler, and add a printf.
Then see if the printf fires while the machine is hung.
Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint().
That won't
That won't catch all interrupts. Most notably, you won't know
if commands are completing. Command completions are much more
prevalent than sequencer or scsi interrupts.
should I try and catch the command completions? which routine is best
to do this in?
ahc_intr() in aic7xxx_inline.h
Please excuse me if you've seen this in questions, but I found a
relevancy to current: If I drop back to 4.3 release, this system boots
every time with no hangs observed in half a dozen tries in either UP
or SMP mode. Anyone else seeing similar?
I doubt that this is related to CAM or the
Just upgraded my server to newest kernel, did a 'make -j16 buildworld' and
an installworld with no problems, and then started building newest kde ...
woke up to this all over my screen ...
The aic7xxx driver is seeing repeated timeouts but everytime it goes
to check on a transaction, the
Currently SC_MOUSE_CHAR occupes 0xd0-0xd4 range which produce conflict
with several languages code tables. I plan to redefine it by default to
0x03-0x07 leaving possibility to redefine it to any range as currently
present. This way minimizes arcane information needed for user to setup
its
I don't consider it inefficient. Sure, if you look at this one aspect
of the caching taken out of context it may appear to be inefficient,
but if you look at the whole enchilada the memory issue is nothing
more then a minor footnote - not worth the effort of worrying about.
There's no downside, really.
It just seems inelegant to have a system that, on paper, is
so inefficient. Can't we do better?
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
I notice that this option is off by default. Can you give a general
idea of when it should be enabled, when it should be disabled, and what bad
things might result with it on?
It consumes a full page per-directory even though the majority of
directories in a stock system are a small
Hi,
Just had one of these on yesterday's -current. Anyone interested in the
details?
Nah. Its probably just you, or something specific to your system.
It couldn't possibly be a bug in *my* code.
;-)
Of course I'm interested!
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
I'm getting these too (I thought it was just me, since it's my first day
of going back to -current after a six month hiatus - I've hit myself with
the clue-stick thoroughly and put it on a different slice this time... but
I digress!) so I can give some additional info, if required. Don't have a
On Fri, 30 Mar 2001, Justin T. Gibbs wrote:
I really need the complete set of messages printed out prior to the panic.
Okay, here yer go (transcribed using hi-tech ballpoint and scribbly
handwriting, I'm afraid!)
This is certainly a bug, but some things about what you've written
make me
Dear Justin,
Since the update around the middle of feb of the ahc driver the aic7892
chip is no longer supported correctly. The same card with aic7870 is
working as usual. So I think that this is the problem. The snapshot
(2001/02/10) of the current version is OK.
Can you give me the revision
I've just tested both -current and -stable on a card with identical
specs. Can you provide more inforamtion on where the attach fails
(e.g. add printfs)?
### 29160 BIOS v.2.57.2
### pciconf
aries# pciconf -l
ahc0@pci0:9:0: class=0x01 card=0xe2a09005 chip=0x00809005 rev=0x02
--
Justin
Looks like I've got a similar problem only its aic7880/wide
I've got a Dell optiplex 450 with an Adaptec 2940uw controller which can
boot but can't "mountroot".
Perhaps something happend recently that makes it difficult to get
"largish" chuncks of contiguous memory? You'll have to instrument
Hi,
dmesg and the output of "ident /sys/dev/aic7xxx/*" and pciconf is
attached (BTW: the -v options to pciconf isn't documented in the
synopsis section of the man page).
Do you need more information, e.g. the output of a verbose boot?
Bye,
Alexander.
I wish I had a system that exhibited this
"Justin T. Gibbs" [EMAIL PROTECTED] wrote:
It is not necessarily sufficient since the media may be changed after
open on certain types of devices that don't have a media lock.
But don't you risk a panic if you do that?
By pulling the media out and flipping off the hardware write prot
Are there any reason device drivers do not check if thier devices are
writable or not when they are opened ? I think returning an error
value, like `od', is the easiest way to avoid this problem.
It is not necessarily sufficient since the media may be changed after
open on certain types of
On a current SMP box running a kernel from this morning I see messages
from the ahc driver I haven't seen before. The machine keeps on running
though. Should I worry about them or back down to kernel of yesterday?
Hmmm. Can you add a call to "ahc_dump_card_state(ahc);" after the
"WARNING"
On a current SMP box running a kernel from this morning I see messages
from the ahc driver I haven't seen before. The machine keeps on running
though. Should I worry about them or back down to kernel of yesterday?
I know you are having difficulties reproducing this, but I believe that
my
: MAC=00:00:80:00:00:80, FWIW.
There's about 4 different dc based cards that don't work because they
don't get the nic address right. Well, that's what I think.
That is fixed with my cardbus patch set... at least for the xircom.
It should be trivial to fix for the others if they store their
: That is fixed with my cardbus patch set... at least for the xircom.
: It should be trivial to fix for the others if they store their
: nic address the same way.
Interestingly enough, they do. However, of all my cards, the both my
xircom just work w/o this.
Warner
The dc driver would get
perl -pi -e "s:^V^M::g" Gibbsdiffs # How come... :-)
That's MH's mime for you.
Summing up: SCSI seems to work like a charm.
The patch has been committed to both -current and -stable.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
Dear FreeBSD'ers,
I am running -CURRENT as of today (sources as of ~ 18:15 GMT). I can
see the following (a # sign precedes my comments):
Can you see if this patch corrects the problem?
--
Justin
Index: dev/aic7xxx/aic7xxx.c
Can you send me the output of "pciconf -l" on this system? My guess
is that your MB vendor did not use the correct subsystem ID for the
aic7896 to enable the second channel. We only recently started to
pay
attention to this. What MB is this?
My system doesn't find any scsi controllers.
After upgrading my system from 13'th December to latest -current,
the ahc driver doesn't attach to onboard AIC-7896 second channel
anymore. I'm cc'g to Mr. Gibbs and Smith in hope they are the right
persons.
Dmesg:
Can you send me the output of "pciconf -l" on this system? My guess
is that
I was mostly trying to push the locks down so that they weren't held during
attach and remove. I was using them to protect mostly the kthread state flag
in the softc, as well as other variables in the softc.
Comments?
It seems to me that having a single thread per-softc gives you this
It seems to me that having a single thread per-softc gives you this
protection without requiring any locks. Other than having to aquire
Giant at thread starup (as most code below us is not thread safe yet),
I don't see any other locking requirements.
I take that back. In pccbb_detach, you need
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
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
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
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
I'll have to look up the CIS_PTR spec. I'm not sure I like hardwiring
things like this.
Where did you get a copy of the pccard spec? Do you have to order
it from the pcmcia SIG?
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
While working on getting the APA-1480 to work under FreeBSD's new
cardbus support, I ran into several issues.
1) When mucking with mapping registers, it is best to *not* have
io or memory space access enabled. This patch defers the setting
of these bits until after all of the mapping
-On [20001109 21:30], Justin T. Gibbs ([EMAIL PROTECTED]) wrote:
If possible, please include a contact name, email, or phone number so
we can ask additional questions if necessary.
Do foreign educational institutes count as well for this purpose?
Yes.
--
Justin
To Unsubscribe: send mail
On Thu, 9 Nov 2000, Peter Wemm wrote:
Do you want to know what is even funnier? One of my onboard ahc *PCI*
controllers (7895 based I think) also responds to the EISA probes if I
enable EISA.
What machine and what does the output from the probe/attach look like?
You'll fail the attach
What machine and what does the output from the probe/attach look like?
You'll fail the attach because the ID is not in the table of known
EISA IDs.
I forgot to mention that the probe will cause the aic78XX controller
to get very upset as you end up referencing a register that should
only be
What about EISA/VL or EISA/PCI systems?
What about them? PCI devices are supposed to be found via PCI configuration
space access. Even in these machines where a PCI card can be falsly
probed as an EISA card, the standard PCI configuration mechanism works
to correctly find PCI devices. VL
What about EISA/VL or EISA/PCI systems?
What about them? PCI devices are supposed to be found via PCI configuration
space access. Even in these machines where a PCI card can be falsly
probed as an EISA card, the standard PCI configuration mechanism works
to correctly find PCI devices.
How do we use the EISA BIOS on an Alpha or an SGI though?
I believe thorpej recently committed some code in NetBSD to do this
on the Alpha.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
As some of you may know, I'm working on a 501(c)3 (tax exempt/non-profit)
determination for the FreeBSD Foundation. The IRS seems to be a little
confused about the nature of FreeBSD and we're currenlty working on
a response to an initial determination from the IRS that was not
favorable. One
I'm subscribed to -stable and not current, and yet I received this
email. Do the lists get mixed up once in a while?
You're the victim of mh's dist command which I used to make this
plea to several mailing lists. Unfortunately it looks like
cross posting is disabled in majordomo (probably for
The IRQ allocation needs the RF_SHAREABLE flag or it will blow up in
the case where the IRQ is shared with another device.
So the EISA attachment doesn't set RF_SHAREABLE if the system is
using a level sensitive interrupt?
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
So the EISA attachment doesn't set RF_SHAREABLE if the system is using
a level sensitive interrupt?
The current EISA code isn't as smart as it should be.
Speaking of that, I'd like to see the EISA code move to be
more like PCI. We should see
The only reason this isn't done is because I, due to the
fledgling nature of the EISA code and the ahc VL card's
almost looking like EISA cards, did the wrong thing here.
We also need to be verifying that io ranges required to
probe for slots are not already claimed by other devices
before
I'm still not clear as to why we need to differentiate them. There really
is no requirement that slot 0 be present (other than it being standard and
all.)
Can we even tell if which EISA devices are really VL devices in disguise?
The only reason is to return the EISA probe to a read-only probe.
Humm... I had wondered why that was there. Is there a way to detect VLB
devices some other way?
This is specific to the aha2842 and is the only way I know of detecting
those boards.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
1 - 100 of 132 matches
Mail list logo
