Re: Card has no functions
--- M. Warner Losh [EMAIL PROTECTED] wrote: Bummmer. What card are you using? Warner Hi Warner, Here's the config that I tested. All cards were recognized now after I set hw.cbb.start_mem to the values shown in Win2K. Is it a problem of decoding the TI memory address? Desktop: ASUS CUSL2 PIII 750 Mhz, Orinoco PCMCIA Adapter (TI 1250) Notebook: IBM Thinkpad 600X with latest BIOS update, cardbus bridge is TI 1450 Cardbus card: Buffalo LPC4-CLX-CB (Realtek 3190B) - (NO PROBLEM) PC Card: Orinoco Silver 3Com 3CCFEM556 (a network/modem combo card) Xircom Credit Card Ethernet 10/100 __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cdefs and XFree86
The recent changes to /usr/include/sys/cdefs.h have broken the build of XFree86-Server. The problem is with the _XOPEN_SOURCE macro. At line cdefs.h it's checked i.e. #if _XOPEN_SOURCE = 600 but in XFree86 it's defined as #define _XOPEN_SOURCE Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdefs and XFree86
Le 2002-04-04, Paul Richards écrivait : #if _XOPEN_SOURCE = 600 Could be changed to #if (_XOPEN_SOURCE - 0) = 600 -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdefs and XFree86
Paul Richards [EMAIL PROTECTED] writes: The recent changes to /usr/include/sys/cdefs.h have broken the build of XFree86-Server. The problem is with the _XOPEN_SOURCE macro. At line cdefs.h it's checked i.e. #if _XOPEN_SOURCE = 600 but in XFree86 it's defined as #define _XOPEN_SOURCE Peter fixed this a day or so ago; see rev 1.51. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
(J!$B9-9p(J!$B!!(J500$B1_(B$B$+$i9b<}1W$J=P2q$$7O%5%$%H$,(B$B1?1D2DG=!*(B
$B=P2q$$7O%5%$%H$NI{6H$K4X$9$k$*CN$i$;$G$9!#(B
$BITMW$NJ}$O%j%9%H$+$i:o=|$7$^$9$N$G!"$3$N$^$^JV?.$7$F$*CN$i$;$/$@$5$$!#(B
$B@$$NCf$K#3K|7o0J>e$"$k$H8@$o$l$F$$$k=P2q$$7O%5%$%H!#(B
$B#3K|7o$b$"$k$H$$$&$3$H$O!"%*%$%7%$;T>l$@$+$i$3$=;2F~$9$k;v6H.8/$$$r2T$.$?$$$H$$$}$K:GE,$G$9!#(B
$B$3$NB>!"K\3JE*$K%S%8%M%9$H$7$F=P2q$$7O%5%$%H$r1?1D$7!"<}F~$rF@$?$$$H$$(B
$B$&?M$rBP>]$K$7$?%3!<%9$b=<\:Y4uK>!W$H2<5-%a!<%k%"%I(B
$B%l%9$^$G$*CN$i$;$/$@$5$$!#$=$N:]!";aL>!J56L>$G$b2D!K$H=;=j!J2?8)$^$G!K!&(B
$B%a!<%k%"%I%l%9$r$*CN$i$;$/$@$5(B $B$$!#(B
$B!Z@83h8~>e0Q0w2q![!!([EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
BUS_SPACE_MAXSIZE isp driver.
I just booted a recent current (or rather attempted to) and saw this when attempting to mount root from a qlogic card on my miata: bus_dmamap_load: Too many segs! buf_len = 0x2000 spec_getpages:(da0a) I/O read failure: (error=22) bp 0xfe0004087ae8 vp 0xfe000ae9 size: 98304, resid: 98304, a_count: 98304, valid: 0x0 nread: 0, reqpage: 7, pindex: 59, pcount: 12 vm_fault: pager read error, pid 1 (init) ... more of same ... The only way I could get the system to boot was to increase BUS_SPACE_MAXSIZE to 128K to match MAXPHYS. I don't know why they don't match in the first place (they don't match on x86 either, so the driver will probably puke there too.) #define BUS_SPACE_MAXSIZE(128 * 1024) Does anybody know why BUS_SPACE_MAXSIZE != MAXPHYS on some platforms? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Ah- this bit Marcel with FreeBSD-ia64 too. I hadn't gotten too that. I haven't tried it yet in i386. Worked for in Alpha Sparc64, but I guess it didn't work for all alphas. I just reinstalled 5.0 and will be trying an i386 kernel shortly. It would seem to me you can't have BUS_SPACE_MAXSIZE less than MAXPHYS- that seems absurd to me. What happened here is that in trying to make isp work for sparc64, I redid the usage of bus_dma. Since the author never finished man pages or wrote up a spec, the implementations (and architecture) is open to interpretation. -matt On Thu, 4 Apr 2002, Andrew Gallatin wrote: I just booted a recent current (or rather attempted to) and saw this when attempting to mount root from a qlogic card on my miata: bus_dmamap_load: Too many segs! buf_len = 0x2000 spec_getpages:(da0a) I/O read failure: (error=22) bp 0xfe0004087ae8 vp 0xfe000ae9 size: 98304, resid: 98304, a_count: 98304, valid: 0x0 nread: 0, reqpage: 7, pindex: 59, pcount: 12 vm_fault: pager read error, pid 1 (init) ... more of same ... The only way I could get the system to boot was to increase BUS_SPACE_MAXSIZE to 128K to match MAXPHYS. I don't know why they don't match in the first place (they don't match on x86 either, so the driver will probably puke there too.) #define BUS_SPACE_MAXSIZE(128 * 1024) Does anybody know why BUS_SPACE_MAXSIZE != MAXPHYS on some platforms? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Matthew Jacob writes: Ah- this bit Marcel with FreeBSD-ia64 too. I hadn't gotten too that. I haven't tried it yet in i386. Worked for in Alpha Sparc64, but I guess it didn't work for all alphas. I just reinstalled 5.0 and will be trying an i386 kernel shortly. It would seem to me you can't have BUS_SPACE_MAXSIZE less than MAXPHYS- that seems absurd to me. Me too. I was about to just change it for alpha, but then I wondered if there was a reason for having BUS_SPACE_MAXSIZE MAXPHYS. I've CC'ed Justin. I think he was the original author, perhaps he can enlighten us. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Actually, I suppose if you change: #define ISP_NSEG((MAXPHYS/PAGE_SIZE) + 1) to #define ISP_NSEG((BUS_SPACE_MAXSIZE/PAGE_SIZE) + 1) this will probably be more correct. I think this is probably what I should be using anyway. BTW- this was more of a 'hackers' or 'scsi' issue. I *used* to, btw, put a massively large number for segments- basically the max *should* be the number of segments I can stick in a single Request Queue (2 or 3) command plus all the continuation entries possible (5 or 7 per continuation entries, for FreeBSD ~250 or so- MMV depending on current state)- that'd be on the order of ~1800 segments. After getting burned by some surprises in the sparc64 implementation, I decided to restrict it to paramaters that were compile time invariants for each platform. I guess I picked the wrong parameter :-). -matt On Thu, 4 Apr 2002, Andrew Gallatin wrote: I just booted a recent current (or rather attempted to) and saw this when attempting to mount root from a qlogic card on my miata: bus_dmamap_load: Too many segs! buf_len = 0x2000 spec_getpages:(da0a) I/O read failure: (error=22) bp 0xfe0004087ae8 vp 0xfe000ae9 size: 98304, resid: 98304, a_count: 98304, valid: 0x0 nread: 0, reqpage: 7, pindex: 59, pcount: 12 vm_fault: pager read error, pid 1 (init) ... more of same ... The only way I could get the system to boot was to increase BUS_SPACE_MAXSIZE to 128K to match MAXPHYS. I don't know why they don't match in the first place (they don't match on x86 either, so the driver will probably puke there too.) #define BUS_SPACE_MAXSIZE(128 * 1024) Does anybody know why BUS_SPACE_MAXSIZE != MAXPHYS on some platforms? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Oops. That wasn't it. Taking this offline. On Thu, 4 Apr 2002, Matthew Jacob wrote: Actually, I suppose if you change: #define ISP_NSEG((MAXPHYS/PAGE_SIZE) + 1) to #define ISP_NSEG((BUS_SPACE_MAXSIZE/PAGE_SIZE) + 1) this will probably be more correct. I think this is probably what I should be using anyway. BTW- this was more of a 'hackers' or 'scsi' issue. I *used* to, btw, put a massively large number for segments- basically the max *should* be the number of segments I can stick in a single Request Queue (2 or 3) command plus all the continuation entries possible (5 or 7 per continuation entries, for FreeBSD ~250 or so- MMV depending on current state)- that'd be on the order of ~1800 segments. After getting burned by some surprises in the sparc64 implementation, I decided to restrict it to paramaters that were compile time invariants for each platform. I guess I picked the wrong parameter :-). -matt On Thu, 4 Apr 2002, Andrew Gallatin wrote: I just booted a recent current (or rather attempted to) and saw this when attempting to mount root from a qlogic card on my miata: bus_dmamap_load: Too many segs! buf_len = 0x2000 spec_getpages:(da0a) I/O read failure: (error=22) bp 0xfe0004087ae8 vp 0xfe000ae9 size: 98304, resid: 98304, a_count: 98304, valid: 0x0 nread: 0, reqpage: 7, pindex: 59, pcount: 12 vm_fault: pager read error, pid 1 (init) ... more of same ... The only way I could get the system to boot was to increase BUS_SPACE_MAXSIZE to 128K to match MAXPHYS. I don't know why they don't match in the first place (they don't match on x86 either, so the driver will probably puke there too.) #define BUS_SPACE_MAXSIZE(128 * 1024) Does anybody know why BUS_SPACE_MAXSIZE != MAXPHYS on some platforms? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/alpha/alpha machdep.c src/sys/alpha/osf1 osf1_signal.c src/sys/coda coda_psdev.c src/sys/compat/linux linux_signal.c src/sys/compat/svr4 svr4_signal.c src/sys/i386/
On Thu, 4 Apr 2002, Bruce Evans wrote: bde 2002/04/04 09:49:49 PST Modified files: sys/alpha/alpha machdep.c sys/alpha/osf1 osf1_signal.c sys/coda coda_psdev.c sys/compat/linux linux_signal.c sys/compat/svr4 svr4_signal.c sys/i386/i386machdep.c sys/i386/ibcs2 ibcs2_signal.c sys/i386/linux linux_sysvec.c sys/i386/svr4svr4_machdep.c sys/ia64/ia64machdep.c sys/kern kern_sig.c subr_trap.c sys/pc98/i386machdep.c sys/sparc64/sparc64 machdep.c sys/sys proc.h signalvar.h Log: Moved signal handling and rescheduling from userret() to ast() so that they aren't in the usual path of execution for syscalls and traps. The main complication for this is that we have to set flags to control ast() everywhere that changes the signal mask. Avoid locking in userret() in most of the remaining cases. Submitted by: luoqi (first part only, long ago, reorganized by me) Reminded by:dillon Tha invariants check in this (in userret()) failed for the first time 10 minutes after I committed it. I think this is harmless (due to a cached flag in ast()) but don't have time to check today. Turn off the check if it spams the console but signals appear to work despite this. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Andrew Gallatin wrote: Me too. I was about to just change it for alpha, but then I wondered if there was a reason for having BUS_SPACE_MAXSIZE MAXPHYS. From what I understand, the Alpha is limited to doing transfers in the first 2G of memory. I'm not sure if the ISA 16M memory limit is in there anywhere, either. The problem is that a DMA initiated by a bus mastering device can only access as many bis of address space as are passed through the bus, end-to-end. For ISA, this ends up being a 16M limit; I think the 2G limit on Alpha is because the limit is 32 bits, but there is some signed math that should be unsigned. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
On Thu, 4 Apr 2002, Terry Lambert wrote: Andrew Gallatin wrote: Me too. I was about to just change it for alpha, but then I wondered if there was a reason for having BUS_SPACE_MAXSIZE MAXPHYS. From what I understand, the Alpha is limited to doing transfers in the first 2G of memory. I'm not sure if the ISA 16M memory limit is in there anywhere, either. The problem is that a DMA initiated by a bus mastering device can only access as many bis of address space as are passed through the bus, end-to-end. For ISA, this ends up being a 16M limit; I think the 2G limit on Alpha is because the limit is 32 bits, but there is some signed math that should be unsigned. Neither is really applicable here. The actual limits for alpha depend on the platforma and how you implement it. Typically, the bigger alphas have been implemented with a 2GB direct mapped window, and then, if they have it, a S/G map setup for the rest (if any) of memory, which also can include ISA mapping. The current Alpha 2.4.18 Linux implementation is quite happy to DMA to 4GB on quite a few alphas. BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Matthew Jacob wrote: Neither is really applicable here. The actual limits for alpha depend on the platforma and how you implement it. Typically, the bigger alphas have been implemented with a 2GB direct mapped window, and then, if they have it, a S/G map setup for the rest (if any) of memory, which also can include ISA mapping. Thanks for the clarification. I was confusing BUS_SPACE_MAXSIZE with BUS_SPACE_MAXSIZE_24BIT and BUS_SPACE_MAXSIZE_32BIT. It's probably too late to rename BUS_SPACE_MAXSIZE to something like BUS_SPACE_MAXXFER. 8-(. The current Alpha 2.4.18 Linux implementation is quite happy to DMA to 4GB on quite a few alphas. Ah. Reference code. BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. Yeah, I get that now. No need to beat me up, I can take care of it myself. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
On Thu, 4 Apr 2002, Terry Lambert wrote: Matthew Jacob wrote: Neither is really applicable here. The actual limits for alpha depend on the platforma and how you implement it. Typically, the bigger alphas have been implemented with a 2GB direct mapped window, and then, if they have it, a S/G map setup for the rest (if any) of memory, which also can include ISA mapping. Thanks for the clarification. I was confusing BUS_SPACE_MAXSIZE with BUS_SPACE_MAXSIZE_24BIT and BUS_SPACE_MAXSIZE_32BIT. It's probably too late to rename BUS_SPACE_MAXSIZE to something like BUS_SPACE_MAXXFER. 8-(. Yes. If we've understood it at all. There are no documents really describing it. The current Alpha 2.4.18 Linux implementation is quite happy to DMA to 4GB on quite a few alphas. Ah. Reference code. BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. Yeah, I get that now. No need to beat me up, I can take care of it myself. 8-) 8-). No, no at least you showed some interest :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Matthew Jacob wrote: Thanks for the clarification. I was confusing BUS_SPACE_MAXSIZE with BUS_SPACE_MAXSIZE_24BIT and BUS_SPACE_MAXSIZE_32BIT. It's probably too late to rename BUS_SPACE_MAXSIZE to something like BUS_SPACE_MAXXFER. 8-(. Yes. If we've understood it at all. There are no documents really describing it. I was going to mention this, but I censured myself so that it wouldn't look like I was whinging... 8-) 8-). The documentation in these areas is atrocious. There needs to be a documentation requirement for the commit of huge things, like bus space, CAM, devfs, GEOM, etc. ... BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. Yeah, I get that now. No need to beat me up, I can take care of it myself. 8-) 8-). No, no at least you showed some interest :-) If that's supposed to trick me into doing the missing documentation, it's not working... 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Last round of sendmail startup changes in place
As discussed earlier in the mailing list, I've committed what will hopefully be the final round of sendmail startup changes: --- start of forwarded message (RFC 934 encapsulation) --- From: Gregory Neil Shapiro [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/etc rc src/etc/defaults rc.conf src/etc/mail Makefile src/etc/sendmail Makefile rc.sendmail src/share/man/man5 rc.conf.5 src/share/man/man8 Makefile rc.sendmail.8 Date: Thu, 4 Apr 2002 18:30:49 -0800 (PST) gshapiro2002/04/04 18:30:49 PST Modified files: etc rc etc/defaults rc.conf etc/mail Makefile etc/sendmail Makefile share/man/man5 rc.conf.5 share/man/man8 Makefile Added files: etc/sendmail rc.sendmail share/man/man8 rc.sendmail.8 Log: Quoting Peter Wemm, At great personal risk, touch the sendmail startup again. As an alternative to sendmail_enable=NONE, solve the boot time problem for non-sendmail users completely by moving all of the sendmail startup code from /etc/rc to /etc/rc.sendmail. The source for that script will be kept in src/etc/sendmail/rc.sendmail so make.conf's NO_SENDMAIL will prevent it from being installed. A new rc.conf variable, mta_start_script specifies the script to run to start the user's preferred MTA. For backward compatibility, it will default to /etc/rc.sendmail. The specified script is called out of /etc/rc after checking to make sure it exists. A new rc.sendmail.8 man page has also been added which now houses the sendmail_* variable descriptions formerly in rc.conf.5. Use /etc/rc.sendmail in /etc/mail/Makefile to reduce code duplication. Reviewed by:-current, -stable, obrien, peter, ru MFC after: 1 week Revision ChangesPath 1.142 +19 -10src/etc/defaults/rc.conf 1.27 +38 -70src/etc/mail/Makefile 1.308 +5 -39 src/etc/rc 1.16 +3 -1 src/etc/sendmail/Makefile 1.1 +193 -0src/etc/sendmail/rc.sendmail (new) 1.160 +13 -105 src/share/man/man5/rc.conf.5 1.26 +4 -0 src/share/man/man8/Makefile 1.1 +241 -0src/share/man/man8/rc.sendmail.8 (new) --- end --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. If you look at the x86 implementation, BUS_SPACE_MAXSIZE is only used in the non-GNUC case and is not referenced (I don't think) by any driver code. Even setting it to MAXPHYS is not truely correct since at some point we will have to start supporting transfer mappings that are larger than what can be mapped by a single buffer. I never realized that there was such controversy over this value... it was just put in so that I could have something for the non-GNUC case. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
On Thu, 4 Apr 2002, Justin T. Gibbs wrote: BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. If you look at the x86 implementation, BUS_SPACE_MAXSIZE is only used in the non-GNUC case and is not referenced (I don't think) by any driver code. Even setting it to MAXPHYS is not truely correct since at some point we will have to start supporting transfer mappings that are larger than what can be mapped by a single buffer. I never realized that there was such controversy over this value... it was just put in so that I could have something for the non-GNUC case. Yeah, but, uh, it'll blow up in one's face. The question I have is what *should* we be using? Should BUS_SPACE_MAXSIZE be bumped up so that any dma allocation we attempt for a platform will fit within it? I mean, it's used in a lot of places, so clearly it must mean something, right? What are the semantics here? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
if_wi_pccards.c breaks kernel builds
cc -O -pipe -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -c /usr/src/sys/modules/wi/../../dev/wi/if_wi_pccard.c /usr/src/sys/modules/wi/../../dev/wi/if_wi_pccard.c:102: `PCMCIA_STR_3COM_3CRWE777A' undeclared here (not in a function) /usr/src/sys/modules/wi/../../dev/wi/if_wi_pccard.c:102: initializer element is not constant /usr/src/sys/modules/wi/../../dev/wi/if_wi_pccard.c:102: (near initialization for `wi_pccard_products[1].pp_name') /usr/src/sys/modules/wi/../../dev/wi/if_wi_pccard.c:102: `PCMCIA_PRODUCT_3COM_3CRWE777A' undeclared here (not in a function) /usr/src/sys/modules/wi/../../dev/wi/if_wi_pccard.c:102: initializer element is not constant /usr/src/sys/modules/wi/../../dev/wi/if_wi_pccard.c:102: (near initialization for `wi_pccard_products[1].pp_product') /usr/src/sys/modules/wi/../../dev/wi/if_wi_pccard.c:102: `PCMCIA_CIS_3COM_3CRWE777A' undeclared here (not in a function) /usr/src/sys/modules/wi/../../dev/wi/if_wi_pccard.c:102: initializer element is not constant /usr/src/sys/modules/wi/../../dev/wi/if_wi_pccard.c:102: (near initialization for `wi_pccard_products[1].pp_cis') *** Error code 1 Stop in /usr/src/sys/modules/wi. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Tool Kit
Hey there, I found this web site that gives some good sources for doing more with the schools web site. Let me know what you think. http://www.pluggedin.org/tool_kit/ Bradley Smith Educator To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
a single buffer. I never realized that there was such controversy over this value... it was just put in so that I could have something for the non-GNUC case. Yeah, but, uh, it'll blow up in one's face. If it gets compiled, I suppose so. The question I have is what *should* we be using? Should BUS_SPACE_MAXSIZE be bumped up so that any dma allocation we attempt for a platform will fit within it? I think it should go away. We should malloc space to hold the segments in the leaf dma tags and base that size on the information in the tag. The segments would only be allocated on the first dma_map_create call on a tag so that intermediate (i.e. non-leaf) tags never have this stuff allocated. I mean, it's used in a lot of places, so clearly it must mean something, right? What are the semantics here? Is it really used in a lot of places? I've always used the bit sized versions of MAXSIZE in my driver code, never the ambiguous one. 8-) -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
On Thu, 4 Apr 2002, Justin T. Gibbs wrote: a single buffer. I never realized that there was such controversy over this value... it was just put in so that I could have something for the non-GNUC case. Yeah, but, uh, it'll blow up in one's face. If it gets compiled, I suppose so. The question I have is what *should* we be using? Should BUS_SPACE_MAXSIZE be bumped up so that any dma allocation we attempt for a platform will fit within it? I think it should go away. We should malloc space to hold the segments in the leaf dma tags and base that size on the information in the tag. The segments would only be allocated on the first dma_map_create call on a tag so that intermediate (i.e. non-leaf) tags never have this stuff allocated. But lacking that, what does it mean? I mean, it's used in a lot of places, so clearly it must mean something, right? What are the semantics here? Is it really used in a lot of places? About 40 files. But everyone has copied them. I've always used the bit sized versions of MAXSIZE in my driver code, never the ambiguous one. 8-) -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
