headers
yangzw | 1 Jul 2003 05:17

Re: add a very useful command to ddb

Given a function(such as amap_alloc), can you quickly find out how it works?
In the most common way, you must use info function command in gdb to see
which source file contains this function, and then open it, check the
subroutines it calls, and use info function command again to see where those
subroutines reside, in order to find recursively all subroutines directly or
indirectly called, what a boring work, and you have to select(maybe guess)
some subroutines you think important, set breakpoints on them one by one,
then you can use bt, up, down command to get the information, and you still
may be puzzled with the runtime execution flow, for example, it is a
difficult way to know how a loop is performed, what runtime parameters a
subroutine in this loop is called with, it may take you up to a whole day
when explore a complicated function in kernel(because you may reboot several
times to reproduct the condition you need to debug).but with the single
command yzw, you can get all of them.

----- Original Message ----- 
From: "Teh Kok How" <khteh <at> willowglen.com.my>
To: "杨致伟" <yangzw <at> cn.is-one.net>
Sent: Tuesday, July 01, 2003 8:49 AM
Subject: Re: add a very useful command to ddb

> Hi;
> This functionality can be achieved with 'backtrace', 'bt', 'up' and 'down'
> which are already in the gdb. How different is yours from the standard
one?
>
> Teh
>
> On Tuesday 20 May 2003 11:48, 杨致伟 wrote:
> > unlike n/p, yzw command use another way to print  more readable
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raymond Morsman | 2 Jul 2003 10:07

ntp is bugging my named?

Hi,

my named stops several times per day and the /var/log/messages says:

Jul  2 00:59:24 tesla named[14742]: transfer of
'infomedicsportal.com/IN' from 193.78.30.50#53: failed while receiving
responses: permission denied
Jun 13 21:14:57 tesla ntpd[16699]: time reset +6.159713 s
Jun 13 21:14:57 tesla ntpd[16699]: frequency error 5636 PPM exceeds
tolerance 500 PPM
Jun 13 21:15:00 tesla named[14742]:
/usr/src/usr.sbin/bind/lib/isc/unix/time.c:239: INSIST(t1->nanoseconds <
1000000000 && t2->nanoseconds < 1000000000) failed
Jun 13 21:15:00 tesla named[14742]: exiting (due to assertion failure)
Jul  2 01:09:45 tesla ntpd[16699]: time reset +6.125444 s
Jul  2 01:09:45 tesla ntpd[16699]: frequency error 5579 PPM exceeds
tolerance 500 PPM

Is this a known problem?

Raymond.
Permalink | Reply | 0 comments |
headers
Barry Scott | 2 Jul 2003 11:02

Re: ntp is bugging my named?

You are not alone, I have seen the same problems.

The hardware this occurs on has a clock problem. The clock drifts 6 mins
in 24 hours - as this is a new system I'm going to get a replace for the
motherboard.

The problems I see are:

* /etc/ntp.drift file contains "NaN"
* ntpd appears to be setting the date far from now
* named vanishes as you report
* date command reported the year as 1934 (is this 2034 miss printed?)

Barry

-----Original Message-----
From: Raymond Morsman [mailto:raymond <at> dyn.org] 
Sent: 02 July 2003 09:08
To: tech <at> openbsd.org
Subject: ntp is bugging my named?

Hi,

my named stops several times per day and the /var/log/messages says:

Jul  2 00:59:24 tesla named[14742]: transfer of
'infomedicsportal.com/IN' from 193.78.30.50#53: failed while receiving
responses: permission denied
Jun 13 21:14:57 tesla ntpd[16699]: time reset +6.159713 s
Jun 13 21:14:57 tesla ntpd[16699]: frequency error 5636 PPM exceeds
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barry Scott | 2 Jul 2003 11:10

Re: ntp is bugging my named?

Here is a part of my messages log that show the time wrap. Raymond, your
log has the same time wrap. I bet the time wrap is causing named to get
unexpected data that crashes it.

BArry

Jun 25 14:58:10 stabledoor ntpd[14479]: frequency error 22202 PPM
exceeds tolerance 500 PPM
Jun  7 12:21:17 stabledoor ntpd[14479]: time reset +27.181870 s
Jun  7 12:21:17 stabledoor ntpd[14479]: frequency error 24937 PPM
exceeds tolerance 500 PPM
Jun 25 15:35:37 stabledoor ntpd[14479]: time reset +27.165882 s
Jun 25 15:35:37 stabledoor ntpd[14479]: frequency error 24923 PPM
exceeds tolerance 500 PPM
Jun  7 12:57:37 stabledoor ntpd[14479]: time reset +28.293563 s
Jun  7 12:57:37 stabledoor ntpd[14479]: frequency error 25957 PPM
exceeds tolerance 500 PPM
Jun 25 16:11:57 stabledoor ntpd[14479]: time reset +28.327747 s

