Re: File name.

[Paweł Jakub Dawidek]

On Sun, Feb 03, 2002 at 11:54:58PM -0800, Alfred Perlstein wrote:
+> However there's a dirty way to get at it via the vfs lookup cache
+> entries hung off the vnode.  Paul Saab showed me a delta that
+> did something nasty like this, but I've got no clue as to where
+> it is now.
+> 
Hmm...

And what with full path when i got filename, proc, etc.
I can get full path or only mountpoint?

-- 
Paweł Jakub Dawidek
Network Administrator.
Am I Evil? Yes, I Am.



msg31382/pgp0.pgp
Description: PGP signature

a note about configure, off_t and struct stat

[Ben Jackson]

I'd like to preserve this for posterity, so I'm hoping the list will accept
this (I'm not subscribed) so that others may benefit from the archives.
I hope no one else ever has to spend the 10 hours on this I did!

IF for some reason configure decides that your system does not define
`off_t' it will put `#define off_t long' in config.h.  Among other things,
this will makes struct stat 4 bytes shorter.  This means that calls to
stat() will now stomp on memory every time it's called.  With auto
variables you might get lucky and hit things like return addresses!
Much fun ensues.

You could probably also get crazy results from mmap() and other things
taking off_t which you are sure you have the prototype for but are getting
32 bit quantities anyway.

For some reason the two things that this bit me on were bonobo-conf
and ximian evolution.  For whatever reason, db-3.1.17 (if you've built
evolution you know what I mean) which I built at the same time detected
off_t fine and didn't have this problem.

--Ben

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Clock Granularity (kernel option HZ)

[Terry Lambert]

Mike Silbersack wrote:
> I was looking at the timer implementation a few weeks ago and pondering if
> it could be improved as well.  I think it's quite clever if you're dealing
> with a quantity of timers < 1000 or so, but it looks like it could be more
> optimal when used with the quantity of timers we have these days.

You can up the number of buckets; the theory is that most
network timeouts have "untimeout" called on them before
they have a chance to fire.  This means that any time you
hit a slot in the wheel, you have to traverse the entire
list of timeouts in the chain for that slot, since the
insertion of new timeouts is not ordered.

It's not really easy to do ordered insertion, since you
would need to have a data structure that lets you access
it as a btree, to even get O(log2(N)+.5) time on the
insertion (e.g. if it were made bsearchable).

The timeouts are based on the number of slots vs. the HZ
of the soft timer, vs. the number of outstanding requests
...this is what determines if there is the possibility of
more than one entry per bucket, or if a bucket list spans
more than 2MSL for all buckets (high HZ vs. number of
slots).  Even so, with a large number of connection
requests in a given soft timer quanta, they all end up in
the same bucket, which is worst case performance under an
attack.

So yeah: it works for a small number of connections (e.g.
desktop use), but falls over under a large number of
connections relative to log2(N) for N buckets (server use), 
so it's pretty suboptimal.

And the longer the list, the less likely you are to get to
all the entries within a quantum, so at some point, you
will starvation deadlock doing timer list traversal, and
nothing else.


> Did you attempt to combine the various tcp timers so that there would be
> one callout per socket?  I think it would be a pretty easy task; just
> store the various timers inside each socket, and only set a callout for
> the soonest to wake one.  Upon wakeup, quickly check them all.  That would
> reduce the total number of events in the callout wheel for one, and might
> help with the hash function aliasing long-term events such as keepalives
> into the current time.  (I'm assuming that the retransmission and other
> short-term timers do a good job of keeping themselves just ahead of the
> clockhand that they aren't falsely checked.)

This actually doesn't work, unless you round all events to
the same interval.  Basically, this would mean that you
would be rescheduling the same set of timers for a small
set of durations.

IMO, it's better to avoid the callout wheel entirely, for
this case.  You don't really want to examine all 2MSL
timers for 1,000,000 connections, every 2MSL.

My preferred approach to to create one list per fixed
duration timer, and then you end up with a small number
of these lists, leaving other timeout events to fall on
the callout wheel.

Then when the softclock fires, you go down each of this
small number of lists, until the time to expire exceeds
the current tick, at which point you bail.

This works with fixed duration lists, where it doesn't
work with the callout wheel, because you know that each
element in the list is a fixed duration, and therefore,
if you link onto the end of the list when scheduling a
new one, you are guaranteed that the list will be ordered
in terms of increasing tick-at-which-to-fire.  In the
callout wheel case, each bucket is not necessarily ordered
in increasing tick, and since the number of ticks is not
fixed -- there is no fixed duration guarantee -- you have
to traverse the entire list.

Since you already know that one of your main assumptions
is that the timeouts will be untimed-out before they
fire, then for a list of N elements, you only have to
traverse M + 1 elements, where there are M elements to
fire for this given interval.

The effect of this is to reduce a list of N elements to
traverse in a given bucket to a single element traversal,
in most cases ( M ~= 0, M << N ).

This effectively scales much better.  It scales almost
infinitely, whereas the other approach scales for the
total number of elements K ( M[0] ... M[n], n~= 5 for
a small number of fixed intervals can translate into a
large "K") to K/number_of_buckets_in_wheel ... basically,
an exponential times log2(number_of_buckets_in_wheel).


Personally, I've looked at the "Opportunistic Timers"
paper, and I'm not convinced about their arguments during
overload conditions; specifically, I think that all it
really does is free up CPU time for the non-overload case
that no one cares about, and degrades to hard timers in
the overload case, where the "opportunity" never presents
to do timer processing, since you're already screwed by
livelock at that point.

I think some small number of fixed interval lists is
probably the correct way to go for large scaling.  You
could probably safely eat a variance of +/- < 1MSL, if
you wanted to do so, by only doing the processing of
the soft interrupt list for the 2MSL timer

Re: File name.

[Terry Lambert]

Pawe³ Jakub Dawidek wrote:

> I can get vnode of changed file.
> I can get inode number of changed file.
> But how can i get file name?
> 
> There is a way to get inode when i have file name and p (struct proc), so
> maybe there is a way to get file name from inode number and p.
> 
> And another thing for chflags syscall.
> I got file name, but how can I get full path name for this file?


char *saved_name;

func()
{
char *foo;

...

fd = open( foo, O_RDWR, 0664);
saved_name = strdup( foo);

...

printf( "name that goes with fd %d is '%s'\n",
fd, saved_name);
...
}

i.e.: You opened the thing, you ought to know its name. 

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: File name.

[Paweł Jakub Dawidek]

On Mon, Feb 04, 2002 at 01:27:39AM -0800, Terry Lambert wrote:
+>  char *saved_name;
+> 
+>  func()
+>  {
+>  char *foo;
+> 
+>  ...
+> 
+>  fd = open( foo, O_RDWR, 0664);
+>  saved_name = strdup( foo);
+> 
+>  ...
+> 
+>  printf( "name that goes with fd %d is '%s'\n",
+>  fd, saved_name);
+>  ...
+>  }
+> 
+> i.e.: You opened the thing, you ought to know its name. 
+> 
Nope. We are in kernel area.
I want to control for example open() syscall:
static int my_open(register struct proc *p, register struct open_args *ea)
{
[...]
}
Name of file to open is in ea->path, but this name can be: ./somefile
and i need a full path to it.

-- 
Paweł Jakub Dawidek
Network Administrator.
Am I Evil? Yes, I Am.



msg31386/pgp0.pgp
Description: PGP signature

Re: file name

[Eugene L. Vorokov]

> I want to control for example open() syscall:
> static int my_open(register struct proc *p, register struct open_args *ea)
> {
> [...]
> }
> Name of file to open is in ea->path, but this name can be: ./somefile
> and i need a full path to it.
 
I faced that problem once. I used an ugly hack: simulation of __getcwd()
syscall. You need to allocate user memory via mmap() with MAP_ANON flag,
pass it to __getcwd(), then copy string to kernel using copyin() or like
that, and munmap() the memory. This is neither proper nor efficient way
to do that, but it's easy and it works. Note that in case of ./ or
several ../ in the file name you may need to do some extra processing
to get "correct" full path.
 
Regards,
Eugene


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

status of bluetooth support for FreeBSD?

[Marco Molteni]

Hi all,

I remember an email thread on -hackers last October on bluetooth
support for FreeBSD:

http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=589265+595599+/usr/local/www/db/text/2001/freebsd-hackers/20011007.freebsd-hackers

There were two different projects, one in design phase (by John Kozubik
<[EMAIL PROTECTED]>) and another (by Maksim Yevmenkin <[EMAIL PROTECTED]>)
with already some beta code working.

any news on this?

thanks
Marco

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file name

[Paweł Jakub Dawidek]

On Mon, Feb 04, 2002 at 01:36:44PM +0300, Eugene L. Vorokov wrote:
+> I faced that problem once. I used an ugly hack: simulation of __getcwd()
+> syscall. You need to allocate user memory via mmap() with MAP_ANON flag,
+> pass it to __getcwd(), then copy string to kernel using copyin() or like
+> that, and munmap() the memory. This is neither proper nor efficient way
+> to do that, but it's easy and it works. Note that in case of ./ or
+> several ../ in the file name you may need to do some extra processing
+> to get "correct" full path.
+>  
Working! thX a lot! :)

-- 
Paweł Jakub Dawidek
Network Administrator.
Am I Evil? Yes, I Am.



msg31389/pgp0.pgp
Description: PGP signature

Re: stack alignment issues

[Michal Mertl]

Greg Shenaut wrote:
> In message <[EMAIL PROTECTED]>, Dan Nelson cleopede:
> >In the last episode (Feb 03), Alfred Perlstein said:
> >> * Michal Mertl <[EMAIL PROTECTED]> [020203 08:17] wrote:
> >> Not really sure what to make of this, anyone else know how we ought
> >> to fix this?
> >
> >This has actually been an issue for ages, most commonly seen with
> >doubles.  take a look at the thread at
>
> Has any "real world" program ever been significantly affected by
> this "problem"?

I don't know any such program but I suppose they exist. The problem is
probably generaly unnoticed by the people running the program.

FWIW OpenBSD 2.6 has the same problem but Linux (kernel 2.0 and 2.4) is
unaffected.

Did you look at the patch by Bruce at
http://groups.yahoo.com/group/freebsd-current/message/39605 ?

Bruce, is it still fresh in your memory? Can you comment on the patch -
can it be commited in some form?

-- 
Michal Mertl
[EMAIL PROTECTED]






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: File name.

[Terry Lambert]

Pawe³ Jakub Dawidek wrote:
> Nope. We are in kernel area.
> I want to control for example open() syscall:
> static int my_open(register struct proc *p, register struct open_args *ea)
> {
> [...]
> }
> Name of file to open is in ea->path, but this name can be: ./somefile
> and i need a full path to it.

Look at the "open" and "exec" source code.

The "." is interpreted in the context of the current
directory for the current process for the lookup.

The answer is to know what "." means, in context.  If
you don't have a current process from which to get a
pointer to the current directory vnode, then you will
need to make one up yourself.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

SMP problem on DELL PowerEdge 2550 with Cyclades Cyclom YeP boards (STABLE 4.5)

[Arjan Knepper]

When a dual processor kernel is used the system panics (crash and 
reboot) on io on the cyclades serial ports.
Single processor kernel runs without problems.

Any ideas?

Thanks,
Arjan Knepper


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: status of bluetooth support for FreeBSD?

[Maksim Yevmenkin]

Hackers,

sorry for wide distribution. there are some news. i will submit full 
status report when its due (this weed i think)

thanks,
max

Marco Molteni wrote:
> 
> Hi all,
> 
> I remember an email thread on -hackers last October on bluetooth
> support for FreeBSD:
> 
> 
>http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=589265+595599+/usr/local/www/db/text/2001/freebsd-hackers/20011007.freebsd-hackers
> 
> There were two different projects, one in design phase (by John Kozubik
> <[EMAIL PROTECTED]>) and another (by Maksim Yevmenkin <[EMAIL PROTECTED]>)
> with already some beta code working.
> 
> any news on this?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Request for submissions: FreeBSD Bi-Monthly Development Status Report

[Robert Watson]

This is a solicitation for submissions for the December 2001 - January
2002 FreeBSD Bi-Monthly Development Status Report.  All submissions are
due by February 8, 2002.  Submissions should be made by filling out the
template found at: 
 
  http://www.FreeBSD.org/news/status/report-sample.xml
 
Submissions must then be e-mailed to the following address:
 
  [EMAIL PROTECTED]
 
For automatic processing.  Reports must be submitted in the XML format
described, or they will be silently dropped.  Submissions made to other
e-mail addresses will be ignored. 
 
Status reports should be submitted once per project, although project
developers may choose to submit additional reports on specific
sub-projects of substantial size.  Status reports are typically one or two
short paragraphs, but the text may be up to 20 lines in length. 
Submissions are welcome on a variety of topics relating to FreeBSD,
including development, documentation, advocacy, and development processes.
Prior status reports may be viewed at:
  
  http://www.FreeBSD.org/news/status/

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: stack alignment issues

[Bruce Evans]

On Mon, 4 Feb 2002, Michal Mertl wrote:

> Did you look at the patch by Bruce at
> http://groups.yahoo.com/group/freebsd-current/message/39605 ?
>
> Bruce, is it still fresh in your memory? Can you comment on the patch -
> can it be commited in some form?

I haven't done anything to clean up the patch.  I hope the problem
will go away in future versions of gcc (align the stack at runtime in
the few routines that actually need it).

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: natd UDP errors with PPP demand dial

[Doug White]

On Sat, 2 Feb 2002, Marko wrote:

> My  question  is  concerning  the  popular  "netd[pid] failed to write
> packet back [Permission denied]" message.

This is caused by ipfw blocking packets after natd has translated them.
Check your firewall rules.

It might be an odd race of the rules not getting installed before natd
fires up. Are you using ppp.linkup (or equivalent) to configure ipfw in
this case?

Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED] |  www.FreeBSD.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: stack alignment issues

