Re: Crossbuild failure on 8-stable
On 6/30/2011 4:22 AM, Hans Petter Selasky wrote:
Hi,
Trying to cross build ARM fails in the following way on 8-stable:
8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011
make toolchain TARGET=arm
Is this perhaps also an issue in 9-current?
Any clues?
cc -O -pipe -ffreestanding -Wformat -I/usr/src/lib/libstand -msoft-float -
D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -
I/usr/src/lib/libstand/../libz -std=gnu99 -c
/usr/src/lib/libstand/../libc/net/ntoh.c
{standard input}: Assembler messages:
{standard input}:27: Error: bad instruction `bswap r0'
{standard input}:53: Error: bad instruction `bswap r0'
and you also said:
Tracing down the issue:
/usr/include/machine/endian.h
#define __byte_swap_int_var(x) \
__extension__ ({ register __uint32_t __X = (x); \
__asm (bswap %0 : +r (__X)); \
__X; })
r0 looks like an ARM register passed to a non-arm assembler. I'm going to try:
Looks like you have an ARM compiler/assembler because the assembler
rejects the i386/amd64 bswap assembly command.
Does anyone remember if the cross compiler has the cross include paths
compiled into them or should there be a -I in the compile command to
correctly expand the #include machine/endian.h ? I thought the cross
path was compiled into the cross compiler.
You manually test the cc command with the included -I option.
--Mark
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang cross builds world
I was inspired by the clang build world topic to try a cross build world of ARM from a i386 computer. I use the build command: make TARGET_ARCH=arm TARGET_CPUTYPE=xscale buildworld (I tried an TARGET_CPUTYPE=cortex-a8 once also, I got the same errors below). /etc/src.conf is taken from the FreeBSD clang web page,. /etc/make.conf has perl version strings. The cross tools build stage apparently makes an i386 compiler: /usr/obj/arm.arm/usr/src/tmp/usr/bin/clang -### FreeBSD clang version 2.8 (branches/release_28 114020) 20100917 Target: i386-undermydesk-freebsd9.0 Thread model: posix When the library build stage begins, the assembler complains about the unknown --32 option from clang. I know the --32 options is a i386 target add-on option. Removing --32 from the command line with a script shim, and sure enough clang is generating i386 assembly code. I know the clang and ARM is not tested nor supported. I am just looking for some clang cross architecture compiling wisdom. --Mark Tinguely ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
Some time ago we changed an address of RAS. Probably that's the problem. Please try with patch below. grzesiek Good job. IMO, ARM atomic.h should have cmpxchg and the other standard atomic routines so applications don't roll their own and they become stale. This will help application writers if we move the atomic commands from the ARMv4/ARMv5 ARM_RAS_START/ARM_RAS_END atomic method to ARMv6/ARMv7 ldrex/strex/clrex commands. --Mark Tinguely ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Another pmap related panic
It could be a memory problem. Could you also please apply an assert to pmap_enter_quick() + INVARIANTS. This is a quick test that checks all the other paths that call pmap_enter_quick() are locked out so that two processors cannot be using the PADDR1/PMAP1 at the same time. --- pmap.c.orig Mon Aug 25 08:46:03 2003 +++ pmap.c Tue Aug 26 07:16:06 2003 @@ -2056,6 +2056,7 @@ pmap_enter_quick(pmap_t pmap, vm_offset_ pt_entry_t *pte; vm_paddr_t pa; + mtx_assert(vm_page_queue_mtx, MA_OWNED); /* * In the case that a page table page is not * resident, we are creating it here. --Mark Tinguely [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another pmap related panic
MY APOLOGIES, I am s embarrassed. I should have placed that in pmap_pte_quick(), not pmap_enter_quick(). --Mark Tinguely [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another pmap related panic
Thank-you, The fact that pmap_pte_quick() panics on the untrue mutex should indicate that it is possible that 2 processors may enter pmap_pte_quick() at the same time and therefore it is possible to have the one processor invalidate the VA/PA mapping using PADDR1/PMAP1. If that is true then the first processor should trap/panic when dereferencing the VA address. If the above is true, a PADDR1 mutex could be added, or use a seperate PADDR/PMAP per processor. Looks like there is already mutex for the copy maps. Did you want me to work up a test PADDR mutex? --Mark. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: passwd issue
on Tue May 21 13:07:13 2002, Trish Lynch [EMAIL PROTECTED] said: femme:~$ passwd Changing local password for trish Old Password: passwd in free(): error: junk pointer, too high to make sense Abort trap does your log file have a swap space exceeded error? If so, restart your inetd. --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic with PCCARD
I'm having panic for the last few days, if I have PCCARD inserted.
If no card is inside, system boots up fine.
Here's the panic message, I've written down.
Fatal trap 12: page fault while in kernel mode
fault virtual address= 0x3c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01ecea5
stack pointer= 0x10:0xc8ca3b00
frame pointer= 0x10:0xc8ca3b00
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 201 (pccardd)
kernel: type 12 trap, code=0
Stopped at device_set_flags+0x9: movl %eax,0x3c (%edx)
db Context switches not allowed in debugger
db t
device_set_flags(0,0,c139a080,c1411e00,0) at device_set_flags+0x9
allocate_driver(c139c600,c1497400,c8ca8ba4,c13a9800,c87a0804) at
allocate_driver+0xd9
crdioctl(c13a9800,c0ac5006,c1497400,3,c87a0804) at crdioctl+0x337
spec_ioctl(c8ca8b4,c8ca8c34,c0cf,c8ca8ba4,c1496d80) at spec_ioctl+0x26
spec_vnoperate(c8ca8ba4,c1496d80,ac,c1497400,c03521a0) at spec_vnoperate+0x15
vn_ioctl(c1496d80,c0ac5006,c1497400,c87a0804,c87a090c) at vn_ioctl+0x10f
ioctl(c87a0804,c8ca8d20,8073140,8073100,0) at ioctl+0x20c
syscall(2f,2f,2f,0,8073100) at syscall+0x24c
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall(54, FreeBSD ELF, ioctl), eip = 0x8054cd0, esp = 0xbfbff93c, ebp =
0xbfbffa48 ---
the panic appears to be a side affect that allocate_driver() in
sys/pccard/pccard.c does not check the success/failure of device_add_child().
The patch that would fix that is:
--- pccard.c.orig Fri Sep 14 03:43:15 2001
+++ pccard.cFri Nov 2 08:21:48 2001
@@ -236,6 +236,8 @@
bcopy(desc-misc, devi-misc, sizeof(desc-misc));
resource_list_init(devi-resources);
child = device_add_child(pccarddev, devi-name, desc-unit);
+ if (child == NULL)
+ return (EIO); /* XXX */
device_set_flags(child, desc-flags);
device_set_ivars(child, devi);
if (bootverbose) {
The real question is, why is device_add_child failing? The best answer
is that the device class is not being found in make_device()
sys/kern/subr_bus.c. I would suggest you print the string in variable
name, I think it is corrupt.
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: hotmail now running win2000
On 09-Aug-00 The Hermit Hacker wrote: use something like netsaint to monitor those machines? and the APC master switch is web administered, so it would be too easy to build a quick perl script to trigger a power outlet correspondign to the partiular server that was n olonger responding ... Personally I would wire something up to the reset switch instead.. there are watchdog cards like the Berkshire to do this. I was asked to fix a Linux driver problem for one of these cards and wrote a FreeBSD driver for the card. Thankfully *BSD is stable enough that this board is not needed, but (trying to justify my time in doing the driver for BSD) the card also has a temperature feature that you could use with a ATX power supply and the FreeBSD 3.x/4.x init to shut off the machine if the internals get to hot. --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
