In this issue:
Sun Ultra 10 + FreeBSD 5.0
PCI-PCI bridge
Re: PCI-PCI bridge
Ultra1 status?
Re: PCI-PCI bridge
Re: PCI-PCI bridge
Re: PCI-PCI bridge
sparc64 tinderbox failure
----------------------------------------------------------------------
Date: Sun, 23 Mar 2003 21:55:57 +0100
From: <Magnus....@telia.se>
Subject: Sun Ultra 10 + FreeBSD 5.0
Hi..
=20
I'm trying to install FreeBSD 5.0 on a Sun Ultra 10 Sparc64 box.. :-\
=20
I've read some stuff about no consoll support.. but succeeded in =
installing the operative system and getting network.
=20
The installation-meny from hell is hackable with this tip.. (got it off =
a maillist)
- -------------------------------------------------------------------------=
- -------------------------------
Choose termtyp 1 in the installationsprompt.
Use Ctrl-N and Ctrl-P to move up and down.. you'll see the mouse pointer =
flash quickly at the
alternetive that's choosen. Then use TAB to move between windows.
Enter/Space to choose stuff and Ctrl-D to delete.
- -------------------------------------------------------------------------=
- -------------------------------
=20
Next step after getting network up n running is XFree86..
When tryin' to install from /usr/ports/x11/XFree86 it doesnt go very =
well though..
I get acouple of critical Error 1 in the (final stage?!) of the =
compilation resulting in
failure of the installation.
=20
(I don't got the errors i get but on request i can reproduce em.. (take =
3 hours of compiling to get em that's why i dont include em here))
=20
Anyone here that succeeded in installing FreeBSD for Sun Ultra 5/10? or =
got any experience that is relevant and might be of help?
=20
Best regards,
//Magnus Glantz
=20
------------------------------
Date: Mon, 24 Mar 2003 14:04:35 +0900
From: Hidetoshi Shimokawa <simo...@sat.t.u-tokyo.ac.jp>
Subject: PCI-PCI bridge
Hi,
I have a problem with PCI-PCI bridge on sparc64(sun ultra5) while
tesing firewire driver.
I have a Adaptec card which has a firewire and a USB2 chips behind
PCI-PCI bridge. With this card the DMA trasfer speed is poor and
it sometimes causes timeout which leads to panic(*1).
I finally found that this is because the PCI-PCI bridge
is not configured correctly and setting the cache line size in the
bridge by pciconf fixes the problem.
(pciconf -w -b pci1:1:0 0x0c 16)
Sun's APB PCI-PCI bridges seem to be configured correctly but the one on
the card doesn't.
Who should configure such bridges?
Does upgrading firmware fix the problem?
(*1) device reports timeouts while DMA transfer is active and
unloading dmamap causes accesss faults.
/\ Hidetoshi Shimokawa
\/ simo...@sat.t.u-tokyo.ac.jp
PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html
output of dmesg and pciconf -lv follows:
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #4: Wed Mar 19 16:50:44 JST 2003
simo...@ett.sat.t.u-tokyo.ac.jp:/export/dpt/FreeBSD/obj/sparc64/export/dpt/FreeBSD/FreeBSD-current/src/sys/TAURUS
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0518000.
Timecounter "tick" frequency 360000000 Hz
cpu0: Sun Microsystems UltraSparc-IIi Processor (360.00 MHz CPU)
Model: SUNW,Ultra-5_10
Allocating major#253 to "net"
Allocating major#252 to "pci"
nexus0: <OpenFirmware Nexus device>
pcib0: <U2P UPA-PCI bridge> on nexus0
pcib0: Sabre, impl 0, version 0, ign 0x7c0
DVMA map: 0xc0000000 to 0xc7ffffff
PCI-PCI bridge at 0/1/1: setting bus #s to 0/1/1
pcib0: ofw_pci_init: descending to subordinate PCI bus
device 1/1/0: latency timer 0 -> 82
pcib0: ofw_pci_init: no interrupt mapping found for 1/1/0 (preset 0)
device 1/1/1: latency timer 0 -> 82
pcib0: ofw_pci_init: mapping intr for 1/1/1 to 33 (preset was 0)
device 1/2/0: latency timer 0 -> 66
pcib0: ofw_pci_init: mapping intr for 1/2/0 to 15 (preset was 15)
device 1/3/0: latency timer 0 -> 16
pcib0: ofw_pci_init: mapping intr for 1/3/0 to 32 (preset was 14)
PCI-PCI bridge at 0/1/0: setting bus #s to 0/2/2
pcib0: ofw_pci_init: descending to subordinate PCI bus
PCI-PCI bridge at 0/1/0: setting bus #s to 0/2/3
PCI-PCI bridge at 2/1/0: setting bus #s to 2/3/3
pcib0: ofw_pci_init: descending to subordinate PCI bus
device 3/8/0: latency timer 8 -> 8
pcib0: ofw_pci_init: mapping intr for 3/8/0 to 16 (preset was 0)
device 3/8/1: latency timer 8 -> 8
pcib0: ofw_pci_init: mapping intr for 3/8/1 to 17 (preset was 0)
device 3/8/2: latency timer 68 -> 132
pcib0: ofw_pci_init: mapping intr for 3/8/2 to 18 (preset was 0)
device 3/11/0: latency timer 0 -> 24
pcib0: ofw_pci_init: mapping intr for 3/11/0 to 19 (preset was 0)
pci0: <PCI bus> on pcib0
pcib1: <APB PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pcib2: <PCI-PCI bridge> at device 1.0 on pci1
pci3: <PCI bus> on pcib2
pci3: <serial bus, USB> at device 8.0 (no driver attached)
pci3: <serial bus, USB> at device 8.1 (no driver attached)
pci3: <serial bus, USB> at device 8.2 (no driver attached)
pci3: <serial bus, FireWire> at device 11.0 (no driver attached)
pcib3: <APB PCI-PCI bridge> at device 1.1 on pci0
pci2: <PCI bus> on pcib3
ebus0: revision 0x01
ebus0: <PCI-EBus2 bridge> mem 0xf1000000-0xf17fffff,0xf0000000-0xf0ffffff at device 1.0 on pci2
ebus0: <auxio> addr 0x140072f000-0x140072f003,0x140072c000-0x140072c003,0x140072a000-0x140072a003,0x1400728000-0x1400728003,0x1400726000-0x1400726003 (no driver attached)
ebus0: <power> addr 0x1400724000-0x1400724003 irq 37 (no driver attached)
ebus0: <SUNW,pll> addr 0x1400504000-0x1400504002 (no driver attached)
sab0: <Siemens SAB 82532 v3.2> addr 0x1400400000-0x140040007f irq 43 on ebus0
sabtty0: <ttya> on sab0
Allocating major#251 to "sabtty"
sabtty0: console 9600,8,n,1,-
sabtty1: <ttyb> on sab0
ebus0: <su> addr 0x14003083f8-0x14003083ff irq 41 (no driver attached)
ebus0: <su> addr 0x14003062f8-0x14003062ff irq 42 (no driver attached)
ebus0: <ecpp> addr 0x1400700000-0x140070000f,0x140030015c-0x140030015d,0x14003043bc-0x14003043cb irq 34 (no driver attached)
ebus0: <fdthree> addr 0x1400720000-0x1400720003,0x1400706000-0x140070600f,0x14003023f0-0x14003023f7 irq 39 (no driver attached)
eeprom0: <EBus EEPROM/clock> addr 0x1400000000-0x1400001fff on ebus0
eeprom0: model mk48t59
eeprom0: hostid 80b94520
ebus0: <flashprom> addr 0x1000000000-0x10000fffff (no driver attached)
ebus0: <SUNW,CS4231> addr 0x1400722000-0x1400722003,0x1400704000-0x140070400f,0x1400702000-0x140070200f,0x1400200000-0x14002000ff irq 36,35 (no driver attached)
hme0: <Sun HME 10/100 Ethernet> mem 0xe0000000-0xe0007fff irq 33 at device 1.1 on pci2
hme0: Ethernet address: 08:00:20:b9:45:20
miibus0: <MII bus> on hme0
nsphy0: <DP83840 10/100 media interface> on miibus0
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci2: <display, VGA> at device 2.0 (no driver attached)
atapci0: <CMD 646 WDMA2 controller> port 0xc00020-0xc0002f,0xc00018-0xc0001b,0xc00010-0xc00017,0xc00008-0xc0000b,0xc00000-0xc00007 irq 32 at device 3.0 on pci2
ata2: at 0xc00000 on atapci0
ata3: at 0xc00010 on atapci0
dcons: virtual 0xca354000 physical 0xc060c000 quad 0x30183000
Allocating major#250 to "dcons"
Timecounters tick every 10.000 msec
Allocating major#249 to "devstat"
ad0: 8223MB <ST38420A> [16708/16/63] at ata2-master WDMA2
acd0: CDROM <CRD-8322B> at ata3-master PIO4
Mounting root from nfs:133.11.135.3:/export/dpt/diskless/root/naiad
setrootbyname failed
NFS ROOT: 133.11.135.3:/export/dpt/diskless/root/taurus
ohci0: <NEC uPD 9210 USB controller> mem 0x100000-0x100fff irq 16 at device 8.0 on pci3
usb0: OHCI version 1.0
usb0: <NEC uPD 9210 USB controller> on ohci0
usb0: USB revision 1.0
uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1: <NEC uPD 9210 USB controller> mem 0x102000-0x102fff irq 17 at device 8.1 on pci3
usb1: OHCI version 1.0
usb1: <NEC uPD 9210 USB controller> on ohci1
usb1: USB revision 1.0
uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
fwohci0: <Texas Instruments TSB12LV26> mem 0x108000-0x10bfff,0x106000-0x1067ff irq 19 at device 11.0 on pci3
fwohci0: driver version 2
fwohci0: OHCI version 1.0 (ROM=1)
fwohci0: No. of Isochronous channel is 4.
pcib1@pci0:1:0: class=0x060400 card=0x00000000 chip=0x5000108e rev=0x13 hdr=0x01
vendor = 'Sun Microsystems'
device = 'SME2411 UltraSPARC-IIi Advanced PCI Bridge'
class = bridge
subclass = PCI-PCI
pcib3@pci0:1:1: class=0x060400 card=0x00000000 chip=0x5000108e rev=0x13 hdr=0x01
vendor = 'Sun Microsystems'
device = 'SME2411 UltraSPARC-IIi Advanced PCI Bridge'
class = bridge
subclass = PCI-PCI
pcib2@pci2:1:0: class=0x060400 card=0x00000080 chip=0x00213388 rev=0x13 hdr=0x01
vendor = 'Hint Corp.'
device = 'HB1-SE33 PCI-to-PCI Bridge'
class = bridge
subclass = PCI-PCI
ohci0@pci3:8:0: class=0x0c0310 card=0x02359004 chip=0x00351033 rev=0x41 hdr=0x00
vendor = 'NEC Electronics Hong Kong'
device = 'uPD9210FGC-7EA USB Host Controller'
class = serial bus
subclass = USB
ohci1@pci3:8:1: class=0x0c0310 card=0x02359004 chip=0x00351033 rev=0x41 hdr=0x00
vendor = 'NEC Electronics Hong Kong'
device = 'uPD9210FGC-7EA USB Host Controller'
class = serial bus
subclass = USB
none0@pci3:8:2: class=0x0c0320 card=0x02e09004 chip=0x00e01033 rev=0x02 hdr=0x00
vendor = 'NEC Electronics Hong Kong'
device = 'uPD720100A USB 2.0 Enhanced Host Controller'
class = serial bus
subclass = USB
fwohci0@pci3:11:0: class=0x0c0010 card=0x8010104c chip=0x8020104c rev=0x00 hdr=0x00
vendor = 'Texas Instruments (TI)'
device = 'TSB12LV26 OHCI-Lynx PCI IEEE 1394 Host Controller'
class = serial bus
subclass = FireWire
ebus0@pci1:1:0: class=0x068000 card=0x00000000 chip=0x1000108e rev=0x01 hdr=0x00
vendor = 'Sun Microsystems'
device = 'SPARC EBUS PCIO PCI I/O Controller'
class = bridge
subclass = PCI-unknown
hme0@pci1:1:1: class=0x020000 card=0x00000000 chip=0x1001108e rev=0x01 hdr=0x00
vendor = 'Sun Microsystems'
device = 'PCIO Happy Meal Ethernet'
class = network
subclass = ethernet
none1@pci1:2:0: class=0x030000 card=0x00000000 chip=0x47501002 rev=0x5c hdr=0x00
vendor = 'ATI Technologies'
device = 'Rage 3D Pro PCI Graphics Accelerator'
class = display
subclass = VGA
atapci0@pci1:3:0: class=0x01018f card=0x06461095 chip=0x06461095 rev=0x03 hdr=0x00
vendor = 'Silicon Image Inc (Was: CMD Technology Inc)'
device = 'PCI-0646 EIDE Adapter (Single FIFO)'
class = mass storage
subclass = ATA
------------------------------
Date: Mon, 24 Mar 2003 07:57:08 -0500
From: Jake Burkholder <ja...@locore.ca>
Subject: Re: PCI-PCI bridge
Apparently, On Mon, Mar 24, 2003 at 02:04:35PM +0900,
Hidetoshi Shimokawa said words to the effect of;
> Hi,
>
> I have a problem with PCI-PCI bridge on sparc64(sun ultra5) while
> tesing firewire driver.
>
> I have a Adaptec card which has a firewire and a USB2 chips behind
> PCI-PCI bridge. With this card the DMA trasfer speed is poor and
> it sometimes causes timeout which leads to panic(*1).
>
> I finally found that this is because the PCI-PCI bridge
> is not configured correctly and setting the cache line size in the
> bridge by pciconf fixes the problem.
> (pciconf -w -b pci1:1:0 0x0c 16)
>
> Sun's APB PCI-PCI bridges seem to be configured correctly but the one on
> the card doesn't.
> Who should configure such bridges?
> Does upgrading firmware fix the problem?
I think this is the firmware's job but it doesn't always do it. Updating
the firmware may or may not help. We try to fix this up on startup by
walking the device tree and initializing all the cache line size registers,
but I notice that we don't do it for subordinate bridges, only for their
child devices.
You might try something like this (untested):
Index: sparc64/pci/ofw_pci.c
===================================================================
RCS file: /home/ncvs/src/sys/sparc64/pci/ofw_pci.c,v
retrieving revision 1.9
diff -u -r1.9 ofw_pci.c
- --- sparc64/pci/ofw_pci.c 19 Feb 2003 05:47:44 -0000 1.9
+++ sparc64/pci/ofw_pci.c 24 Mar 2003 12:48:39 -0000
@@ -216,6 +216,8 @@
panic("ofw_pci_init: OF_getprop failed");
slot = OFW_PCI_PHYS_HI_DEVICE(pcir.phys_hi);
func = OFW_PCI_PHYS_HI_FUNCTION(pcir.phys_hi);
+ PCIB_WRITE_CONFIG(dev, busno, slot, func, PCIR_CACHELNSZ,
+ clnsz / 4, 1);
if (strcmp(type, OFW_PCI_PCIBUS) == 0) {
/*
* This is a pci-pci bridge, initalize the bus number and
@@ -269,8 +271,6 @@
PCIB_WRITE_CONFIG(dev, busno, slot, func,
PCIR_LATTIMER, imin(lat, 255), 1);
}
- - PCIB_WRITE_CONFIG(dev, busno, slot, func,
- - PCIR_CACHELNSZ, clnsz / 4, 1);
/* Initialize the intline registers. */
if ((intr = ofw_pci_route_intr(node, ign)) != 255) {
Jake
------------------------------
Date: Mon, 24 Mar 2003 14:11:40 +0100
From: Armijn Hemel <arm...@nl.linux.org>
Subject: Ultra1 status?
'llo,
the webpage says the Ultra1 is not supported yet. I did some digging
through the archives and saw that if I've a hme card that it should be
possible to get something working. I have a SunSwift card in my machine
(hme + SCSI), so I want to give it a shot. The machine now runs OpenBSD,
but I can easily slide in another disk to install FreeBSD...
Where exactly can I find installing instructions (if there are any)?
armijn
- --
---------------------------------------------------------------------------
arm...@nl.linux.org | http://people.nl.linux.org/~armijn/ | Penguin Power
---------------------------------------------------------------------------
http://nl.linux.org/ | Alles over Linux
---------------------------------------------------------------------------
------------------------------
Date: Tue, 25 Mar 2003 00:13:40 +0900
From: Hidetoshi Shimokawa <simo...@sat.t.u-tokyo.ac.jp>
Subject: Re: PCI-PCI bridge
At Mon, 24 Mar 2003 07:57:08 -0500,
Jake Burkholder wrote:
>
> Apparently, On Mon, Mar 24, 2003 at 02:04:35PM +0900,
> Hidetoshi Shimokawa said words to the effect of;
>
> > Hi,
> >
> > I have a problem with PCI-PCI bridge on sparc64(sun ultra5) while
> > tesing firewire driver.
> >
> > I have a Adaptec card which has a firewire and a USB2 chips behind
> > PCI-PCI bridge. With this card the DMA trasfer speed is poor and
> > it sometimes causes timeout which leads to panic(*1).
> >
> > I finally found that this is because the PCI-PCI bridge
> > is not configured correctly and setting the cache line size in the
> > bridge by pciconf fixes the problem.
> > (pciconf -w -b pci1:1:0 0x0c 16)
> >
> > Sun's APB PCI-PCI bridges seem to be configured correctly but the one on
> > the card doesn't.
> > Who should configure such bridges?
> > Does upgrading firmware fix the problem?
>
> I think this is the firmware's job but it doesn't always do it. Updating
> the firmware may or may not help. We try to fix this up on startup by
> walking the device tree and initializing all the cache line size registers,
> but I notice that we don't do it for subordinate bridges, only for their
> child devices.
>
> You might try something like this (untested):
Thanks, I'll try it tomorrow.
BTW, the latency timer and secondary(?) latency timer of the bridge
are zero too. Shall we configure those values too?
I don't observe significant performance change by changing those
values though.
/\ Hidetoshi Shimokawa
\/ simo...@sat.t.u-tokyo.ac.jp
PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html
------------------------------
Date: Mon, 24 Mar 2003 12:04:38 -0500
From: Jake Burkholder <ja...@locore.ca>
Subject: Re: PCI-PCI bridge
Apparently, On Tue, Mar 25, 2003 at 12:13:40AM +0900,
Hidetoshi Shimokawa said words to the effect of;
> At Mon, 24 Mar 2003 07:57:08 -0500,
> Jake Burkholder wrote:
> >
> > Apparently, On Mon, Mar 24, 2003 at 02:04:35PM +0900,
> > Hidetoshi Shimokawa said words to the effect of;
> >
> > > Hi,
> > >
> > > I have a problem with PCI-PCI bridge on sparc64(sun ultra5) while
> > > tesing firewire driver.
> > >
> > > I have a Adaptec card which has a firewire and a USB2 chips behind
> > > PCI-PCI bridge. With this card the DMA trasfer speed is poor and
> > > it sometimes causes timeout which leads to panic(*1).
> > >
> > > I finally found that this is because the PCI-PCI bridge
> > > is not configured correctly and setting the cache line size in the
> > > bridge by pciconf fixes the problem.
> > > (pciconf -w -b pci1:1:0 0x0c 16)
> > >
> > > Sun's APB PCI-PCI bridges seem to be configured correctly but the one on
> > > the card doesn't.
> > > Who should configure such bridges?
> > > Does upgrading firmware fix the problem?
> >
> > I think this is the firmware's job but it doesn't always do it. Updating
> > the firmware may or may not help. We try to fix this up on startup by
> > walking the device tree and initializing all the cache line size registers,
> > but I notice that we don't do it for subordinate bridges, only for their
> > child devices.
> >
> > You might try something like this (untested):
>
> Thanks, I'll try it tomorrow.
>
> BTW, the latency timer and secondary(?) latency timer of the bridge
> are zero too. Shall we configure those values too?
> I don't observe significant performance change by changing those
> values though.
Yes, probably. Again, currently the pci code tries to set the latency
timer of child devices correctly, but not the bridge itself.
Jake
------------------------------
Date: Mon, 24 Mar 2003 14:08:58 -0500 (EST)
From: John Baldwin <j...@FreeBSD.org>
Subject: Re: PCI-PCI bridge
On 24-Mar-2003 Jake Burkholder wrote:
> Apparently, On Tue, Mar 25, 2003 at 12:13:40AM +0900,
> Hidetoshi Shimokawa said words to the effect of;
>
>> At Mon, 24 Mar 2003 07:57:08 -0500,
>> Jake Burkholder wrote:
>> >
>> > Apparently, On Mon, Mar 24, 2003 at 02:04:35PM +0900,
>> > Hidetoshi Shimokawa said words to the effect of;
>> >
>> > > Hi,
>> > >
>> > > I have a problem with PCI-PCI bridge on sparc64(sun ultra5) while
>> > > tesing firewire driver.
>> > >
>> > > I have a Adaptec card which has a firewire and a USB2 chips behind
>> > > PCI-PCI bridge. With this card the DMA trasfer speed is poor and
>> > > it sometimes causes timeout which leads to panic(*1).
>> > >
>> > > I finally found that this is because the PCI-PCI bridge
>> > > is not configured correctly and setting the cache line size in the
>> > > bridge by pciconf fixes the problem.
>> > > (pciconf -w -b pci1:1:0 0x0c 16)
>> > >
>> > > Sun's APB PCI-PCI bridges seem to be configured correctly but the one on
>> > > the card doesn't.
>> > > Who should configure such bridges?
>> > > Does upgrading firmware fix the problem?
>> >
>> > I think this is the firmware's job but it doesn't always do it. Updating
>> > the firmware may or may not help. We try to fix this up on startup by
>> > walking the device tree and initializing all the cache line size registers,
>> > but I notice that we don't do it for subordinate bridges, only for their
>> > child devices.
>> >
>> > You might try something like this (untested):
>>
>> Thanks, I'll try it tomorrow.
>>
>> BTW, the latency timer and secondary(?) latency timer of the bridge
>> are zero too. Shall we configure those values too?
>> I don't observe significant performance change by changing those
>> values though.
>
> Yes, probably. Again, currently the pci code tries to set the latency
> timer of child devices correctly, but not the bridge itself.
You probably should set it for the bridge since the bridge has to
act as a master on the primary bus for the devices on the subordinate
bus that initiate transactions with other devices.
- --
John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
------------------------------
Date: Tue, 25 Mar 2003 05:43:43 -0500 (EST)
From: Mike Barcroft <mi...@sparc64.style9.org>
Subject: sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html
- --------------------------------------------------------------
>>> Rebuilding the temporary build tree
- --------------------------------------------------------------
>>> stage 1: bootstrap tools
- --------------------------------------------------------------
>>> stage 2: cleaning up the object tree
- --------------------------------------------------------------
>>> stage 2: rebuilding the object tree
- --------------------------------------------------------------
>>> stage 2: build tools
- --------------------------------------------------------------
>>> stage 3: cross tools
- --------------------------------------------------------------
>>> stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
- --------------------------------------------------------------
>>> stage 4: building libraries
- --------------------------------------------------------------
===> lib/libatm
cc1: warnings being treated as errors
/tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_vcc_info':
/tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:175: warning: cast increases required alignment of target type
/tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_subnet_mask':
/tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:229: warning: cast increases required alignment of target type
/tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_cfg_info':
/tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:395: warning: cast increases required alignment of target type
/tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_intf_info':
/tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:433: warning: cast increases required alignment of target type
*** Error code 1
Stop in /tinderbox/sparc64/src/lib/libatm.
*** Error code 1
Stop in /tinderbox/sparc64/src/lib.
*** Error code 1
Stop in /tinderbox/sparc64/src.
*** Error code 1
Stop in /tinderbox/sparc64/src.
*** Error code 1
Stop in /tinderbox/sparc64/src.
*** Error code 1
Stop in /tinderbox/sparc64/src.
------------------------------
End of freebsd-sparc-digest V5 #258
***********************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-sparc-digest in the body of the message