[Mike Silbersack]

On Tue, 5 Feb 2002, Bruce Evans wrote:

> On Mon, 4 Feb 2002, Michal Mertl wrote:
>
> > Did you look at the patch by Bruce at
> > http://groups.yahoo.com/group/freebsd-current/message/39605 ?
> >
> > Bruce, is it still fresh in your memory? Can you comment on the patch -
> > can it be commited in some form?
>
> I haven't done anything to clean up the patch.  I hope the problem
> will go away in future versions of gcc (align the stack at runtime in
> the few routines that actually need it).
>
> Bruce

Well, if Linux aligns the initial stack, the chance that gcc will have
auto-alignment added sounds to be about zero.  You might as well go ahead
with your patch when you get a chance.

Mike "Silby" Silbersack


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: stack alignment issues

[Alfred Perlstein]

* Mike Silbersack <[EMAIL PROTECTED]> [020204 10:04] wrote:
> 
> On Tue, 5 Feb 2002, Bruce Evans wrote:
> 
> > On Mon, 4 Feb 2002, Michal Mertl wrote:
> >
> > > Did you look at the patch by Bruce at
> > > http://groups.yahoo.com/group/freebsd-current/message/39605 ?
> > >
> > > Bruce, is it still fresh in your memory? Can you comment on the patch -
> > > can it be commited in some form?
> >
> > I haven't done anything to clean up the patch.  I hope the problem
> > will go away in future versions of gcc (align the stack at runtime in
> > the few routines that actually need it).
> >
> > Bruce
> 
> Well, if Linux aligns the initial stack, the chance that gcc will have
> auto-alignment added sounds to be about zero.  You might as well go ahead
> with your patch when you get a chance.

