trimming of chroot jail path in df(1)
[Please Cc: me] I've found module jailfsstat: http://garage.freebsd.pl/jailfsstat.tgz which task is that process in jail can see only file systems mounted inside of jail. It works somehow incorrect and I would like to ask you for an URL of FreeBSD's vfs implementation documentation. -- NEVE-RIPE, will build world for food Ukrainian FreeBSD User Group http://uafug.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What RFCs are supported by FreeBSD
Well, right now I was trying to understand if RFC2003 (IP-ENCAP) is supported. IP-Encapsulation is supported by using gif interface. -- julien.bournelle at int-evry.fr ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Retrieving disk geometry
Hi, Under FreeBSD 4.x the ioctl DIOCGDINFO could be used to retrieve the number of cylinders, heads and sectors of a drive. This could be called on /dev/ad0 for example. Under FreeBSD 5 it seems to produce Inappropriate ioctl for device unless you call it on an individual partition (/dev/ad0s1a for example). Is there a way around this? Thanks, Andrew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[no subject]
[EMAIL PROTECTED] --- This message contains no viruses. Guaranteed by Kaspersky Anti-Virus. www.antivirus.lv ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: trimming of chroot jail path in df(1)
On Mon, Jun 02, 2003 at 04:02:48PM +0300, Alexandr Kovalenko wrote: + I've found module jailfsstat: + + http://garage.freebsd.pl/jailfsstat.tgz + + which task is that process in jail can see only file systems mounted + inside of jail. + + It works somehow incorrect and I would like to ask you for an URL of + FreeBSD's vfs implementation documentation. Somebody has raported that there is off-by-one error somewhere, but it wasn't critical AFAIK. Have you found some other incorrect behaviour? If yes, I could always fix it in my free time. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Forged subscriptions and the troll.
Pawel, On Mon, 02 Jun 2003, Pawel Jakub Dawidek wrote: Maybe is time to disallow posting for non-members on selected lists? I second that, there are (probably) lots of people willing to moderate the lists and weed out the junk from valid posts. Yes, that would mean a possible few hours delay (maybe a day) for non-subscribers but I would think that is acceptable. With time those not subscribed but with a large number of valid posts could be whitelisted and thus don't get stuck in the moderator queue. /Oli -- Olafur Osvaldsson Systems Administrator Internet a Islandi hf. Tel: +354 525-5291 Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forged subscriptions and the troll.
Pawel Jakub Dawidek writes: On Sun, Jun 01, 2003 at 04:46:10PM +0100, Mark Murray wrote: + We are currently being attacked by an individual who is attempting + to mass-subscribe our lists to other mailing lists. +=20 + PLEASE DO NOT RESPOND TO ANY OF THIS MAIL! I am taking care of it. +=20 + Thank you for your co-operation. :-) Maybe is time to disallow posting for non-members on selected lists? As I said, I'm taking care of things. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forged subscriptions and the troll.
Mark == Mark Murray [EMAIL PROTECTED] writes: Mark As I said, I'm taking care of things. Thanks, Mark. Hope it won't give you to much work. Eric Masson -- Depuis ce matin, j'ai une IP en 213.@@@.@@@ et des plumes. C'est devenu apparement une IP statique. Mon contrat me donne droit à une IP dynamique.. -+- TW in http://www.le-gnu.net : Neuneu se fixe -+- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: trimming of chroot jail path in df(1)
Hello, Pawel Jakub Dawidek! On Mon, Jun 02, 2003 at 05:16:54PM +0200, you wrote: On Mon, Jun 02, 2003 at 04:02:48PM +0300, Alexandr Kovalenko wrote: + I've found module jailfsstat: + + http://garage.freebsd.pl/jailfsstat.tgz + + which task is that process in jail can see only file systems mounted + inside of jail. + + It works somehow incorrect and I would like to ask you for an URL of + FreeBSD's vfs implementation documentation. Somebody has raported that there is off-by-one error somewhere, but it wasn't critical AFAIK. Have you found some other incorrect behaviour? If yes, I could always fix it in my free time. Incorrect behaviour is: in host system: bash-2.05b# df Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a128990 35988 8268430%/ /dev/da0s1f 20643028344 1890814 0%/tmp /dev/da0s1g 10322414 1703924 779269818%/usr /dev/da0s1h 97825400 3834024 86165344 4%/usr/local /dev/da0s1e 2064302 12758 1886400 1%/var /dev/da1s1e 233513688 1889152 212943448 1%/jails procfs 4 4 0 100%/proc /dev/vn1a 503966 14987031378032%/jails/mounts/217.20.163.128 procfs 4 4 0 100%/jails/mounts/217.20.163.128/proc /dev/vn2a 503966 20364026001044%/jails/mounts/217.20.163.129 procfs 4 4 0 100%/jails/mounts/217.20.163.129/proc with your, unpatched version: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vn1a 503966 149870 31378032%/ procfs 4 4 0 100%/proc /dev/vn2a 503966 203640 26001044% procfs 4 4 0 100%/proc with patch I've just sent to you: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vn1a 503966 149870 31378032%/ procfs 4 4 0 100%/proc -- NEVE-RIPE, will build world for food Ukrainian FreeBSD User Group http://uafug.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Retrieving disk geometry
Andrew wrote: Hi, Under FreeBSD 4.x the ioctl DIOCGDINFO could be used to retrieve the number of cylinders, heads and sectors of a drive. This could be called on /dev/ad0 for example. Under FreeBSD 5 it seems to produce Inappropriate ioctl for device unless you call it on an individual partition (/dev/ad0s1a for example). Is there a way around this? No. Becouse there is in fact no such thing like a geometry on modern ATA drives. There is just a quigmare of values which serve only one single purpose - satisfying rotten code in stinking BIOS. Not more not less. (Modern is here on the scale of about 8 or even more years.) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What RFCs are supported by FreeBSD
Nickolay A. Kritsky wrote: Does anybody know, which RFCs are followed by FreeBSD's core network drivers (like IP,TCP,routing,UDP,ICMP drivers)? All of them. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Retrieving disk geometry
Andrew wrote: Under FreeBSD 4.x the ioctl DIOCGDINFO could be used to retrieve the number of cylinders, heads and sectors of a drive. This could be called on /dev/ad0 for example. Under FreeBSD 5 it seems to produce Inappropriate ioctl for device unless you call it on an individual partition (/dev/ad0s1a for example). Is there a way around this? All the geometries returned by this call are fictitous these days, so there's really no value to it. What you really want is the SCSI mode page 2, or the Maxtor or Quantum vendor-private command, for IDE. Anything else means that you're going to be pessimising, rather than optimizing, when you make decisions on the basis of disk geometry reported by this call. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Are write() calls guaranteed atomic?
In the last episode (Jun 02), Matthew Hagerty said:
I'm writing a server that receives data via a named pipe (FIFO) and
will always have more than one other process sending data to it, and
I'm concerned with preventing data multiplexing. The data coming in
will be lines of text delimited with a newline, but the processes
writing the data have no knowledge of the FIFO, they simply think
they are writing to a file. This being the case, the processes
writing the data give no regard to PIPE_BUF and may send data in
longer lengths (but probably never longer than 2K to 4K.)
Will the kernel ensure that the data write() will be delivered to the
FIFO atomically even if the data is larger than PIPE_BUF, such that
two or more successive read() calls will retrieve the data in order?
Pipes are always FIFO; it's part of their definition. From SUSv3:
A read on the file descriptor fildes[0] shall access data written to
the file descriptor fildes[1] on a first-in-first-out basis.
To ensure that your writes don't get interleaved with writes from other
processes, you do need to limit your write sizes to PIPE_BUF or less
bytes:
Write requests of {PIPE_BUF} bytes or less shall not be interleaved
with data from other processes doing writes on the same pipe. Writes
of greater than {PIPE_BUF} bytes may have data interleaved, on
arbitrary boundaries, with writes by other processes, whether or not
the O_NONBLOCK flag of the file status flags is set.
If you cannot modify the clients, try changing your server to create a
Unix domain socket instead of a named pipe (the clients shouldn't see
any difference).
--
Dan Nelson
[EMAIL PROTECTED]
Dan,
Thanks for the info, very helpful! What reference did you get that from?
I searched high and low to find a definitive answer (like the one above)
before posting.
As for the clients, no, I don't have control over them. They are web
server child processes, Apache usually. I considered using a socket, but
I must have missed something since I didn't realize you could have a local
socket that looks and smells like a file to external processes? Based on
your post, can I assume that I can create a socket that can be accessed
using open() and write() by external processes?
On my way to RTFM... man socket (again...)
Thanks,
Matthew
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Are write() calls guaranteed atomic?
In local.freebsd-hackers, you wrote: Thanks for the info, very helpful! What reference did you get that from? I searched high and low to find a definitive answer (like the one above) before posting. You can find an online version of the Single Unix Specification v3 at http://www.unix-systems.org/version3/online.html (although it's kind of hard to guess that you need that document from the write(2) man page). -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Are write() calls guaranteed atomic?
On Mon, Jun 02, 2003 at 12:57:05PM -0400, Matthew Hagerty wrote:
In the last episode (Jun 02), Matthew Hagerty said:
I'm writing a server that receives data via a named pipe (FIFO) and
will always have more than one other process sending data to it, and
I'm concerned with preventing data multiplexing. The data coming in
will be lines of text delimited with a newline, but the processes
writing the data have no knowledge of the FIFO, they simply think
they are writing to a file. This being the case, the processes
writing the data give no regard to PIPE_BUF and may send data in
longer lengths (but probably never longer than 2K to 4K.)
Will the kernel ensure that the data write() will be delivered to the
FIFO atomically even if the data is larger than PIPE_BUF, such that
two or more successive read() calls will retrieve the data in order?
Pipes are always FIFO; it's part of their definition. From SUSv3:
A read on the file descriptor fildes[0] shall access data written to
the file descriptor fildes[1] on a first-in-first-out basis.
To ensure that your writes don't get interleaved with writes from other
processes, you do need to limit your write sizes to PIPE_BUF or less
bytes:
Write requests of {PIPE_BUF} bytes or less shall not be interleaved
with data from other processes doing writes on the same pipe. Writes
of greater than {PIPE_BUF} bytes may have data interleaved, on
arbitrary boundaries, with writes by other processes, whether or not
the O_NONBLOCK flag of the file status flags is set.
If you cannot modify the clients, try changing your server to create a
Unix domain socket instead of a named pipe (the clients shouldn't see
any difference).
--
Dan Nelson
[EMAIL PROTECTED]
Dan,
Thanks for the info, very helpful! What reference did you get that from?
I searched high and low to find a definitive answer (like the one above)
before posting.
http://www.unix-systems.org/version3/online.html
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: Your application
This is an autoresponder. I'll never see your message. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Locking, locking...
On 02-Jun-2003 Pawel Jakub Dawidek wrote:
Hello hackers...
I need advice how to handle with one locking problem.
For example I got some list with some values. This list could be
modified by any process. I want to get values from this list and
copy them to allocated table. But how to count number of needed
fields?
mtx_lock(mtx_list_lock);
n = 0;
SLIST_FOREACH(elem, list_head, l_next) {
n++;
}
mtx_unlock(mtx_list_lock);
tab = malloc(n * sizeof(something), M_TEMP, M_WAITOK);
mtx_lock(mtx_list_lock);
[...]
As we all knew size of list could be changed when we were in malloc().
Of course we could check list size again after malloc() and mtx_lock(),
but what to do when it was changed? Recall memory allocation?
If size of this list depends on every process there is a chance to DoS
such piece of code. Return an error? Not always it is possible.
IMHO there should be malloc() version that could be called under lock.
Malloc() M_NOWAIT could be called in such scenario?
How do you handle with situations like this?
In the process case, the all process list is protected by an sx lock
(which you can hold across malloc(M_WAITOK)). Another solution in
some cases is that if the list grows, just copy out the first n items.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: sendfile in FreeBSD 2.2
Hi, I am following up my own post. I have been able to do most of the porting, but I
have one question. What do I replace the OFF_TO_IDX() macro with? I could start with
code that always passes the offset as 0 (sending the complete file). Any help would be
appreciated.
br
vijay
-Original Message-
From: ext Yaoping Ruan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 21, 2003 12:42 PM
To: Singh Vijay (NET/MtView)
Cc: [EMAIL PROTECTED]
Subject: Re: sendfile in FreeBSD 2.2
Hi,
VOP_GETVOBJECT() macro is created by kern/vnode_if.pl and vnode_if.src. By running
them you should be able to get vnode_if.c and vnode_if.h file. In vnode_if.h, you will
get the macro defined as follow: (From FreeBsd 4.6)
static __inline int VOP_GETVOBJECT __P((
struct vnode *vp,
struct vm_object **objpp));
static __inline int VOP_GETVOBJECT(vp, objpp)
struct vnode *vp;
struct vm_object **objpp;
{
struct vop_getvobject_args a;
int rc;
a.a_desc = VDESC(vop_getvobject);
a.a_vp = vp;
a.a_objpp = objpp;
rc = VCALL(vp, VOFFSET(vop_getvobject), a);
return (rc);
}
Hope this helps.
- Yaoping
Message: 19
Date: Wed, 21 May 2003 09:32:26 -0700
From: [EMAIL PROTECTED]
Subject: sendfile in FreeBSD 2.2
To: [EMAIL PROTECTED]
Message-ID:
Hello. Would it be possible to port the sendfile system call to a FreeBSD 2.2 based
system? Has anyone done this? I am trying to port the code from a later FreeBSD
release and I have been unable to find out what the VOP_GETVOBJECT() macro does and
how/what should it be replaced with for my case. Any help is appreciated.
Thanks
vijay
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Sound Panic - VIA VT8233
Hi,
I'm getting a consistant reproducable panic with my onboard VIA VT8233 sound.
Attached backtrace and dmesg and sysctl.conf
FreeBSD bigguy.am-productions.biz 4.8-RELEASE FreeBSD 4.8-RELEASE #3: Mon Jun
2 15:47:53 EDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BIGGUY i386
Thanks in advance,
--
Anish Mistry#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc0165197 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc01655d5 in panic (fmt=0xc02d83cc %s)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0xc028e43b in trap_fatal (frame=0xdbbd7e0c, eva=0)
at /usr/src/sys/i386/i386/trap.c:974
#4 0xc028de1e in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = 7644, tf_esi = -1042644992, tf_ebp = -608338324,
tf_isp = -608338376, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 7644,
tf_trapno = 18, tf_err = 0, tf_eip = -1071212057, tf_cs = 8,
tf_eflags = 66118, tf_esp = -1041577408, tf_ss = -1042677632})
at /usr/src/sys/i386/i386/trap.c:636
#5 0xc02699e7 in feed_rate (f=0xc1eaca40, c=0xc1d5c500, b=0xc1da7000 ,
count=7644, source=0xc1d9fb00)
at /usr/src/sys/dev/sound/pcm/feeder_rate.c:426
#6 0xc026ba03 in feed_vchan_s16 (f=0xc1c11200, c=0xc1c2a80
#7 0xc026999a in feed_rate (f=0xc1d5df00, c=0xc1c2a800, b=0xc1c36000 ,
count=2048, source=0xc1c1d800) at feeder_if.h:61
#8 0xc02654a0 in sndbuf_feed (from=0xc1c1d800, to=0xc1c1d900,
channel=0xc1c2a800, feeder=0xc1d5df00, count=2048) at feeder_if.h:61
#9 0xc0265943 in chn_wrfeed (c=0xc1c2a800)
at /usr/src/sys/dev/sound/pcm/channel.c:219
#10 0xc026598b in chn_wrintr (c=0xc1c2a800)
---Type return to continue, or q return to quit---
at /usr/src/sys/dev/sound/pcm/channel.c:235
#11 0xc0265d29 in chn_intr (c=0xc1c2a800)
at /usr/src/sys/dev/sound/pcm/channel.c:444
#12 0xc025fa7c in via_intr (p=0xc1c2a980)
at /usr/src/sys/dev/sound/pci/via8233.c:436
#13 0xc0296655 in intr_mux (arg=0xc11801c0)
at /usr/src/sys/i386/isa/intr_machdep.c:582
#14 0x2808ac93 in ?? ()
#15 0x280885f2 in ?? ()
#16 0x280897ca in ?? ()
#17 0x2807fedf in ?? ()
#18 0x28072139 in ?? ()
#19 0x28073f98 in ?? ()
#20 0x804dbc6 in ?? ()
#21 0x804d698 in ?? ()
#22 0x804d367 in ?? ()
#23 0x8049dd2 in ?? ()
# Allow users to mount devices
vfs.usermount=1
# Enable ATI TV Tuner to capture all channels :) FINALLY!
hw.bt848.tuner=4
# enable 4x mode for the graphics card
hw.nvidia.registry.EnableVia4x=1
hw.nvidia.registry.EnableAGPFW=1
kern.fallback_elf_brand=3
# Enable async access to sound card
hw.snd.pcm0.vchans=6
#hw.snd.pcm1.buffersize=4096
#hw.snd.pcm1.vchans=4
hw.snd.maxautovchans=6
#hw.snd.pcm0.buffersize=10240
# Increase shared memory for smoother video playback
#kern.ipc.shmmax=134217728
#kern.ipc.shmall=32768
# enable dma add to /boot/loader.conf
#hw.ata.ata_dma=1
#hw.ata.atapi_dma=1
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.8-RELEASE #3: Mon Jun 2 15:47:53 EDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BIGGUY
Timecounter i8254 frequency 1193182 Hz
CPU: AMD Athlon(tm) processor (1333.39-MHz 686-class CPU)
Origin = AuthenticAMD Id = 0x644 Stepping = 4
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
AMD Features=0xc044RSVD,AMIE,DSP,3DNow!
real memory = 402587648 (393152K bytes)
avail memory = 386265088 (377212K bytes)
Preloaded elf kernel kernel at 0xc050b000.
Preloaded elf module linux.ko at 0xc050b09c.
Preloaded elf module nvidia.ko at 0xc050b13c.
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 7 entries at 0xc00fdf00
apm0: APM BIOS on motherboard
apm0: found APM BIOS v1.2, connected at v1.2
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pcib1: PCI to PCI bridge (vendor=1106 device=b099) at device 1.0 on pci0
pci1: PCI bus on pcib1
nvidia0: GeForce2 MX/MX 400 mem 0xe000-0xe7ff,0xec00-0xecff irq 11
at device 0.0 on pci1
bktr0: BrookTree 878 mem 0xef101000-0xef101fff irq 11 at device 8.0 on pci0
iicbb0: I2C bit-banging driver on bti2c0
iicbus0: Philips I2C bus on iicbb0 master-only
iicsmb0: I2C to SMB bridge on iicbus0
smbus0: System Management Bus on iicsmb0
smb0: SMBus general purpose I/O on smbus0
iic0: I2C general purpose I/O on iicbus0
iicbus1: Philips I2C bus on iicbb0 master-only
iicsmb1: I2C to SMB bridge on iicbus1
smbus1: System Management Bus on iicsmb1
smb1: SMBus general purpose I/O on smbus1
iic1: I2C general purpose I/O on iicbus1
smbus2: System Management Bus on bti2c0
smb2: SMBus general purpose I/O on smbus2
bktr0: Warning - card vendor 0x1002 (model 0x0003) unknown.
bktr0: Pinnacle/Miro TV, Temic NTSC tuner.
pci0: unknown card
pcic cbb Problems on Acer TM 360
I use Acer Travelmate 360. But my wireless card doesn't work at all on 5.0 RELEASE or 4.8RELEASE With 5.0 RELEASE, NEW CARD kernel: cbb0 can't grab register. so my wireless card has no power when startup. OLD CARD kernel: I always get watchdog timeout when I command pccardd, and system halt. With 4.8 RELEASE, I don't know why When I start my notebook, pcic0 and pcic1 show the message 5.0v failed, change to 3.3v and tell me to report to [EMAIL PROTECTED] for this error?? I try my best to figure out what is the problem, but I give up Hope someone can help me, Because I need this notebook to do a job in a few days with FreeBSD system. I will really appreciate for any addivice If need other information about this problem, just mail to me. thanks. A-Lun ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network stack cloning / virtualization patches
On Mon, Jun 02, 2003 at 11:58:25PM +0200, Marko Zec wrote: There are two major possible causes for overhead increase. First, each IP protocol related tunable variable and most of the global symbols involved in network processing have been virtualized. [...] And second, many kernel functions have been extended with an additional argument, typically a pointer to a struct vimage, A third issue on the x86 is a lack of registers: There are only 6 general purpose registers (and each of them actually has a specific purpose). Eating one of these registers to maintain a pointer to a struct vimage will be a noticable performance hit. However, a couple of percents in overhead increase that can be observed only in worst case loopback tests do not present a problem in any real-life scenario. Agreed. It would be useful to get some real-world figures. Julian, am I safe in assuming that you have an interest in this work? If not, I may setup a p4 branch to work with and to merge these bits into -CURRENT if no one else is interested. -sc I would be really honored to see the cloning code merged in -CURRENT one day. However, at the moment I'm strongly opposed to such a proposal, since the code is simply not mature enough. My understanding is that the p4 tree is specifically intended for this sort of thing. It provides a controlled environment where the code could be nursed from its current immature form into something that can be safely merged into the main CVS tree. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: Problems with usb HID device on freebsd
I sent this message also to FreeBSD USB maintainer and to NetBSD original author without luck, can you point me to the right direction? TIA, Riccardo. PS: please Cc: me, I follow only current@ - Forwarded message from myself [EMAIL PROTECTED] - I'm trying to interface my new APC (RS 500) with FreeBSD 4.8-STABLE but I found some (a lot of?) problems: # usbdevs -v -d Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), VIA(0x), rev 1.00 uhub0 port 1 powered port 2 addr 2: low speed, self powered, config 1, \ Back-UPS RS 500 FW:30.j2.I USB FW:j2(0x0002), \ American Power Conversion(0x051d), rev 0.06 Looking into source I found that prototyping: -8-[ /usr/src/lib/libusbhid/libusbhid.h ]-8- [...] int hid_report_size(report_desc_t d, unsigned int id, enum hid_kind k); [...] is different from man page (2nd/3rd parameter swapped): -8-[ man hid_report_size ]-8- [...] int hid_report_size(report_desc_t d, unsigned int id, hid_kind_t k); [...] I think man page is wrong, but this is not a problem. After playing with usbhidctl I found that my APC use 0xff84, 0xff85 and 0xff86 instead of 0x84, 0x85 and 0x86 as it would so I created a custom file with the contents of /usr/share/misc/usb_hid_usage and with a copy of pages 132/133 to 0xff84/0xff85 and now it decode pages/usages. Now I'm at a dead end, usbhidctl say: device does not support immediate mode, only changes reported. but interrogating device with -a and/or -l show me only zeros. If you need my config/boot.log feel free to download them from: ftp://ftp.torrini.org/pub/FreeBSD/APC-hacking/ What else can I do (apart from changing UPS)? I hope you can point me to the right direction (docs or ML)... TIA PS: can you change .../usb_hid_usage and use hex notation, instead of decimal one, also for pages because usbhidctl report them as hex? -- Riccardo. ( http://www.GUFI.org/~vic/ ) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
