RetroBSD • View topic - LiteBSD bug list

View unanswered posts | View active topics

Board index » LiteBSD - Unix for microcontrollers with MMU » Bug Reports

All times are UTC

LiteBSD bug list

Page 2 of 3

[ 50 posts ]

Go to page Previous 1, 2, 3 Next

Print view

Previous topic | Next topic

Author

Message

majenko

Post subject: Re: LiteBSD bug list

Posted: Fri Oct 16, 2015 8:33 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

vak wrote:

majenko wrote:

/sbin/init is not receiving (or ignoring) signals.

This may explain why /sbin/halt does not work as expected.

That's what I'm investigating at the moment that led to that conclusion...

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Fri Oct 16, 2015 8:49 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

This is looking like it might be (again) to do with variadic functions. There is the snippet:

Code:

    sigfillset(&mask);
    delset(&mask, SIGABRT, SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGSYS,
        SIGXCPU, SIGXFSZ, SIGHUP, SIGTERM, SIGTSTP, SIGALRM, 0);

delset() is supposed to work through each argument until it reaches 0 removing them from the set &mask. I have some debugging in there:

Code:

    while (sig = va_arg(ap, int)) {
        warning("Activating signal %d", sig);
        sigdelset(maskp, sig);
    }

I would expect:

Code:

Activating signal 6
Activating signal 8
...
Activating signal 17
Activating signal 14

Instead I get (drum roll...)

Code:

Activating signal -1

Replacing that variadic function call with a list of discrete calls to sigdelset it suddenly starts working perfectly. So there is definitely something up with variadics. Out of interest that function is defined as:

Code:

void
#ifdef __STDC__
delset(sigset_t *maskp, ...)
#else
delset(va_alist)
    va_dcl