I agree, either way we should try to optimized the current situation,
especially if it seems to give a 2x perf boost!

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

A question about timecounters

[John Polstra]

I'm trying to understand the timecounter code, and in particular the
reason for the "microuptime went backwards" messages which I see on
just about every machine I have, whether running -stable or -current.
This problem is usually attributed to too much interrupt latency.  My
question is, how much latency is "too much"?  Which interrupt has to
be locked out for how long in order to see these messages?

John

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: A question about timecounters

[Dominic Marks]

On Mon, Feb 04, 2002 at 01:21:25PM -0800, John Polstra wrote:
> I'm trying to understand the timecounter code, and in particular the
> reason for the "microuptime went backwards" messages which I see on
> just about every machine I have, whether running -stable or -current.

I see them everywhere with -CURRENT, but not at all with -STABLE. This is
with two seperate machines. Perhaps that may add clues.

> This problem is usually attributed to too much interrupt latency.  My
> question is, how much latency is "too much"?  Which interrupt has to
> be locked out for how long in order to see these messages?
> 
> John
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message

-- 
Dominic

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Bluetooth stack for FreeBSD (full status)

[Maksim Yevmenkin]

Hackers,

Here is full status report on project i was working on. I apologize for
the
wide distribution, but i think that might be interesting.

Bluetooth stack for FreeBSD (Netgraph implementation)
=

The project is making progress. I decided to submit report because now i
have
some confidence that i can make it actually work. The goal is to design
and
implement Host Controller Interface (HCI) and Link Layer Control and
Adaptation
Protocol (L2CAP) layers using Netgraph framework. All information
obtained from
Bluetooth Specification Book v1.1.

More distant goal is to write support for Service Discovery Protocol
(SDP) and
RFCOMM protocol (serial port emulation over Bluetooth link). RFCOMM is
more fun
(IMO) and the current plan is to write RFCOMM Netgraph module and then
tie it
with "ng_tty" to complete the graph.

BTW, while i was working on this Nokia has released another open source
Bluetooth stack for Linux - Affix (http://affix.sourceforge.net). And i
do
not want to see FreeBSD behind :)

Project roadmap


Step 1: General design

Status: Complete. Everything is pretty much defined and i have
more
or less clear picture of how it will work. However, there are
several
minor issues. I still trying to figure them out.

Step 2: Implementation (HCI and L2CAP layer)

Status: Complete. HCI and L2CAP Netgraph nodes have been
implemented.
Most of the implementation issues have been resolved. However,
there
are some parts of the code that may require minor changes.

Step 3: Testing

Status: In progress. I finally figured out how to etherboot
-current
under VMWare (would be nice if someone can put it into
handbook), and
now i have perfect "sand box".

Testing is likely to take some time. I do not have real
Bluetooth
hardware at this point, so i wrote some tools that allow me to
test
the code. Some of them will be used as foundation for future
utilities.
But i only can do spot testing. I need hardware.

At this point the code seems to work, but i still need to test
all
failure modes and make sure code does the right thing. The
Bluetooth
specification does not provide great details on everything
(IMO), so
i'm trying to do reasonable thing.

After this step is complete i will make an engineering release
and
make it available to the community. The purpose is to collect
feedback
from people who familiar with Netgraph and/or Bluetooth and make
all
required changes.

Step 4: Utilities/Library API/Documentation

Status: In progress. Some work already has been done as part of
"Step 3: Testing". I need some time and external input to figure
out
what is actually required. Ideal case would be to reuse what is
already
implemented.

Step 5: Unit testing with real hardware

Status: Not complete. I keep looking for Bluetooth hardware
every day.
I'm glad to see that it is actually exists.

The good news is that some cards have UART 1650 on board, so (i
hope)
they are just fancy serial ports. If that is true, then "ng_sio"
module
would be perfect. The "ng_sio" will act just like "ng_ether"
module,
but for serial ports.

NOTE: "ng_sio" module does not exist yet :)

Step 6: Final acceptance testing and stable release

Status: Not complete. This is not for me to decide :) I hope to
get
feedback from people.

Issues
==

1. Bluetooth hardware. I do not have real Bluetooth hardware and i need
it
   badly :) If people can donate hardware/specs it would be great. I
promise
   to write all required drivers and make them available. I also promise
to
   return hardware/specs on first request. For now my plan is to spend
some
   amount of $$$ and get a card or even two.

2. Project name. I would like to see the name that reflects the
following:
   - it is a Bluetooth stack
   - implementation is for FreeBSD
   - implementation based on Netgraph framework

Thanks,
max

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: A question about timecounters

[John Polstra]

In article <[EMAIL PROTECTED]>,
Dominic Marks  <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 04, 2002 at 01:21:25PM -0800, John Polstra wrote:
> > I'm trying to understand the timecounter code, and in particular the
> > reason for the "microuptime went backwards" messages which I see on
> > just about every machine I have, whether running -stable or -current.
> 
> I see them everywhere with -CURRENT, but not at all with -STABLE. This is
> with two seperate machines. Perhaps that may add clues.

I'm looking for something less empirical than that.  When somebody
says this problem is caused by too much interrupt latency, I assume
they have a mental model of what is going wrong when this excessive
latency occurs.  Given that, it should be possible to make a statement
like, "If X is never locked out for longer than Y, this problem
cannot happen."  I'm looking for definitions of X and Y.  X might be
hardclock() or softclock() or non-interrupt kernel processing.  Y
would be some measure of time, probably a function of HZ and/or the
timecounter frequency.

John
-- 
  John Polstra
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

VCD file system?

[Mike Meyer]

I'm not sure where this should go, but -hackers seems to be about right.

I notice that I can put a Video CD in a Windows machine - even back to
W98 - and it manages to show me folders and files on it. This makes me
think that the thing has a file system on it.

The question is then - what's the file system format, and is it
available for FreeBSD or is someone working on it?

Thanx,
  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Bluetooth stack for FreeBSD (full status)

[Will Andrews]

