Re: Call for Testers: FreeBSD webcam driver (and more)

Hi Luigi,
The pwc.ko can detect my webcam (Orite MB-631), but pwcview cannot work.
I am using FreeBSD 6-stable.
The conosle log is here
-----
spca50x_set_packet_size: Set packet size: size (0), alt becomes 0
spca5xx_setMode Looking for 352 x 288 palette 0x8
spca5xx_setMode have 0 x 0 palette 0x0 method 0
spca5xx_setMode have 0 x 0 palette 0x0 method 0
spca5xx_setMode have 0 x 0 palette 0x0 method 0
spca5xx_setMode have 352 x 288 palette 0x2f method 0
Found code 0 method 0 Soft Win width height 352 x 288 Hard Win width
height 352 x 288
spca50x_set_packet_size: Set packet size: size (2580), alt becomes 5
spca camera, call spca5xx_setMode alt now 5
em2820_init: to be done
chipid 0x11
format 0x34
cwidth 0xa0
cheight 0x78
spca5xx_setMode Looking for 352 x 288 palette 0x8
spca5xx_setMode have 0 x 0 palette 0x0 method 0
spca5xx_setMode have 0 x 0 palette 0x0 method 0
spca5xx_setMode have 0 x 0 palette 0x0 method 0
spca5xx_setMode have 352 x 288 palette 0x2f method 0
Found code 0 method 0 Soft Win width height 352 x 288 Hard Win width
height 352 x 288
spcaCameraStart: unknown bridge 24 (non fatal but should)
endpoint 2 frame size 2580
pwc0: Invalid packetsize (2580) for endpoint 130

[patch] mount fails to call external programs

Hello.

The 'mount' program attempts to maintain external mount programs in order to determine whether it needs to
call external programs or handle it internally.

Not all external programs can be listed in mount.c.  Indeed, my mount_md failed after mount trying to handle
it itself.

The solution is to maintain interally handlable fs types.

I am not fully sure if I listed all of them correctly; however, it fixes the problem.

Thanks,
Hiro

