--- "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: A
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 PRO
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
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
$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$$$&J}$K:GE,$G$9!#(B
$B$3$NB
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:
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
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 wou
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' o
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
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
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 i
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
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 memo
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
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.
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 comm
>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
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
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-de
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
>> a single buffer. I never realized that there was such controversy
>> over this value... it was just put in so that I could have something
>> for the non-GNUC case.
>
>Yeah, but, uh, it'll blow up in one's face.
If it gets compiled, I suppose so.
>The question I have is what *should* we b
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 compile
23 matches
Mail list logo