On Mon, Feb 04, 2002 at 01:42:21PM -0800, Maksim Yevmenkin wrote:
> Hackers,

Please properly format your email so it doesn't look like the
below so I can read it.

> Here is full status report on project i was working on. I apologize for
> the
> wide distribution, but i think that might be interesting.
> 
> Bluetooth stack for FreeBSD (Netgraph implementation)
> =
> 
> The project is making progress. I decided to submit report because now i
> have
> some confidence that i can make it actually work. The goal is to design
> and
> implement Host Controller Interface (HCI) and Link Layer Control and
> Adaptation
> Protocol (L2CAP) layers using Netgraph framework. All information
> obtained from
> Bluetooth Specification Book v1.1.
[...]

This sounds like something that should be submitted to
[EMAIL PROTECTED] for inclusion with the
next FreeBSD Development Monthly Status Report.  You'll want to
abridge it for that purpose though.  :)

Regards,
-- 
wca

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: VCD file system?

[Wilko Bulte]

On Mon, Feb 04, 2002 at 04:35:19PM -0600, Mike Meyer wrote:

ISO9660, so plain old CDROM fs.

At least the VCDs I bought in HongKong last year are like that.

Wilko

> I'm not sure where this should go, but -hackers seems to be about right.
> 
> I notice that I can put a Video CD in a Windows machine - even back to
> W98 - and it manages to show me folders and files on it. This makes me
> think that the thing has a file system on it.
> 
> The question is then - what's the file system format, and is it
> available for FreeBSD or is someone working on it?
> 
>   Thanx,
>--
> Mike Meyer <[EMAIL PROTECTED]>http://www.mired.org/home/mwm/
> Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
---end of quoted text---

