Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-sparc-digest V5 #221

0 views

Skip to first unread message

owner-freebsd...@freebsd.org

unread,

Jan 21, 2003, 5:47:06 AM1/21/03

freebsd-sparc-digest Tuesday, January 21 2003 Volume 05 : Number 221

In this issue:
Re: Problem with iommu_dvmamap_create
Re: Problem with iommu_dvmamap_create
Re: Problem with iommu_dvmamap_create
Netra X1 & Davicom ethernet
Re: Netra X1 & Davicom ethernet
Re: Netra X1 & Davicom ethernet
Re: Problem with iommu_dvmamap_create
Re: Problem with iommu_dvmamap_create
FreeBSD 5.0-RELEASE first install on an Ultra60
Re: FreeBSD 5.0-RELEASE first install on an Ultra60
Re: Problem with iommu_dvmamap_create

----------------------------------------------------------------------

Date: Mon, 20 Jan 2003 10:52:11 +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 18:19:59 +0100, Harti Brandt wrote:
TM>> On Fri, 17 Jan 2003, Thomas Moestl wrote:
TM>> TM>BUS_DMAMAP_NSEGS (and BUS_SPACE_MAXSIZE) is pretty arbitrary, the only
TM>> TM>thing to limit is the stack space used by the segment array. In the
TM>> TM>current setting, 272 bytes are used at most, which is less than 1.5
TM>> TM>minimal function frames. Values such as 64 should still be OK.
TM>>
TM>> Would it be possible if you change it just there?
TM>
TM>Yes, I'll do that with the next update.

Thanks.

Just while I could not sleep last night, it occured to me, that the code
should work without even this change when the kernel is compiled with gcc.
The code in iommu.c and bus_machdep.c use #ifdef __GNUC__ to use dynamic
arrays on stack that have size ddmat->dt_nsegements size. So if I create a
tag with a number of segments large enough, the arrays should be large
enough. The only problem should be, that the size check around line 823 in
iommu.c should also be conditionalized (for __GCC__ BUS_DMAMAP_NSEGS
should not be checked.) Well, for some reason, that seems not to work.

TM>So do I. Can you maybe put the full code of the driver in question
TM>somewhere for download?

Ok, I've put if_hatm.tar.bz into
ftp://ftp.fokus.gmd.de/pub/cats/usr/harti/ngatm. Beware, this is my
working code. The tag in question is the tx_tag and is created in
if_hatm.c:1699. The DMAMAPs with this tag are create in if_hatm.c:465.
They are used then in if_hatm_tx.c. The bug is triggered, however, even by
only creating them. The first sign of the bug is that the card does not
update the interrupt status words. These are dma-ed into the queue
controlled by the irq_0 member of struct hatm_softc. I suppose the DMA
goes somewhere else, because soon after that usually something bad happens
to the system.

harti
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de

------------------------------

Date: Mon, 20 Jan 2003 16:17:12 +0100
From: Thomas Moestl <t...@freebsd.org>
Subject: Re: Problem with iommu_dvmamap_create

On Mon, 2003/01/20 at 10:52:11 +0100, Harti Brandt wrote:
> On Fri, 17 Jan 2003, Thomas Moestl wrote:
>
> TM>On Fri, 2003/01/17 at 18:19:59 +0100, Harti Brandt wrote:
> TM>> On Fri, 17 Jan 2003, Thomas Moestl wrote:
> TM>> TM>BUS_DMAMAP_NSEGS (and BUS_SPACE_MAXSIZE) is pretty arbitrary, the only
> TM>> TM>thing to limit is the stack space used by the segment array. In the
> TM>> TM>current setting, 272 bytes are used at most, which is less than 1.5
> TM>> TM>minimal function frames. Values such as 64 should still be OK.
> TM>>
> TM>> Would it be possible if you change it just there?
> TM>
> TM>Yes, I'll do that with the next update.
>
> Thanks.
>
> Just while I could not sleep last night, it occured to me, that the code
> should work without even this change when the kernel is compiled with gcc.
> The code in iommu.c and bus_machdep.c use #ifdef __GNUC__ to use dynamic
> arrays on stack that have size ddmat->dt_nsegements size. So if I create a
> tag with a number of segments large enough, the arrays should be large
> enough. The only problem should be, that the size check around line 823 in
> iommu.c should also be conditionalized (for __GCC__ BUS_DMAMAP_NSEGS
> should not be checked.) Well, for some reason, that seems not to work.

