Re: Strange SCSI related system hang
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 response to console, serial terminal or network. After a hard > reset the system came back online normally and is working normally again. > > Note that the machine had an uptime of 4 days, 14 hours before the problem > occured and it never happened before. > > Could this be a hardware problem? Perhaps. Is your WD drive getting hot? The ahc driver believes that, during a message out phase, the target simply dropped off the bus. It may be that the ahc driver did something to provoke that, but without a bus analyzer on the drive, it is hard to know. According to the progrom counter, we are waiting for the target to request the next byte at the time this occurs, but that request never comes. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Please test the PS/2 mouse driver patch
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/2 mice found on Thinkpads? 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. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Please test the PS/2 mouse driver patch
> >>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, there features are available in W*ndoes, but not in >FreeBSD? Yes. >There can be two possible explanations: > >a) These features are implemented in the device firmware level and >need to be explicitly activated by the driver software on the host >computer. W*ndows driver knows it, but our psm driver doesn't. This would be my guess. >b) These features are entirely implemented by the W*ndows driver >software. The TrackPoint itself is behaving just like the ordinary 2, >or 3, button pointing device. The W*ndows driver is so smart, our psm >driver isn't :-) Could be. PSM does see it as just a 'Generic' device, but I do notice some odd behavior if I move the trackpoint really fast. I've always assumed that this was from a spurious double-click event caused by pressing on the trackpoint, but I could be wrong. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel panics when initializing aic7895 controller at startup.
>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 kernel) >the error message >"ahc0: brkadrintr, Data-path Parity Error at seqaddr = 0x14e" >occurs. > >any ideas, that could help? I just want to make sure. Is your problem fixed now? -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AIC card not recognised?
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? -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird new SCSI diagnostics in -current
>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
Re: ahc panics and (da2:ahc2:0:2:0): data overrun detected in Data-Out phase. Tag == 0x25.
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 provided a buffer with any data in it. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
How do I get a PCCARD modem to work?
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
Re: How do I get a PCCARD modem to work?
>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... > >-Soren The pccard brokenness is not sio's fault. If I were following where our PCCARD support was going, I might take a stab at fixing this myself... Perhaps I'll learn more at FreeBSD-con. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AHC0 fireworks ?
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 logs) on my scsi chain. > I had never experienced such things in the near past (even if as an old > current user sometimes I see also worse things :-) > > Btw I don't see in the current mailing list threads about iussues on the > scsi subsystem recently so it can be a problem related to my hardware (even > if I didn't experience it before)... > > I append the logs of my system (sorry for the long post): > > Now I am trying to make a "blind" make world to see it changes something... Parity errors indicate that data integrity is compromised on your SCSI cable. Perhaps you bumped a connector, or a connector had been loose for a long time and has just shifted to the point of causing a failure. Open your case, reseat everything and see if the problem clears up. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Remote GDB *still* buggy...
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 body of the message
Re: Remote GDB *still* buggy...
>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 this... > >So did I. Are you just getting hangs? What kind of UART? On which side of the connection? I'm using my Thinkpad 770X as the GDB host and it says: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A On the machine I'm trying to debug, a Dell Precision 410, I have: sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A I suppose I could rip open the case to try and find what part they put on the motherboard for the 16550 support, but I'm had similar results with other machines. In GDB, you see some message about "malformed messages" and you can't seem to do anything. The other odd part is that speeds up to even 115200 work just fine up until the point that interrupt services are enabled. Then your hosed. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCSI->IDE
>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 peripheral driver will just know that for x protocol, only y commands are allowed. These fields are in the "CAM_NEW_TRAN_CODE" in current. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hmm.... Adaptec SCB timeouts on -current, can reproduce at will
>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 versions. See if Fujitsu has a firmware upgrade. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aic7880 prints some timeouts after recent commit (yesterday)
>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 problem. Unfortunately
I don't, so it has been difficult to get the workaround for this
particular hardware bug correct.
Can you see if this patch works for you?
--
Justin
Index: aic7xxx.c
===
RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx.c,v
retrieving revision 1.41.2.17
diff -c -r1.41.2.17 aic7xxx.c
*** aic7xxx.c 2001/03/12 14:57:40 1.41.2.17
--- aic7xxx.c 2001/03/12 20:30:40
***
*** 2006,2018
ahc_lookup_phase_entry(int phase)
{
struct ahc_phase_table_entry *entry;
! int i;
/*
* num_phases doesn't include the default entry which
* will be returned if the phase doesn't match.
*/
! for (i = 0, entry = ahc_phase_table; i < num_phases; i++) {
if (phase == entry->phase)
break;
}
--- 2006,2019
ahc_lookup_phase_entry(int phase)
{
struct ahc_phase_table_entry *entry;
! struct ahc_phase_table_entry *last_entry;
/*
* num_phases doesn't include the default entry which
* will be returned if the phase doesn't match.
*/
! last_entry = &ahc_phase_table[num_phases];
! for (entry = ahc_phase_table; entry <= last_entry; entry++) {
if (phase == entry->phase)
break;
}
Index: aic7xxx.seq
===
RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx.seq,v
retrieving revision 1.94.2.11
diff -c -r1.94.2.11 aic7xxx.seq
*** aic7xxx.seq 2001/03/12 14:57:43 1.94.2.11
--- aic7xxx.seq 2001/03/12 20:47:35
***
*** 2076,2082
testDFSTATUS, HDONE jnz dma_scb_hang_dma_done;
testDFSTATUS, HDONE jnz dma_scb_hang_dma_done;
testDFSTATUS, HDONE jnz dma_scb_hang_dma_done;
- testDFSTATUS, HDONE jnz dma_scb_hang_dma_done;
/*
* The PCI module no longer intends to perform
* a PCI transaction and HDONE has not come true.
--- 2076,2081
***
*** 2102,2107
--- 2101,2107
*/
not SINDEX;
add A, 5, SINDEX;
+ cmp A, 4je dma_finish;
jmp dma_scb_hang_fifo;
dma_scb_hang_dma_done:
and DFCNTRL, ~HDMAEN;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ahc driver: aic7892 no longer supported
>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 IDs of the files you are testing? There was a short window where the probe had some issues, but I don't recall if this is one of them. A "pciconf -l" from the working system would be useful too. I have lots of 29160s here so I should be able to reproduce this locally if there is still an issue. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc driver: aic7892 no longer supported
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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc driver: aic7892 no longer supported
> >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 the driver to find out where the attach is failing. Start by going into aic7xxx.c:ahc_init() and adding a printf to all of the early returns. If that doesn't catch it, do the same for aic7xxx_pci.c:aic7xxx_config(). I'll add this logging the next time I touch the driver. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc driver: aic7892 no longer supported (conflict with ATA)
>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. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc_intr - referenced scb not valid... panic for safety
>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 "unsubscribe freebsd-current" in the body of the message
Re: ahc_intr - referenced scb not valid... panic for safety
>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 >copy of the dump handy, but the offending controller is a 7895 (possibly a >7899 [39160] but I think the 7895 gets hit first) I really need the complete set of messages printed out prior to the panic. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc_intr - referenced scb not valid... panic for safety
>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 believe that its not quite acurate. Its really important that the messages be correct for me to figure out what is going wrong. Can you try one more time? Any chance you have a second computer that could be on the receiving end of a serial console to record the output verbatum? Also, your 4.3-BETA kernel seems to work okay. Can you give me the revision ids on all of the files in sys/dev/aic7xxx that were used to generate that kernel? Any chance you could step through the commits on the -stable branch from that date forward to see which ones broke the driver for you? The three subsequent commits are: revision 1.94.2.13 date: 2001/03/21 05:00:00; author: gibbs; state: Exp; lines: +7 -8 MFC rev 1.115. Don't allow our DMA engine to be re-enabled late in the shutdown phase of a data transfer by the idle loop fetching an S/G segment. Approved by:jkh revision 1.94.2.12 date: 2001/03/19 15:09:26; author: gibbs; state: Exp; lines: +4 -3 MFC: Fix phase table lookup and PCI 2.1 retry bug workaround. Approved by:jkh revision 1.94.2.11 date: 2001/03/12 14:57:43; author: gibbs; state: Exp; lines: +101 -70 MFC: Update to top of tree. You can feed the dates into cvs via the -D option to sync to particular points. Be sure to add 10 minutes to these dates to account for time stamp squew during the commit. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: Filesystem gets a huge performance boost
> 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 fraction of that size. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: Filesystem gets a huge performance boost
>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
Re: FW: Filesystem gets a huge performance boost
>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. This is like saying that there is nothing to be gained by making better use of available cache memory. I don't care that the cache is dynamic and caches the right things when the cache is effectively made so small that it doesn't cache my working set. Even with VMIO turned on for directories, Linux kicks our ass in caching meta-data unless you have a lot of memory. That sucks. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons mouse char range redefine proposal
>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 language correctly. Perhaps this could be configured directly via the language table or keymap? Whatever the solution, it should be automatic with the configuration of a locale change. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap_pager / SCB time outs?
> >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 transaction is already complete. This usually indicates (as the driver mentions) a problem with interrupts. Perhaps one of the SMPng guys may know why this is happening. At this point, I don't believe that it is an aic7xxx specific bug. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
>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 aic7xxx driver. You probably need to work with John Baldwin to trace the early execution of the system to see why it is haning up. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
>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 catch all interrupts. Most notably, you won't know if commands are completing. Command completions are much more prevalent than sequencer or scsi interrupts. >My current (freshly cvsupped sources) kernel with the printf()s in it >is pretty consistent in it's behavior: with SMP it hangs soon after >the 15 second SCSI delay and keystrokes will not cause it to continue >to boot. > >The order that they print out on the screen is this: > >message "Waiting 15 seconds for SCSI devices to settle" > >(approximately 15 second delay) > >26 times scsiint called with intstat = 0x4, status0 = 0, status = 0x88 > (SELTO & BUSFREE?) So 26 of the 30 possible target ID positions on the controller are empty. >2 times seqint called with instat = 0x71 (BAD_STATUS?) Two commands returned status other than 0 - most likely "check condition". >36 times seqint called with intstat = 0x61 (HOST_MSG_LOOP?) We negotiated transfer settings with some devices. These all seem quite normal. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
>> 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 gates all interrupt activity. I don't know that it will tell you why you are hung though. All that is clear is that interrupts at least work for a time. >btw, thanks very much for your help! Sure. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
>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 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 buffers that might contribute to the mapping. >Each mbuf has a single data buffer associated with >it (either the data area in the mbuf itself, or external storage). We're >not allowed to make assumptions about where these buffers are. Also, a >single ethernet frame can be fragmented across multiple mbufs in a list. > >So unless I'm mistaken, for each mbuf in an mbuf list, what we >have to do is this: > >- create a bus_dmamap_t for the data area in the mbuf using > bus_dmamap_create() Creating a dmamap, depending on the architecture, could be expensive. You really want to create them in advance (or pool them), with at most one dmamap per concurrent transaction you support in your driver. >- do the physical to bus mapping with bus_dmamap_load() bus_dmamap_load() only understands how to map a single buffer. You will have to pull pieces of bus_dmamap_load into a new function (or create inlines for common bits) to do this correctly. The algorithm goes something like this: foreach mbuf in the mbuf chain to load /* * Parse this contiguous piece of KVA into * its bus space regions. */ foreach "bus space" discontiguous region if (too_many_segs) return (error); Add new S/G element With the added complications of deferring the mapping if we're out of space, issuing the callback, etc. >- call bus_dmamap_sync() as needed (might handle copying if bounce > buffers are required) >- >- do post-DMA sync as needed (again, might require bounce copying) >- call bus_dmamap_unload() to un-do the bus mapping (which might free > bounce buffers if some were allocated by bus_dmamap_load()) >- destroy the bus_dmamap_t Chances are you are going to use the map again soon, so destroying it on every transaction is a waste. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
>
>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,
>> "cannot create a dma tag for control spaces");
>> free(isp->isp_xflist, M_DEVBUF);
>> free(pci->dmaps, M_DEVBUF);
>> return (1);
>> }
>>
You'll need to change the number of segments to match the max
supported by the card (or the max you will ever need). This
example made me realize that the bounce code doesn't deal with
multiple segments being copied into a single page (i.e. tracking
and using remaining free space in a page already allocated for
bouncing for a single map). I'll have to break loose some time
to fix that.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
>> >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 buffers >> that might contribute to the mapping. > >Yes yes, I understand that. But that's only if you want to map >a buffer that's larger than PAGE_SIZE bytes, like, say, a 64K >buffer being sent to a disk controller. What I want to make sure >everyone understands here is that I'm not typically dealing with >buffers this large: instead I have lots of small buffers that are >smaller than PAGE_SIZE bytes. A single mbuf alone is only 256 >bytes, of which only a fraction is used for data. An mbuf cluster >buffer is usually only 2048 bytes. Transmitted packets are typically >fragmented across 2 or 3 mbufs: the first mbuf contains the header, >and the other two contain data. (Or the first one contains part >of the header, the second one contains additional header data, >and the third contains data -- whatever.) At most I will have 1500 >bytes of data to send, which is less than PAGE_SIZE, and that 1500 >bytes will be fragmented across a bunch of smaller buffers that >are also smaller than PAGE_SIZE. Therefore I will not have one >dmamap with multiple segments: I will have a bunch of dmamaps >with one segment each. 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 that compose that packet and there is no reason that each chunk needs to have it own, and potentially expensive, dmamap. >> Creating a dmamap, depending on the architecture, could be expensive. >> You really want to create them in advance (or pool them), with at most >> one dmamap per concurrent transaction you support in your driver. > >The only problem here is that I can't really predict how many transactions >will be going at one time. I will have at least RX_DMA_RING maps (one for >each mbuf in the RX DMA ring), and some fraction of TX_DMA_RING maps. >I could have the TX DMA ring completely filled with packets waiting >to be DMA'ed and transmitted, or I may have only one entry in the ring >currently in use. So I guess I have to allocate RX_DMA_RING + TX_DMA_RING >dmamaps in order to be safe. Yes or allocate them in chunks so that the total amount is only as large as the greatest demand your driver has ever seen. >> With the added complications of deferring the mapping if we're >> out of space, issuing the callback, etc. > >Why can't I just call bus_dmamap_load() multiple times, once for >each mbuf in the mbuf list? Due to the cost of the dmamaps, the cost of which is platform and bus-dma implementation dependent - e.g. could be a 1-1 mapping to a hardware resource. Consider the case of having a full TX and RX ring in your driver. Instead of #TX*#RX dmamaps, you will now have three or more times that number. There is also the issue of coalessing the discontiguous chunks if there are too many chunks for your driver to handle. Bus dma is supposed to handle that for you (the x86 implementation doesn't yet, but it should) but it can't if it doesn't understand the segment limit per transaction. You've hidden that from bus dma by using a map per segment. >(Note: for the record, an mbuf list usually contains one packet >fragmented across multiple mbufs. An mbuf chain contains several >mbuf lists, linked together via the m_nextpkt pointer in the >header of the first mbuf in each list. By the time we get to >the device driver, we always have mbuf lists only.) Okay, so I haven't written a network driver yet, but you got the idea, right? 8-) >> Chances are you are going to use the map again soon, so destroying >> it on every transaction is a waste. > >Ok, I spent some more time on this. I updated the code at: > >http://www.freebsd.org/~wpaul/busdma I'll take a look. >The changes are: ... >- Added routines to allocate a chunk of maps in a singly linked list, > from which the other routines can grab them as needed. Are these hung off the dma tag or something? dmamaps may hold settings that are peculuar to the device that allocated them, so they cannot be shared with other clients of bus_dmamap_load_mbuf. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
> >> 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 that compose that packet and there is no reason >> that each chunk needs to have it own, and potentially expensive, dmamap. > >Maybe, but bus_dmamap_load() only lets you map one buffer at a time. >I want to map a bunch of little buffers, and the API doesn't let me >do that. And I don't want to change the API, because that would mean >modifying busdma_machdep.c on each platform, which is a hell that I >would rather avoid. bus_dmamap_load() is only one part of the API. bus_dmamap_load_mbuf or bus_dmamap_load_uio or also part of the API. They just don't happen to be impmeneted yet. 8-) Perhaps there should be an MD primitive that knows how to append to a mapping? This would allow you to write an MI loop that does exactly what you want. >> there are too many chunks for your driver to handle. Bus dma is >> supposed to handle that for you (the x86 implementation doesn't >> yet, but it should) but it can't if it doesn't understand the segment >> limit per transaction. You've hidden that from bus dma by using a >> map per segment. > >Ok, a slightly different question: what happens if I call >bus_dmamap_load() more than once with different buffers but with >the same dmamap? The behavior is undefined. >> >- Added routines to allocate a chunk of maps in a singly linked list, >> > from which the other routines can grab them as needed. >> >> Are these hung off the dma tag or something? dmamaps may hold settings >> that are peculuar to the device that allocated them, so they cannot >> be shared with other clients of bus_dmamap_load_mbuf. > >It's a separate list. The driver is reponsible for allocating the >head of the list, then it hands it to bus_dmamap_list_alloc() along >with the required dma tag. bus_dmamap_list_alloc() then calls >bus_dmapap_create() to populate the list. The driver doesn't have >to manipulate the list itself, until time comes to destroy it. Okay, but does this mean that bus_dmamap_load_mbuf no longer takes a dmamap? Drivers may want to allocate/manage the dmamaps in a different way. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Review: offsetof//fldoff patch.
> >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 "unsubscribe freebsd-current" in the body of the message
panic in vfinddev in -current
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,c0abe900,c0abed00,c877acec,c333f380) at ufs_vinit+0x4e ffs_vget(c0b01c00,1882,c877ad60,0,c7dc1900) at ffs_vget+0x267 ufs_lookup(c877adb8,c877adcc,c018e6fa,c877adb8,c7dc1900) at ufs_lookup+0x995 ufs_vnoperate(c877adb8,c7dc1900,c8770c03,c877aeb4,c877adc0 at ufs_vnoperate+15 vfs_cache_lookup(c877ae10,c877ae20,c0191804,c877ae10,c7dc1900) at vfs_cache_lookup+0x28a ufs_vnoperate(c877ae10,c7dc1900,c0b1c800,c877aeb4,c77e5840) at ufs_vnoperate+0x15 lookup(c877ae8c,c02b57d8,0,c77e5840,c77e5840) at lookup+0x290 namei(c877ae8c,c02b57d8,0,c77e5840,80b4340) at namei+0x178 lstat(c88e5840,c877af80,80b4348,80b5028,80b4300) at lstat+0x41 syscall2(2f,2f,2f,80b4300,80b5028) at syscall2+0x33c Xint0x80_syscall() at Xint0x80_syscall+0x1f Since addaliasu doesn't bother to check for NODEV, I take it this is a "can't happen" situation? -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
IP wierdness...
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 hosts, the system seems to drop all incoming connections. This even applies to ICMP traffic. For instance, a 4.1-stable machine can not ping my laptop, but the laptop can ping/telnet/ftp to the 4.1-stable machine. Looking at tcpdump traces on the laptop, it appears that the ICMP echo request is received correctly, but the system never responds. I'm not running IPSEC or ipfw, and all of the sysctls that seem to be related to filtering or rate limiting incoming packets look normal. I'm running -current as of a few hours ago, but this has been broken for me for at least a week in -current. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP wierdness...
>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 "unsubscribe freebsd-current" in the body of the message
Re: IP wierdness...
> >> >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 cable to the hub... I've done much better than that. I've tried how different switches at different locations (home and work) which just happened to have different cables. 8-) The funny thing is that the version of this card that lacks a modem seems to work just fine. Windows can also talk to the card that is having problems under FreeBSD without any difficulty. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
>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 "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
>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 if there is something at slot 0 and only then attempt to probe for sub-devices on the bus. 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 we blindly access them. For this to all work with the VL ahc cards, the EISA code will have to release all resources associated with empty slots and the ahc driver will have to grow an ISA front end. I'm willing to help out on this work (still have a functional EISA machine), but I stopped short last time over concern on how to support Alpha/PA-RISC machines that might have multiple EISA busses. >I've got uncommitted code that ties it to the ELCR. Is this stuff documented anywhere? I've always wanted to gain access to the aic7xxx card's nonvolatile region in the ELCR, but I could never find out how to do this. >Bus front end code shouldn't have to know about level/edge triggered IRQs. So long as the ELCR is guaranteed to work. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
>> 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 we blindly access them. For this to all work with >> the VL ahc cards, the EISA code will have to release all >> resources associated with empty slots and the ahc driver will >> have to grow an ISA front end. > >The EISA code currently doesn't reserve resources for empty slots. > >I'd like to make the bus driver reserve all EISA specific address space >though. This would prevent an ISA card that just happens to use an EISA like identification scheme from attaching after EISA. Unfortunately, the 2842VL card does this. >> I'm willing to help out on this work (still have a functional EISA >> machine), but I stopped short last time over concern on how to support >> Alpha/PA-RISC machines that might have multiple EISA busses. > >I can't see how multiple EISA busses would be possible. While a PCI-EISA >bridge might make it easier, you've only got one valid set of IO port >ranges and ELCR ports. I suppose you could remap the address space but >who needs more than 10 EISA slots anyway? I just want to make sure that we at least support the EISA Alpha machines. I honestly don't know how they were set up. >> Is this stuff documented anywhere? I've always wanted to gain access >> to the aic7xxx card's nonvolatile region in the ELCR, but I could >> never find out how to do this. > >Humm... > >Try ftp://ftp.jurai.net/users/winter/eisabook.zip I can't seem to fetch it. Permission denied. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
>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. The ahc VL cards require that their ID0 register be written too prior to reading the ID byte. This isn't required for true EISA cards and may prove harmful to other devices that just happen to be in that space. For instance, some PCI devices can be identified as EISA cards if you probe the full EISA bus blindly. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
>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 the message
Re: vx driver patch
>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 because the ID is not in the table of known EISA IDs. Joerg can probably give additional examples of this problem. This is one reason we don't probe all 15 slots yet. If we reserved the address space properly before doing the probe and also only performed the probe if the mainboard ID is valid, this wouldn't be an issue any longer. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
>>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 referenced while the chip is in a paused state. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
> >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 cards are identified using ISA probe techniques in all cases I'm aware of. It just turns out that the 2842 uses a scheme that is very similar to that of an EISA card. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
>> >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 cards are identified using ISA probe >> techniques in all cases I'm aware of. It just turns out that the 2842 >> uses a scheme that is very similar to that of an EISA card. > >As a backgrounder for other-than-Justin, Adaptec has a habit of >making multipurpose ROMs that sit on different types of devices, >so that they don't have to maintain multiple images. It's the >EISA stuff in these ROMs that causes a non-EISA BIOS based EISA >probe to incorrectly identify them as EISA. This is not correct. You are making this all much more confusing than it is. The 2842 will not be identified as an EISA device by the system BIOS or any other OS but FreeBSD. This is because you must *write* to the "EISA like" ID registers prior to reading them in order for them to return somthing other than 0. So, if our EISA probe stops poking the ID registers prior to reading them, the 2842 will not be seen. Secondly, there are some PCI systems that lack EISA slots entirely, but map device register space in traditionally EISA slot address ranges. Some of the aic78xx cards just happen to have registers in these locations that have values that satisfy an EISA probe. Of course, you're not supposed to be poking them in this way once the card is setup and, should the EISA code honor address reservations made by the system, as well as whether an EISA mainboard controller is found, these conflicts just wouldn't happen. All other VLB cards I know of look just like their ISA counterparts from a probe perspective. They shouldn't enter into this discussion. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
> >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
FreeBSD Foundation: Examples of FreeBSD as teaching aid/research plat
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 thing that would help us to explain the nature of FreeBSD and how it is used by the public is to enumerate some specific examples of how FreeBSD is used as either a teaching aid or a research platform by educational institutions. If possible, please include a contact name, email, or phone number so we can ask additional questions if necessary. Thanks in advance for your help! Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD Foundation: Examples of FreeBSD as teaching aid/research plat
>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 good reason), so a conventional 'To' line didn't work. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD Foundation: Examples of FreeBSD as teaching aid/research plat
>-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 to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic - probably aic7810/398X related
>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: aic7xxx.c
===
RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx.c,v
retrieving revision 1.60
diff -c -r1.60 aic7xxx.c
*** aic7xxx.c 2000/11/12 05:19:46 1.60
--- aic7xxx.c 2000/11/12 21:11:43
***
*** 3689,3694
--- 3689,3696
struct scb_data *scb_data;
scb_data = ahc->scb_data;
+ if (scb_data == NULL)
+ return;
switch (scb_data->init_level) {
default:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Cardbus fixes
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 registers are probed. It might be even better to defer this until a particular mapping is activated and to disable that type of access when a new register is activated. 2) The PCI spec is very explicit about how mapping registers and the expansion ROM mapping register should be probed. This patch makes cardbus_add_map() follow the spec. 3) The PCI spec allows a device to use the same address decoder for expansion ROM access as is used for memory mapped register access. This patch carefully enables and disables ROM access along with resource (de)activiation. 4) The cardbus CIS code treats the CIS_PTR as a mapping register if it is mentioned in the CIS. I don't have a spec handy to understand why the CIS_PTR is mentioned in the CIS, but allocating a memory range for it is certainly bogus. My patch ignores bar #6 to prevent the mapping. 5) The CIS code allocated duplicate resources to those already found by cardbus_add_resources(). The fix is to pass in the bar computed from the CIS instead of the particular resource ID for that bar, so bus_generic_alloc_resource succeeds in finding the old resource. It seems somewhat strange that we have to have two methods for finding and activating the mapping registers. Isn't one method sufficient? 6) cardbus_read_exrom_cis() failed to advance correctly to higer rom images. To effect the fix, the cis_ptr value must be provided to the different CIS reading methods, unaltered. 7) The CIS code seems to use the wrong bit to determine rather a particular register mapping is for I/O or memory space. From looking at the two cards I have, it seems TPL_BAR_REG_AS should be 0x10 instead of 0x08. Otherwise, all registers that should be I/O mapped gain a second mapping in memory space. 8) The cardbus bridge code leaves memory space prefetching enabled. Prefetching is only allowed if the target device indicates (through its mapping register) that prefetching is allowable. My patch simply disables prefetching and includes code to detect this capability and pass an RF flag to enable it, but nothing more. 9) The pccbb code was impoperly handling the I/O and mem range limit registers. The limit register indicates the highest valid address in the window, not the first invalid address outside the window. One last thing that is started here is an attempt to rely more heavily on PCI register definitions and eventually functions, to get things done. The cardbus code duplicates a lot of functionality that is already available in the pci code (mapping register size/type detection). One other thing that struck me while I was looking at this was that the resource manager should be providing the "resource pooling" that pccbb_cardbus_auto_open() emulates. Although the cardbus bridges we support only provide 4K granularity for memory mapped windows, things like external rom access often can be mapped on 2K boundaries. This could allow the resource manager to allocate a range that doesn't appear to overlap with another allocation but does due to the bridges constraints. I might look into adding the concept of hierarchical resource pools to the resource manager so that, for example, the cardbus bridges pool will always grow in 4K increments from its parent resource pool. The parent would then grow according to its own requirements, etc. -- Justin Index: dev/cardbus/cardbus.c === RCS file: /usr/cvs/src/sys/dev/cardbus/cardbus.c,v retrieving revision 1.2 diff -c -r1.2 cardbus.c *** dev/cardbus/cardbus.c 2000/10/18 03:21:48 1.2 --- dev/cardbus/cardbus.c 2000/11/19 01:41:58 *** *** 114,121 int rid, u_long start, u_long count); static int cardbus_get_resource_method(device_t dev, device_t child, int type, int rid, u_long *startp, u_long *countp); ! static void cardbus_add_map(device_t bdev, device_t dev, ! pcicfgregs *cfg, int reg); static void cardbus_add_resources(device_t dev, pcicfgregs* cfg); static void cardbus_release_all_resources(device_t dev, struct resource_list *rl); --- 114,121 int rid, u_long start, u_long count); static int cardbus_get_resource_method(device_t dev, device_t child, int type, int rid, u_long *startp, u_long *countp); ! static int cardbus_add_map(device_t bdev, device_t dev, ! pcicfgregs *cfg, int reg); static void c
Re: Cardbus fixes
>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 message
Re: Getting at cardbus CIS data from inside drivers
>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 facilitates walking the CIS that can be used at anytime. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
>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 to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
>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 might want a ftell sort of >interface as well. I'll likely punt on the seek/ftell part. I think it was Jonathan that mentioned that at times when you read one entry you want to skip to another entry that it may reference. I don't have the spec to know, but that is why I thought the flexibility of having a seeking interface might be necessary. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
>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 to look at the CIS entries for the >other function of the card for various reasons (some of them need to >know what kind of modem is present, iirc, to initalize some things in >a non-standard way, the example was the NetBSD driver mhz, iirc). I >don't wish to preclude that. 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 that region. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cardbus woes
>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 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. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cardbus woes
>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 a mechanism to ensure that you are no-longer executing in your interrupt handler prior to destroying the softc. What you really want on detach (not only for pccbb, but in general), is a way to kill your ithread via bus_teardown_intr. Since we only provide a single ithread per shareable interrupt source, this wouldn't quite work, but you get the general idea. Can anyone think of another general "synchronization method" for a case where the second event may never happen again? Even if you check in the detach routine to see if an interrupt is pending in hardware for your device, this won't tell you if your interrupt thread has already been dispatched but the interrupt source has gone away (card was removed, so interrupt line is dead). Hmmm. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lost second channel of AIC-7896
>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 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? -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lost second channel of AIC-7896
>> 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. Are you sure that your drives aren't just attached to the second port? Have you tried a current since Friday? I committed a fix for the original problem that was reported. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCSI CD recorder no longer attached; minor issues
>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
===
RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx.c,v
retrieving revision 1.63
diff -c -r1.63 aic7xxx.c
*** dev/aic7xxx/aic7xxx.c 2001/01/05 19:15:36 1.63
--- dev/aic7xxx/aic7xxx.c 2001/01/08 04:48:36
***
*** 487,494
printf("Sending Sense\n");
}
#endif
! sg->addr = ahc->scb_data->sense_busaddr
! + (hscb->tag*sizeof(struct scsi_sense_data));
sg->len = ahc_get_sense_bufsize(ahc, scb);
sg->len |= AHC_DMA_LAST_SEG;
--- 487,493
printf("Sending Sense\n");
}
#endif
! sg->addr = ahc_get_sense_bufaddr(ahc, scb);
sg->len = ahc_get_sense_bufsize(ahc, scb);
sg->len |= AHC_DMA_LAST_SEG;
Index: dev/aic7xxx/aic7xxx_freebsd.c
===
RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx_freebsd.c,v
retrieving revision 1.16
diff -c -r1.16 aic7xxx_freebsd.c
*** dev/aic7xxx/aic7xxx_freebsd.c 2000/12/20 01:11:37 1.16
--- dev/aic7xxx/aic7xxx_freebsd.c 2001/01/08 04:46:28
***
*** 337,343
*/
memset(&ccb->csio.sense_data, 0, sizeof(ccb->csio.sense_data));
memcpy(&ccb->csio.sense_data,
! &ahc->scb_data->sense[scb->hscb->tag],
(scb->sg_list->len & AHC_SG_LEN_MASK)
- ccb->csio.sense_resid);
scb->io_ctx->ccb_h.status |= CAM_AUTOSNS_VALID;
--- 337,343
*/
memset(&ccb->csio.sense_data, 0, sizeof(ccb->csio.sense_data));
memcpy(&ccb->csio.sense_data,
! ahc_get_sense_buf(ahc, scb),
(scb->sg_list->len & AHC_SG_LEN_MASK)
- ccb->csio.sense_resid);
scb->io_ctx->ccb_h.status |= CAM_AUTOSNS_VALID;
Index: dev/aic7xxx/aic7xxx_inline.h
===
RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx_inline.h,v
retrieving revision 1.9
diff -c -r1.9 aic7xxx_inline.h
*** dev/aic7xxx/aic7xxx_inline.h2000/12/20 01:11:37 1.9
--- dev/aic7xxx/aic7xxx_inline.h2001/01/08 04:55:49
***
*** 200,205
--- 200,211
static __inline void ahc_swap_with_next_hscb(struct ahc_softc *ahc,
struct scb *scb);
static __inline void ahc_queue_scb(struct ahc_softc *ahc, struct scb *scb);
+ static __inline struct scsi_sense_data *
+ ahc_get_sense_buf(struct ahc_softc *ahc,
+ struct scb *scb);
+ static __inline uint32_t
+ ahc_get_sense_bufaddr(struct ahc_softc *ahc,
+ struct scb *scb);
/*
* Determine whether the sequencer reported a residual
***
*** 344,349
--- 350,374
if ((ahc->features & AHC_AUTOPAUSE) == 0)
unpause_sequencer(ahc);
}
+ }
+
+ static __inline struct scsi_sense_data *
+ ahc_get_sense_buf(struct ahc_softc *ahc, struct scb *scb)
+ {
+ int offset;
+
+ offset = scb - ahc->scb_data->scbarray;
+ return (&ahc->scb_data->sense[offset]);
+ }
+
+ static __inline uint32_t
+ ahc_get_sense_bufaddr(struct ahc_softc *ahc, struct scb *scb)
+ {
+ int offset;
+
+ offset = scb - ahc->scb_data->scbarray;
+ return (ahc->scb_data->sense_busaddr
+ + (offset * sizeof(struct scsi_sense_data)));
}
/** Interrupt Processing **/
Re: SOLVED: SCSI CD recorder no longer attached; minor issues
>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 the message
Re: YES! laptop installing
>: 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 nic address the same way. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: YES! laptop installing
>: 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 the mac address wrong for one of my xircom cards but not so wrong as to make it non-functional. The other xircom card (the type-III with modem) seemed to end up with a mac address that was considered invalid by many switches. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc messages
>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" printf in aic7xxx.c? I'm trying to reproduce this here as well. I don't know what I've changed that could cause the qoutfifo to become confused. How many drives do you have on the controller? -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc messages
>> >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 latest checkin corrects the problem. Please let me know if you experience any additional difficulties. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
>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 devices that don't have a media lock. Some devices will only tell you that they are write protected on the first write, etc. For the devices where we can tell, we should make the check in open, but not rely on that catching all cases where a driver will return EACCESS. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
>"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 protect? Even pulling out the media for a valid filesystem shouldn't panic. All I/O to that volume should fail and your system may become next to useless, but the system shouldn't panic. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Changes to ahc driver broke kernel
>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. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Problem booting from aic7890/91 Ultra2 SCSI
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.15 that was fixed a day or so later. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
>> # 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 checkin, but cannot see why it would not properly prevent the messages from being displayed. Perhaps Mikhail would be willing to instrument the code and determine why it doesn't work properly? -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How to add a new bootdevice to the new boot code ???
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 > passed in major# as describing the device rather than specifying > the driver. Why not have the boot blocks pass in a device 'name' rather than a major number. If the goal is to ditch major numbers entirely with a properly working DEVFS, then using major numbers in the new boot loader seems to be the wrong way to go. Until DEVFS is a reality, the kernel will still need to perform a name to major number translation, but it should be left up to the kernel. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How to add a new bootdevice to the new boot code ???
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 layer ontop of the existing > wd driver or of cause on top of the new I'm doing, but all it adds > is overhead, both performance wise and codesize wise. There is nothing > that prohibits having both of cause, but it is not a priority for me > to add more complexity into the picture before everything else is done. 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 - Peripheral driver to device routing - debugging/tracing facilities - an extensible error recovery framework - an understanding of command queuing (also relevant for ATAPI) - understanding of hot plug events - an aplication pass-thru interface The question about translation layers is secondary and I would likely choose to not introduce a translation at all. Issuing pure ATAPI commands to atapi devices at the peripheral driver level is somthing that CAM could easily do. I would probably choose to merge ATAPI functionality into the da driver to avoid duplicated code and to ensure that bug fixes only need to be performed in one place. After all, the machinery for talking to an ATAPI or SCSI disk is very similar (If the disk says it needs to be spun up, spin it up; if we have too many transactions outstanding and fear tag starvation, send an ordered tag; when we close the disk or panic, synchronize its cache to stable media; etc. etc.) even if the command op codes and format are slightly different. But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How to add a new bootdevice to the new boot code ???
>> 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 >> > passed in major# as describing the device rather than specifying >> > the driver. >> >> Why not have the boot blocks pass in a device 'name' rather than a >> major number. If the goal is to ditch major numbers entirely with >> a properly working DEVFS, then using major numbers in the new boot >> loader seems to be the wrong way to go. Until DEVFS is a reality, >> the kernel will still need to perform a name to major number translation, >> but it should be left up to the kernel. > >Because there's no way to work out a name either. If I explicitly say: 1:foobar(0,a)/kernel there certainly is a way to work out the name. Perhaps in the autoboot case you'll have to guess, but it would be nice if the current boot mechanism allowed user intervention as a way to boot a kernel with an unknown bdev. >All the loader has to go on is the BIOS unit number and the disklabel, >the latter of which can't be relied on to be up-to-date (ie. it >reflects what the disk was when it was laid out, not what some nominal >kernel is going to call it). Well, the disklabel format should be revamped so that we can tag devices in a unique fashion (user's pet name for the partition plus a 128bit random number perhaps). This would allow the boot loader to alway tell the kernel unambiguously how to find the root device. It would also allow us to ensure that the attach order for all devices with a BSD label matched the BIOS probe order. I would also love to be able to mount volumes by the name that I've picked for them rather than by device node too - it would practically eliminate the need for hard wiring of devices. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How to add a new bootdevice to the new 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 >shared, while at compile time it built two seperate subsystems that were >compiled specifically for the target peripheral bus with definitions to >suit each so that "translation" was never used. The plan has always been to migrate the SCSI knowledge in the XPT layer into a 'personality' module leaving the generic portions of the CAM XPT intact. The personalities would be compiled in using the "atapibus0" and "scbus0" keywords in config. I don't think it would be that hard, but it would require time I don't have right now. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How to add a new bootdevice to the new boot code ???
>> 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 functionality. >> - 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.freebsd.org/~gibbs/cam.html for the start of a discussion of these features and why transaction routing was implemented this way. >> - debugging/tracing facilities >Well, there is a little of that allready, more to come. Right. Its duplicated functionality. >> - an extensible error recovery framework > >Well, here is room for improvement, I haven't put any real error >checking code in there by now, it will just fail and report that >for now. This is alpha level code remember. But how will you deal with errors especially when there are overlapped commands? CAM already deals with this in a very clean way. When an error occurs, the controller driver freezes the queue of commands to the erring device, notifies the peripheral driver of the error, and allows the driver to insert error recovery actions before any other commands are ever released to the device. This even allows you to toss back unexecuted but queued commands at the controller level to be reinserted into the transport layer's command queue to ensure proper ordering. This all plays off of the priority features inherent in how transactions are queued. Command queuing was a major factor in why I wrote the CAM code. Solving these issues is not trivial. >> - an understanding of command queuing (also relevant for ATAPI) > >Hmm, well, yes, but I'm not sure that what ATA/ATAPI has to offer >here is comaptible with the CAM framwork. I plan to support tagged >queueing on ATA disks though. CAM only knows that multiple commands may be outstanding at a time and that they must be marked with serial numbers for proper replay when an error occurs. The specifics of how multiple transactions are specified is something that can be completely isolated into the 'personality' module and as a protocol between the peripheral drivers and the controller drivers. >> - understanding of hot plug events > >This really isn't an issue on ATA/ATAPI devices in most cases, >but in the mobile world there is a need for this, but that is >already being worked on. We need alot of work in other places >in the kernel, before this can be really utilized though. So why invent a new notification and cleanup strategy when the CAM one has already been developed and tested in the SCSI world? >> - an aplication pass-thru interface > >Hmm, what for ?? cdrecord, a userland disk format utility, camcontrol functionality, etc. etc. >ATAPI commands could esily be passed through, but I'd like a >driver to be in charge here, and besides we allready have drivers >for most existing ATAPI HW. The pass-thru driver is in charge in the CAM world. Is this not sufficient? Sure, there needs to be locking primitives so that drivers competing for the same device do not step on each others toes, but this is already specified by CAM and should be only a day or so of effort to implement. >ATAPI has nothing to do in the da driver, well maybe for ZIP/LS120 >drives, but disks are ATA, and that needs translation. Why does it need translation? Why not simply issue ATA commands right through the CAM Transport layer. Perhaps you use a function table in your peripheral driver to build the right CAM Control Blocks to send for a particular device. Perhaps you have a completely different peripheral driver for ATA and SCSI devices. That is up to the implementor. My choice would be to have one peripheral driver here, but CAM doesn't tie your hands one way or the other. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How to add a new bootdevice to the new boot code ???
>> >> - 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.freebsd.org/~gibbs/cam.html > >That will probably need changes to work with ATA4's tagged queing at >least... I just read the ATA5 draft (couldn't find the last ATA4 draft at the wdc website). I don't see any issues here other than the fact that the effect of overlapped commands on data integrity seems to be unspecified. Are they always handled in FIFO order? Can reads be seek optimized? What happens in the case of a queued write after a queued read to the same location? My hope is that, since the spec does not allow you to specify the sorting restrictions on a per request basis as you can in SCSI, FIFO ordering is implied. They even mention that the feature is intended to overlap command processing latency without mentioning the possibility of other optimizations, so perhaps this really is the case. Too bad they didn't just define the two bits necessary (and left as spares in the tag specification register) to allow the same queuing feature set as SCSI. >> Command queuing was a major factor in why I wrote the CAM code. Solving >> these issues is not trivial. > >Agreed, but have you looked at how ATA4 handles queing ?? Yes. >> >> - an aplication pass-thru interface >> > >> >Hmm, what for ?? >> >> cdrecord, a userland disk format utility, camcontrol functionality, >> etc. etc. > >He he, ATAPI dont need cdrecord as all ATAPI burners use the same >command set (MMC), where your average SCSI burner has its own >propietary command set (well, the ATA/ATAPI guys did get one thing >right :) ), Almost all newer SCSI cd burners use MMC now and cdrecord supports MMC devices. Why write another utility if there is already one that speaks the necessary language that our users are familiar with? >OK, I'm done discussing this (se my other mail), I'd rater spend >my (very limitted) time productively. Fair enough. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Call for Review: Suport for BIO_ORDERED bios
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. FreeBSD has offered these semantics before. I added support for ordered bufs over a decade ago, but with no consumers of that interface in the tree, it was removed. Today the landscape has changed: ZFS requires ordered semantics to be able to safely commit transactions, Jeff Roberson has talked of modifying UFS to take advantage of this feature to speed up soft-updates, Linux ext3/4 filesystems will take advantage of this feature, and VMs using storage exported via Xen's blkback interface can also querry for this feature. My changes are sufficient to allow ZFS and the Xen blkback driver (more on that driver in another email) to perform ordered I/O. Additional, mostly trivial, changes will be required to pass ordering information through the buf interface if/when other buf clients grow to use this capability. Are there any comments/concerns about these changes before I commit them? Thanks, Justin Change 216125 by just...@spectrabsd.import on 2010/07/29 16:24:07 Add the BIO_ORDERED flag for struct bio and update bio clients to use it. sys/sys/bio.h: Add BIO_ORDERED as bit 4 of the bio_flags field in struct bio. sys/kern/subr_disk.c: In bioq_disksort(), bypass the normal sort for bios with the BIO_ORDERED attribute and instead insert them into the queue with bioq_insert_tail(). bioq_insert_tail() not only gives the desired command order during insertion, but also provides barrier semantics so that commands disksorted in the future cannot pass the just enqueued transaction. sys/cam/ata/ata_da.c: sys/cam/scsi/scsi_da.c Use an ordered command for SCSI/ATA-NCQ commands issued in response to bios with the BIO_ORDERED flag set. sys/cam/scsi/scsi_da.c Use an ordered tag when issuing a synchronize cache command. Wrap some lines to 80 columns. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c sys/geom/geom_io.c Mark bios with the BIO_FLUSH command as BIO_ORDERED. Affected files ... ... //depot/SpectraBSD/head/sys/cam/ata/ata_da.c#5 edit ... //depot/SpectraBSD/head/sys/cam/scsi/scsi_da.c#4 edit ... //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c#3 edit ... //depot/SpectraBSD/head/sys/geom/geom_io.c#4 edit ... //depot/SpectraBSD/head/sys/kern/subr_disk.c#3 edit ... //depot/SpectraBSD/head/sys/sys/bio.h#3 edit Change 216126 by just...@spectrabsd.import on 2010/07/29 16:35:46 Correct bioq_disksort so that bioq_insert_tail() offers barrier semantic. The barrier semantics of bioq_insert_tail() were broken in two ways: o In bioq_disksort(), an added bio could be inserted at the head of the queue, even when a barrier was present, if the sort key for the new entry was less than that of the last queued barrier bio. o The last_offset used to generate the sort key for newly queued bios did not stay at the position of the barrier until either the barrier was de-queued, or a new barrier (which updates last_offset) was queued. When a barrier is in effect, we know that the disk will pass through the barrier position just before the "blocked bios" are released, so using the barrier's offset for last_offset is the optimal choice. sys/geom/sched/subr_disk.c: sys/kern/subr_disk.c: o Update last_offset in bioq_insert_tail(). o Only update last_offset in bioq_remove() if the removed bio is at the head of the queue (typically due to a call via bioq_takefirst()) and no barrier is active. o In bioq_disksort(), if we have a barrier (insert_point is non-NULL), set prev to the barrier and cur to it's next element. Now that last_offset is kept at the barrier position, this change isn't strictly necessary, but since we have to take a decision branch anyway, it does avoid one, no-op, loop iteration in the while loop that immediately follows. Affected files ... ... //depot/SpectraBSD/head/sys/geom/sched/subr_disk.c#3 edit ... //depot/SpectraBSD/head/sys/kern/subr_disk.c#4 edit --- //depot/vendor/FreeBSD/head/sys/cam/ata/ata_da.c2010-07-25 15:43:52.0 -0600 +++ /home/justing/perforce/FreeBSD/head/sys/cam/ata/ata_da.c2010-07-25 15:43:52.0 -0600 @@ -874,7 +8
CFT - Xen infrastructure and block I/O improvements
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 larger and more outstanding I/Os. o A completely rewritten block back driver with support for fronting I/O to both raw devices and files. o General cleanup and documentation of the XenBus and XenStore support code. o Robustness and performance updates for the block front driver. o Fixes to the netfront driver. Some of these changes have already been pushed back into FreeBSD, but the bulk of them need additional testing, especially under i386 PV, before they can be committed. If you work in the Xen area, I'd appreciate your review and/or testing of these changes. http://people.freebsd.org/~gibbs/FreeBSD-head-xen-diffs_2010_09_16.txt Thanks, Justin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT - Xen infrastructure and block I/O improvements
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 Xen support. These include: ... >> Justin, this is quite a big diff (16k lines). I wonder if you can create >> separate diffs (xenstore, blkback, xenbus, etc.) for easier review and >> commenting. > > '... and comment'. The bulk of the patch is due to code reorganization. Unfortunately SVN doesn't reflect the copies properly in a diff, but at least the diff will apply properly even in a non-SVN backed source tree. This original patch should be the best for testers. The following SVN operations were made to the source tree to clean up it's organization and to import functionality from the vendor (1 file): # Does not apply to FreeBSD's NewBus method for dealing with XenBus devices svn delete sys/xen/xenbus/init.txt # Linux version of backend XenBus service routines. Never ported to FreeBSD. # OBE: See xenbusb.c, xenbusb_if.m, xenbusb_front.c xenbusb_back.c svn delete sys/xen/xenbus/xenbus_probe_backend.c # Split XenStore into its own tree. XenBus is a software layer built on top # of XenStore. The old arrangement and the naming of some structures and # functions blurred these lines making it difficult to discern what services # are provided by which layer and what times these services are available # (e.g. during system startup and shutdown). mkdir sys/xen/xenstore svn add sys/xen/xenstore svn move sys/xen/xenbus/xenbus_dev.c sys/xen/xenstore/xenstore_dev.c svn copy sys/xen/xenbus/xenbusvar.h sys/xen/xenstore/xenstorevar.h svn move sys/xen/xenbus/xenbus_xs.c sys/xen/xenstore/xenstore.c # Split up XenBus code into methods available for use by client # drivers (xenbus.c) and code used by the XenBus "bus code" to # enumerate, attach, detach, and service bus drivers. svn move sys/xen/xenbus/xenbus_client.c sys/xen/xenbus/xenbus.c svn move sys/xen/xenbus/xenbus_probe.c sys/xen/xenbus/xenbusb.c svn copy sys/xen/xenbus/xenbusb.c sys/xen/xenbus/xenbusb.h # Merged with xenstore.c svn delete sys/xen/xenbus/xenbus_comms.c svn delete sys/xen/xenbus/xenbus_comms.h # Merged with new XenBus control driver mkdir sys/dev/xen/control svn add sys/dev/xen/control svn move sys/xen/reboot.c sys/dev/xen/control/control.c # New file from Xen vendor with macros and structures used by # a block back driver to service requires from a VM running a # different ABI (e.g. amd64 back with i386 front). svn add sys/xen/blkif.h These alone account for 6k lines of svn diff. A diff against a tree with these operations already made may make more sense to a reviewer. You can download this diff from here: http://people.FreeBSD.org/~gibbs/FreeBSD-head-xen_post-svn-ops_2010-09-17_diffs.txt It isn't much shorter since the additional context has amplified the changes. The bulk is largely caused by refactoring, and comments. It will probably be easier to just review the files in sys/xen/xenstore and sys/xen/xenbus in their entirety, but the comments bellow (boiled down from our SCM system), when coupled with the diffs, should give you enough information to understand the intentions behind the changes. -- Justin sys/conf/files: Adjust kernel build spec for new XenBus/XenStore layout and added Xen functionality. sys/dev/xen/balloon/balloon.c: sys/dev/xen/netfront/netfront.c: sys/dev/xen/blkfront/blkfront.c: sys/xen/xenbus/... sys/xen/xenstore/... o Rename XenStore APIs and structures from xenbus_* to xs_*. o Adjust to use of M_XENBUS and M_XENSTORE malloc types for allocation of objects returned by these APIs. o Adjust for changes in the bus interface for Xen drivers. sys/dev/xen/blkback/blkback.c: Rewrite the Block Back driver to attach properly via newbus, operate correctly in both PV and HVM mode regardless of domain (e.g. can be in a DOM other than 0), and to deal with the latest metadata available in XenStore for block devices. Allow users to specify a file as a backend to blkback, in addition to character devices. Use the namei lookup to figure out whether it's a device node or a file, and use the appropriate interface. One current issue with the file interface is that we're effectively limited to having a single command at a time outstanding. To get around this, we may need to try using the vnode pager more directly, or perhaps coming up with a direct interface into ZFS. (i.e. something similar to zvols, but without the performance issues.) This will impact reads more than writes, because writes are cached but with random reads you have to go all the way down to the disk, so you suffer t
[PATCH] OpenSolaris/ZFS: C++ compatibility
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 changes modify files that come from OpenSolaris, I want to be
sure I understand the project's policies regarding divergence from
the vendor before I check them in. All of the changes save one should
be trivial to merge with vendor changes and I will do that work for the
v28 import. Is there any reason I should not commit these changes?
Thanks,
Justin
Change 477353 by justing@justing-ns1 on 2011/02/04 10:11:30
Remove C constructs that are incompatible with C++ from various
OpenSolaris and ZFS header files. These changes are sufficient
to allow a C++ program to use the libzfs library.
Note: The majority of these files already included 'extern "C"'
declarations, so the intention of providing C++ compatibility
already existed even if it wasn't provided.
cddl/compat/opensolaris/include/assert.h:
Wrap our compatibility assert implementation in
'extern "C"'. Since this is a compatibility header
I matched the Solaris style of doing this explicitly
rather than rely on FreeBSD's __BEGIN/END_DECLS macro.
sys/cddl/compat/opensolaris/sys/kstat.h:
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h:
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa.h:
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h:
Place comments around parameters in function declarations
that conflict with C++ keywords.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_ioctl.h:
In C, nested structures are visible in the global namespace,
but in C++, they take on the namespace of the structure in
which they are contained. Flatten nested structure
definitions within struct zfs_cmd so these structures are
visible in the global namespace when compiled in both
languages.
Affected files ...
... //depot/SpectraBSD/head/cddl/compat/opensolaris/include/assert.h#4 edit
... //depot/SpectraBSD/head/sys/cddl/compat/opensolaris/sys/kstat.h#4 edit
...
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h#4
edit
...
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa.h#4
edit
...
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_ioctl.h#4
edit
...
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h#6
edit
Differences ...
//depot/SpectraBSD/head/cddl/compat/opensolaris/include/assert.h#4 (text)
@@ -43,6 +43,10 @@
#include
#include
+#ifdef __cplusplus
+extern "C" {
+#endif
+
static __inline void
__assert(const char *expr, const char *file, int line)
{
@@ -52,4 +56,9 @@
abort();
/* NOTREACHED */
}
+
+#ifdef __cplusplus
+}
+#endif
+
#endif /* !_ASSERT_H_ */
//depot/SpectraBSD/head/sys/cddl/compat/opensolaris/sys/kstat.h#4 (text)
@@ -58,7 +58,7 @@
} value;
} kstat_named_t;
-kstat_t *kstat_create(char *module, int instance, char *name, char *class,
+kstat_t *kstat_create(char *module, int instance, char *name, char */*class*/,
uchar_t type, ulong_t ndata, uchar_t flags);
void kstat_install(kstat_t *ksp);
void kstat_delete(kstat_t *ksp);
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h#4
(text)
@@ -131,7 +131,7 @@
void dsl_pool_memory_pressure(dsl_pool_t *dp);
void dsl_pool_willuse_space(dsl_pool_t *dp, int64_t space, dmu_tx_t *tx);
int dsl_free(zio_t *pio, dsl_pool_t *dp, uint64_t txg, const blkptr_t *bpp,
-zio_done_func_t *done, void *private, uint32_t arc_flags);
+zio_done_func_t *done, void */*private*/, uint32_t arc_flags);
void dsl_pool_ds_destroyed(struct dsl_dataset *ds, struct dmu_tx *tx);
void dsl_pool_ds_snapshotted(struct dsl_dataset *ds, struct dmu_tx *tx);
void dsl_pool_ds_clone_swapped(struct dsl_dataset *ds1, struct dsl_dataset
*ds2,
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa.h#4
(text)
@@ -511,7 +511,7 @@
struct zbookmark;
struct zio;
extern void spa_log_error(spa_t *spa, struct zio *zio);
-extern void zfs_ereport_post(const char *class, spa_t *spa, vdev_t *vd,
+extern void zfs_ereport_post(const char */*class*/, spa_t *spa, vdev_t *vd,
struct zio *zio, uint64_t stateoroffset, uint64_t length);
extern void zfs_post_remove(spa_t *spa, vdev_t *vd);
extern void zfs_post_autoreplace(spa_t *spa, vdev_t *vd);
//depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sy
Re: [PATCH] OpenSolaris/ZFS: C++ compatibility
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++. SpectraLogic's intention >> is to return this work to the FreeBSD project once it is a bit more >> complete. >> >> Since these changes modify files that come from OpenSolaris, I want to be >> sure I understand the project's policies regarding divergence from >> the vendor before I check them in. All of the changes save one should >> be trivial to merge with vendor changes and I will do that work for the >> v28 import. Is there any reason I should not commit these changes? > > Now that OpenSolaris is dead we don't have to be so strict with keeping > the diff against vendor small at all cost. I'd prefer not to modify > vendor code whenever possible so it is easier for us to cooperate with > IllumOS (we already took ome code from them). 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++ support (extern "C" blocks), they just don't quite deliver. The changes shouldn't be controversial. > Me and my company are also interested in fault management daemon > (although not restricted to ZFS, but a more general purpose mechanism > like FMA in Solaris). We have talked internally about this at Spectra too. Since we don't have BSD licensed nvpair code, we've thought of using Google protocol buffers to allow extensible encoding of fault data. The GP implementation is MIT licensed and looks like it might be less cumbersome to use than nvpairs. For the first release of our product, however, we are just making due with the string data that devctl provides. > My question would be are there any chances you may > be convinced to use plain C? With C we might be able to help, but not > with C++. The core FMA support needs to be reasonably accessible from C code of course (fully functional and not cumbersome to use). But we should allow FMA agents to be coded in whatever language is convenient to the developer. The project may only be able to accept agents in C (and I'm voting for C++ too) into it's distribution, but that policy should not drive us to make the FMA architecture hard to access from shell, python, ruby, or some other language. The reason I chose C++ for this task is that devd, the source of the events I process, already requires C++ so using C++ in zfsd doesn't impose any new requirements on the system. Zfsd, like even the C kernel of FreeBSD is coded in an object oriented fashion, but its much cleaner to implement this type of design in a language that inherently supports object oriented concepts. Could I rewrite all that I have in C? Sure, but there would have to be some compelling reasons to offset the reduction in clarity and maintainability such a change would cause. Is your inability to help on a C++ version of this code due to distaste for C++ or just a lack of experience with it? Thanks, Justin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] OpenSolaris/ZFS: C++ compatibility
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++ support (extern "C" blocks), they
>> just don't quite deliver. The changes shouldn't be controversial.
>
> Sure. To be clear: I'm not against those changes, I think they are worth
> it. And getting IllumOS to accept them back is definitely a good idea.
Ok.
>> We have talked internally about this at Spectra too. Since we don't have
>> BSD licensed nvpair code, we've thought of using Google protocol buffers
>> to allow extensible encoding of fault data. The GP implementation is
>> MIT licensed and looks like it might be less cumbersome to use than
>> nvpairs. For the first release of our product, however, we are just
>> making due with the string data that devctl provides.
>
> I've developed similar API during HAST work, maybe it is a good starting
> point? src/sbin/hastd/nv.{c,h}.
Sure. If the decision is made to use nvpairs, I would advocate for
emulating the Solaris API. There's no reason to be slightly different
from an established implementation.
>> The reason I chose C++ for this task is that devd, the source of the
>> events I process, already requires C++ so using C++ in zfsd doesn't
>> impose any new requirements on the system. Zfsd, like even the C
>> kernel of FreeBSD is coded in an object oriented fashion, but its
>> much cleaner to implement this type of design in a language that
>> inherently supports object oriented concepts. Could I rewrite all
>> that I have in C? Sure, but there would have to be some compelling
>> reasons to offset the reduction in clarity and maintainability such
>> a change would cause.
>
> Hmm, so zfsd will receive events from devd? I'm in opinion that we
> should let devd alone. In my initial port I used devd, because it was
> closest match, but if we want to clean it up, we shouldn't go through
> devd. For example ZFS v28 can report whole binary blocks where checksum
> doesn't match and passing those through devd would be cumbersome.
zfsd parses devctl event data (via devd's unix domain socket) into an
internal event class representation. The data representation for the
event class as well as the source for the event data can be easily
changed out once a more complete solution is available. For the policies
SpectraLogic needs for its first product launch, the data coming through
devctl is sufficient even if it is not ideal.
>> Is your inability to help on a C++ version of this code due to distaste
>> for C++ or just a lack of experience with it?
>
> The latter. I'm sure there are many committers that are fluent in C++,
> but all of them know C. I was under impression that Warner implemented
> devd in C++ also as a kind of experiment, which nobody really followed.
FreeBSD has lots of examples of really well written C code and shell code,
but almost no examples written in more modern languages (C++ isn't even
that modern!). That's too bad. My hope is that, by submitting another
example of (dare I hope well written) C++ use in FreeBSD, that this will
change. At least review the code (when I release it in a few weeks) before
begging me to rewrite it! :-)
--
Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Adaptec AIC7902 Ultra320 Problems
> 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 5 at device 2.1 on > pci3 > aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs > > Trying to install 5.1-CURRENT-20030709-JPSNAP or 4.8-STABLE on the > box gives a timeout error that will hang the disk in a state that > resetting the machine does not clear, and only power cycling will > clear. Ive replaced the disks with no change, but installed and > ran Redhat 7.3 on the box with no timeouts or errors. The problem you are encountering looks to be a drive firmware issue exposed when the drive is running at high queue depths. The linux driver limites the tag depth to 32 by default. The FreeBSD driver does not throttle in this way. It seems that we just overwhelm the drive with commands and it just stops doing anything on the bus. According to the timeout trace, the target just stopped sending packets while still sitting on the bus. I have not tested this particular drive, so I do not know if update firmware is available for it. You might try running in non-packetized mode by toggling this option via SCSI-Select. You previous test of running at "160" just reduced the clock rate, but still allowed the use of the newer, faster, packetized format. -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.cscsi_da.c src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.csrc/sys/dev/firewire sbp.c
> 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 > problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them > for devices that still fail. Did you ever find the bug in the sync cache "silence errors" code that was the root cause for most of the quirks? -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: USB da(4) quirks deprecated
> 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 to reitterate, the quirks are there for situations that cannot be handled in a more programatic way (e.g. a device that dies when you send it a certain command). Please don't blindly re-enable quirks to silence junk that winds up in syslog. -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Adaptec AIC7902 Ultra320 Problems
> 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 contacted Hitachi (they bought the IBM drive division) for a firmware update? -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CAM changes causing prob?
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. > There seems to be some relation to how recently the last lot of tape activity > was (althought this is rather tenuous). It would be usefull to see the "ps -l" output for the hung process so we know what resource it is blocking on. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: About that 'new-bus' stuff.
>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_space and bus_dma >reimported from NetBSD. As far as I know, there is no compelling >reason to have them be different. For bus_space, no. For bus_dma, there are some reasons for them to be different in one area: the callback mechanism for returning a valid dma mapping. The rest of the differences are primarily from the fact that NetBSD has enhanced or modified their interfaces since my original work and I haven't found the time to sync us back up. >Warner -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "hanging root device to da0s1a"
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 console buffer? -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "hanging root device to da0s1a"
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 contiguously into the console buffer? > > This would just move the race. It is probably already elsewhere for > serial consoles. Perhaps I should use the log facility instead of printf in the announce code? -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "hanging root device to da0s1a"
>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 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 console buffer? > >Am I missing something here ? We shouldn't set the root device until >CAM is done probing, right ? 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. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "hanging root device to da0s1a"
>>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. > >I think we should hold off the rootdev determination until after the >printfs, unless you tell me that this will delay the boot by many >seconds in too many cases. It will probably add 5->15 seconds for anyone with a cdrom drive with even greater delays for people with more than 2 or 3 devices. There are also devices like scanners and older WORM devices that can take up to a minute to become ready. It seems quite silly to me to hold up booting for devices that are not even referenced during boot. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FP exceptions broken (Re: Interesting bogons from last night's 4.0 snapshot.)
> 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 switch some IDT entries. > 4) Fix for (2) is not very well implemented. It moves the IDT without >hiding idt[] from (3). > 5) Rev.1.55 of disturbed the probe order so that (4) is >done before (3). This breaks the IDT context switching if the F00F >fix gets installed. npx traps and interrupts end up being serviced >by the dummy probe routines. Do you record this stuff anywhere? I think we should have a Bruce's nits page so this stuff isn't forgotten. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: PCI bus numbering and orphaned devices
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 you just get all bits set in whatever you read? If so, the headertype check should be better bounded. -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
+*
+* 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)
return (bus_generic_attach(dev));
} else
This one looks good, please commit. The comment above is outdated, so
it might be better to just remove it completely.
At least fix the typo in the comment if you aren't going to remove it.
--
Justin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
: > 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 you just get all bits set in whatever you read? If so, : the headertype check should be better bounded. hdrtype would be 0xff. 0xff & 0x7f is 0x7f, which is greater than 2. Sorry. Read the test backwards. -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