-- 
|   / o / /_  _ [EMAIL PROTECTED]
|/|/ / / /(  (_)  Bulte Arnhem, the Netherlands

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: VCD file system?

[Moran, Chris]

I am pretty sure it is ISO

- Original Message -
From: "Mike Meyer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 05, 2002 9:35 AM
Subject: VCD file system?


> I'm not sure where this should go, but -hackers seems to be about right.
>
> I notice that I can put a Video CD in a Windows machine - even back to
> W98 - and it manages to show me folders and files on it. This makes me
> think that the thing has a file system on it.
>
> The question is then - what's the file system format, and is it
> available for FreeBSD or is someone working on it?
>
> Thanx,
>  --
> Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
> Independent WWW/Perforce/FreeBSD/Unix consultant, email for more
information.
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: fork rate limit

[Anthony Schneider]

I've actually wanted something like this for a while and have considered
coding it myself.  Perhaps this could go into a login.conf variable
(which I would have to create myself), but originally my plan was basically
kill off parent processes with the uid of the user who is fork()'ing too
often (200 per 10 seconds sounds good) simply hard-coded.

Now, should this be available as a login.conf variable, and should the
variable ever be used on a system other than my own, it could very easily be
defaulted to something like :maxforks=0: for a 10 second timespan, and set
to :maxforks=200: for the scenario we are talking about, perhaps assigned
exclusively to student (or untrusted) accounts.  So, by default, the limit
will be ignored, and aside from the potential for poor implementation of this,
the only side effect would be a default login.conf with an extra line, and
perhaps a few extra lines in the login.conf manpage.

Some people would like to limit this, and should they want to, they should
be able to.  People run public access systems (myself included) where fork
bombs can put a huge load on the system before a sysadmin can finally pick
out the perpetrator and zap him.  This is a non-fatal, but VERY annoying
scenario to deal with, and if it can be prevented, I say go for it.

I believe that a few tweaks to fork1(), struct uidinfo and some others would
do the trick.  Gaspar, if you choose to go ahead with this and would like
assistance (testing, coding), I'd be glad to help.  Also, if anyone has any
further input, I know that I'd be glad to hear about it.
-Anthony.


p.s. sincerest apologies for anyone who may have received several copies of
this email.  I've been having a few mail difficulties.

On Sat, Feb 02, 2002 at 11:54:36PM -0800, Mike Makonnen wrote:
> On Sun, 3 Feb 2002 02:35:46 +0400
> Gaspar Chilingarov <[EMAIL PROTECTED]> wrote:
> 
> > I've got such situation on our free shellbox set up in the
> > university - some newbies were kidding with old while(1) fork();
> > attack. Finnaly they got hit by memory limits set up for each
> > user, but anyway they were taking a lot of processor time. I
> > prefer to limit some uid's ability to do many forks in some
> > short period - like 'no more than 200 forks in 10 seconds' or
> > smthng like this.
> 
> Lock them out of the box for a while. If they do it again ban them
> forever. The students will learn pretty quickly not to do such things.
> This means less work for you, and no need to continuously maintain diffs
> against the kernel sources. IMO it's a *very,very* bad thing to
> introduce changes into the kernel that might introduce unintended side
> effects when the problem can be solved administratively.
> 
> 
> cheers,
> mike makonnen
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message









msg31407/pgp0.pgp
Description: PGP signature

Re: fork rate limit

[Dan Nelson]

In the last episode (Feb 04), Anthony Schneider said:
> I've actually wanted something like this for a while and have considered
> coding it myself.  Perhaps this could go into a login.conf variable
> (which I would have to create myself), but originally my plan was basically
> kill off parent processes with the uid of the user who is fork()'ing too
> often (200 per 10 seconds sounds good) simply hard-coded.

Killing off parent procs could really upset a regular user who is
running ./configure, which could easily spawn a couple undred processes
in 10 seconds.  Maybe simply delay the fork() until the rate drops?

-- 
Dan Nelson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Bluetooth stack for FreeBSD (full status)

[Terry Lambert]

Maksim Yevmenkin wrote:
> More distant goal is to write support for Service Discovery Protocol
> (SDP) and RFCOMM protocol (serial port emulation over Bluetooth link).

FWIW:

The SDP is based on SLP; the Salutation Consortium (also
with major support from IBM) has several implementations
of this, and there are a couple of public implementations
as well, including a mesh-enabled DA.  If you search for
"Service Location Protocol" on the web, you should find
most of these.

I haven't really taken an active interest in BlueTooth,
since there are no laptops or printers that come with
it already present; I rather think it will end up as
still-born because of 802.11e Gigabit wireless, which
can use as little or less power.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Bluetooth stack for FreeBSD (full status)

[Duncan Barclay]

From: "Terry Lambert" <[EMAIL PROTECTED]>
> I haven't really taken an active interest in BlueTooth,
> since there are no laptops or printers that come with
> it already present; I rather think it will end up as
> still-born because of 802.11e Gigabit wireless, which
> can use as little or less power.

There are now a few devices with Bluetooth in them. Sony has had a Viao
with it in for a while.

802.11e is not gigabit wireless. .11e is quality of service enhancements
to the .11 MAC. You may be confusing it with .11a - 54Mbps at 5.2GHz or
the new .11g giving 54Mbps at 2.45GHz. Some people (Proxim) have .11a cards
that can operate at 108Mbps. This will have a reduced range though as they
probably halve the forward error correction somehow - maybe by
increased puncturing.

.11 without .11e is worse than Bluetooth for certain data types. For example
it cannot carry isochronous data. Bluetooth was never meant to compete
with .11 and was designed for a different purpose - mobile phones.
Wanderering
around the UK's high streets a lot of phone shops and a couple of the bigger
consumer electronics chains are now selling Bluetooth enabled stuff.

Duncan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: fork rate limit

[Anthony Schneider]

good point.  it seems that on open (yet restricted) systems, users wouldn't
be ./configure'ing much software, particularly if quotas are small and
network access is next to none, which would leave me inclined to go with
the kill().

But, of course, that would just be for my own uses.  Perhaps there's a way
to do both?  Either have two login.conf variables, one for delay and one
for timespan, or even combine them into one with a 'd' or 't' suffix?  I
guess the kill() isn't particularly necessary.
-Anthony.

On Mon, Feb 04, 2002 at 05:35:51PM -0600, Dan Nelson wrote:
> In the last episode (Feb 04), Anthony Schneider said:
> > I've actually wanted something like this for a while and have considered
> > coding it myself.  Perhaps this could go into a login.conf variable
> > (which I would have to create myself), but originally my plan was basically
> > kill off parent processes with the uid of the user who is fork()'ing too
> > often (200 per 10 seconds sounds good) simply hard-coded.
> 
> Killing off parent procs could really upset a regular user who is
> running ./configure, which could easily spawn a couple undred processes
> in 10 seconds.  Maybe simply delay the fork() until the rate drops?
> 
> -- 
>   Dan Nelson
>   [EMAIL PROTECTED]



msg31411/pgp0.pgp
Description: PGP signature

Re: Bluetooth stack for FreeBSD (full status)

[Maksim Yevmenkin]

Duncan Barclay wrote:
> 
> From: "Terry Lambert" <[EMAIL PROTECTED]>
> > I haven't really taken an active interest in BlueTooth,
> > since there are no laptops or printers that come with
> > it already present; I rather think it will end up as
> > still-born because of 802.11e Gigabit wireless, which
> > can use as little or less power.
> 
> There are now a few devices with Bluetooth in them. Sony has had a Viao
> with it in for a while.

yes, Sony VAIO PCG-SR31K

http://www.zdnet.co.uk/reviews/rstories/0,3040,e7110920,00.html

as far as printing goes, you can get Bluetooth adapter for your
printer. 

thanks,
max

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: stack alignment issues

[Terry Lambert]

Alfred Perlstein wrote:
> > Well, if Linux aligns the initial stack, the chance that gcc will have
> > auto-alignment added sounds to be about zero.  You might as well go ahead
> > with your patch when you get a chance.
> 
> I agree, either way we should try to optimized the current situation,
> especially if it seems to give a 2x perf boost!

How about "aligning the initial stack"?

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: A question about timecounters

[Mike Smith]

> In article <[EMAIL PROTECTED]>,
> Dominic Marks  <[EMAIL PROTECTED]> wrote:
> > On Mon, Feb 04, 2002 at 01:21:25PM -0800, John Polstra wrote:
> > > I'm trying to understand the timecounter code, and in particular the
> > > reason for the "microuptime went backwards" messages which I see on
> > > just about every machine I have, whether running -stable or -current.
> > 
> > I see them everywhere with -CURRENT, but not at all with -STABLE. This is
> > with two seperate machines. Perhaps that may add clues.
> 
> I'm looking for something less empirical than that.  When somebody
> says this problem is caused by too much interrupt latency, I assume
> they have a mental model of what is going wrong when this excessive
> latency occurs.

It's not necessarily caused by interrupt latency.  Here's the assumption 
that's being made.

There is a ring of timecounter structures, of some size.  In testing,
I've used sizes of a thousand or more, but still seen this problem.

There is a pointer to the "current" timecounter structure.

When the "current" time is updated, the following procedure is followed:

 - Find the "next" timecounter in the ring.
 - Update its contents with the new current time.
 - Move the "current" pointer.

When one wishes to read the current time, one proceeds as follows:

 - Get the "current" pointer and save it locally.
 - Read the timecounter structure via the local "current" pointer.

Since the operations on the "current" pointer are atomic, there is no 
need to lock the structure.

There are a couple of possible problems with this mechanism.

One is that the ring "catches up" with your saved copy of the
"current" pointer, ie. inbetween fetching the pointer and reading the
timecounter contents, the "next" pointer passes over you again in such
a fashion that you get garbage out of the structure.

Another is that there is a race between multiple updaters of the
timecounter; if two parties are both updating the "next" timecounter
along with another party trying to get the "current" time, this could
cause corruption.

All that interrupt latency will do is make the updates late; I can't
actually see how it could cause corruption.  Corruption has to be
caused by mishandling of the timecounter ring in some fashion.

Note that you can probably eliminate the ring loop theory by
allocating a very large number of entries in the ring by setting
NTIMECOUNTER (kern/kern_tc.c) higher.  The structures are small; try
100,000 or so.

If you can reproduce under these circumstances, try adding some checks
to make sure the "current" timecounter pointer is behaving
monotonically; just save the last timecounter pointer in microtime()
et. al.

Another test worth performing is to look at the tco_delta function for
the timecounter and make sure that it returns a sane value, and one
that doesn't behave out of synch with the interrupt handler that updates
the timecounter proper.  If you save the delta value in the timecounter 
and zero it when it's updated, you can catch this.

You can rule this out by using getmicroptime() rather than
microuptime(); it may return the same value twice, which isn't
desirable, but that would be better than nothing.

Hope this helps a bit.

Regards,
Mike

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: A question about timecounters

[John Polstra]

In article <[EMAIL PROTECTED]>,
Mike Smith  <[EMAIL PROTECTED]> wrote:
> 
> It's not necessarily caused by interrupt latency.  Here's the assumption 
> that's being made.
[...]

Thanks for the superb explanation!  I appreciate it.

> There is a ring of timecounter structures, of some size.  In testing,
> I've used sizes of a thousand or more, but still seen this problem.
> 
> There is a pointer to the "current" timecounter structure.

That's the global variable named "timecounter", right?  I did notice
one potential problem: that variable is not declared volatile.  So
in this part ...

> When one wishes to read the current time, one proceeds as follows:
> 
>  - Get the "current" pointer and save it locally.
>  - Read the timecounter structure via the local "current" pointer.

... the compiler is perfectly free to reread the global multiple
times in the function rather than using the saved local copy.  If the
"current" pointer has moved in that time, we'll an inconsistent view
of the timecounter.  In looking at the generated code I haven't found
any actual instances of that.  But I'll try making it volatile just to
make sure.  Even if it doesn't cause any problems currently, I think
we should change it to volatile since it could start to cause problems
some day.

I also noticed this in tco_forward():

tco = timecounter;
tc = sync_other_counter();
[...]
if (tco->tc_poll_pps)

But sync_other_counter() loads its own copy of "timecounter",
and there's no guarantee it hasn't changed from the value that
tco_forward() saved in its local variable.  I'm not sure yet if
that's a potential problem.  It could corrected by passing "tco" as
an argument to sync_other_counter.  I'll try that too.

> There are a couple of possible problems with this mechanism.
> 
> One is that the ring "catches up" with your saved copy of the
> "current" pointer, ie. inbetween fetching the pointer and reading the
> timecounter contents, the "next" pointer passes over you again in such
> a fashion that you get garbage out of the structure.

As you mentioned, with a large enough ring this should be impossible.
If I read the code correctly, the "current" pointer is only moved
once per second.  So in the current ring of 4 counters (number 0 is
special), it would take 4 seconds to wrap around the ring.  That's a
pretty long time.

> Another is that there is a race between multiple updaters of the
> timecounter; if two parties are both updating the "next" timecounter
> along with another party trying to get the "current" time, this could
> cause corruption.
> 
> All that interrupt latency will do is make the updates late; I can't
> actually see how it could cause corruption.  Corruption has to be
> caused by mishandling of the timecounter ring in some fashion.

I agree.

> Note that you can probably eliminate the ring loop theory by
> allocating a very large number of entries in the ring by setting
> NTIMECOUNTER (kern/kern_tc.c) higher.  The structures are small; try
> 100,000 or so.

OK, but even the thousand you tried should give a cushion of more
than 16 minutes.

> If you can reproduce under these circumstances, try adding some checks
> to make sure the "current" timecounter pointer is behaving
> monotonically; just save the last timecounter pointer in microtime()
> et. al.
> 
> Another test worth performing is to look at the tco_delta function for
> the timecounter and make sure that it returns a sane value, and one
> that doesn't behave out of synch with the interrupt handler that updates
> the timecounter proper.  If you save the delta value in the timecounter 
> and zero it when it's updated, you can catch this.
> 
> You can rule this out by using getmicroptime() rather than
> microuptime(); it may return the same value twice, which isn't
> desirable, but that would be better than nothing.
> 
> Hope this helps a bit.

Yep, thanks again.

John
-- 
  John Polstra
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: VCD file system?

[Daniel O'Connor]

On 04-Feb-2002 Moran, Chris wrote:
> I am pretty sure it is ISO

VCD's have a 'shell' ISO9660 FS on them to put stuff like a VCD player and
movie info on, but the actual movie data is not stored on that FS.

I believe it is recorded with a different mode that has less error checking
(more space) on another track.

I think mplayer can play them though.

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

pthread_sigmask problem

[callum . gibson]

Hi all,
I have an application which attempts to block all signals using
pthread_sigmask(). I'm aware that this only works on the current thread,
however this call occurs before any other threads are created and so
should be inherited. I call it as follows:

sigset_t signalSet;

(void)sigfillset(&signalSet);
(void)pthread_sigmask(SIG_BLOCK, &signalSet, NULL);

However, it seems that signals such as SIGPIPE, SIGINT, etc will still
kill the process. I also tried replacing the pthread_sigmask call with
sigprocmask to see if it made any difference, which it didn't.

The only other relevant info I can think of, is that I start up another
thread specifically for catching SIGTERM, thusly:

(void)sigemptyset(&signalSet);
(void)sigaddset(&signalSet, SIGTERM);
if (sigwait(&signalSet, &signo) < 0 || signo != SIGTERM)
/* some error handling */;

/* shutdown cleanly */
etc.

This part still works as expected.

Additionally, I have the same code working under Solaris threads (not pthreads
on Solaris) fine, the only relevant change being the call thr_sigsetmask
instead of pthread_sigmask.

The same behaviour is exhibited on 4.3-RELEASE and 4.4-RELEASE.

Any ideas on what is wrong?

regards,
Callum

(c)2002 Callum Gibson   [EMAIL PROTECTED]
Global Markets IT, Deutsche Bank, Australia   61 2 9258 1620
### The opinions in this message are mine and not Deutsche's ###

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: VCD file system?

[Mike Meyer]

[Context recovered from top posting.]

Wilko Bulte <[EMAIL PROTECTED]> types:
> On Mon, Feb 04, 2002 at 04:35:19PM -0600, Mike Meyer wrote:
> > I notice that I can put a Video CD in a Windows machine - even back to
> > W98 - and it manages to show me folders and files on it. This makes me
> > think that the thing has a file system on it.
> > The question is then - what's the file system format, and is it
> > available for FreeBSD or is someone working on it?
> ISO9660, so plain old CDROM fs.
> 
> At least the VCDs I bought in HongKong last year are like that.

Here's what happens when I try and mount one on a SCSI cdrom drive:

bash-2.05a$ mount /cdrom
cd9660: /dev/cd0c: Invalid argument

This one worked on Windows. At least, I managed to get it to play the
video.

Thanx,
  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Bluetooth stack for FreeBSD (full status)

[Terry Lambert]

Duncan Barclay wrote:
> There are now a few devices with Bluetooth in them. Sony has had a Viao
> with it in for a while.

Which model?  My PCG-XG29 and the 505 a friend of mine
recently bout don't have it.  You'd think that with IBM
being so "gung ho" about BlueTooth, that every ThinkPad,
IBM "Palm Pilot", and Lexmark printer would have it.

IBM is notoriously schitzophrenic, though, and it's
pretty clear it's the technical people puching it, and
manufacturing is far behind.


> 802.11e is not gigabit wireless. .11e is quality of service enhancements
> to the .11 MAC. You may be confusing it with .11a - 54Mbps at 5.2GHz or
> the new .11g giving 54Mbps at 2.45GHz. Some people (Proxim) have .11a cards
> that can operate at 108Mbps. This will have a reduced range though as they
> probably halve the forward error correction somehow - maybe by
> increased puncturing.

Actually, I was thinking of 802.16, but I turned the
"6" into an "e".  There was a recent article on it, where
the FCC had approved it, but the cell phone companies were
all up in arms over their revenue model being shot in the
head.

It uses broadband over a large number of carrier frequencies,
and *really* is gigabit wireless.

The article also noted that radio astronomers were upset
about the amount of "white noise" it would produce, which
would make radio astronomy harder.


> .11 without .11e is worse than Bluetooth for certain data types. For example
> it cannot carry isochronous data. Bluetooth was never meant to compete
> with .11 and was designed for a different purpose - mobile phones.
> Wanderering around the UK's high streets a lot of phone shops and a
> couple of the bigger consumer electronics chains are now selling
> Bluetooth enabled stuff.

I've also heard it sold as "the ultimate solution for PDAs",
and "the replacement for IR links, which currently have to
be line-of-sight", and "the way to get rid of cables".

I think we'll eventually find out that "it's both a desert
topping, and a floor wax!".  8-).  But right now, it's a
solution in search of a problem.

All this is really going off topic, though...

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: pthread_sigmask problem

[Daniel Eischen]

On Tue, 5 Feb 2002 [EMAIL PROTECTED] wrote:
> Hi all,
> I have an application which attempts to block all signals using
> pthread_sigmask(). I'm aware that this only works on the current thread,
> however this call occurs before any other threads are created and so
> should be inherited. I call it as follows:
> 
> sigset_t signalSet;
> 
> (void)sigfillset(&signalSet);
> (void)pthread_sigmask(SIG_BLOCK, &signalSet, NULL);
> 
> However, it seems that signals such as SIGPIPE, SIGINT, etc will still
> kill the process. I also tried replacing the pthread_sigmask call with
> sigprocmask to see if it made any difference, which it didn't.

Yes, at least with FreeBSD pthreads you have to either install a signal
handler to catch these signals or to set the handler to SIG_IGN.  When
you set a threads signal mask, even if it is for all threads, you don't
affect how signals are delivered to the process.  The default action
for SIGPIPE and SIGINT is to kill the process, so setting masks for
threads doesn't affect this.

> The only other relevant info I can think of, is that I start up another
> thread specifically for catching SIGTERM, thusly:
> 
> (void)sigemptyset(&signalSet);
> (void)sigaddset(&signalSet, SIGTERM);
> if (sigwait(&signalSet, &signo) < 0 || signo != SIGTERM)
>   /* some error handling */;
> 
> /* shutdown cleanly */
> etc.
> 
> This part still works as expected.

POSIX explicitly states that if you use sigwait() and there are no
handlers installed, that the effect is as if a handler is installed
for the signal.  So using sigwait() will automagically install a
handler for the signal and then remove it once the sigwait() is
completed (that is, unless the application already installed a handler
for the signal, in which case sigwait doesn't install a handler).

-- 
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: pthread_sigmask problem

[callum . gibson]

Thanks, Dan. (I saw your name come up in the archives next to a lot of
threads/signals posts while I was looking for an answer to this so I
wondered if you'd answer. :-)

[EMAIL PROTECTED] writes:
}> However, it seems that signals such as SIGPIPE, SIGINT, etc will still
}> kill the process. I also tried replacing the pthread_sigmask call with
}> sigprocmask to see if it made any difference, which it didn't.
}Yes, at least with FreeBSD pthreads you have to either install a signal
}handler to catch these signals or to set the handler to SIG_IGN.  When
}you set a threads signal mask, even if it is for all threads, you don't
}affect how signals are delivered to the process.  The default action
}for SIGPIPE and SIGINT is to kill the process, so setting masks for
}threads doesn't affect this.