Hmmm, how does it fail?

> TM>So do I. Can you maybe put the full code of the driver in question
> TM>somewhere for download?
>
> Ok, I've put if_hatm.tar.bz into
> ftp://ftp.fokus.gmd.de/pub/cats/usr/harti/ngatm. Beware, this is my
> working code. The tag in question is the tx_tag and is created in
> if_hatm.c:1699. The DMAMAPs with this tag are create in if_hatm.c:465.
> They are used then in if_hatm_tx.c. The bug is triggered, however, even by
> only creating them. The first sign of the bug is that the card does not
> update the interrupt status words. These are dma-ed into the queue
> controlled by the irq_0 member of struct hatm_softc. I suppose the DMA
> goes somewhere else, because soon after that usually something bad happens
> to the system.

From a quick inspection, I can see one class of problems (which might
or might not be the cause for this specific behaviour, but will cause
trouble in any case): you need to do endiannes conversions for memory
that is accessed by DMA and interpreted or written by the
adapter. Since it is a PCI card, it operates on little-endian
data. While the bus_space_* functions know the access size and will
automatically do endianess conversions for you (unless you use the
stream variants of them), there is no way to automatically do this for
DMA (unless we can guarantee that the access size is always the
desired datum size, which we cannot, and even then it would be
non-portable).
This would e.g. explain a bogus interrupt status word: since it is
written by the adapter, it needs to be converted to host byte order
before it is interpreted; the following:

