kern/30440, please commit enclosed patch
hi, could someone please commit the patch enclosed in kern/30440 to -current? thanks, christian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
problem with dynamic sysctls in -current
hmm,
i've posted the attached mail a week ago to this list, but got no
response. could someone please comment on this issue?
thanks,
christian
-- Forwarded message --
Date: Sat, 1 Sep 2001 03:26:46 +0200 (CEST)
From: Christian Carstensen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: dynamic sysctl problem and proposed hot fix
hi,
i just came across a problem with dynamic sysctls:
when unloading a driver module that used dyn sysctls, my system paniced
with oid too high. that problem is caused by sysctl_ctx_free() in
kern/kern_sysctl.c, that first deregisters all oids in the list to see if
a error occurs. then, all oids are being reregistered and, if there was no
error, they're finally removed.
during the second phase, sysctl_register_oid(e1-entry) is called with
n := e1-entry-oid_number being the old oid number with n CTL_AUTO_START.
that leads to panic(static sysctl too high) in sysctl_register_oid.
one approach might be to initialize the oid_number field to contain the
value OID_AUTO before calling sysctl_regiser_oid, but i'm unsure about the
side effects of doing that in sysctl_ctx_free().
alternatively, the old oid number could be reused, the following patch
should do, but it's just a workaround.
best,
christian
--
Sorry, no defects found. Please try a different search
[http://www.cisco.com/support/bugtools/bugtool.shtml]
Index: kern_sysctl.c
===
RCS file: /usr/cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.113
diff -r1.113 kern_sysctl.c
83a84,96
static struct sysctl_oid *
sysctl_find_oidnumber(const int number, struct sysctl_oid_list *list)
{
struct sysctl_oid *oidp;
SLIST_FOREACH(oidp, list, oid_link) {
if (oidp-oid_number == number) {
return (oidp);
}
}
return (NULL);
}
125c138,139
panic(static sysctl oid too high: %d, oidp-oid_number);
---
if (sysctl_find_oidnumber(oidp-oid_number, parent))
panic(static sysctl oid too high: %d, oidp-oid_number);
177c191
if (error)
---
if (error)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
and another one...
hi,
in net/bpf.c, bpfdetach(), stuct bpf_if *bp is used in a for loop, that,
if not terminated by break before, leaves bp == NULL.
evaluating (bp-bif_ifp == NULL) two lines later will cause a NULL pointer
dereference, resulting in trap 12.
please apply the attached patch.
best,
christian
--
Sorry, no defects found. Please try a different search
[http://www.cisco.com/support/bugtools/bugtool.shtml]
Index: bpf.c
===
RCS file: /usr/cvs/src/sys/net/bpf.c,v
retrieving revision 1.80
diff -r1.80 bpf.c
1267c1267
if (bp-bif_ifp == NULL) {
---
if (bp == NULL || bp-bif_ifp == NULL) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ufs ext attr problem...
On Fri, 31 Aug 2001, Robert Watson wrote: Could you try the attached patch, which does what you suggest? i've applied exactly the same patch yesterday and that works fine for me. best, christian -- Sorry, no defects found. Please try a different search [http://www.cisco.com/support/bugtools/bugtool.shtml] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ufs ext attr problem...
hi, it seems like there's a problem in ffs_unmount, ffs_vfsops.c:841: if ufs_extattr_stop() returns EOPNOTSUPP, calling ufs_extattr_uepm_destroy two lines later will cause a panic(ufs_extattr_uepm_destroy: not initialized) in ufs_extattr.c:175, at least on my machine. maybe, ufs_extattr_uepm_destroy() should be enclosed in a else statement in ffs_vfsops.c? best, christian -- Sorry, no defects found. Please try a different search [http://www.cisco.com/support/bugtools/bugtool.shtml] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
dynamic sysctl problem and hot fix
hi,
i just came across a problem with dynamic sysctls:
when unloading a driver module that used dyn sysctls, my system paniced
with oid too high. that problem is caused by sysctl_ctx_free() in
kern/kern_sysctl.c, that first deregisters all oids in the list to see if
a error occurs. then, all oids are being reregistered and, if there was no
error, they're finally removed.
during the second phase, sysctl_register_oid(e1-entry) is called with
n := e1-entry-oid_number being the old oid number with n
CTL_AUTO_START.
that leads to panic(static sysctl too high) in sysctl_register_oid.
one approach might be to initialize the oid_number field to contain the
value OID_AUTO before calling sysctl_regiser_oid, but i'm unsure about the
side effects of doing that in sysctl_ctx_free().
alternatively, the old oid number could be reused, the following patch
should do, but it's just a workaround.
best,
christian
--
Sorry, no defects found. Please try a different search
[http://www.cisco.com/support/bugtools/bugtool.shtml]
Index: kern_sysctl.c
===
RCS file: /usr/cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.113
diff -r1.113 kern_sysctl.c
83a84,96
static struct sysctl_oid *
sysctl_find_oidnumber(const int number, struct sysctl_oid_list *list)
{
struct sysctl_oid *oidp;
SLIST_FOREACH(oidp, list, oid_link) {
if (oidp-oid_number == number) {
return (oidp);
}
}
return (NULL);
}
125c138,139
panic(static sysctl oid too high: %d, oidp-oid_number);
---
if (sysctl_find_oidnumber(oidp-oid_number, parent))
panic(static sysctl oid too high: %d, oidp-oid_number);
177c191
if (error)
---
if (error)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
background fsck panics?
hi, after some weeks without softupdates, i recently reenabled them on my notebook. it seems, that my problems still exist. background checking one of my partitions leads to a panic() complaining about some block too large error. sorry, i didn't capture the message, and for obvious reasons i don't like reproducing that condition. it might be useful to know, that fsck checks all other partitions without problems. moreover, that one partition that causes the problem, contains a .fsck_snapshot entry: slot 5 ino 0 reclen 444: regular, `.fsck_snapshot' any ideas? best, christian -- Sorry, no defects found. Please try a different search [http://www.cisco.com/support/bugtools/bugtool.shtml] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: -current on ibm tp a20p?
On Sun, 26 Nov 2000, Cameron Grant wrote: the sound card is a Crystal Semiconductor CS 4624 controller with CS 4297A AC97 codec, pcic0 is a TI PCI-1450 PCI-CardBus Bridge. sound output results in "pcm0: play interrupt timeout, channel dead". try turning off apm and all power saving in the bios setup. I've tried that, when I first encountered that problem. This doesn't change anything. - Sigh... regards, Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current on ibm tp a20p?
On Sat, 25 Nov 2000, Peter Wemm wrote: This means your pccard memory window overlaps something. Do you have an ATI rage chipset by any chance? My Vaio has one of these and its rom is 80K long and goes from 0xc - 0xd3fff. pccardd defaults to 0xd for mapping the CIS which is right underneath the ROM. Try: pccard_mem="0xd4000" in /etc/rc.conf. Or even 0xd8000 if that doesn't work. Peter, Thanks for your comment. For some reason my notebook needs pccard_mem="0xdc000", but with this option set pcmcia support works well. regards, Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current on ibm tp a20p?
hi, has someone of you got -current working on a ibm thinkpad a20p? at the moment, i can't use pccard and sound card support. to be honest, this problem is not -current specific, - it also occurs with 4.x os. the sound card is a Crystal Semiconductor CS 4624 controller with CS 4297A AC97 codec, pcic0 is a TI PCI-1450 PCI-CardBus Bridge. sound output results in "pcm0: play interrupt timeout, channel dead". when inserting a pccard, the card is not being recognized, pccardd tends to call it something like "Null, Null". Any hints or ideas? regards, christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current on ibm tp a20p?
On Fri, 24 Nov 2000, Rogier R. Mulhuijzen wrote: 1) is this a CardBus card maybe? It happens with a) Lucent WaveLAN (silver) b) 3com 3c589d 2) What does 'pccardc dumpcis' return? Code 85 not found Code 85 not found code Unknown ignored Code 134 not found Code 134 not found code Unknown ignored Code 13 not found Code 13 not found code Unknown ignored Code 195 not found Code 195 not found code Unknown ignored Code 100 not found Code 100 not found code Unknown ignored Code 115 not found Code 115 not found code Unknown ignored Code 93 not found Code 93 not found code Unknown ignored Code 96 not found Code 96 not found code Unknown ignored Code 192 not found Code 192 not found code Unknown ignored Configuration data for card in slot 0 Tuple #1, code = 0x0 (Null tuple), length = 12 000: 40 cb a3 00 00 00 00 00 00 20 40 60 Tuple #2, code = 0x0 (Null tuple), length = 139 000: 55 44 16 00 01 f3 00 30 70 50 49 2e c0 8b 2e c0 010: 50 49 86 29 00 18 00 00 0c 01 00 00 2e c0 8b 8b 020: 24 6e 01 00 00 00 00 b4 c6 02 00 00 00 41 00 00 030: 0d 43 70 72 67 74 28 29 31 39 2c 39 38 31 39 20 040: 49 74 6c 43 72 6f 61 69 6e 0a 49 74 6c 43 72 6f 050: 61 69 6e 49 74 6c 55 44 2c 50 45 32 30 28 75 6c 060: 20 37 29 18 18 ff 00 80 54 41 00 f2 00 b4 cd 0a 070: 74 32 c3 01 16 02 c0 c0 02 e4 c0 55 ec 60 46 b4 080: bb 00 01 cd 66 90 c2 00 20 e2 c3 Tuple #3, code = 0x0 (Null tuple), length = 220 000: 6a e8 ff 55 ec 53 c5 04 07 00 09 e4 e8 ff eb 1f 010: 58 c2 00 8b 50 46 24 04 3c 76 04 50 a2 58 c2 00 020: 8b 50 46 c0 04 e8 ff c0 50 d1 58 c2 00 8b 50 46 030: 86 50 d9 86 50 d3 58 c2 00 8b 66 66 46 66 c0 50 040: d7 66 c0 50 cf 66 5d 04 55 ec 50 8b 04 c1 10 e8 050: ff 3a 36 66 c0 50 ab 66 5d 04 55 ec 53 1e 46 8e 060: 06 8b 08 4e 67 03 43 f9 59 5b e4 c2 00 66 06 30 070: 2b 8b 4e 02 75 16 66 f6 f5 6c 66 c0 c0 c1 04 03 080: 89 02 c1 10 46 88 07 46 2f c6 05 8d 10 56 66 ca 090: 88 04 76 66 ca c7 00 ff 46 93 6c 89 02 c1 10 5e 0a0: 88 07 c1 10 46 ff c6 05 b4 f8 15 5d c4 55 07 5e 0b0: 32 80 00 01 c3 80 28 f0 00 1e 4d 1e 46 f0 07 59 0c0: 38 59 00 60 08 2e 1e 00 e1 cd 72 80 00 1a e1 80 0d0: 80 0b 2e 1e 00 e1 cd 72 80 00 00 61 Tuple #4, code = 0x0 (Null tuple), length = 96 000: 8b e6 bf 00 0a cd 66 f9 74 f6 01 1c 2a 18 b8 b1 010: 1a 83 01 30 b8 b1 1a 06 02 10 83 01 30 b8 b1 1a 020: 06 02 61 c3 60 3e 02 77 80 bd 00 18 33 0e 02 33 030: 2e 1e 00 30 b8 b1 1a 1d 0e 02 8b e6 bf 00 0a cd 040: 66 e1 bf 00 0d cd 66 90 52 4c f5 88 02 00 03 49 050: 74 6c 42 6f 20 67 6e 20 65 73 6f 20 2e 20 42 69 Tuple #5, code = 0x0 (Null tuple), length = 48 000: 36 00 00 00 00 00 00 01 e8 ff 83 bd 00 04 c0 04 010: 01 cb 60 06 40 26 13 0e 83 20 e0 66 33 66 00 00 020: 2e 0e 03 03 8a 66 c1 03 00 d1 66 e9 66 83 40 00 Tuple #6, code = 0x0 (Null tuple), length = 14 000: 26 e8 fd 3c 0d 50 45 45 30 20 6f 6c 20 6f Tuple #7, code = 0x20 (Manufacturer ID), length = 105 000: 64 65 6f 67 20 72 65 62 73 20 65 6f 79 00 c0 ff 010: 80 00 8d 81 00 75 e2 8c c1 06 8c 8b 6a 07 8b 13 020: 83 20 e1 8e 2e 26 03 50 53 2e 3e 02 75 66 8b a5 030: 66 0f 1e 02 2e b7 ab 66 d9 17 2e 16 02 2e b7 b5 040: 66 0f 0e 02 03 66 d3 83 10 c1 04 c1 04 33 5b 66 050: e3 66 e3 33 2e 0e 03 03 8e 83 02 e9 1b 73 eb e8 060: fe 50 e0 0e 0f 50 ff 92 cb PCMCIA ID = 0x6564, OEM ID = 0x676f Tuple #8, code = 0x0 (Null tuple), length = 229 000: 5b 8e 8b fb 8b 8a 2e 0e 03 c1 03 e9 d1 c1 0a 03 010: 90 81 00 8e 33 33 fc aa 1d 0a 45 69 69 67 74 65 020: 52 4c 4c 61 65 0d 0a e8 fd 68 05 d4 b4 b9 00 c0 030: cd 07 66 90 e8 fd e8 fe f8 75 c3 a9 0e c6 e8 fb 040: 68 00 a6 53 66 57 1e 0f 0f 66 83 b1 00 0b f7 a3 050: 40 0f c6 ba c0 da 3e 00 aa 69 c2 00 fa f0 ec 68 060: 05 68 66 83 b1 00 85 00 12 0d 50 45 45 31 20 61 070: 65 63 64 20 4f 20 44 73 72 63 75 65 77 73 6e 74 080: 66 75 64 00 c3 07 e3 f8 eb 08 eb 03 72 eb 8a 02 090: 80 00 8e e3 53 6a 1e 00 a8 3c 74 e9 ff 3e 00 ff 0a0: 74 3b 73 66 3d 42 24 b8 b6 04 f8 72 50 00 1e 00 0b0: 78 3c 74 eb 8c 8e 66 83 b1 00 17 f7 a3 40 0f 92 0c0: 66 81 24 43 0f 86 0e 20 2e 36 00 ff ee 2e 36 00 0d0: ff e8 2e 36 00 00 c4 50 68 06 26 75 cb c4 5a c4 0e0: 83 00 1f 68 06 Tuple #9, code = 0x0 (Null tuple), length = 82 000: af eb 0d 42 5f 6f 64 72 29 3d 20 bb 00 db 48 8a 010: 6c 38 74 8a e2 0f 0f 07 5e 66 59 c3 0a 4e 49 49 020: 4c 29 66 0f 16 00 2e b7 2e 66 d0 2e b7 30 66 d0 030: 2e b7 b9 66 d0 2e b7 bb 66 d0 81 ff 00 66 ea b8 040: 00 c0 8b 13 2b 26 36 00 66 53 50 a1 00 e0 8e 66 050: e2 66 Tuple #10, code = 0x0 (Null tuple), length = 219 000: 89 66 74 83 04 f4 db c3 10 db db e8 58 66 1f d0 010: c1 10 c4 c1 10 8b 2c fa 40 8e 36 26 00 e4 8e 8b 020: fb c1 10 50 53 57 55 00 00 6a 66 00 56 ec 40 8e 030: 26 16 00 e2 83 18 fc a1 00 89 02 a1 00 89 04 a1 040: 00 89 06 a1 00 89 08
why is my current so .... stable?
hi, Sorry, but after my last make world (Tue Jan 11 15:07:18 CET 2000) I didn't have to reboot (ok, once, after the install ;). I'm using softupdates, vinum, smp and scsi, but the instability seems gone. I've caused heavy load on the machine for reasonable long periods, but nothing crashed. -- Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: why is my current so .... stable?
On Wed, 12 Jan 2000, Donn Miller wrote: My guess is that once -current gets closer to the release date, it becomes more and more stable. I guess the period of greatest instability occurs somewhere about 1/4 to 1/2 through the -current life cycle. We could do a chart plotting stability vs. time for the life cycle of a given -current. That could help people decide whether or not they want to run -current. This would be great, but I wonder from what source we could take reliable data about -current's stability. But what I've meant was: I've had these ugly system freezes not perfactly reproducable, but very often. From what I've read on current list, the problems still exist, but not on my system. At least this system runs stable for 1 day now. I'm wondering, why. -- Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
reported system freezes...
so, ok, i've tried several checkout dates for sys and tested the compiled kernels. as i cannot reproduce this freeze thing, this is quite vague, but kernels up to 04 Jan 2000 worked fine, those from 05 Jan 2000 up to now don't. maybe, this is useful information. -- Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: reported system freezes...
On Tue, 11 Jan 2000, Alfred Perlstein wrote: are you running vinum or softupdates? Kirk just fixed softupdates and I committed a patch to vinum just last night. yes, i am running vinum and softupdates. i've checked out the recent sources some minutes ago, and making a new world. this will take an hour. i'll tell you, if that's working. -- Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
On Mon, 10 Jan 2000, Joao Pedras wrote: What I have in common with Christian is that it hangs during high usage, as I mentioned in my first post (e.g. compiling something, buildworld). this is funny: the system operates well, even when on heavy load (especially disk load), until i want a little more 8). to become more precisely, a cvs checkout or make world is no problem, if - and that's really interesting - nothing else requests the system's attention. i've had some successfully reproducable crashes when generating much i/o usage (cvs, buildworld), which in fact caused no problem, and then simply starting pine. at the moment, pine opened the mail folder, all my noisy hard disks stopped and it was perfectly quiet apart from cpu fans. -- Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel panics when initializing aic7895 controller at startup.
hi, with the latest changes to src/sys/pci/pci_ahc.c (partity error handling), i'm unable to boot a current kernel, because of panic during system boot. i've attached dmesg from a working kernel version (2000/01/06) to this mail. marked with (***) you'll find the line, where (with the new kernel) the error message "ahc0: brkadrintr, Data-path Parity Error at seqaddr = 0x14e" occurs. any ideas, that could help? -- Christian ... ahc0: Adaptec aic7895 Ultra SCSI adapter irq 16 at device 18.0 on pci0 ahc0: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: Adaptec aic7895 Ultra SCSI adapter irq 16 at device 18.1 on pci0 ahc1: aic7895 Wide Channel B, SCSI Id=7, 16/255 SCBs ... Waiting 5 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! da1 at ahc0 bus 0 target 2 lun 0 da1: QUANTUM FIREBALL1080S 1Q09 Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 8) da1: 1042MB (2134305 512 byte sectors: 64H 32S/T 1042C) Mounting root from ufs:/dev/da0a da0 at ahc0 bus 0 target 0 lun 0 da0: IBM OEM 0662S12 1011 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 1003MB (2055035 512 byte sectors: 64H 32S/T 1003C) cd0 at ahc0 bus 0 target 4 lun 0 cd0: YAMAHA CRW4416S 1.0f Removable CD-ROM SCSI-2 device cd0: 8.333MB/s transfers (8.333MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed da2 at ahc1 bus 0 target 0 lun 0 da2: IBM DCAS-34330W S65A Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da2: 4134MB (8467200 512 byte sectors: 64H 32S/T 4134C) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
ok, last mail before going to bed, it just... freezes! maybe, that's not interesting at all, but every time the error occured on my system, there was much disk usage (buildworld, cron scripts, ... netscape ;)). -- Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
On Mon, 10 Jan 2000, Dave J. Boers wrote: Can any of you tell me wether you have SCSI in your system (the ahc driver, perhaps)? I too had one of these strange lockups today (see earlier post) and it seems SCSI related. The lockup occured during an I/O operation. Now I cvsupped and I find the ahc driver panic-ing on boot time with a parity error as well. welcome to the club. world's getting more amazing with every checkout ;) -- Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
ok, this runs stable for 3 hours now... try a current kernel (checked out 4 hours ago), using a version of the file /usr/src/sys/pci/ahc_pci.c from 2000/01/06. ok, maybe it's not by any means stable, but works better than everything else within the last 24 hours. -- Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
this runs stable for 3 hours now... try a current kernel (checked out 4 hours ago), using a version of the file /usr/src/sys/pci/ahc_pci.c from 2000/01/06. ok, maybe it's not by any means stable, but works better than everything else within the last 24 hours. grrr, after 10 mins fsck... i was wrong. Problem is that the lockups (I think) are ahc-related and my SCSI hard drive did refuse to come online on one or two occasions while booting the system cold... I therefore concluded that it might be a problem with the hardware. Now (with the new kernel) I find the scsi system unstable and I have doubts again. i'm using a ahc 7895 onboard on a tyan thunder 100. i've seen my cdrom occasionally not coming up until power cycling. is this a known bug with that controller? One piece of information might also be useful in this context. After the system lockup I sort of benchmarked the scsi performance by doing "dd if=/dev/zero of=./testfile bs=100 count=128" (actually I varied the blocksize) and got a _very poor_ performance of only 4 Mb/sec (which is usually around 10 to 12 Mb/sec). I isolated my drive to be the only scsi device and I even clocked the SCSI bus down from 20 Mhz to 8 Mhz, but to no avail. scsi performance is very bad on my system for a long time now. operating on many small files, for example, my IBM DCAS-34330W is 100% busy with only 1.2 MB/s. i don't know why, but i suspect vinum in combination with some old scsi devices to cause that. -- Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i4b broken by cdevsw changes...
hi there, it seems as isdn drivers have been broken with current cdevsw registration changes. The current kernel does not link with i4b anymore. -- christian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
vinum broken??
Hi, Does anyone else experience problems with the current kernel release and vinum? I've compiled a new kernel along with a make world today. After rebooting vinum did not start: /dev/vinum/Control: invalid operation... Any suggestions? regards, Christian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
