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 available
On Sep 20, 2014, at 11:06 AM, Konstantin Belousov 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 rather we make
On Aug 8, 2014, at 5:22 AM, Konstantin Belousov 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 it.
> I do not wa
at 4:42 PM, "Justin T. Gibbs" 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 wrote:
>
>> Hello.
>>
&g
>
>
>
> Dmitriy Makarov wrote:
> DM> The attached patch by Steven Hartland fixes issue for me too. Thank you!
> DM>
> DM>
> DM> --- Исходное сообщение ---
> DM> От кого: "Steven Hartland" < kill...@multiplay.co.uk >
> DM> Дата: 1
On Oct 10, 2013, at 12:40 PM, Michael Schmiedgen 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':
> /usr/src/sys/xen/gnttab.c
On Sep 17, 2013, at 4:53 PM, Steven Hartland wrote:
> - Original Message - From: "Justin T. Gibbs"
>
>
>> 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 yo
>
> I'd have to did some more to see how ashift in cache devices is or isn't
> implemented.
>
> Regards
> Steve
>
> - Original Message - From: "Dmitriy Makarov"
> To: "Steven Hartland"
> Cc: "Borja Marcos" ; ;
&g
On Jan 23, 2013, at 1:39 PM, Alexander Motin 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 an
On Dec 4, 2012, at 6:18 PM, Matthew Jacob 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 will. I be
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/25
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
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:
>>&g
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
>>> http://img839.imageshack
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 b
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
>
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 d
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 chang
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
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 for
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.
Free
> I've got another drive now to mess about with:
>
> da0: 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 serious problems. Have
> 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.
> 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
> pro
> I have a Supermicro SuperServer 6013P-8, with:
>
> ahd0: 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: port
> 0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq
: > 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
: slo
+*
+* 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
s
> 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
> 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 term
> 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 t
>> 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-director
>
> 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
> 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.
--
> 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
> 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
> ===>
>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 po
>> 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
>> 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 b
>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
>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
>
>
>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 thin
>
>:
>: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, t
>: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
>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 impo
>: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 pr
>> 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 dinne
>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 ver
>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 peripher
>
>> 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/leng
>> >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 multip
>
>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.
>> 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_inlin
>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 wo
>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 aic
>
>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 tra
>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 lan
>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 fr
>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
>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
>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 think I found the problem. The problem occur since 03/14/2001. The
>following files could be infvolved:
You'll have to ask Soren about this. It looks like one part of
ata-all (this is in -stable), clears the RF_SHAREABLE flag. I
don't know why this would be necessary for a PCI IDE device.
-
>
>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 instru
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
--
Just
>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 revis
>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 exhibi
>"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 pull
>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 dev
>> >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
>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" pr
>: 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
>: 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
>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 o
>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 c
>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 tha
>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 n
>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
pr
>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
>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
>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
>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
>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 m
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 re
>Yesterday I decided to upgrade my home server from it's PRE_SMPNG
>state to -current, but now it panics just after detecting the
>aic7810 RAID controller (though unsupported, the box booted happily
>on an PRE_SMPNG kernel).
My guess is that this patch will fix your problem.
--
Justin
Index: ai
>-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
>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
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 thi
>
>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
>> >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
>
>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 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
>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 atta
>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 t
>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 pr
>> 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
1 - 100 of 135 matches
Mail list logo
