In article <[EMAIL PROTECTED]> you wrote:
> Hi all,
>
> This morning I had a very strange (at least I've never seen it before) SCSI
> related system hang. The system simply stopped responding at 9:30:03 am
> this morning. I found it in this state at 13:20. It had been hanging
> _hard_. No respon
In article <[EMAIL PROTECTED]> you wrote:
> I wrote a patch for the psm driver to add support for several PS/2 mice.
> It is in http://www.freebsd.org/~yokota/ps2mice-24Jan2000.tar.gz.
> I am attaching README included in the patch.
>
> Thank you.
>
> Kazu
Do you have specs on the Trackpoint PS/
>
>>Do you have specs on the Trackpoint PS/2 mice found on Thinkpads?
>
>No.
>
>>The version on my 770X has a double click by "pushing hard on the
>>trackpoint" feature. It also has the ability to do the scroll
>>thing if you hold the middle mouse button and move the trackpoint.
>
>You mean, the
>hi,
>
>with the latest changes to src/sys/pci/pci_ahc.c (partity error handling),
>i'm unable to boot a current kernel, because of panic during system boot.
>
>i've attached dmesg from a working kernel version (2000/01/06) to this
>mail. marked with (***) you'll find the line, where (with the new
In article <[EMAIL PROTECTED]> you wrote:
> I get the following:
>
> pci0: unknown card (vendor=0x9004, dev=0x5078) at 8.0 irq 11
Nothing has changed in this area for some time and the id for this
card is in the table of supported devices. Do you get any additional
information from a boot -v?
>I'm noticing some new output. What does it mean and is it going
>to stay there? :-)
Peter killed these last week.
>
>- Jordan
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In article <[EMAIL PROTECTED]> you wrote:
>
> I'm getting this with a recent current (6. october):
>
> (da2:ahc2:0:2:0): data overrun detected in Data-Out phase. Tag == 0x25.
> (da2:ahc2:0:2:0): Have seen Data Phase. Length = 0. NumSGs = 1.
Someone is telling us to transmit data, but has not
It looks like both nsio and sio have PCCARD support disabled at the
moment. Is there any other way I can get the system to recognize my
modem?
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
>It seems Justin T. Gibbs wrote:
>> It looks like both nsio and sio have PCCARD support disabled at the
>> moment. Is there any other way I can get the system to recognize my
>> modem?
>
>Fix the broken sio, it might be KNF and all but it doesn't work...
>
&g
In article <[EMAIL PROTECTED]> you wrote:
> Hi,
> I am running 4.0-current of:
> FreeBSD gmarco.eclipse.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Thu Nov 18
> 09:33:43 CET
> 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GMARCO i386
>
> But I have now a lot of errors (as you can see in this log
I still can't get remote GDB to work correctly in a 5.0-current
environment at speeds greater than 9600bps. Is anyone else
experiencing similar results? I thought that grog had fixed this...
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the bo
>On Wednesday, 14 June 2000 at 11:05:41 -0600, Justin T. Gibbs wrote:
>> I still can't get remote GDB to work correctly in a 5.0-current
>> environment at speeds greater than 9600bps. Is anyone else
>> experiencing similar results? I thought that grog had fixed thi
>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
>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
>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
>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
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
>
>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 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.
-
>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
>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 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
>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 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.
>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
>
>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
>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
>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
>> 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
>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.
>
>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,
>>
>> >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
>
>> 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
>
>Please test & review this patch:
>
> http://phk.freebsd.dk/patch/offsetof.patch
I believe that several drivers include stddef.h to get
offsetof. I think most of these files are flagged by
"/* for offsetof */".
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscrib
I beleive that I've somehow corrupted my /dev on my laptop.
An ls -l in there causes an instant panic:
Copied by hand...
vfinddev(,3,c877ac84,10002,1) at vfinddev+0xc
<= NODEV
addaliasu(c7dc0a00,10002,c0b04800,c33e1180,c0b149e4) at ufs_vinit+0x44
ufs_vinit(c0b01c00,c0abe
After the recent introduction of cardbus support into -current, I
decided to upgrade my laptop. At first glance, the system seemed
to support a Xircom "Real Port" 10/100/56K modem card with the
dc driver. The funny thing though is that, although I can initiate
IP or TCP connections to remote hos
>tcpdump on the laptop sees the packet? That's very odd.
Ceratinly is. I don't think this particular problem has anything
to do with the cardbus adapter. I run tcpdump with "-v -v -v" and
it never reported a bad checksum either.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
>
>> >tcpdump on the laptop sees the packet? That's very odd.
>>
>> Ceratinly is. I don't think this particular problem has anything
>> to do with the cardbus adapter. I run tcpdump with "-v -v -v" and
>> it never reported a bad checksum either.
>
>For curiosity's sake, I'd try a different cab
>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 "unsub
>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
>> 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
>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
>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
>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
>>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
>
>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 thi
>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
>-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
>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
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
>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
>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
>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
>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
>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
>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
>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
>> 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
>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
===
>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
>: 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
>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
>> >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
>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
>"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
>There were some changes made to ahc driver made on 1/13/99
>And i can no longer boot a current kernel
You'll have to give me more information so that I can reproduce
the problem here. A good start would be to send a complete dmesg
from the system using a kernel that boots correctly for you.
--
In article <4.1.19990117003737.009d4...@194.184.65.4> you wrote:
>
> Ok, first the conclusion...
>
> I am not able to boot anymore from a 3.0-current system while I can boot
> quite nicely from the 3.0-RELEASE generic kernel.
What revision of aic7xxx.c do you have? I introduced a bug in rev 1
>> # Are you *sure* you're running -current as of today? Justin put code in to
>> # silence Illegal request error messages from the sync cache command.
These messages, since they are occurring only during a panic, are caused
by the code in dashutdown(). I didn't modify this code in my last check
In article <199903171103.naa13...@ceia.nordier.com> you wrote:
> Søren Schmidt wrote:
>
>> OK, easy enough, this is what I want to do:
>>
>> Boot from an ata disk on major# 30, device name "ad", plain and simple.
>
> I'd be inclined to handle this outside the boot code, by treating the
> passe
In article <199903171205.naa25...@freebsd.dk> you wrote:
> It seems David O'Brien wrote:
>> > Boot from an ata disk on major# 30, device name "ad", plain and simple.
>>
>> Does this mean ata disks won't come under CAM/da ?
>
> Not if I can help it :)
> It could be done by slamming a translation l
>> In article <199903171103.naa13...@ceia.nordier.com> you wrote:
>> > Søren Schmidt wrote:
>> >
>> >> OK, easy enough, this is what I want to do:
>> >>
>> >> Boot from an ata disk on major# 30, device name "ad", plain and simple.
>> >
>> > I'd be inclined to handle this outside the boot code,
>I half suspect that what Justin had in mind at some point was a set of common
>code that is either #ifdef'ed or otherwise preprocessed to produce a
>standalone 'SCSI-CAM' system versus an 'ATA[PI]-CAM' system. This would
>have the advantage of having all the common code together in one place and
>> My main complaint so far about the new ATAPI stuff is that it duplicates
>> or lacks (assuming it will be implemented) much of what CAM would have
>> given for almost free:
>>
>> - Interrupt driven configuration
>
>That there allready, if we mean the same thing here.
Right. Its duplicated fun
>> >> - Peripheral driver to device routing
>> >
>> >Such as ?
>>
>> Such as the ability to have more than one driver share the
>> same device, command generation counts and priority queuing
>> to allow correct 'replay' of overlapped commands when an
>> error occurs, etc. See:
>>
>> http://www.f
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
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
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
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 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
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
>
> 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
> 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
> 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.
> 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
In article <199904090127.jaa07...@ariadne.tensor.pgs.com> you wrote:
> After the last lot of CAM changes, I occasionally get processes hanging
> attempting to access my QIC-525 tape drive. They can't be killed, so doing
> backups can be a mite troublesome. Sometimes it works, sometimes it doesn't
>In message <19990412175644.7de5f1...@spinner.netplex.com.au> Peter Wemm writes
>:
>: to being able to use their drivers with less hassles. (There will be
>: enough fun due to differences in bus_space and bus_dma, but that's
>: another issue)
>
>I know that many people would like to see bus_
In article <199905191637.jaa03...@dingo.cdrom.com> you wrote:
> I'm not sure why it happens like this; try putting a DELAY() just
> before we actually set the root device and see if you can put it off.
Why not just spl() protect that printf call so that its output is
dumped contiguously into the
In article <199905210435.oaa11...@godzilla.zeta.org.au> you wrote:
>>> I'm not sure why it happens like this; try putting a DELAY() just
>>> before we actually set the root device and see if you can put it off.
>>
>>Why not just spl() protect that printf call so that its output is
>>dumped contigu
>In message <199905192231.qaa09...@narnia.plutotech.com>, "Justin T. Gibbs" wri
>t
>es:
>>In article <199905191637.jaa03...@dingo.cdrom.com> you wrote:
>>> I'm not sure why it happens like this; try putting a DELAY() just
>>> before w
>>CAM has finished probing at this point, but it holds off on announcing
>>devices until it has all necessary info. The drives may need to
>>be spun up, etc. I believe the printf happens before the device has
>>been opened and CAM blocks in the open until the device is really
>>ready for service.
> Actually, it works on a Celeron but fails on a P5. This is caused by the
> following bug suite (in approximately historical order):
> 1) IRQ13 interface was broken as designed.
> 2) Intel F00F bug.
> 3) Probe for (1) is not very well implemented. It hacks on the idt[]
>global to context swi
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
+*
+* 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
: slo
1 - 100 of 135 matches
Mail list logo