I figured it was just using the default action for these signals. So, am
I mistaken in thinking that SIG_BLOCK was supposed to ignore those signals
or is this a pthreads bug on FreeBSD? Or just an "undefined" behaviour
and a pthreads gotcha? It's worth noting that even with pthreads on Solaris
I get the behaviour I was expecting (ie the signals are ignored) using
either pthread_sigmask or sigprocmask.

Also, is it documented anywhere which signals will behave like this? It
seems like it would be all of them, as if the process still has an inherent
signal mask independent of the threads running, thus requiring signal
handlers to be installed for them. Hmm, it's a lot more verbose calling
sigaction for every signal rather than a single pthread_sigmask call.
I guess that's why we have for loops.

C

(c)2002 Callum Gibson   [EMAIL PROTECTED]
Global Markets IT, Deutsche Bank, Australia   61 2 9258 1620
### The opinions in this message are mine and not Deutsche's ###

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: VCD file system?

[Terry Lambert]

Mike Meyer wrote:
> Here's what happens when I try and mount one on a SCSI cdrom drive:
> 
> bash-2.05a$ mount /cdrom
> cd9660: /dev/cd0c: Invalid argument
> 
> This one worked on Windows. At least, I managed to get it to play the
> video.

Do you read German?

Here is a Linux version:

http://home.t-online.de/home/ritzert/videocd.html

The VideoCD format was never really publically documented
back when it was popular, and there were some programs that
reverse engineered it that Phillips went after (MPegTV?);
I remember that the last set of Commodore hardware had a
license for it, and it was held as a closely guarded secret
at that time.

It's actually pretty trivial; you need to be able to read
the full sector, instead of just the smaller "formatted"
data portion of it; this is already supported in an CDROM
hardware that can read raw audio off a CDROM, which is
pretty much any CDROM drive since the first one that could
do it in the SGI Indy, and the first one you could legally
buy in the U.S. seperate from a system (the Toshiba 3401B;
I have one, of course).

Probably, you are talking about a very old Video CD (CD-i),
which is Green Book standard.  Panasonix and Matsushita
CD drives can't read these, so it might just be a difference
in hardware.

If you are talking about a newer one, then it's a White Book
standard, or, the newer Video CD 2.0.  To get a copy of this,
you have to be a licensee from Phillips of one of:

o   CD Information Agreement
o   Software Dev Package
o   CD Disc/Player
o   VideoCD Disc/Player

See:




-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: pthread_sigmask problem

[callum . gibson]

callum writes:
}handlers to be installed for them. Hmm, it's a lot more verbose calling
}sigaction for every signal rather than a single pthread_sigmask call.
}I guess that's why we have for loops.

Doh! You can specify a set of signals with sigaction. Sorry about that.

C

(c)2002 Callum Gibson   [EMAIL PROTECTED]
Global Markets IT, Deutsche Bank, Australia   61 2 9258 1620
### The opinions in this message are mine and not Deutsche's ###

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: A question about timecounters

[John Baldwin]

On 04-Feb-02 John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Dominic Marks  <[EMAIL PROTECTED]> wrote:
>> On Mon, Feb 04, 2002 at 01:21:25PM -0800, John Polstra wrote:
>> > I'm trying to understand the timecounter code, and in particular the
>> > reason for the "microuptime went backwards" messages which I see on
>> > just about every machine I have, whether running -stable or -current.
>> 
>> I see them everywhere with -CURRENT, but not at all with -STABLE. This is
>> with two seperate machines. Perhaps that may add clues.
> 
> I'm looking for something less empirical than that.  When somebody
> says this problem is caused by too much interrupt latency, I assume
> they have a mental model of what is going wrong when this excessive
> latency occurs.  Given that, it should be possible to make a statement
> like, "If X is never locked out for longer than Y, this problem
> cannot happen."  I'm looking for definitions of X and Y.  X might be
> hardclock() or softclock() or non-interrupt kernel processing.  Y
> would be some measure of time, probably a function of HZ and/or the
> timecounter frequency.

X is hardclock I think, since hardclock() calls tc_windup().  I'm not sure what
Y is except that it is indeed a known value.  phk should know as he is Mr.
Timecounter.

> John
> -- 
>   John Polstra
>   John D. Polstra & Co., Inc.Seattle, Washington USA
>   "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: pthread_sigmask problem

[Daniel Eischen]

On Tue, 5 Feb 2002 [EMAIL PROTECTED] wrote:
> Thanks, Dan. (I saw your name come up in the archives next to a lot of
> threads/signals posts while I was looking for an answer to this so I
> wondered if you'd answer. :-)
> 
> [EMAIL PROTECTED] writes:
> }> However, it seems that signals such as SIGPIPE, SIGINT, etc will still
> }> kill the process. I also tried replacing the pthread_sigmask call with
> }> sigprocmask to see if it made any difference, which it didn't.
> }Yes, at least with FreeBSD pthreads you have to either install a signal
> }handler to catch these signals or to set the handler to SIG_IGN.  When
> }you set a threads signal mask, even if it is for all threads, you don't
> }affect how signals are delivered to the process.  The default action
> }for SIGPIPE and SIGINT is to kill the process, so setting masks for
> }threads doesn't affect this.
> 
> I figured it was just using the default action for these signals. So, am
> I mistaken in thinking that SIG_BLOCK was supposed to ignore those signals
> or is this a pthreads bug on FreeBSD? Or just an "undefined" behaviour
> and a pthreads gotcha? It's worth noting that even with pthreads on Solaris
> I get the behaviour I was expecting (ie the signals are ignored) using
> either pthread_sigmask or sigprocmask.

It's not clear to me that using pthread_sigmask should change
the default behaviour that signals have on the process.  Thread
signal masks seem to be independent of installed signal handlers
and default actions that signals have on the process.