while (q->head != tail) {
status = q->irq[q->head];
q->irq[q->head] = HE_REGM_ITYPE_INVALID;

would become:

while (q->head != tail) {
status = le32toh(q->irq[q->head]);
q->irq[q->head] = htole32(HE_REGM_ITYPE_INVALID);

Similarly, the fields in the various descriptor structures defined in
if_hatmreg.h need to be converted (since it looks like the adapter
DMAs them to find out target addresses etc.). This would cause wrong
addresses to be used for DMA; it's not unlikely that those addresses
would be outside of the target address space of the host bridge, so
they could be interpreted as writes to other PCI devices (or cause bus
errors if there is no such target device).

- 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: Mon, 20 Jan 2003 16:40:56 +0100 (CET)
From: Harti Brandt <bra...@fokus.gmd.de>
Subject: Re: Problem with iommu_dvmamap_create

On Mon, 20 Jan 2003, Thomas Moestl wrote:

TM>On Mon, 2003/01/20 at 10:52:11 +0100, Harti Brandt wrote:
TM>> On Fri, 17 Jan 2003, Thomas Moestl wrote:
TM>>
TM>> Just while I could not sleep last night, it occured to me, that the code
TM>> should work without even this change when the kernel is compiled with gcc.
TM>> The code in iommu.c and bus_machdep.c use #ifdef __GNUC__ to use dynamic
TM>> arrays on stack that have size ddmat->dt_nsegements size. So if I create a
TM>> tag with a number of segments large enough, the arrays should be large
TM>> enough. The only problem should be, that the size check around line 823 in
TM>> iommu.c should also be conditionalized (for __GCC__ BUS_DMAMAP_NSEGS
TM>> should not be checked.) Well, for some reason, that seems not to work.
TM>
TM>Hmmm, how does it fail?

Trying to send a 60000 byte PDU gives me the following:

hatm0: <FORE HE> mem 0x100000-0x1fffff irq 20 at device 2.0 on pci1
hatm: hw.hatm0.rbps0.size=32
hatm: hw.hatm0.rbps0.thresh=8
hatm: hw.hatm0.rbpl0.size=32
hatm: hw.hatm0.rbpl0.thresh=8
hatm: hw.hatm0.rbps1.size=32
hatm: hw.hatm0.rbps1.thresh=8
hatm0: ForeRunnerHE 155, Rev. B, S/N 5705534, MAC=00:20:48:57:0f:3e
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
iommu_dvmamap_load_buffer: too many segments.
seg[0]=tpd[1,0]=c02d8800/2048
seg[1]=tpd[1,1]=c02da800/2048
seg[2]=tpd[1,2]=c02dd000/2048
seg[3]=tpd[2,0]=c02de800/2048
seg[4]=tpd[2,1]=c02e0000/2048
seg[5]=tpd[2,2]=c02e3800/2048
seg[6]=tpd[3,0]=c02e5000/2048
seg[7]=tpd[3,1]=c02e6800/2048
seg[8]=tpd[3,2]=c02e8000/2048
seg[9]=tpd[4,0]=c02eb800/2048
seg[10]=tpd[4,1]=c02ed000/2048
seg[11]=tpd[4,2]=c02ee800/2048
seg[12]=tpd[5,0]=c02f0000/2048
seg[13]=tpd[5,1]=c0c67800/2048
seg[14]=tpd[5,2]=c0c69000/2048
seg[15]=tpd[6,0]=c0c6a800/2048
seg[16]=tpd[6,1]=c0c6c000/2048
seg[17]=tpd[6,2]=17f02cc0/1077936128
seg[18]=tpd[7,0]=1/3438465064
seg[19]=tpd[7,1]=ccf2d010/3438465048
seg[20]=tpd[7,2]=ccf2c711/3222760340
seg[21]=tpd[8,0]=f/0
seg[22]=tpd[8,1]=432a330/324612608
seg[23]=tpd[8,2]=1390b550/77178368
seg[24]=tpd[9,0]=16d20570/0
seg[25]=tpd[9,1]=ccf2da80/3223451912
seg[26]=tpd[9,2]=7def510/132025856
seg[27]=tpd[10,0]=0/0
seg[28]=tpd[10,1]=17f178c0/0
seg[29]=tpd[10,2]=0/1077936128

Starting at seg[17] the segments are simply wrong. The number of segments
in the tag is 39 so this should work. (The numbers are the phys address
and segment length).

TM>>From a quick inspection, I can see one class of problems (which might
TM>or might not be the cause for this specific behaviour, but will cause
TM>trouble in any case): you need to do endiannes conversions for memory
TM>that is accessed by DMA and interpreted or written by the
TM>adapter. Since it is a PCI card, it operates on little-endian
TM>data. While the bus_space_* functions know the access size and will
[...]

The card is desgined for operation in LE and BE systems. It has a register
where you set bits which tell the card to swap the data during DMA. There
is a function hatm_init_endianess, which sets the right bits.

TM>This would e.g. explain a bogus interrupt status word: since it is
TM>written by the adapter, it needs to be converted to host byte order
TM>before it is interpreted; the following:
TM>
TM> while (q->head != tail) {
TM> status = q->irq[q->head];
TM> q->irq[q->head] = HE_REGM_ITYPE_INVALID;
TM>
TM>would become:
TM>
TM> while (q->head != tail) {
TM> status = le32toh(q->irq[q->head]);
TM> q->irq[q->head] = htole32(HE_REGM_ITYPE_INVALID);

This is really not the problem. When I create tx_tag with a maximum of 1
segment, the receive function of the card works (that means interrupt
status is correctly processed, receive queues and buffers are correctly
red and written). When I create tx_tag with a number of segments > 1 than
only creating a couple of DMA maps with this tag (not using them at all)
entirly confuses operation.

But as I said already - with your patch applied it seems to work (albeit
not very stable, but this may be my fault).

harti
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de

------------------------------

Date: Mon, 20 Jan 2003 18:44:07 +0100
From: fra...@i-m-c.it
Subject: Netra X1 & Davicom ethernet

- --17pEHd4RhPHOinZp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,
I have installed the latest snapshot on my netra X1,=20
and, how i know, the if_dc driver is not working.

My question is simple: when the if_dc drivers will work on sparc64?

I'm ansious to work with my machine :)

thanks and Regards, and good work!

- --=20

Franco (nextime) Lanza - i-m-c.it
Network Admin
tel: +39 339 8125940
tel: +39 347 3243736
Milano - Italy

you can download my public key at:
http://danex.i-m-c.it/nextime.asc || Key Servers
Key fingerprint =3D E4EF A5B7 7B93 0499 2832 D375 F437 D880 83D5 E711
- -----------------------------------

- --17pEHd4RhPHOinZp
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+LDVn9DfYgIPV5xERAjs6AKCBS1zWrcrWu0XVy0/sHPNl5THzywCgjxrV
z7TV4+7juDAAunQIC9KU3zo=
=jH1J
- -----END PGP SIGNATURE-----

- --17pEHd4RhPHOinZp--

------------------------------

Date: Mon, 20 Jan 2003 09:46:48 -0800
From: Maxime Henrion <m...@freebsd.org>
Subject: Re: Netra X1 & Davicom ethernet

fra...@i-m-c.it wrote:
> Hello,
> I have installed the latest snapshot on my netra X1,
> and, how i know, the if_dc driver is not working.
>
> My question is simple: when the if_dc drivers will work on sparc64?
>
> I'm ansious to work with my machine :)
>
> thanks and Regards, and good work!

The dc(4) driver needs to be converted to the busdma API before working
on sparc64. It's next on my TODO list and I'll take care of it once I'm
finished with fxp(4).

Once it's converted to busdma, it will need to be fixed WRT endianness
issues and then it should just work.

Cheers,
Maxime

------------------------------

Date: Mon, 20 Jan 2003 11:07:59 -0800
From: "David O'Brien" <obr...@freebsd.org>
Subject: Re: Netra X1 & Davicom ethernet

On Mon, Jan 20, 2003 at 06:44:07PM +0100, fra...@i-m-c.it wrote:
> Hello,
> I have installed the latest snapshot on my netra X1,
> and, how i know, the if_dc driver is not working.
...
> I'm ansious to work with my machine :)

If you have an empty PCI slot, you can pick up a $5 Realtek card and use
that. Jake got that working not too long ago. Tmm also committed
changes to the 3c90x driver (xl) so that it will work on [some] sparc64
machines.

------------------------------

Date: Mon, 20 Jan 2003 20:29:46 +0100
From: Thomas Moestl <t...@freebsd.org>
Subject: Re: Problem with iommu_dvmamap_create

On Mon, 2003/01/20 at 16:40:56 +0100, Harti Brandt wrote:
> On Mon, 20 Jan 2003, Thomas Moestl wrote:
>
> TM>On Mon, 2003/01/20 at 10:52:11 +0100, Harti Brandt wrote:
> TM>> On Fri, 17 Jan 2003, Thomas Moestl wrote:
> TM>>
> TM>> Just while I could not sleep last night, it occured to me, that the code
> TM>> should work without even this change when the kernel is compiled with gcc.
> TM>> The code in iommu.c and bus_machdep.c use #ifdef __GNUC__ to use dynamic
> TM>> arrays on stack that have size ddmat->dt_nsegements size. So if I create a
> TM>> tag with a number of segments large enough, the arrays should be large
> TM>> enough. The only problem should be, that the size check around line 823 in
> TM>> iommu.c should also be conditionalized (for __GCC__ BUS_DMAMAP_NSEGS
> TM>> should not be checked.) Well, for some reason, that seems not to work.
> TM>
> TM>Hmmm, how does it fail?
>
> Trying to send a 60000 byte PDU gives me the following:
>
> hatm0: <FORE HE> mem 0x100000-0x1fffff irq 20 at device 2.0 on pci1
> hatm: hw.hatm0.rbps0.size=32
> hatm: hw.hatm0.rbps0.thresh=8
> hatm: hw.hatm0.rbpl0.size=32
> hatm: hw.hatm0.rbpl0.thresh=8
> hatm: hw.hatm0.rbps1.size=32
> hatm: hw.hatm0.rbps1.thresh=8
> hatm0: ForeRunnerHE 155, Rev. B, S/N 5705534, MAC=00:20:48:57:0f:3e
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> iommu_dvmamap_load_buffer: too many segments.
> seg[0]=tpd[1,0]=c02d8800/2048
> seg[1]=tpd[1,1]=c02da800/2048
> seg[2]=tpd[1,2]=c02dd000/2048
> seg[3]=tpd[2,0]=c02de800/2048
> seg[4]=tpd[2,1]=c02e0000/2048
> seg[5]=tpd[2,2]=c02e3800/2048
> seg[6]=tpd[3,0]=c02e5000/2048
> seg[7]=tpd[3,1]=c02e6800/2048
> seg[8]=tpd[3,2]=c02e8000/2048
> seg[9]=tpd[4,0]=c02eb800/2048
> seg[10]=tpd[4,1]=c02ed000/2048
> seg[11]=tpd[4,2]=c02ee800/2048
> seg[12]=tpd[5,0]=c02f0000/2048
> seg[13]=tpd[5,1]=c0c67800/2048
> seg[14]=tpd[5,2]=c0c69000/2048
> seg[15]=tpd[6,0]=c0c6a800/2048
> seg[16]=tpd[6,1]=c0c6c000/2048
> seg[17]=tpd[6,2]=17f02cc0/1077936128
> seg[18]=tpd[7,0]=1/3438465064
> seg[19]=tpd[7,1]=ccf2d010/3438465048
> seg[20]=tpd[7,2]=ccf2c711/3222760340
> seg[21]=tpd[8,0]=f/0
> seg[22]=tpd[8,1]=432a330/324612608
> seg[23]=tpd[8,2]=1390b550/77178368
> seg[24]=tpd[9,0]=16d20570/0
> seg[25]=tpd[9,1]=ccf2da80/3223451912
> seg[26]=tpd[9,2]=7def510/132025856
> seg[27]=tpd[10,0]=0/0
> seg[28]=tpd[10,1]=17f178c0/0
> seg[29]=tpd[10,2]=0/1077936128
>
> Starting at seg[17] the segments are simply wrong. The number of segments
> in the tag is 39 so this should work. (The numbers are the phys address
> and segment length).

Hmmmm, looks like the printf() part of the size check is still intact,
did you forget to remove the break statement maybe? I don't see
anything else that would make it stop exactly at BUS_DMAMAP_NSEGS.

> TM>>From a quick inspection, I can see one class of problems (which might
> TM>or might not be the cause for this specific behaviour, but will cause
> TM>trouble in any case): you need to do endiannes conversions for memory
> TM>that is accessed by DMA and interpreted or written by the
> TM>adapter. Since it is a PCI card, it operates on little-endian
> TM>data. While the bus_space_* functions know the access size and will
> [...]
>
> The card is desgined for operation in LE and BE systems. It has a register
> where you set bits which tell the card to swap the data during DMA. There
> is a function hatm_init_endianess, which sets the right bits.

Ahhh, sorry, I didn't notice that. Nifty feature.

> This is really not the problem. When I create tx_tag with a maximum of 1
> segment, the receive function of the card works (that means interrupt
> status is correctly processed, receive queues and buffers are correctly
> red and written). When I create tx_tag with a number of segments > 1 than
> only creating a couple of DMA maps with this tag (not using them at all)
> entirly confuses operation.
>
> But as I said already - with your patch applied it seems to work (albeit
> not very stable, but this may be my fault).

Yes, but I strongly suspect that the bug is only hidden by it,
probably because it corrects the semantics of IOMMU_MAX_PRE_SEG, which
effectively results in preallocation being reduced by one segment. I
finally managed to reproduce similar behaviour, and think I might have
a real fix. Can you please revert the previous patch (just to get a
clean environment for reproducing the behaviour) and try again with
just the attached patch applied?

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: Mon, 20 Jan 2003 20:41:32 +0100
From: Thomas Moestl <t...@freebsd.org>
Subject: Re: Problem with iommu_dvmamap_create

- --vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, 2003/01/20 at 20:29:46 +0100, Thomas Moestl wrote:
> Yes, but I strongly suspect that the bug is only hidden by it,
> probably because it corrects the semantics of IOMMU_MAX_PRE_SEG, which
> effectively results in preallocation being reduced by one segment. I
> finally managed to reproduce similar behaviour, and think I might have
> a real fix. Can you please revert the previous patch (just to get a
> clean environment for reproducing the behaviour) and try again with
> just the attached patch applied?

Bah, actually attaching it might help.

- 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

- --vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="iommu-sz.diff"

Index: sparc64/iommu.c
===================================================================
RCS file: /ncvs/src/sys/sparc64/sparc64/iommu.c,v
retrieving revision 1.14
diff -u -r1.14 iommu.c
- --- sparc64/iommu.c 6 Jan 2003 21:59:54 -0000 1.14
+++ sparc64/iommu.c 20 Jan 2003 19:17:47 -0000
@@ -288,6 +288,7 @@
struct iommu_state *first;
vm_size_t size;
vm_offset_t offs;
+ u_int64_t end;
int i;

/*
@@ -317,13 +318,13 @@
* First IOMMU to be registered; set up resource mamangement
* and allocate TSB memory.
*/
+ end = is->is_dvmabase + (size << (IO_PAGE_SHIFT - IOTTE_SHIFT));
iommu_dvma_rman.rm_type = RMAN_ARRAY;
iommu_dvma_rman.rm_descr = "DVMA Memory";
if (rman_init(&iommu_dvma_rman) != 0 ||
rman_manage_region(&iommu_dvma_rman,
(is->is_dvmabase >> IO_PAGE_SHIFT) + resvpg,
- - (is->is_dvmabase + (size <<
- - (IO_PAGE_SHIFT - IOTTE_SHIFT))) >> IO_PAGE_SHIFT) != 0)
+ (end >> IO_PAGE_SHIFT) - 1) != 0)
panic("iommu_init: can't initialize dvma rman");
/*
* Allocate memory for I/O page tables. They need to be

- --vtzGhvizbBRQ85DL--

------------------------------

Date: Mon, 20 Jan 2003 21:52:08 -0000
From: "Andy Coates" <an...@bribed.net>
Subject: FreeBSD 5.0-RELEASE first install on an Ultra60

Hello,

Hoping someone is wise enough on here to help me out. I'm having
trouble installing the just released 5.0 for sparc64 on my Ultra60. The
install prompts you to choose a terminal type, but all 5 simply don't
have a the arrow-keys functionality, so I can't progress through the
install.

Anyone know a way of getting this to work? (without a serial cable,
although if it does push the console out ala solaris then at least I
can find a cable, but at the moment I'm stuck with a PC monitor).

Thanks,
Andy.

------------------------------

Date: Tue, 21 Jan 2003 07:24:39 +0000
From: "Francis little" <og...@hayesbrook.kent.sch.uk>
Subject: Re: FreeBSD 5.0-RELEASE first install on an Ultra60

Your best bet is with a serial cable...

>>> "Andy Coates" <an...@bribed.net> 01/20/03 09:52pm >>>
Hello,

Thanks,
Andy.

------------------------------

Date: Tue, 21 Jan 2003 11:46:55 +0100 (CET)
From: Harti Brandt <bra...@fokus.fraunhofer.de>
Subject: Re: Problem with iommu_dvmamap_create

On Mon, 20 Jan 2003, Thomas Moestl wrote:

TM>On Mon, 2003/01/20 at 16:40:56 +0100, Harti Brandt wrote:
TM>> On Mon, 20 Jan 2003, Thomas Moestl wrote:
TM>>
TM>> seg[15]=tpd[6,0]=c0c6a800/2048
TM>> seg[16]=tpd[6,1]=c0c6c000/2048
TM>> seg[17]=tpd[6,2]=17f02cc0/1077936128
TM>> seg[18]=tpd[7,0]=1/3438465064
TM>> seg[19]=tpd[7,1]=ccf2d010/3438465048
TM>> seg[20]=tpd[7,2]=ccf2c711/3222760340
TM>> seg[21]=tpd[8,0]=f/0
TM>> seg[22]=tpd[8,1]=432a330/324612608
TM>> seg[23]=tpd[8,2]=1390b550/77178368
TM>> seg[24]=tpd[9,0]=16d20570/0
TM>> seg[25]=tpd[9,1]=ccf2da80/3223451912
TM>> seg[26]=tpd[9,2]=7def510/132025856
TM>> seg[27]=tpd[10,0]=0/0
TM>> seg[28]=tpd[10,1]=17f178c0/0
TM>> seg[29]=tpd[10,2]=0/1077936128
TM>>
TM>> Starting at seg[17] the segments are simply wrong. The number of segments
TM>> in the tag is 39 so this should work. (The numbers are the phys address
TM>> and segment length).
TM>
TM>Hmmmm, looks like the printf() part of the size check is still intact,
TM>did you forget to remove the break statement maybe? I don't see
TM>anything else that would make it stop exactly at BUS_DMAMAP_NSEGS.

With the attached patch it looks better - it removes the check for
BUS_DMAMAP_NSEGS and also adds a break for promoting the error from
load_buffer back to load_mbuf and exit the loop there in case of an error.
(Sorry, the patch contains also the patch that you sent in your last
mail).

TM>Yes, but I strongly suspect that the bug is only hidden by it,
TM>probably because it corrects the semantics of IOMMU_MAX_PRE_SEG, which
TM>effectively results in preallocation being reduced by one segment. I
TM>finally managed to reproduce similar behaviour, and think I might have
TM>a real fix. Can you please revert the previous patch (just to get a
TM>clean environment for reproducing the behaviour) and try again with
TM>just the attached patch applied?

That seems to work. I have reverted both the change to subr_rman.c and
iommu.c (1.14) before applying your patch.

Thanks,
harti
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de

------------------------------

End of freebsd-sparc-digest V5 #221
***********************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-sparc-digest in the body of the message

0 new messages