Re: Should jail treat ip-number?

[John Hay]

> >
> >I have some concern about jail, and would like to discuss them.
> >
> >Currentlly jail set an ip-number and let prisoned processes
> >only to bind it.
> >My concerns are,
> >
> >(1)When IPv6 is added to the system, more general id would be
> >   desirable.
> 
> I agree, *IF* IPv6 ever becomes a reality, we will look at this.

So when will you consider that it became a reality? :-) Or am I just
dreaming that some operating systems and routers ship with IPv6 and
that IANA, ARIN, APNIC and RIPE are dishing out IPv6 addresses and
that we are in the process of getting Kame integrated into FreeBSD? :-)

John
-- 
John Hay -- [EMAIL PROTECTED]


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

Re: Should jail treat ip-number?

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Yoshinobu Inoue writes:
>Hello,
>
>I have some concern about jail, and would like to discuss them.
>
>Currentlly jail set an ip-number and let prisoned processes
>only to bind it.
>My concerns are,
>
>(1)When IPv6 is added to the system, more general id would be
>   desirable.

I agree, *IF* IPv6 ever becomes a reality, we will look at this.

>(2)What is the goal of the restriction?

To isolate people in the jail from the "real" machine and from
other jails.

>   If physical level access protection is wanted,

it isn't.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Should jail treat ip-number?

[Yoshinobu Inoue]

Hello,

I have some concern about jail, and would like to discuss them.

Currentlly jail set an ip-number and let prisoned processes
only to bind it.
My concerns are,

(1)When IPv6 is added to the system, more general id would be
   desirable.

(2)What is the goal of the restriction?
   If physical level access protection is wanted,
   then specifing interface name is more general and certain
   way of achieving it.
   (Because when that ip-number is replaced to another
network interface, then the restriction also will move on
it)

   If some virtual network level protection is wanted,
   then specifying ip-number is suitable, but I think more
   general id should be used such as a pointer to a sockaddr.


I think kernel change will not so much for any above addition
or changes, but there will be some backword compatibility
issue for API. (some member addition to the jail structure,
and jail command extensions)

Yoshinobu Inoue


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

Re: Using non-PIC code in shared libraries?

[Peter Wemm]

Nate Williams wrote:
> What happens when this is done?  Can it ever work?
> 
> How about the reverse, where you link in PIC compiled libraries into
> static (.a) libraries?  Does this work?
> 
> Assuming it works (in either case) are there any performance
> hits/advantages to either?
> 
> My impression from past discussions is that you can't use non-PIC code
> in shared libraries (it won't work), and that you can use PIC code in
> static libraries, but you take a performance hit for it...
> 
> Am I right?

You *can* use non-PIC for shared libraries, but the resulting code requires
text relocations at runtime which cause copy-on-write faults and kill any
shareability.  This might be acceptable if you are using .so's for
single-process plug-ins or something, but generally you wouldn't want it
for libc (for example. :-).  Of course, getting ld-elf.so and ld(1) to be
quiet about it is another thing altogether...

Cheers,
-Peter




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

Re: FreeBSD at IETF (was: Re: IETF gettogether)

[Robert Watson]

Not yet -- I'm part way into porting the driver, but my experience with
pccard programming and the kernel pccard interface is somewhat dated.  I
hope to have better news soon--however, I'd welcome better news from
someone else :-).  Brian Wellington, who sits beside me with a NetBSD
machine, comments that he's found the NetBSD driver to have stability
problems, so..

Hope to see you on Wednesday at the FreeBSD dinner..

Robert


On Mon, 8 Nov 1999, Matt Crawford wrote:

> Has anyone got the Baystack IETF loaner cards working under FreeBSD yet?
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


  Robert N M Watson 

[EMAIL PROTECTED]  http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



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

Re: Use remote debugging on 3.3-Release

[Kenneth D. Merry]

Zhihui Zhang wrote...
> 
> I did a little remote debugging with serial cable on 4.0-current a while
> ago.  But now I can not make it work on 3.3-RELEASE.
> 
> I have used kermit to make sure that the cable connection is good.  I also
> have added necessary kernel options into the configuration file.  My
> questions are:
> 
> (1) What flag should I use with sio0.  FreeBSD-current uses 0x80.  What
> should I use with 3.3-RELEAE?  I have tried 0x40.

I use 0x50 with -stable, and 0x80 with -current.  Annoying, but it seems to
work.  (the stable in question isn't a up-to-the-minute version of -stable,
though)

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]


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

Use remote debugging on 3.3-Release

[Zhihui Zhang]

I did a little remote debugging with serial cable on 4.0-current a while
ago.  But now I can not make it work on 3.3-RELEASE.

I have used kermit to make sure that the cable connection is good.  I also
have added necessary kernel options into the configuration file.  My
questions are:

(1) What flag should I use with sio0.  FreeBSD-current uses 0x80.  What
should I use with 3.3-RELEAE?  I have tried 0x40.

(2) Is there a bug in FreeBSD 3.3-Release that prevents me from doing
remote debugging?

(3) Are there anything not described in the Online manual that I should
pay attention to? 

Any help is appreciated.

-Zhihui



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

strange NFS stuff going on... (inpcb=0x0,...)

[Karsten W. Rohrbach]

hi, i recently migrated our news box (which runs approx. 1MB/s nntp
traffic inbound and >2MB/s outbound) to several systems and got the
spool onto a vinum volume that spans 6 scsi busses (adaptec 3940UW) each
4 disks (IBM DNES 18GB). theres a private switched interconnect between
the reader box and the "fileserver" now and nfs seem to crash on me
somehow. nnrpd start to die after a few megabytes transfer and if i do
an fstat -vp on one of the nnrpd's i get
root@NEWS:black[~]31# fstat -vp 3820
USER CMD  PID   FD MOUNT  INUM MODE SZ|DV R/W
news nnrpd   3820 root / 2 drwxr-xr-x 512  r
news nnrpd   3820   wd /sp  158720 drwxrwxr-x  923136  r
news nnrpd   3820 text /   376 -r-xr-xr-x   90424  r
news nnrpd   38200* internet stream tcp
news nnrpd   38201* internet stream tcp
news nnrpd   38202* internet stream tcp
news nnrpd   38203* local dgram d4c7f400 <-> d4c7efc0
news nnrpd   38204* internet dgram udp d44b1600
news nnrpd   38205 /sp  158720 drwxrwxr-x  923136  r
news nnrpd   3820   12* local dgram d4c7fe40

example lsof output of one of the dead nnrpd's:
COMMAND PID USER   FD   TYPE DEVICE   SIZE/OFF NODE NAME
nnrpd  3820 news  rtd   VDIR   4,1310725122 /
nnrpd  3820 news  txt   VREG   4,131072  90424  376 
/home/news/bin/nnrpd
nnrpd  3820 news  txt   VREG   4,131078  63832   182626 
/usr/libexec/ld-elf.so.1
nnrpd  3820 news  txt   VREG   4,131078   757939707 
/usr/lib/libscrypt.so.2
nnrpd  3820 news  txt   VREG   4,131078  3185539805 
/usr/lib/libutil.so.2
nnrpd  3820 news  txt   VREG   4,131078 51772739742 /usr/lib/libc.so.3
nnrpd  3820 news0u  inet   0t0  TCP can't read inpcb 
at 0x
nnrpd  3820 news1u  inet   0t0  TCP can't read inpcb 
at 0x
nnrpd  3820 news2u  inet   0t0  TCP can't read inpcb 
at 0x
nnrpd  3820 news3u  unix 0xd42353c00t0 ->0xd422edc0
nnrpd  3820 news4u  inet 0xd44b16000t0  UDP 
localhost:1276->localhost:1119
nnrpd  3820 news5r  VDIR  130,1 923136   158720 
/sp/art/alt/binaries/sounds/mp3
nnrpd  3820 news   12u  unix 0xd422e3200t0 ->(none)