#endif
{

So there is obviously some kind of fudging going on there already.

Top

Pito

Post subject: Re: LiteBSD bug list

Posted: Fri Oct 16, 2015 9:12 pm

Contributor

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui

Long time back while messing with double precision we had an issue with va_arg stuff.. Alignment issue or what..

_________________
Pukao Hats Cleaning Services Ltd.

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Fri Oct 16, 2015 9:22 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

That was in retro and with 64 bit values not knowing where to align on a 32 bit system. This is 32 bit values on a more modern 32 bit system.

Top

vak

Post subject: Re: LiteBSD bug list

Posted: Fri Oct 16, 2015 10:09 pm

Committer

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1081
Location: Sunnyvale, CA

majenko wrote:

Replacing that variadic function call with a list of discrete calls to sigdelset it suddenly starts working perfectly. So there is definitely something up with variadics.

Wow...
Thanks for digging this out: now we at least know what to fix.
It makes sense to replace varargs.h with stdarg.h - everywhere, not only in init.c.

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Fri Oct 16, 2015 10:15 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

I guess the ifdefs are in there to allow compilation under gcc 2 in LiteBSD. Shame we haven't actually got that compiled yet

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Fri Oct 16, 2015 10:40 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

I have managed to log in using ftp!!!

Systematically stripping out the old style va_arg stuff and replacing it with stdarg seems to do the trick. I should try it on init to see if that works too.

Although... that should be happening anyway because of the __STDC__ macro. With that defined (and it is, I tested) it's using stdarg not varargs.

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Fri Oct 16, 2015 10:52 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

Well, now ftp is working all I need is a functional slip connection.

However, as soon as a SLIP packet arrives on the serial it seems to completely crash the whole kernel - complete and utter lockage.

LiteBSD:

Code:

# slattach tty1 9600
# ps ax
  PID TT  STAT      TIME COMMAND
...
   49  4  SW     0:00.01 slattach tty1 9600
...
# ifconfig sl0 inet 10.0.0.1 10.0.0.2 netmask 255.255.255.0
# ifconfig sl0
sl0: flags=c011<UP,POINTOPOINT,LINK2,MULTICAST>
        inet 10.0.0.1 --> 10.0.0.2 netmask 0xffffff00 
# 

Linux:

Code:

root@dell:~/git/LiteBSD# slattach -L -s 9600 ttyUSB2 &
root@dell:~/git/LiteBSD# ifconfig sl0 inet 10.0.0.2 pointopoint 10.0.0.1                                
root@dell:~/git/LiteBSD# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.

... And now LiteBSD is locked up solid.

--

Further testing shows that it's the slattach that is the trigger for the crash, not the ifconfig. If I have the Linux configured and pinging then run the slattach on the WiFire it's an immediate crash as soon as the first packet arrives - even before I have a chance to do the ifconfig.

--

As far as sending goes - I don't see any data leaving the serial port at all. The packet queue routine is running to completion, but nothing is actually getting out of the port...

Top

Pito

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 6:51 am

Contributor

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui

vak wrote:

Pito wrote:

Unix for simple microcontrollers.
For example pic16f84..

Your variant?

RetroBSD - Unix for better microcontrollers
RetroBSD - Unix for clever microcontrollers
RetroBSD - Unix for smarter microcontrollers
RetroBSD - Unix for MIPS microcontrollers

_________________
Pukao Hats Cleaning Services Ltd.

Top

vak

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 6:58 am

Committer

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1081
Location: Sunnyvale, CA

Technically, RetroBSD is Unix for microcontrollers without MMU, but it sounds too confusing for inexperienced visitor.

Top

Pito

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 7:12 am

Contributor

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui

vak wrote:

Technically, RetroBSD is Unix for microcontrollers without MMU, but it sounds too confusing for inexperienced visitor.

The same for LiteBSD - Unix for microcontrollers with MMU

That is like an old joke (not to be transleted in english) - a guy came to an electronics components store and asked for a "photoresistor". And the lady there answered to him the Photoshop store is just around the corner..

_________________
Pukao Hats Cleaning Services Ltd.

Top

vak

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 7:29 am

Committer

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1081
Location: Sunnyvale, CA

Well, when you have a microcontroller with MMU - you are usually aware of it. At least you can find it mentioned in a datasheet. When you don't have MMU, which is the case for all Cortex-M cores ant most others, it's hard ti understand what it is all about. That's the difference.

Top

Pito

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 7:40 am

Contributor

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui

Marketing is not about technology know-how.
You have to simply attract a prospect. When he/she stays at your site few minutes long he/she gets the detailed info (ie. he/she needs an MMU).
So I would not insist on technicalities when creating names for forum indexes.

_________________
Pukao Hats Cleaning Services Ltd.

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 10:44 am

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

Re: slip... I am starting to wonder if slattach is actually connecting the interface and the tty together properly. If outgoing is getting lost and incoming isn't even getting as far as the slip interface it's starting to look that way.

I added some debugging at the start of the slip reception routine and made the routine do absolutely nothing and it still crashes without triggering the debugging. Next port of call is slattach (both the binary and the kernel function) to see what exactly it is doing.

Top

wiz

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 11:49 am

Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092

Hi Matt and all,

How do we get Wiz to.... There is no hope

.

So my question now is: Now that we have virtual memory,how big can a user program be in virtual space? And what limits are there to user data space?

I guess I really gotta get an MZ...EF board up and running.

And is there provision to lock a program into physical memory? This seems most important for debuggers and other kernel mode stuff

Maybe it is too soon to ask? But IMHO very important to allow.

Lots of fun

.

Wiz

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 12:09 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

Ok - getting deeper into this slip issue - and I think I may have found a bit of a glaring issue...

Is this *really* a good idea?

Code:

tp->t_sc = (caddr_t)sc;

tp->t_sc, for a UART tty, is the address of the UART register set.

Code:

uart_regmap_t *reg = tp->t_sc;

The SLIP interface is overwriting that with the address of it's sl_softc structure, so the UART is then forgetting how to do anything at all - and that leads to all sorts of lockups and kernel panics.

So we really mustn't abuse the t_sc entry in the tty struct to store the UART register set pointer - it's really not good. Instead I think we should store them in a separate array. In fact, don't we already hvae that as `uart_base[unit]`...? Why do we even need to use t_sc for storing the register set?

And I guess the code that used to handle t_sc properly and feed data to where it needs to go (the slip interface) doesn't even exist...?

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 12:16 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

Ok, so scrapping t_sc from the UART code and replacing it with uart_base[unit] has cured the complete lockup and/or kernel panic caused by receiving anything once slattach has been run.

Now to see about how to do the hooking in of the real t_sc handling code so that the slip interface can receive it's data...

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 12:34 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

OK, so we are half way there with this. I can ping out from LiteBSD and I see the echo request packet arrive on the PC, and it replies with an echo reply. That echo reply doesn't make it from the UART through to the slip interface though. I need to find out how to create that link.

... Ok, so slattach sets the line discipline to 4 (SLIPDISC) so that it should then route through to slinput() but I don't yet know how that mechanism actually works...

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 12:58 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

Ok, got it! Another bug in the UART code.

It was calling

Code:

ttyinput(c,tp);

for each received character. Instead it should actually have been calling

Code:

(*linesw[tp->t_line].l_rint)(c, tp)

And now that I have changed that:

Code:

matt@dell:~/git/LiteBSD/sys/compile/WIFIRE.pic32$ telnet 10.0.0.1
Trying 10.0.0.1...
Connected to 10.0.0.1.
Escape character is '^]'.


4.4BSD-Lite (wifire.majenko.co.uk) (ttyp0)

login: matt
Password:
Last login: Fri Oct 16 20:26:27 on tty1
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.   All rights reserved.

4.4BSD-Lite UNIX #1: Fri Apr 01 00:00:00 PDT 1994

Welcome to 4.4BSD-Lite!

erase ^H, kill ^U, intr ^C status ^T
$ w
10:12PM  up 4 mins, 2 users, load averages: 0.02, 0.10, 0.06
USER    TTY FROM              LOGIN@  IDLE WHAT
root     co -                10:08PM     3 -sh (sh)
matt     p0 10.0.0.2         10:08PM     0 w
$

It's even on the internets!

Code:

$ traceroute retrobsd.org
traceroute to retrobsd.org (166.84.7.114), 30 hops max, 40 byte packets
 1  10.0.0.2 (10.0.0.2)  139.921 ms  124.046 ms  432.89 ms
 2  * 192.168.0.1 (192.168.0.1)  199.29 ms  143.168 ms
 3  79-76-112-1.dynamic.dsl.as9105.com (79.76.112.1)  254.31 ms  153.334 ms  274.465 ms
 4  85-210-253-74.dynamic.dsl.as9105.com (85.210.253.74)  141.991 ms  146.796 ms  148.362 ms
 5  85-210-253-87.dynamic.dsl.as9105.com (85.210.253.87)  138.332 ms 85-210-253-79.dynamic.dsl.as9105.com (85.210.253.79)  145.422 ms 85-210-253-99.dynamic.dsl.as9105.com (85.210.253.99)  153.567 ms
 6  host-78-144-9-218.as13285.net (78.144.9.218)  570.76 ms host-78-144-9-211.as13285.net (78.144.9.211)  266.509 ms host-78-144-10-174.as13285.net (78.144.10.174)  260.586 ms
 7  v209.core1.lon1.he.net (216.66.84.213)  144.457 ms host-78-144-9-85.as13285.net (78.144.9.85)  158.297 ms v209.core1.lon1.he.net (216.66.84.213)  143.794 ms
 8  10ge2-9.core1.lon2.he.net (72.52.92.222)  158.806 ms v209.core1.lon1.he.net (216.66.84.213)  152.894 ms 10ge2-9.core1.lon2.he.net (72.52.92.222)  152.794 ms
 9  100ge1-1.core1.nyc4.he.net (72.52.92.166)  211.578 ms  209.389 ms  375.799 ms
10  eth3-132.l3v2.nyc.access.net (216.66.27.235)  225.528 ms 100ge1-1.core1.nyc4.he.net (72.52.92.166)  210.078 ms eth3-132.l3v2.nyc.access.net (216.66.27.235)  226.474 ms
11  goa.vak.ru (166.84.7.114)  223.042 ms  225.307 ms  366.328 ms
$ 

Top

majenko

Post subject: Re: LiteBSD bug list

Posted: Sat Oct 17, 2015 2:33 pm

Committer

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3

I'm seeing various crashes while doing normal operations (like mounting a filesystem on /mnt then just trying to look at what is there) with:

Code:

panic: kmem_malloc: kmem_map too small
syncing disks... panic: lockmgr: locking against myself

dumping to dev 2, offset 64512
dump device bad

Code that makes the message:

Code:

    /*
     * Locate sufficient space in the map.  This will give us the
     * final virtual address for the new memory, and thus will tell
     * us the offset within the kernel map.
     */
    vm_map_lock(map);
    if (vm_map_findspace(map, 0, size, &addr)) {
        vm_map_unlock(map);
        if (canwait)        /* XXX  should wait */
            panic("kmem_malloc: %s too small",
                map == kmem_map ? "kmem_map" : "mb_map");
        return (0);
    }

Fix: increase NKMEMCLUSTERS in the kernel config to 64 - I guess that gives the kernel more RAM at the cost of a smaller amount for userland, which would result in more swapping?

Top

Page 2 of 3

[ 50 posts ]

Go to page Previous 1, 2, 3 Next

Board index » LiteBSD - Unix for microcontrollers with MMU » Bug Reports

All times are UTC

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum