freebsd-sparc-digest V5 #219
owner-freebsd...@freebsd.org
freebsd-sparc-digest Saturday, January 18 2003 Volume 05 : Number 219
In this issue:
Problem with iommu_dvmamap_create
Re: Problem with iommu_dvmamap_create
Re: Problem with iommu_dvmamap_create
Re: Sparc64 floating point questions
Re: Problem with iommu_dvmamap_create
Re: Problem with iommu_dvmamap_create
Re: Problem with iommu_dvmamap_create
Re: Problem with iommu_dvmamap_create
sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install
Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install
Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install
Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install
Re: Sparc64 floating point questions
----------------------------------------------------------------------
Date: Fri, 17 Jan 2003 15:34:37 +0100 (CET)
From: Harti Brandt <bra...@fokus.gmd.de>
Subject: Problem with iommu_dvmamap_create
Hi,
it seems, there is a problem in this function. I have a case, where my
driver creates a dma_tag with a maxsize of 64k-1, a maximum segment size
of 64k-1 and a large maximum number of segments (say 30...40). As soon, as
I create a DMA map with this tag, the io gets botched (up to the point,
that the boot prom reports a nvram checksum error). When I comment out the
code in iommu.c as follows I can at least create and destroy the maps
without any bad effect (I did not try to load them yet):
int
iommu_dvmamap_create(bus_dma_tag_t pt, bus_dma_tag_t dt, struct iommu_state *is,
int flags, bus_dmamap_t *mapp)
{
bus_size_t totsz, presz, currsz;
int error, i, maxpre;
if ((error = sparc64_dmamap_create(pt->dt_parent, dt, flags, mapp)) != 0)
return (error);
KASSERT(SLIST_EMPTY(&(*mapp)->dm_reslist),
("iommu_dvmamap_create: hierarchy botched"));
iommu_map_insq(*mapp);
/*
* Preallocate DVMA space; if this fails now, it is retried at load
* time. Through bus_dmamap_load_mbuf() and bus_dmamap_load_uio(), it
* is possible to have multiple discontiguous segments in a single map,
* which is handled by allocating additional resources, instead of
* increasing the size, to avoid fragmentation.
* Clamp preallocation to BUS_SPACE_MAXSIZE. In some situations we can
* handle more; that case is handled by reallocating at map load time.
*/
totsz = ulmin(IOMMU_SIZE_ROUNDUP(dt->dt_maxsize), IOMMU_MAX_PRE);
error = iommu_dvma_valloc(dt, is, *mapp, totsz);
if (error != 0)
return (0);
#if 0
/*
* Try to be smart about preallocating some additional segments if
* needed.
*/
maxpre = imin(dt->dt_nsegments, IOMMU_MAX_PRE_SEG);
presz = dt->dt_maxsize / maxpre;
for (i = 0; i < maxpre && totsz < IOMMU_MAX_PRE; i++) {
currsz = round_io_page(ulmin(presz, IOMMU_MAX_PRE - totsz));
error = iommu_dvma_valloc(dt, is, *mapp, currsz);
if (error != 0)
break;
totsz += currsz;
}
#endif
return (0);
}
The problem seems to be the dt_maxsize / maxpre. In my case this evaluates
to 0 and the call to valloc will use a currsz of 0. This seems to have bad
effects on the resource manager.
Also the loop will allocate one segment more than it needs (it does not
count the first allocation). This is, however, not critical.
I suggest also changing the comment above - it mentions BUS_SPACE_MAXSIZE,
but BUS_SPACE_MAXSIZE does not figure in the code (should be
IOMMU_MAX_PRE probably, which happens to be BUS_SPACE_MAXSIZE).
Regards,
harti
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de
------------------------------
Date: Fri, 17 Jan 2003 17:08:57 +0100
From: Thomas Moestl <t...@freebsd.org>
Subject: Re: Problem with iommu_dvmamap_create
- --sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Fri, 2003/01/17 at 15:34:37 +0100, Harti Brandt wrote:
> Hi,
>
> it seems, there is a problem in this function. I have a case, where my
> driver creates a dma_tag with a maxsize of 64k-1, a maximum segment size
> of 64k-1 and a large maximum number of segments (say 30...40). As soon, as
> I create a DMA map with this tag, the io gets botched (up to the point,
> that the boot prom reports a nvram checksum error). When I comment out the
> code in iommu.c as follows I can at least create and destroy the maps
> without any bad effect (I did not try to load them yet):
Can you please make try the attached patch? I mostly posted it to this
list before it fixes some bogons which may be related (bugs in the
lowaddr and boundary handling) and adds some diagnostics. I also fixed
the two issues you noted below and KASSERT()ed that presz can't be 0.
Can you also please post the exact map and tag creation calls?
> int
> iommu_dvmamap_create(bus_dma_tag_t pt, bus_dma_tag_t dt, struct iommu_state *is,
> int flags, bus_dmamap_t *mapp)
> {
> bus_size_t totsz, presz, currsz;
> int error, i, maxpre;
>
> if ((error = sparc64_dmamap_create(pt->dt_parent, dt, flags, mapp)) != 0)
> return (error);
> KASSERT(SLIST_EMPTY(&(*mapp)->dm_reslist),
> ("iommu_dvmamap_create: hierarchy botched"));
> iommu_map_insq(*mapp);
> /*
> * Preallocate DVMA space; if this fails now, it is retried at load
> * time. Through bus_dmamap_load_mbuf() and bus_dmamap_load_uio(), it
> * is possible to have multiple discontiguous segments in a single map,
> * which is handled by allocating additional resources, instead of
> * increasing the size, to avoid fragmentation.
> * Clamp preallocation to BUS_SPACE_MAXSIZE. In some situations we can
> * handle more; that case is handled by reallocating at map load time.
> */
> totsz = ulmin(IOMMU_SIZE_ROUNDUP(dt->dt_maxsize), IOMMU_MAX_PRE);
> error = iommu_dvma_valloc(dt, is, *mapp, totsz);
> if (error != 0)
> return (0);
> #if 0
> /*
> * Try to be smart about preallocating some additional segments if
> * needed.
> */
> maxpre = imin(dt->dt_nsegments, IOMMU_MAX_PRE_SEG);
> presz = dt->dt_maxsize / maxpre;
> for (i = 0; i < maxpre && totsz < IOMMU_MAX_PRE; i++) {
> currsz = round_io_page(ulmin(presz, IOMMU_MAX_PRE - totsz));
> error = iommu_dvma_valloc(dt, is, *mapp, currsz);
> if (error != 0)
> break;
> totsz += currsz;
> }
> #endif
> return (0);
> }
>
> The problem seems to be the dt_maxsize / maxpre. In my case this evaluates
> to 0 and the call to valloc will use a currsz of 0. This seems to have bad
> effects on the resource manager.
Hmmm, allocating with a size of 0 would of course be a bug, but I fail to
see what would cause presz to be 0 in the first place in your example -
maxpre will be IOMMU_MAX_PRE_SEG = 3 then, so (64k-1) / 3 = 21845.
It will always be > 0 if maxsize > min(maxseg, IOMMU_PRE_SEG), and all
else would be a bogus tag.
> Also the loop will allocate one segment more than it needs (it does not
> count the first allocation). This is, however, not critical.
Doh, right.
> I suggest also changing the comment above - it mentions BUS_SPACE_MAXSIZE,
> but BUS_SPACE_MAXSIZE does not figure in the code (should be
> IOMMU_MAX_PRE probably, which happens to be BUS_SPACE_MAXSIZE).
Will do (it used to be BUS_SPACE_MAXSIZE directly, but I overlooked
the comment when changing things).
Thanks,
- Thomas
- --
Thomas Moestl <tmo...@gmx.net> http://www.tu-bs.de/~y0015675/
<t...@FreeBSD.org> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
- --sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="iommu-misc.diff"
Index: sparc64/sparc64/iommu.c
===================================================================
RCS file: /ncvs/src/sys/sparc64/sparc64/iommu.c,v
retrieving revision 1.14
diff -u -r1.14 iommu.c
- --- sparc64/sparc64/iommu.c 6 Jan 2003 21:59:54 -0000 1.14
+++ sparc64/sparc64/iommu.c 17 Jan 2003 15:52:16 -0000
@@ -517,10 +517,13 @@
{
struct resource *res;
struct bus_dmamap_res *bdr;
- - bus_size_t align, bound, sgsize;
+ bus_size_t align, sgsize;
- - if ((bdr = malloc(sizeof(*bdr), M_IOMMU, M_NOWAIT)) == NULL)
+ if ((bdr = malloc(sizeof(*bdr), M_IOMMU, M_NOWAIT)) == NULL) {
+ printf("iommu_dvma_valloc: res descriptor allocation "
+ "failed.\n");
return (EAGAIN);
+ }
/*
* If a boundary is specified, a map cannot be larger than it; however
* we do not clip currently, as that does not play well with the lazy
@@ -531,9 +534,9 @@
sgsize = round_io_page(size) >> IO_PAGE_SHIFT;
if (t->dt_boundary > 0 && t->dt_boundary < IO_PAGE_SIZE)
panic("iommu_dvmamap_load: illegal boundary specified");
- - bound = ulmax(t->dt_boundary >> IO_PAGE_SHIFT, 1);
res = rman_reserve_resource_bound(&iommu_dvma_rman, 0L,
- - t->dt_lowaddr, sgsize, bound >> IO_PAGE_SHIFT,
+ t->dt_lowaddr >> IO_PAGE_SHIFT, sgsize,
+ t->dt_boundary >> IO_PAGE_SHIFT,
RF_ACTIVE | rman_make_alignment_flags(align), NULL);
if (res == NULL)
return (ENOMEM);
@@ -719,7 +722,7 @@
* is possible to have multiple discontiguous segments in a single map,
* which is handled by allocating additional resources, instead of
* increasing the size, to avoid fragmentation.
- - * Clamp preallocation to BUS_SPACE_MAXSIZE. In some situations we can
+ * Clamp preallocation to IOMMU_MAX_PRE. In some situations we can
* handle more; that case is handled by reallocating at map load time.
*/
totsz = ulmin(IOMMU_SIZE_ROUNDUP(dt->dt_maxsize), IOMMU_MAX_PRE);
@@ -732,7 +735,10 @@
*/
maxpre = imin(dt->dt_nsegments, IOMMU_MAX_PRE_SEG);
presz = dt->dt_maxsize / maxpre;
- - for (i = 0; i < maxpre && totsz < IOMMU_MAX_PRE; i++) {
+ KASSERT(presz != 0, ("iommu_dvmamap_create: bogus preallocation size "
+ ", nsegments = %d, maxpre = %d, maxsize = %lu", dt->dt_nsegments,
+ maxpre, dt->dt_maxsize));
+ for (i = 1; i < maxpre && totsz < IOMMU_MAX_PRE; i++) {
currsz = round_io_page(ulmin(presz, IOMMU_MAX_PRE - totsz));
error = iommu_dvma_valloc(dt, is, *mapp, currsz);
if (error != 0)
@@ -766,8 +772,10 @@
pmap_t pmap = NULL;
KASSERT(buflen != 0, ("iommu_dvmamap_load_buffer: buflen == 0!"));
- - if (buflen > dt->dt_maxsize)
+ if (buflen > dt->dt_maxsize) {
+ printf("iommu_dvmamap_load_buffer: buffer too long.\n");
return (EINVAL);
+ }
if (td != NULL)
pmap = vmspace_pmap(td->td_proc->p_vmspace);
@@ -813,6 +821,8 @@
sgcnt++;
if (sgcnt >= dt->dt_nsegments ||
sgcnt >= BUS_DMAMAP_NSEGS) {
+ printf("iommu_dvmamap_load_buffer: too many "
+ "segments.\n");
error = EFBIG;
break;
}
@@ -860,7 +870,7 @@
if (error != 0) {
iommu_dvmamap_vunload(is, map);
- - (*cb)(cba, NULL, 0, error);
+ (*cb)(cba, sgs, 0, error);
} else {
/* Move the map to the end of the LRU queue. */
iommu_map_insq(map);
Index: kern/subr_rman.c
===================================================================
RCS file: /ncvs/src/sys/kern/subr_rman.c,v
retrieving revision 1.27
diff -u -r1.27 subr_rman.c
- --- kern/subr_rman.c 27 Nov 2002 03:55:22 -0000 1.27
+++ kern/subr_rman.c 12 Jan 2003 22:45:20 -0000
@@ -229,7 +229,7 @@
*/
do {
rstart = (rstart + amask) & ~amask;
- - if (((rstart ^ (rstart + count)) & bmask) != 0)
+ if (((rstart ^ (rstart + count - 1)) & bmask) != 0)
rstart += bound - (rstart & ~bmask);
} while ((rstart & amask) != 0 && rstart < end &&
rstart < s->r_end);
@@ -263,8 +263,11 @@
* two new allocations; the second requires but one.
*/
rv = malloc(sizeof *rv, M_RMAN, M_NOWAIT | M_ZERO);
- - if (rv == 0)
+ if (rv == 0) {
+ printf("rman_reserve_resource: out of "
+ "memory.\n");
goto out;
+ }
rv->r_start = rstart;
rv->r_end = rstart + count - 1;
rv->r_flags = flags | RF_ALLOCATED;
@@ -282,6 +285,8 @@
*/
r = malloc(sizeof *r, M_RMAN, M_NOWAIT|M_ZERO);
if (r == 0) {
+ printf("rman_reserve_resource: out of "
+ "memory.\n");
free(rv, M_RMAN);
rv = 0;
goto out;
- --sdtB3X0nJg68CQEu--
------------------------------
Date: Fri, 17 Jan 2003 17:30:13 +0100 (CET)
From: Harti Brandt <bra...@fokus.gmd.de>
Subject: Re: Problem with iommu_dvmamap_create
On Fri, 17 Jan 2003, Thomas Moestl wrote:
TM>Can you please make try the attached patch? I mostly posted it to this
TM>list before it fixes some bogons which may be related (bugs in the
TM>lowaddr and boundary handling) and adds some diagnostics. I also fixed
TM>the two issues you noted below and KASSERT()ed that presz can't be 0.
TM>
TM>Can you also please post the exact map and tag creation calls?
if (bus_dma_tag_create(NULL, 1, 0,
BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL,
HE_MAX_PDU, 3 * HE_CONFIG_MAX_TPD_PER_PACKET, HE_MAX_PDU, 0,
&sc->tx_tag)) {
device_printf(dev, "could not allocate TX tag\n");
error = ENOMEM;
goto failed;
}
error = bus_dmamap_create(sc->tx_tag, 0, &t->map);
if (error != 0) {
HE_MAX_PDU is 65535 and HE_CONFIG_MAX_TPD_PER_PACKET is 11.
TM>Hmmm, allocating with a size of 0 would of course be a bug, but I fail to
TM>see what would cause presz to be 0 in the first place in your example -
TM>maxpre will be IOMMU_MAX_PRE_SEG = 3 then, so (64k-1) / 3 = 21845.
TM>It will always be > 0 if maxsize > min(maxseg, IOMMU_PRE_SEG), and all
TM>else would be a bogus tag.
Oh well, I see, I got it wrong. I was confused by all these MAX_PRE and
maxpres.
On a related topic. I just got a panic when actually using the map. There
are two problems: the first is the definition of BUS_DMAMAP_NSEGS. These
seems to be 128k/8k = 16. On the other hand MCLBYTES is 2048 so that a 64k
PDU is segmented into 32 or more mbufs. I think, that NSEGS should be
large enough to handle 64k PDUs so it should probably be 40 or so.
The other problem is, that bus_dmamap_load_mbuf happily will try to load
such a PDU. There is a check in iommu_dvmamap_load_buffer for the segment
count and it sets error to EFBIG, but the function than fails to check
that error. The return at the end should probably read 'return (error)'.
I try your patch and tell you the results.
Thanks,
harti
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de
------------------------------
Date: Fri, 17 Jan 2003 08:31:05 -0800 (PST)
From: John Polstra <j...@polstra.com>
Subject: Re: Sparc64 floating point questions
In article <2003011713...@crow.dom2ip.de>,
Thomas Moestl <tmo...@gmx.net> wrote:
> Since you are going to write to all fp registers anyway, both will get
> set automatically. These bits are not used by the hardware and exist
> only to allow software to skip saving unused registers. The kernel
> does not currently make use of them. However, if it (or a userland
> thread manager) did, and a switch was to take place before all
> registers were restored, the missing dirty bits would indicate that
> the yet unaccessed parts of the registers need not be saved, which
> does not matter at all since their old values will not be used any
> more.
> The kernel itself does never clear DU and DL, so it is possible to use
> them in user land to skip unnecessary saving (and unneccesary
> reloading if one of the halves was not accessed at all); in this case
> it would be necessary to clear the bits explicitely after reloading.
> Both will however get set currently each time the fp registers are
> restored after a (kernel) context switch, so this does probably not
> really pay off. Also, things would break if the kernel started to use
> them for saving decisions.
>
> Setting FEF explicitely before reloading makes sure that a fp state
> that was saved on a previous context switch and that might not have
> been restored yet will not be restored due to the following register
> accesses. Since all registers will be overwritten anyway, this would
> just eat cycles unnecessarily.
Thanks! I understand it perfectly now.
John
- --
John Polstra
John D. Polstra & Co., Inc. Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
------------------------------
Date: Fri, 17 Jan 2003 18:05:28 +0100 (CET)
From: Harti Brandt <bra...@fokus.gmd.de>
Subject: Re: Problem with iommu_dvmamap_create
On Fri, 17 Jan 2003, Thomas Moestl wrote:
TM>Can you please make try the attached patch? I mostly posted it to this
TM>list before it fixes some bogons which may be related (bugs in the
TM>lowaddr and boundary handling) and adds some diagnostics. I also fixed
TM>the two issues you noted below and KASSERT()ed that presz can't be 0.
It seems, that your patch fixes the problem, although I'm not sure how :-)
It even prints 'iommu_dvmamap_load_buffer: too many segments' now,
but crashes afterwards (see my previous mail).
Regards,
harti
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de
------------------------------
Date: Fri, 17 Jan 2003 18:11:11 +0100
From: Thomas Moestl <t...@freebsd.org>
Subject: Re: Problem with iommu_dvmamap_create
On Fri, 2003/01/17 at 17:30:13 +0100, Harti Brandt wrote:
> On Fri, 17 Jan 2003, Thomas Moestl wrote:
> TM>Hmmm, allocating with a size of 0 would of course be a bug, but I fail to
> TM>see what would cause presz to be 0 in the first place in your example -
> TM>maxpre will be IOMMU_MAX_PRE_SEG = 3 then, so (64k-1) / 3 = 21845.
> TM>It will always be > 0 if maxsize > min(maxseg, IOMMU_PRE_SEG), and all
> TM>else would be a bogus tag.
>
> Oh well, I see, I got it wrong. I was confused by all these MAX_PRE and
> maxpres.
>
> On a related topic. I just got a panic when actually using the map. There
> are two problems: the first is the definition of BUS_DMAMAP_NSEGS. These
> seems to be 128k/8k = 16. On the other hand MCLBYTES is 2048 so that a 64k
> PDU is segmented into 32 or more mbufs. I think, that NSEGS should be
> large enough to handle 64k PDUs so it should probably be 40 or so.
BUS_DMAMAP_NSEGS (and BUS_SPACE_MAXSIZE) is pretty arbitrary, the only
thing to limit is the stack space used by the segment array. In the
current setting, 272 bytes are used at most, which is less than 1.5
minimal function frames. Values such as 64 should still be OK.
> The other problem is, that bus_dmamap_load_mbuf happily will try to load
> such a PDU. There is a check in iommu_dvmamap_load_buffer for the segment
> count and it sets error to EFBIG, but the function than fails to check
> that error. The return at the end should probably read 'return (error)'.
Bah, that's what you get when you reorganize code too much. It should
just return (EFBIG) instead of setting error.
> I try your patch and tell you the results.
Thanks. Looking at the code you pasted above, I'm afraid that they
won't help though. The only possibility for a simple map creation to
break things in that way is that it changes the available DVMA space
and may cause this or other maps to be pruned. In both cases, another
driver must be using DMA already or do load or unload operations for
this to take any effect. So, can you please tell me which other
DMA-using devices you have in that box, so that I can try to figure
out the possible interactions?
- Thomas
- --
Thomas Moestl <tmo...@gmx.net> http://www.tu-bs.de/~y0015675/
<t...@FreeBSD.org> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
------------------------------
Date: Fri, 17 Jan 2003 18:19:59 +0100 (CET)
From: Harti Brandt <bra...@fokus.gmd.de>
Subject: Re: Problem with iommu_dvmamap_create
On Fri, 17 Jan 2003, Thomas Moestl wrote:
TM>On Fri, 2003/01/17 at 17:30:13 +0100, Harti Brandt wrote:
TM>> On Fri, 17 Jan 2003, Thomas Moestl wrote:
TM>> TM>Hmmm, allocating with a size of 0 would of course be a bug, but I fail to
TM>> TM>see what would cause presz to be 0 in the first place in your example -
TM>> TM>maxpre will be IOMMU_MAX_PRE_SEG = 3 then, so (64k-1) / 3 = 21845.
TM>> TM>It will always be > 0 if maxsize > min(maxseg, IOMMU_PRE_SEG), and all
TM>> TM>else would be a bogus tag.
TM>>
TM>> Oh well, I see, I got it wrong. I was confused by all these MAX_PRE and
TM>> maxpres.
TM>>
TM>> On a related topic. I just got a panic when actually using the map. There
TM>> are two problems: the first is the definition of BUS_DMAMAP_NSEGS. These
TM>> seems to be 128k/8k = 16. On the other hand MCLBYTES is 2048 so that a 64k
TM>> PDU is segmented into 32 or more mbufs. I think, that NSEGS should be
TM>> large enough to handle 64k PDUs so it should probably be 40 or so.
TM>
TM>BUS_DMAMAP_NSEGS (and BUS_SPACE_MAXSIZE) is pretty arbitrary, the only
TM>thing to limit is the stack space used by the segment array. In the
TM>current setting, 272 bytes are used at most, which is less than 1.5
TM>minimal function frames. Values such as 64 should still be OK.
Would it be possible if you change it just there?
TM>Thanks. Looking at the code you pasted above, I'm afraid that they
TM>won't help though. The only possibility for a simple map creation to
TM>break things in that way is that it changes the available DVMA space
TM>and may cause this or other maps to be pruned. In both cases, another
TM>driver must be using DMA already or do load or unload operations for
TM>this to take any effect. So, can you please tell me which other
TM>DMA-using devices you have in that box, so that I can try to figure
TM>out the possible interactions?
I have an ATA controller from which I boot, a hme card and an adaptec
29160, but I don't use the SCSI disk at the moment. What I did to trigger
the error was:
1) compile the code with the '3 * HE_....' changed to 1.
2) install, kldload, ifconfig up -> ok
3) compile the original code
3) kldunload, install, kldload, ifconfig up -> baaaah
'baaaah' means, that a lot of strange things happen: the driver gets a lot
of interrupts, but the interrupt status words (these are written per DMA)
are invalid. when kldunloading sometimes I get a repeated loop of 'fast
data mmu ... miss' and ddb prompts. After booting (I need to switch the
machine off to do this!) the nvram checksum is usually bad and the machine
ofw status is reset. I tried to find the problem for 3 days now.... With
your patch applied things seem better, but I still fail to see why :-)
Thanks,
harti
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de
------------------------------
Date: Fri, 17 Jan 2003 18:33:03 +0100
From: Thomas Moestl <t...@freebsd.org>
Subject: Re: Problem with iommu_dvmamap_create
On Fri, 2003/01/17 at 18:19:59 +0100, Harti Brandt wrote:
> On Fri, 17 Jan 2003, Thomas Moestl wrote:
> TM>BUS_DMAMAP_NSEGS (and BUS_SPACE_MAXSIZE) is pretty arbitrary, the only
> TM>thing to limit is the stack space used by the segment array. In the
> TM>current setting, 272 bytes are used at most, which is less than 1.5
> TM>minimal function frames. Values such as 64 should still be OK.
>
> Would it be possible if you change it just there?
Yes, I'll do that with the next update.
> I have an ATA controller from which I boot, a hme card and an adaptec
> 29160, but I don't use the SCSI disk at the moment.
Hmmm, none of these has boundary requirements of a form that were
broken previously. The lowaddr breakage also affects none of them (it
was quite harmless for the class of the PCI devices that is currently
supported).
> What I did to trigger the error was:
>
> 1) compile the code with the '3 * HE_....' changed to 1.
> 2) install, kldload, ifconfig up -> ok
> 3) compile the original code
> 3) kldunload, install, kldload, ifconfig up -> baaaah
>
> 'baaaah' means, that a lot of strange things happen: the driver gets a lot
> of interrupts, but the interrupt status words (these are written per DMA)
> are invalid. when kldunloading sometimes I get a repeated loop of 'fast
> data mmu ... miss' and ddb prompts. After booting (I need to switch the
> machine off to do this!) the nvram checksum is usually bad and the machine
> ofw status is reset. I tried to find the problem for 3 days now.... With
> your patch applied things seem better, but I still fail to see why :-)
So do I. Can you maybe put the full code of the driver in question
somewhere for download?
Thanks,
- Thomas
- --
Thomas Moestl <tmo...@gmx.net> http://www.tu-bs.de/~y0015675/
<t...@FreeBSD.org> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
------------------------------
Date: Fri, 17 Jan 2003 17:56:10 -0500 (EST)
From: Drew Derbyshire <a...@gnats.plus.kew.com>
Subject: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install
>Number: 47175
>Category: sparc64
>Synopsis: Sparc Ultra 5/10 console not usable for FreeBSD install
>Confidential: no
>Severity: critical
>Priority: low
>Responsible: freebsd-sparc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Fri Jan 17 15:00:23 PST 2003
>Closed-Date:
>Last-Modified:
>Originator: Drew Derbyshire
>Release: FreeBSD 5.0 RC3 sparc64
>Organization:
Kendra Electronic Wonderworks
>Environment:
System:
Clean FreeBSD 5.0 RC3 install on Sun Ultra 5/10 UPA/PCI
UltraSparc IIi 333Mhz) OpenFirmware Console with monitor
on system video adapter and standard Sun keyboard from hell
(tm).
>Description:
Attempted to install FReeBSD 5.0 RC3 on Sparc with system console.
(OpenFirmware console and standard Sun keyboard).
Install kernel prompt comes up with numerous choices for
serial consoles, but none for the native console! Various
choices all fail -- some produce garbled output, others are
readable but don't highlight text and don't parse basic
keyboard operations (such as up arrow).
>How-To-Repeat:
Boot FreeBSD 5.0 install CDROM on ultra Sparc with a real console.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
------------------------------
Date: Fri, 17 Jan 2003 15:04:38 -0800 (PST)
From: Kris Kennaway <kr...@FreeBSD.org>
Subject: Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install
Synopsis: Sparc Ultra 5/10 console not usable for FreeBSD install
State-Changed-From-To: open->closed
State-Changed-By: kris
State-Changed-When: Fri Jan 17 15:03:59 PST 2003
State-Changed-Why:
Yes, console support is not yet available.
http://www.freebsd.org/cgi/query-pr.cgi?pr=47175
------------------------------
Date: Fri, 17 Jan 2003 15:10:07 -0800 (PST)
From: Kris Kennaway <kr...@obsecurity.org>
Subject: Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install
The following reply was made to PR sparc64/47175; it has been noted by GNATS.
From: Kris Kennaway <kr...@obsecurity.org>
To: Drew Derbyshire <a...@gnats.plus.kew.com>
Cc: FreeBSD-gn...@FreeBSD.ORG
Subject: Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install
Date: Fri, 17 Jan 2003 15:03:28 -0800
On Fri, Jan 17, 2003 at 05:56:10PM -0500, Drew Derbyshire wrote:
> Install kernel prompt comes up with numerous choices for
> serial consoles, but none for the native console! Various
> choices all fail -- some produce garbled output, others are
> readable but don't highlight text and don't parse basic
> keyboard operations (such as up arrow).
"Yes" :-)
i.e. well-known, documented limitation.
Kris
------------------------------
Date: Sat, 18 Jan 2003 13:03:44 +0000
From: Nick Jones <ni...@freebsd.cx>
Subject: Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install
On Fri, 17 Jan 2003 at 17:56:10 -0500, Drew Derbyshire wrote:
> Install kernel prompt comes up with numerous choices for
> serial consoles, but none for the native console! Various
> choices all fail -- some produce garbled output, others are
> readable but don't highlight text and don't parse basic
> keyboard operations (such as up arrow).
It *is* possible, albeit somewhat fiddly. Using termtype selection 1, you can
use Ctrl-N and Ctrl-P to move up and down the list (you will see the cursor
flash on the screen momentarily indictating the menu choice), space to select,
and Ctrl-D to delete.
Like I say - fiddly, but better than nothing if for some reason you are unable
to install via a serial console :)
- --
/Nick
------------------------------
Date: Sat, 18 Jan 2003 14:30:26 -0800
From: "David O'Brien" <obr...@freebsd.org>
Subject: Re: Sparc64 floating point questions
On Tue, Jan 14, 2003 at 04:47:23PM -0800, John Polstra wrote:
> I don't know much about Sparc machines. But it sounds like there
> exist 64-bit Sparcs which are not UltraSPARCs. So I'd better do it
> the most general way.
I'd have to stretch my brain to be sure about that (maybe the Fujitsu
HAL?). For FreeBSD's purposes, you should assume that all 64-bit Sparcs
are UltraSPARC's. That is certainly how I have the toolchain configured.
------------------------------
End of freebsd-sparc-digest V5 #219
***********************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-sparc-digest in the body of the message