system config is as follows:
both boxes running freebsd 3.3-RELEASE
fileserver backend
tyan tomcat ii (i440BX) bios 1.18
p-iii 450 (options I686_CPU, NO_F00F_HACK)
256m sdram (will be 768m sdram/ecc)
ahc[0..5] 3x aha-3940uw (options AHC_ALLOW_MEMIO)
da0 ibm dnes 9GB uw
da[1..24] 24x ibm dnes 18GB uw
fxp0 intel etherexpress pro 100+/server (options NMBCLUSTERS=8192)
media 100BaseTX mediaopt full-duplex
filesystems on vinum w/ softupdates
/db stripe, 4disks, 68GB
/sp stripe, 20disks, 341GB
nfs_server_flags="-u -t -n 16"
newsreader frontend
asus p2b-s (i440BX) bios 1011
p-iii 450 (options I686_CPU, NO_F00F_HACK)
512mb sdram (will be 1gb sdram/ecc)
ahc0 adaptec u2w onboard
da0 ibm dnes 9GB u2w
fxp[0,1] intel etherexpress pro100+/server (options NMBCLUSTERS=8192)
media 100BaseTX mediaopt full-duplex
fxp0 -> internet
fxp1 -> private storage network 10.0.0.0/24
nfs_client_flags="-n 8"
fstab:
bucket:/sp  /sp nfs \
rw,bg,noatime,-r=1024,-w=1024,intr,-a=3,-d,-t=10 0 0
bucket:/db  /db nfs \
rw,bg,noatime,-r=1024,-w=1024,intr,-a=3,-d,-t=10 0 0

the main question: why do those guys hang there? the nnrpd i use is from
the inn-1.7.2-insync+actived distribution/patchkit

any ideas? as far as i understand it chokes because of nonexistent pcb's
that are set 0, but i'm not this deep into nfs anyway... any help
appreciated...

/k

-- 
> "There is a God, but He drinks" -- Blore
http://www.nacamar.de - http://www.nacamar.net - http://www.webmonster.de 
http://www.apache.de - http://www.quakeforum.de - finger [EMAIL PROTECTED]
KR433/KR11-RIPE - PGP-KFP = F9 A0 DF 91 74 07 6A 1C  5F 0B E0 6B 4D CD 8C 44


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

Re: loader security problem

[Alexey Zelkin]

hi,

On Sun, Nov 07, 1999 at 05:29:02PM +0900, Daniel C. Sobral wrote:

> > IMHO, it would be nice to have password protected loader(8) (like linux lilo)
> > or just ACLs for loader(8)'s "more" command (like unavailable for viewing
> > files)
> 
> cat >/boot/passwd.4th < Say... does LILO have a scripting language?

One my friend is linux-fan. And I know about lilo by his speach :)
I even did not try to look to lilo's sources and I can't answer such _complex_
question :) 

-- 
/* Alexey Zelkin   && [EMAIL PROTECTED]*/
/* Tavric National University  && [EMAIL PROTECTED]  */
/* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */


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

Re: machine/bus.h

[Warner Losh]

In message <[EMAIL PROTECTED]> Jeroen Ruigrok/Asmodai 
writes:
: machine/bus.h claims, in its comment section, that it supports 8 byte
: read/writes, but never in the whole file does it declare anything
: remotely akin to bus_space_read_8().
: 
: Any reason why not?

Because no busses that we support support atomic 8 byte accesses.  At
least that's my guess.

Warner


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

Using non-PIC code in shared libraries?

[Nate Williams]

What happens when this is done?  Can it ever work?

How about the reverse, where you link in PIC compiled libraries into
static (.a) libraries?  Does this work?

Assuming it works (in either case) are there any performance
hits/advantages to either?