Index: mount.c
===================================================================
RCS file: /home/ncvs/src/sbin/mount/mount.c,v
retrieving revision 1.92
diff -u -r1.92 mount.c
--- mount.c	14 Nov 2006 01:07:42 -0000	1.92
+++ mount.c	1 Feb 2007 05:25:55 -0000
 <at>  <at>  -133,18 +133,19  <at>  <at> 
 	 */
 	unsigned int i;
 	const char *fs[] = {
-	"cd9660", "mfs", "msdosfs", "nfs", "nfs4", "ntfs",
-	"nwfs", "nullfs", "portalfs", "smbfs", "udf", "umapfs",
-	"unionfs",

Re: [patch] mount fails to call external programs

Yoshihiro Ota wrote:
> Hello.
> 
> The 'mount' program attempts to maintain external mount programs in order to determine whether it needs
to call external programs or handle it internally.
> 
> Not all external programs can be listed in mount.c.  Indeed, my mount_md failed after mount trying to
handle it itself.
> 
> The solution is to maintain interally handlable fs types.
> 
> I am not fully sure if I listed all of them correctly; however, it fixes the problem.
> 
> Thanks,
> Hiro
> 
> 
> ------------------------------------------------------------------------
> 
> Index: mount.c
> ===================================================================
> RCS file: /home/ncvs/src/sbin/mount/mount.c,v
> retrieving revision 1.92
> diff -u -r1.92 mount.c
> --- mount.c	14 Nov 2006 01:07:42 -0000	1.92
> +++ mount.c	1 Feb 2007 05:25:55 -0000
>  <at>  <at>  -133,18 +133,19  <at>  <at> 
>  	 */
>  	unsigned int i;
>  	const char *fs[] = {

Re: [CFT] ncurses wide character support

On 1/31/07, Rong-en Fan <grafan <at> gmail.com> wrote:
> Finally, I have ncurses wide character support. Patch is at
>
> http://people.freebsd.org/~rafan/ncurses/ncursesw-5.6-fbsd7-20070128.diff
>
> Before you can apply it, you need to
>
> mkdir -p \
>         /usr/src/lib/ncurses/formw \
>         /usr/src/lib/ncurses/menuw \
>         /usr/src/lib/ncurses/ncursesw \
>         /usr/src/lib/ncurses/panelw
>
> Please note this patch accidentally removes libmytinfo (it is going to be
> removed soon). I have tested on my i386 current with mutt. It works just
> fine.

Now libmytinfo is removed, use the new patch instead:

http://people.freebsd.org/~rafan//ncurses/ncursesw-5.6-fbsd7-20070201.diff

Regards,
Rong-En Fan

> I use a hack in src/Makefile.inc1 to make amd64 world + lib32 work. Details
> can be found in
>
> http://lists.freebsd.org/pipermail/freebsd-hackers/2007-January/019408.html
>
> Please test and feedbacks are welcome. :)

Re: Call for Testers: FreeBSD webcam driver (and more)

Luigi Rizzo wrote:
> Basically I would like to know how it builds/works on -current,
> have reports on cameras that work with it and those which don't
> and so on. The driver supports the Video4Linux API so it should
> be useful for a variety of applications.

It builds, kldload/kldunload works, but camera don't recognized.
My hardware:
Notebook Maxselect GT3000 (seems like a Clevo M550J)
http://www.clevo.com.tw/products/M550J.asp

usbdevs -v
port 8 addr 2: high speed, power 500 mA, config 1, USB2.0 
Camera(0x5602), vendor 0x0402(0x0402), rev 1.00

I've found two related to this webcam projects:
http://sourceforge.net/search/?type_of_search=soft&words=m560x
But not yet tried this driver.

--

-- 
WBR, Andrey V. Elsukov
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

<sys/lock.h> breaks C++ in kernel Click

Hi,

A C++ reserved keyword crept in, which is breaking the Click kernel 
module build.
This patch gets rid of the argument names from the prototypes, which 
also fixes style bugs.
Could I have an ok from someone for this?

Cheers,
BMS

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

First steps towards importing gvirstor into -current

Hi!

As announced, the plan was to start working on importing gvirstor into
CVS after 6.2 was successfully released. For those who don't know,
gvirstor is a GEOM class providing storage virtualisation facility, i.e.
its purpose is to offer the ability to create a virtual storage device
of arbitrarily large size (typically several terabytes) which consists
of an arbitrary number of physical storage devices (actually any
lower-level GEOM providers, including RAID devices) of arbitrary size
(typically 50 GB - 400 GB hard drives).

The latest sources are available in p4 and conveniently on FreeBSD's
wiki site: http://wiki.freebsd.org/gvirstor .

There are some known minor issues that will be fixed in the following
days (mostly related to overly verbose error messages), so (at the
suggestion of my mentor - pjd) I'm inviting interested users to try it
out and report any problems found (if there are such). Also, benchmarks
of gvirstor in close-to-real-life usage are welcome.

The idea is to stabilize the current code, and new features will be
developed later.

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Re: Interesting speed benchmarks

On Wed, 2007-Jan-31 07:54:24 +0200, Ian FREISLICH wrote:
>As a random datapoint that might or might not be related.  In the
>last year or so I was pontificating about how much better SCSI was
>that IDE/ATA to my boss.  I then did some benchmarks on my (CURRENT)
>system and discovered that an old 10Gig 7.5krpm UDMA33 disk
>significantly out perform some Seagate Cheatah LVD 10krpm disks.

I have access to a Sun V20z at work:
mpt0: <LSILogic 1030 Ultra4 Adapter> port 0x2000-0x20ff mem
0xfe850000-0xfe85ffff,0xfe840000-0xfe84ffff irq 27 at device 4.0 on pci2
mpt0: [GIANT-LOCKED]
mpt0: MPI Version=1.2.15.0
mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE )
mpt0: 0 Active Volumes (1 Max)
mpt0: 0 Hidden Drive Members (6 Max)
da0 at mpt0 bus 0 target 0 lun 0
da0: <FUJITSU MAW3073NC 0103> Fixed Direct Access SCSI-3 device 
da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled
da0: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C)
da1 at mpt0 bus 0 target 1 lun 0
da1: <FUJITSU MAW3073NC 0103> Fixed Direct Access SCSI-3 device 
da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled
da1: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C)

Whilst the drives are geom mirrored, running in "prefer" mode forces
all reads to come off the first drive (iostat/systat verify this) and
I get:
# df -ki /home
Filesystem         1K-blocks      Used    Avail Capacity iused     ifree %iused  Mounted on
/dev/mirror/gm0s1f  38999124  13440472 22438724    37%  273895   4766231    5%   /home

lock contention etc.

here's an intersting set of numbers..

notice the increase in 'system time' for the same work done when  there
is more parallelism.

make buildworld
     3762.94 real      2627.66 user      1275.78 sys
     3763.32 real      2632.04 user      1271.80 sys
     3763.34 real      2627.99 user      1276.39 sys
     3763.03 real      2632.50 user      1270.91 sys

make -j 2 buildworld
     2465.10 real      2958.94 user      1918.64 sys
     2463.97 real      2968.43 user      1910.65 sys
     2472.13 real      2978.64 user      1912.80 sys
     2582.83 real      2965.51 user      2047.19 sys

make -j 4 buildworld
     2262.88 real      4322.31 user      3333.58 sys
     2255.88 real      4330.32 user      3319.48 sys
     2256.09 real      4318.84 user      3336.57 sys
     2257.63 real      4338.34 user      3313.07 sys

(2 processors with HTT)  (looks like 4 processors)
-current, sched_4bsd

I'm guessing that the extra system time represents a lot of
contention somewhere.

What is the best way to get actual numbers on this?

Re: lock contention etc.

Julian Elischer writes:
 > I'm guessing that the extra system time represents a lot of
 > contention somewhere.
 > 
 > What is the best way to get actual numbers on this?

The Dtrace lockstat tool is designed for this, and I've used it to
track down contention like this on Solaris.  It seems to be on the
TODO list for the FreeBSD Dtrace port at
http://people.freebsd.org/~jb/dtrace/todo.html.  I wonder how soon it
will arrive..  It is one of the things that I'm most looking forward
to.

Drew

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"