-----Original Message-----
From: Raymond Morsman [mailto:raymond <at> dyn.org] 
Sent: 02 July 2003 09:08
To: tech <at> openbsd.org
Subject: ntp is bugging my named?

Hi,

my named stops several times per day and the /var/log/messages says:

Jul  2 00:59:24 tesla named[14742]: transfer of
(Continue reading)

Permalink | Reply | 0 comments |
headers
c0g | 3 Jul 2003 18:50
Picon
Favicon

is there way to force kernel to fragment packets?


Hi!
I am reposting message posted on misc <at> , because there was no answer.
I've made gif tunnel (protected by IPSec) between two OpenBSD boxes.

~                           tunnel
client ---- rl0-OBSD-gif0 ======= gif0-OBSD-rl0 --- internet -- server

(both routers are in the same wireless network, they sees each other arp
packets; there is no other hosts in this wireless network)

MTU of the tunnel is smaller than 1500. When server transmits big
packets to client, they don't fit in the tunnel, so OBSD box sends icmp
need to frag. Some servers are broken and drops this kind of icmp
packets. This is well knows mss-mtu issue - can be repaired by changing
mss to fit mtu hack on router box.
But i think, that in my setup, it is not optimal. I want to maximalize
usage of my internet connection, so I want to transmit and receive
packets as big as possible = 1500 bytes. Changing mss will increase
number of small packets. Larger number of packets mean that there is
more "signalization" data bounded to each packet, so there is fewer room
for data that these packets carry. So fragmentation (only between tunnel
endpoints which are under my control) sounds better in my opinion.

Is there any way to tell OpenBSD kernel to fragment too big packets
going thru tunnel instead sending icmp need to frag? To make tunnel
transparent?

Or if there is no such way, maybe there is some simple kernel hack,
which will turn fragmentation always on? If so, please give me some hint
(Continue reading)

Permalink | Reply | 1 comment |
headers
John R. Shannon | 3 Jul 2003 19:22
Favicon

Re: is there way to force kernel to fragment packets?


 Yes, with pf. Look at scrub no-df 

--

-- 

John R. Shannon
john <at> johnrshannon.com
Permalink | Reply | 0 comments |
headers
Jaime Vargas | 3 Jul 2003 20:06
Picon

Problems prism hostap mode with Firmware 1.7.4

Hello All,

I had modified the wi driver to support ssid hiding and restrict 
responses to
ssid "ANY" request associations.   This new feature only works with 
prism
firmware 1.6.3 and above. The only public version of the firmware that I
found above 1.4.9 is 1.7.4.

The new features work well, however I am having some problems with
clients associating to the network, with and without my driver changes.

Which lead me to believe that there are some bugs in the hostap code or
the firmware. I was wondering if anyone has try to fix these? Or if 
somebody
can guide me to where the problem may be and how to fix it.

The changes that I did involve adding an option to support
WI_RID_CFNENHSECURITY, and support code in the driver.

But as I said I don't think the problem is with my modifications as I 
had
done tests with the original driver without any changes, and clients can
not join a hostap network under firmware 1.7.4.

Any help will be greatly appreciated. Thanks, Jaime

dmesg follows:

OpenBSD 3.3 (NET4521) #2: Thu May 22 12:27:05 EDT 2003
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Ahern | 3 Jul 2003 23:48

pthread_mutex_trylock, unlock

it appears, in 3.3-alpha, that if i do a trylock in one thread, then
an unlock in another the unlock will fail.

ring any bells? would this have anything to do w/ mutex attributes?
i'm just using all the defaults, from pthread_mutexattr_init.

fwiw, this worked fine in 3.2. between this and the SIGALRM behaviors, i'm
think that there are some serious, serious differences between thread
handling and signal handling between 3.2 and 3.3. i mean, i realize that
there were serious changes, but i didn't think the behaviors would change so
much.

tia,

Bill
Permalink | Reply | 1 comment |
headers
Florin SIMEN | 4 Jul 2003 00:39
Picon

newbie select() problem

Hi, I have a problem with a select function on /dev/cuaXX. It seems that
it returns that the descriptor has changed. But if I do a read before
select, read  returns 0, and after select, read returns 0 
too. select() doesn't give any errors. The file descriptor set is zeroed
at begining, and than added a new file descriptor of the opened serial
Any links or sugestions are welcome. 
Thanks.
Permalink | Reply | 1 comment |
headers
Marco S Hyman | 4 Jul 2003 02:40
Favicon
Gravatar

Re: pthread_mutex_trylock, unlock

William Ahern writes:
 > it appears, in 3.3-alpha, that if i do a trylock in one thread, then
 > an unlock in another the unlock will fail.

It's supposed to fail.   From the man page:

     If the current thread holds the lock on mutex, then the
     pthread_mutex_unlock() function unlocks mutex.
	...
     pthread_mutex_trylock() will fail if:

     [EPERM]       The current thread does not hold a lock on mutex.

Or are you doing something else.  A test case would be appreciated.

// marc
Permalink | Reply | 0 comments |

Gmane