> Also, is it documented anywhere which signals will behave like this? It
> seems like it would be all of them, as if the process still has an inherent
> signal mask independent of the threads running, thus requiring signal
> handlers to be installed for them. Hmm, it's a lot more verbose calling
> sigaction for every signal rather than a single pthread_sigmask call.
> I guess that's why we have for loops.

See sigaction(2).

>From your other email:

> Doh! You can specify a set of signals with sigaction. Sorry about that.

Nope, you can only install a handler for one signal at a time.

-- 
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: pthread_sigmask problem

[callum . gibson]

Let me know if I should take this off list now since it's probably reached
its limit of interest for most people.

[EMAIL PROTECTED] writes:
}> I figured it was just using the default action for these signals. So, am
}> I mistaken in thinking that SIG_BLOCK was supposed to ignore those signals
}> or is this a pthreads bug on FreeBSD? Or just an "undefined" behaviour
}> and a pthreads gotcha? It's worth noting that even with pthreads on Solaris
}> I get the behaviour I was expecting (ie the signals are ignored) using
}> either pthread_sigmask or sigprocmask.
}It's not clear to me that using pthread_sigmask should change
}the default behaviour that signals have on the process.  Thread
}signal masks seem to be independent of installed signal handlers
}and default actions that signals have on the process.

Well, it depends on what it means to block a signal. From reading the manpage
it seems to indicate that delivery of these signals is deferred indefinitely
until a thread sigwaits for them or if a thread doesn't have them blocked.
Since I was doing this as the very first thing in the process (ie there
are no other threads), it would imply that all other threads created from
then on would also block those signals. This is certainly how it behaves on
Solaris. Haven't checked Linux but will report back if you're interested.
In practice, FreeBSD's thread library probably has internal threads operating
in the background which are there from the outset and don't inherit this
mask and it's _those_ threads which are taking delivery of the fatal signals.

}> Also, is it documented anywhere which signals will behave like this? It
}> seems like it would be all of them, as if the process still has an inherent
}> signal mask independent of the threads running, thus requiring signal
}> handlers to be installed for them. Hmm, it's a lot more verbose calling
}> sigaction for every signal rather than a single pthread_sigmask call.
}> I guess that's why we have for loops.
}See sigaction(2).

Yeah, doesn't really explain if the process is anything more than the
sum of its threads. Under Solaris that's all it is. A non-threaded process
is actually a process with a single thread. This is the state of the process
when I do the sigprocmask/thr_setsigmask/pthread_sigmask call. It's only
after you make your first call to the thread library proper (by creating
a new thread) that the background threads appear (this is on Solaris).
I suspect this is not how it works on FreeBSD - the method of compilation
even gives a clue to this (a special compiler directive). Even without making
any new threads a FreeBSD threaded program will probably have these internal
threads (I'm speculating here as I don't have the equivalent of pstack
to be able to check that). I guess it also has something to do with being
a userland implementation?

I guess the question boils down to: Should an application be able to operate
oblivious to the existence of internal threads? Does a process exist
apart from the threads that make it up?

Anyway, sigaction does the trick - it just seems superfluous on Solaris,
at least.

}>From your other email:
}> Doh! You can specify a set of signals with sigaction. Sorry about that.
}Nope, you can only install a handler for one signal at a time.

Spotted that just after I sent it but I figured replying to myself twice
in a row was Really Bad (tm). I was right the first time.

C

(c)2002 Callum Gibson   [EMAIL PROTECTED]
Global Markets IT, Deutsche Bank, Australia   61 2 9258 1620
### The opinions in this message are mine and not Deutsche's ###

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: stack alignment issues

[Bruce Evans]

On Mon, 4 Feb 2002, Mike Silbersack wrote:

> On Tue, 5 Feb 2002, Bruce Evans wrote:
> > I haven't done anything to clean up the patch.  I hope the problem
> > will go away in future versions of gcc (align the stack at runtime in
> > the few routines that actually need it).
>
> Well, if Linux aligns the initial stack, the chance that gcc will have
> auto-alignment added sounds to be about zero.  You might as well go ahead
> with your patch when you get a chance.

There is a nonzero probability that the pessimization of aligning in almost
every routine will be fixed someday.  Actually, the pessimization is worse
-- the alignment is done before every call.

Example:

%%%
foo.c:
foo()
{
f1(1);
f2(2);
f3(3.0);
}
%%%

gcc -O -S [-mpreferred-stack boundary] currently generates the following
code for this:

%%%
.file   "z.c"
.version"01.01"
gcc2_compiled.:
.section.rodata
.p2align 3
.LC0:
.long 0x0,0x4008
.text
.p2align 2,0x90
.globl foo
.typefoo,@function
foo:
pushl %ebp
movl %esp,%ebp
subl $8,%esp# <- extra instruction for alignment (for foo)
addl $-12,%esp  # <- extra instruction for alignment (for f1)
pushl $1
call f1
addl $-12,%esp  # <- extra instruction for alignment (for f2)
pushl $2
call f2
addl $32,%esp   # <- extra instruction for alignment (for f3)
addl $-8,%esp   # <- extra instruction for alignment (another)
pushl .LC0+4
pushl .LC0
call f3
leave
ret
.Lfe1:
.sizefoo,.Lfe1-foo
.ident  "GCC: (c) 2.95.3 20010315 (release)"
%%%

It should generate something like:

.file   "z.c"
.version"01.01"
gcc2_compiled.:
.section.rodata
.p2align 3
.LC0:
.long 0x0,0x4008
.text
.p2align 2,0x90
.globl foo
.typefoo,@function
foo:
pushl %ebp
movl %esp,%ebp
andl $~0x7,%esp # <- extra instruction for alignment (for foo)
# Only needed since foo() uses FPU.
# 8-byte alignment enough for doubles?
# Adjust in prologue so that there are
# hopefully no alloca()-like issues, except
# we need a frame pointer to restore %esp.
pushl $1
call f1
pushl $2
call f2
pushl .LC0+4
pushl .LC0
call f3
leave
ret
.Lfe1:
.sizefoo,.Lfe1-foo
.ident  "GCC: (c) 2.95.3 20010315 (release)"
%%%

My patch is not suitable for committing verbatim.  It has 2 or 3 XXX's.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FreeBSD 5.x

[John Baldwin]

On 20-Jan-02 Robert Watson wrote:
> 
> On Sat, 19 Jan 2002, Alp Atici wrote:
> 
>> Is gcc 3.x going to be the default compiler starting from FBSD 5.x
>> series? Is the development on current branch compiled using gcc 3.0 (or
>> up)? 
>> 
>> Is 5.x series going to be based on a preemptible kernel?
> 
> Can't answer the gcc question, but yes, John Baldwin currently has support
> for preemption in his SMPng development tree.

The kernel is already somewhat preemptive.  The kernel in 5.0 will certainly be
preemptible, as making a kernel SMP safe makes it laregly preemptible (i.e,
safe for preemption) as well.  Making the kernel "fully" preemptive (i.e., we
can switch tasks on any setrunqueue() if the conditions favor that) is actually
a fairly esay thing to do, I'm just not sure how well it works right now. :)  I
just recently fixed some bugs in the alpha pmap code that should help out with
getting our kernel closer to that goal.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message