My impression from past discussions is that you can't use non-PIC code
in shared libraries (it won't work), and that you can use PIC code in
static libraries, but you take a performance hit for it...

Am I right?



Nate


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

Re: FreeBSD at IETF (was: Re: IETF gettogether)

[Matt Crawford]

Has anyone got the Baystack IETF loaner cards working under FreeBSD yet?


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

Re: Procfs' pointers to files.

[Peter Jeremy]

On Sun, 7 Nov 1999 10:15:42 -0500 (EST), Brian Fundakowski Feldman <[EMAIL PROTECTED]> 
wrote:
>The _REALLY_ obvious solution to this is to find the real path on exec()
>and store the pointer in proc.  How is this full of "overhead" and
>"impractical"?

Finding _an_ absolute path on exec() is not too hard (though it's
not totally trivial).  At worst, it requires knowledge of the process
WD and then following a relative path (expanding symlinks along the way).
The problems I can see are:
- In theory, converting from a relative to absolute pathname can result
  in a pathname exceeding MAXPATHLEN bytes.
- A process may not have the permissions to translate it's CWD into an
  absolute pathname.  (Consider a couple of mode 111 directories).
- Either proc would need to grow by MAXPATHLEN, or a suitable external
  buffer would need to be malloc'd to hold the path.
- In the case of jail()d or chroot()d processes, the resultant path
  would be relative to the jail, not the `normal' filesystem.
- The pathname used for the original exec() is not guaranteed to be
  valid after the exec() - parts of it could be deleted or moved.

On Sat, 6 Nov 1999 15:54:50 -0500 (EST), Brian Fundakowski Feldman <[EMAIL PROTECTED]> 
wrote:
> does it seem as if the pathname of the executable being stored as
>a virtual symlink in procfs as "file" would solve these security
>problems?

I'm not convinced that this solves all the security problems, though
it does solve most of them.  My major concern would be that it would
leak information relating to the contents of execute-only directories
(which may or may not be important).

Maybe, rather than trying to solve the general case, we look at what
(valid) uses there are for /proc/xxx/file, and what permissions they
need.  As far as I can see, the only purposes are to allow a debugger
to access the executable and to allow the process to re-exec itself.
In particular, I can't see any reason for UIDs other than root or the
process itself having any access at all.  In the case of non-setuid
processes, this means that /proc/xxx/file should be owned by the
process UID and the mode should be 500 or 100, depending on whether
the UID had read permission to the original executable.

Unfortunately, when you take setuid programs into account, it gets
far less clear:  Reasonable cases could be made for having the owner
either the real or effective UID.

Peter


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

machine/bus.h

[Jeroen Ruigrok/Asmodai]

Hi,

machine/bus.h claims, in its comment section, that it supports 8 byte
read/writes, but never in the whole file does it declare anything
remotely akin to bus_space_read_8().

Any reason why not?

The outcome of this answer will determine whether I make a patch to
correct the comments or add the missing declararions.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Pleasure's a sin, and sometimes sin's a pleasure.


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

Re: ARM support

[Mike Smith]

> 
> Yes, loading from an ext2fs partition works fine. Well, I tried for the
> last 10 minutes to find a suitable way to tell in a manner that would not
> sounds religious that using ext2fs is not really an option to no avail.

Well, let's be practical.  Is there any alternative?  If the firmware 
insists on loading something from an ext2 filesystem, you don't have a 
lot of choice.  So write a tiny boot2 that lives in a tiny ext2 
filesystem, and knows how to find a FreeBSD filesystem and the loader. 
Then you can pretend that the ext2 filesystem isn't there. 8)

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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

handbook require major update

[Alexey Zelkin]

 hi,
 
 I just looked over 12th chapter of the handbook (PC Hardware compatibility)
 and found that we _must_ update and add/extend all sub-chapters there. This
 chapter is mostly based on information submited at 1995. It's very sad! :-(
 Please, take a look over this chapter and feel free to submit any new
 sub-chapters, sections, paragraphs or fixes to existent ones as simple
 text or SGML patches to -doc maillist.
 
 Thanks you very much!

-- 
/* Alexey Zelkin   && [EMAIL PROTECTED]*/
/* Tavric National University  && [EMAIL PROTECTED]  */
/* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */


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

RE: ARM support

[Stephane Potvin]

> -Original Message-
> From: Daniel C. Sobral [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 08, 1999 10:24 AM
> To: Stephane Potvin
> Cc: [EMAIL PROTECTED]
> Subject: Re: ARM support
> 
> 
> Stephane Potvin wrote:
> > 
> > > M... have you tried ext2fs?
> > 
> > Yes, loading from an ext2fs partition works fine. Well, I tried for the
> > last 10 minutes to find a suitable way to tell in a manner that 
> would not
> > sounds religious that using ext2fs is not really an option to no avail.
> > I guess that my english skills are not that good :-)
> > Thanks for the suggestion though.
> 
> Hehhehe. :-)
> 
> See, the *only* thing you need on ext2fs is /boot/*. You create a
> fake root with fully-populated /boot on an ext2fs, and the real root
> (including the kernel) on another partition. Since *loader* groks
> ufs, you should be ok.
> 
> Actually, /kernel, /kernel.old may also reside on ext2fs, as they
> not used after being loaded by loader.
> 
> Anyway, as the end result, your system will be running fully ufs
> once booted. Special care will be needed when installing/upgrading
> boot stuff, but...

Amen. This will be far less complicated that what I had in mind originally.
Thanks for the tip. I'll keep you posted on the developments.

Steph

--
Stephane E. Potvin
InnoMediaLogic Inc. - http://www.multichassis.com/



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

Re: ARM support

[Daniel C. Sobral]

Stephane Potvin wrote:
> 
> > M... have you tried ext2fs?
> 
> Yes, loading from an ext2fs partition works fine. Well, I tried for the
> last 10 minutes to find a suitable way to tell in a manner that would not
> sounds religious that using ext2fs is not really an option to no avail.
> I guess that my english skills are not that good :-)
> Thanks for the suggestion though.

Hehhehe. :-)

See, the *only* thing you need on ext2fs is /boot/*. You create a
fake root with fully-populated /boot on an ext2fs, and the real root
(including the kernel) on another partition. Since *loader* groks
ufs, you should be ok.

Actually, /kernel, /kernel.old may also reside on ext2fs, as they
not used after being loaded by loader.

Anyway, as the end result, your system will be running fully ufs
once booted. Special care will be needed when installing/upgrading
boot stuff, but...

--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]

What y'all wanna do?
Wanna be hackers? Code crackers? Slackers
Wastin' time with all the chatroom yakkers?


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

RE: ARM support

[Stephane Potvin]

> -Original Message-
> From: Daniel C. Sobral [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 08, 1999 3:29 AM
> To: Stephane E. Potvin
> Cc: Mike Smith; [EMAIL PROTECTED]
> Subject: Re: ARM support
> 
> 
> "Stephane E. Potvin" wrote:
> > 
> > Unfortunately no. It uses a stripped down linux kernel as firmware.
> 
> In that case the source code is available, yes?

I guess so, I didn't tried really hard to find out. Call me lazy but
I didn't want to take the chance blowing up the existing firmware and
have to program a new one using jtag :)

> M... have you tried ext2fs?

Yes, loading from an ext2fs partition works fine. Well, I tried for the
last 10 minutes to find a suitable way to tell in a manner that would not
sounds religious that using ext2fs is not really an option to no avail.
I guess that my english skills are not that good :-)
Thanks for the suggestion though.

Steph

--
Stephane E. Potvin
InnoMediaLogic Inc. - http://www.multichassis.com/


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

Re: PCMCIA Chipset

[Geoff Buckingham]

On Thu, Nov 04, 1999 at 08:18:17PM -1000, Richard Puga wrote:
> I am having trouble with a PCMCIA chipset
> 
> I have a ISA to PCMCIA adaptor, it is made by ActionTec model no. PC-250
> www.actiontec.com
> 
> the chip on it has the following information on it;
> 
> 
> D japan
> DB6082
> 1992 DATABOOK
> 1992 FMI
> FUJITSU 1992
> 9412 E57
> 
> the avalible I/O addresses are
> 
> 200h 240h 280h 2c0h 300h 340h and 380h
> 
> is this controler supported by FreeBSD,  PAO maybe?
> 
> if so how do you impliment it in the kernel config.
> 
> Thank you
> 
I have no idea if this will work but try the PAO for 3.3_RELEASE install 
disks from http://www.jp.freebsd.org/PAO you should be able to see what is
detected without installing anything.

Failing that their FAQ has the following to say, ther is no explictit 
reference to ISA cards nore a Fujitsu chipset;

   The PC Card driver of PAO supports following PC Card controllers:

Intel i82365SL (and compatibles)
Cirrus Logic PD-6710
Cirrus Logic PD-6720
Cirrus Logic PD-6722
Cirrus Logic PD-6729 (PCI-PCMCIA bridge)
Cirrus Logic PD-6730 (PCI-PCMCIA bridge)
IBM PCIC (on some ThinkPads)
IBM KING
O2micro OZ6729 (PCI-PCMCIA bridge)
O2micro OZ6730 (PCI-PCMCIA bridge)
Ricoh RF5C296 (i82365 compatible)
Ricoh RF5C396
Vadem 468
Vadem 469
VLSI 82C146

PAO does not support following PC Card controllers.  (If you
have laptops with these controller, please write drivers for
these controllers for PAO :-).

Databook TCIC (on some ancient laptops)

Some PCI-CardBus bridges can be used in i82365-compatible
mode.  Currently it is being tested on following chipsets:

Cirrus Logic PD-6832
Texas Instruments PCI-1130
Texas Instruments PCI-1131
Texas Instruments PCI-1220
Texas Instruments PCI-1221
Texas Instruments PCI-1250
Toshiba ToPIC95
Toshiba ToPIC97
Ricoh RL5C465
Ricoh RL5C475
Ricoh RL5C476
Ricoh RL5C478

If your PC Card controller is not supported, please contact me
([EMAIL PROTECTED]) or BSD-nomads team ([EMAIL PROTECTED]).
I need following information to hack the chip:

o The name of the PC Card controller of your
  machine. (e.g. Cirrus Logic 6832).

o PCI device ID of PC Card controller (If your PC Card
  controller is PCI - PC Card bridge or PCI - CardBus
  bridge).




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

Re: ARM support

[Daniel C. Sobral]

"Stephane E. Potvin" wrote:
> 
> Unfortunately no. It uses a stripped down linux kernel as firmware.

In that case the source code is available, yes?

M... have you tried ext2fs?

--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]

What y'all wanna do?
Wanna be hackers? Code crackers? Slackers
Wastin' time with all the chatroom yakkers?




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

Re: Limitations in FreeBSD

[Mike Smith]

> * Matthew Dillon
> | FreeBSD boxes can handle up to 4 Gigabytes of main memory.
> 
> Is this true for the Alpha kernels too?

There are issues with > 1GB of RAM on Alphas at the moment, which may 
be easier to resolve soon.  We have a 4100 with 1GB, which should be 
upgraded to 1.5 shortly and which will be available for various people 
to beat on at that point.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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

Re: writing much slower than reading...

[John-Mark Gurney]

Matthew Dillon scribbled this message on Nov 7:
> When you write to a raw disk with your dd, it is reading a block from 
> /dev/zero into its local buffer which involves a zeroing operation
> that the read code never had to do, then dd writes the buffer to disk.

thank you! this is exactly what I was looking for... :)

I wrote a simple test program that uses a static buffer of 1meg to read
and write from... I ran the test to transfer 512megs and their system
time is almost equal...  I knew it was something really stupid like
that...

now to find out why the bt848 card can't sustain more than 15fps when
I'm writing to the disk...  and only can do 7-8fps in 640x480... probably
something to do w/ the pci bus getting overloaded or the chipset...

-- 
  John-Mark Gurney  Voice: +1 408 975 9651
  Cu Networking   

  "The soul contains in itself the event that shall presently befall it.
  The event is only the actualizing of its thought." -- Ralph Waldo Emerson


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