Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

[Borja Marcos]

> On 14 Feb 2020, at 19:18, Ed Maste  wrote:
> 
> Upstream OpenSSH-portable removed libwrap support in version 6.7,
> released in October 2014. We've maintained a patch in our tree to
> restore it, but it causes friction on each OpenSSH update and may
> introduce security vulnerabilities not present upstream. It's (past)
> time to remove it.

There’s no way to fight it? I know it’s an old program (first time I used it 
was back in 1992 or so!)
but it’s really convenient and easy to use. 





Borja.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i

[Borja Marcos]

> On 01 Aug 2016, at 19:30, Michelle Sullivan <miche...@sorbs.net> wrote:
> 
> There are reasons for using either…

Indeed, but my decision was to run ZFS. And getting a HBA in some 
configurations can be difficult because vendors insist on using 
RAID adapters. After all, that’s what most of their customers demand.

Fortunately, at least some Avago/LSI cards can work as HBAs pretty well. An 
example is the now venerable LSI2008.

> Nowadays its seems the conversations have degenerated into those like Windows 
> vs Linux vs Mac where everyone thinks their answer is the right one (just as 
> you suggested you (Borja Marcos) did with the Dell salesman), where in 
> reality each has its own advantages and disadvantages.

I know, but this is not the case. But it’s quite frustrating to try to order a 
server with a HBA rather than a RAID and receiving an answer such as
“the HBA option is not available”. That’s why people are zapping, flashing and, 
generally, torturing HBA cards rather cruelly ;)

So, in my case, it’s not about what’s better or worse. It’s just a simpler 
issue. Customer (myself) has made a decision, which can be right or wrong. 
Manufacturer fails to deliver what I need. If it was only one manufacturer, 
well, off with them, but the issue is widespread in industry. 

> Eg: I'm running 2 zfs servers on 'LSI 9260-16i's... big mistake! (the ZFS, 
> not LSI's)... one is a 'movie server' the other a 'postgresql database' 
> server...  The latter most would agree is a bad use of zfs, the die-hards 
> won't but then they don't understand database servers and how they work on 
> disk.  The former has mixed views, some argue that zfs is the only way to 
> ensure the movies will always work, personally I think of all the years 
> before zfs when my data on disk worked without failure until the disks 
> themselves failed... and RAID stopped that happening...  what suddenly 
> changed, are disks and ram suddenly not reliable at transferring data? .. 
> anyhow back to the issue there is another part with this particular hardware 
> that people just throw away…

Well, silent corruption can happen. I’ve seen it once caused by a flaky HBA and 
ZFS saved the cake. Yes. there were reliable replicas. Still, rebuilding would 
be a pain in the ass. 

> The LSI 9260-* controllers have been designed to provide on hardware RAID.  
> The caching whether using the Cachecade SSD or just oneboard ECC memory is 
> *ONLY* used when running some sort of RAID set and LVs... this is why LSI 
> recommend 'MegaCli -CfgEachDskRaid0' because it does enable caching..  A good 
> read on how to setup something similar is here: 
> https://calomel.org/megacli_lsi_commands.html (disclaimer, I haven't parsed 
> it all so the author could be clueless, but it seems to give generally good 
> advice.)  Going the way of 'JBOD' is a bad thing to do, just don't, 
> performance sucks. As for the recommended command above, can't comment 
> because currently I don't use it nor will I need to in the near future... but…

Actually it’s not a good idea to use heavy disk caching when running ZFS. Its 
reliability depends on being able to commit metadata to disk. So I don’t care 
about that caching option. Provided you have enough RAM, ZFS is very effective 
caching data itself.

> If you (O Hartmann) want to use or need to use ZFS with any OS including 
> FreeBSD don't go with the LSI 92xx series controllers, its just the wrong 
> thing to do..  Pick an HBA that is designed to give you direct access to the 
> drives not one you have to kludge and cajole.. Including LSI controllers with 
> caches that use the mfi driver, just not those that are not designed to work 
> in a non RAID mode (with or without the passthru command/mode above.)

As I said, the problem is, sometimes it’s not so easy to find the right HBA. 

> So moral of the story/choices.  Don't go with ZFS because people tell you its 
> best, because it isn't, go with ZFS if it suits your hardware and 
> application, and if ZFS suits your application, get hardware for it.

Indeed, I second this. But really, "hardware for it" covers a rather broad 
cathegory ;) ZFS can even manage to work on hardware _against_ it.






Borja.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i

[Borja Marcos]

> On 01 Aug 2016, at 15:12, O. Hartmann  wrote:
> 
> First, thanks for responding so quickly.
> 
>> - The third option is to make the driver expose the SAS devices like a HBA
>> would do, so that they are visible to the CAM layer, and disks are handled by
>> the stock “da” driver, which is the ideal solution. 
> 
> I didn't find any switch which offers me the opportunity to put the PRAID
> CP400i into a simple HBA mode.

The switch is in the FreeBSD mfi driver, the loader tunable I mentioned, 
regardless of what the card
firmware does or pretends to do.

It’s not visible doing a "sysctl -a”, but it exists and it’s unique even. It’s 
defined here:

https://svnweb.freebsd.org/base/stable/10/sys/dev/mfi/mfi_cam.c?revision=267084=markup
(line 93)

>> In order to do it you need a couple of things. You need to set the variable
>> hw.mfi.allow_cam_disk_passthrough=1 and to load the mfip.ko module.
>> 
>> When booting installation media, enter command mode and use these commands:
>> 
>> -
>> set hw.mfi.allow_cam_disk_passthrough=1
>> load mfip
>> boot
>> ———
> 
> Well, I'm truly aware of this problemacy and solution (now), but I run into a
> henn-egg-problem, literally. As long as I can boot off of the installation
> medium, I have a kernel which deals with the setting. But the boot medium is
> supposed to be a SSD sitting with the PRAID CP400i controller itself! So, I
> never be able to boot off the system without crippling the ability to have a
> fullspeed ZFS configuration which I suppose to have with HBA mode, but not
> with any of the forced RAID modes offered by the controller. 

Been there plenty of times, even argued quite strongly about the advantages of 
ZFS against hardware based RAID
5 cards. :) I remember when the Dell salesmen couldn’t possibly understand why 
I wanted a “software based RAID rather than a
robust, hardware based solution” :D 

At worst, you can set up a simple boot from a thumb drive or, even better, a 
SATADOM installed inside the server. I guess it will
have SATA ports on the mainboard. That’s what I use to do. FreeNAS uses a 
similar approach as well. And some modern servers
also can boot from a SD card which you can use just to load the kernel.

Depending on the number of disks you have, you can also sacrifice two to set up 
a mirror with a “nomal” boot system, and using
the rest of the disks for ZFS. Actually I’ve got an old server I set up in 
2012. It has 16 disks, and I created a logical volume (mirror)
with 2 disks for boot, the other 14 disks for ZFS.

If I installed this server now I would do it different, booting off a thumb 
drive. But I was younger and naiver :)






Borja.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mfi driver performance too bad on LSI MegaRAID SAS 9260-8i

[Borja Marcos]

> On 01 Aug 2016, at 08:45, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
> 
> On Wed, 22 Jun 2016 08:58:08 +0200
> Borja Marcos <bor...@sarenet.es> wrote:
> 
>> There is an option you can use (I do it all the time!) to make the card
>> behave as a plain HBA so that the disks are handled by the “da” driver. 
>> 
>> Add this to /boot/loader.conf
>> 
>> hw.mfi.allow_cam_disk_passthrough=1
>> mfip_load=“YES"
>> 
>> And do the tests accessing the disks as “da”. To avoid confusions, it’s
>> better to make sure the disks are not part of a “jbod” or logical volume
>> configuration.
>> 
>> 
>> 
>> 
>> Borja.
> [...]
> 
> How is this supposed to work when ALL disks (including boot device) are 
> settled
> with the mfi (in our case, it is a Fujitsu CP400i, based upon LSI3008 and
> detected within FreeBSD 11-BETA and 12-CURRENT) controller itself?
> 
> I did not find any solution to force the CP400i into a mode making itself
> acting as a HBA (we intend to use all drives with ZFS and let FreeBSD
> kernel/ZFS control everything).

Have you tried that particular option? 

With kinda recent LSI based cards you have three options:

- The most usual and definitely NOT RECOMMENDED option is to define a logical 
volume per disk
which actually LSI Logic called before JBOD mode. It’s not recommended at all 
if you want to run ZFS.

- Recent cards, I think I saw this first on the LSI3008, have a JBOD mode that 
exposes the drives as “mfisyspd” devices.
I don’t recommend it either, because the syspd drives are a sort of limited 
version of a disk device. With SSDs, especially, you
don’t have access to the TRIM command.

- The third option is to make the driver expose the SAS devices like a HBA 
would do, so that they are visible to the
CAM layer, and disks are handled by the stock “da” driver, which is the ideal 
solution. 

However, this third option might not be available in some custom firmware 
versions for certain manufacturers? I don´t
know. And I would hesitate to make the conversion on a production machine 
unless you have a complete and reliable
full backup of all the data in case you need to rebuild it.

In order to do it you need a couple of things. You need to set the variable 
hw.mfi.allow_cam_disk_passthrough=1
and to load the mfip.ko module.

When booting installation media, enter command mode and use these commands:

-
set hw.mfi.allow_cam_disk_passthrough=1
load mfip
boot
———


Remember that after installation you need to update /boot/loader.conf in the 
system you just installed with the
following contents:

 hw.mfi.allow_cam_disk_passthrough=1
 mfip_load=“YES”


A note regarding CAM and MFI visibility: On some old firmware versions for the 
LSI2008 I’ve even seen the disks
available both as “mfi” and “da” drivers. If possible, you should try to set 
them up as “unconfigured good” on the RAID
firmware. Use the RAID firmware set up or maybe mfiutil(8)

Also, make sure you don’t create any logical volumes on the disks you want 
exposed to CAM. You should delete
the logical volumes so that the MFI firmware doesn’t do anything with them. 

AND BEWARE: Doing these changes to a system in production with valuable data is 
dangerous. Make sure you have a full
and sound backup before making these changes.

As a worst case, the card could expose the devices both as “syspd” and CAM 
(i.e., “da” drives) but as long as you don’t
touch the syspd devices the card won’t do anything to them as far as I know. It 
could be a serious problem, however, if you 
access a drive part of a logical volume through CAM, as RAID cards tend do to 
“patrol reads” and other stuff on them. 

Provided it’s safe to do what I recommended, try it and follow up by email. 





Borja.




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Fix Emulex oce driver in CURRENT

[Borja Marcos]

On Dec 5, 2014, at 2:00 PM, Steven Hartland wrote:

 
 On 04/09/2014 09:49, Borja Marcos wrote:
 On Jun 30, 2014, at 8:02 PM, John Baldwin wrote:
 
 I think these sound fine, but I've cc'd Xin Li (delphij@) who has worked 
 with
 folks at Emulex to maintain this driver.  He is probably the best person to
 review this.
 Hi,
 
 Seems 10.1 is on the pipeline now, but as far as I know none of these fixes 
 have been applied to -STABLE. Any chances to do it yet? As far as I know, 
 the oce driver is currently unusable in -STABLE. I managed to cause a 
 panic reliably within 30 seconds.
 
 Was there any conclusion to this, current and releng/10.0  releng/10.1 seem 
 pretty similar with regards oce but a customer is reporting panics very 
 similar to this thread.
 
 Did the commit of the additional locking never make it in?

Not as far as I know. I´ve updated a couple of machines here to 10-STABLE and 
I've been applying the patch manually myself. 

I don't think it's been applied even to -HEAD. 

For now I've told my coworkers to avoid Emulex cards whenever possible. As far 
as  I know the driver is unusable in its present state.






Borja.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fix Emulex oce driver in CURRENT

[Borja Marcos]

On Jun 30, 2014, at 8:02 PM, John Baldwin wrote:

 
 I think these sound fine, but I've cc'd Xin Li (delphij@) who has worked with
 folks at Emulex to maintain this driver.  He is probably the best person to
 review this.

Hi,

Seems 10.1 is on the pipeline now, but as far as I know none of these fixes 
have been applied to -STABLE. Any chances to do it yet? As far as I know, the 
oce driver is currently unusable in -STABLE. I managed to cause a panic 
reliably within 30 seconds.






Borja.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fix Emulex oce driver in CURRENT

[Borja Marcos]

On Jul 15, 2014, at 10:22 AM, Stefano Garzarella wrote:

 Hi,
 I found other problems in the oce driver during some experiments with
 netmap in emulation mode.

What about driver  version 10.0.747.0? At least in my configuration it works 
perfectly, no crashes despite keeping it running for several days at full 
bandwidth.

I have a server about to go into production. Should this patch work on 
10-STABLE?






Borja.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fix Emulex oce driver in CURRENT

[Borja Marcos]

On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote:

 I used the oce driver in CURRENT. 
 I think that this patch in combination with the previous one should work in 
 10-STABLE.
 
 I have only tested if it works with CURRENT, but now I try if it works with 
 10-STABLE and I'll send you some feedback.

I can still try. Will get back to you soon.


Cheers,




Borja.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fix Emulex oce driver in CURRENT

[Borja Marcos]

On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote:

 I used the oce driver in CURRENT.
 I think that this patch in combination with the previous one should work in
 10-STABLE.
 
 I have only tested if it works with CURRENT, but now I try if it works with
 10-STABLE and I'll send you some feedback.

Hmmm. The patch seems to be broken. I have tried to apply it renaming the 
a/usr/src... to oce_if.c.old and oce_if.c, etc, and patch complains:

Patching file oce_if.c using Plan A...
patch:  malformed patch at line 6: int wq_index);


Was it broken by the email client formatting? Or am I being especially clumsy 
today? ;)




Borja.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fix Emulex oce driver in CURRENT

[Borja Marcos]

On Jul 15, 2014, at 11:45 AM, Stefano Garzarella wrote:

 I just tried to run iperf3 with this patch and STABLE-10 and it seems to work.
 Do you have a panic?

Still compiling :) Anyway, you didn't suffer panics before, right?




Borja.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fix Emulex oce driver in CURRENT

[Borja Marcos]

On Jul 15, 2014, at 11:45 AM, Stefano Garzarella wrote:

 I just tried to run iperf3 with this patch and STABLE-10 and it seems to
 work.
 Do you have a panic?

So far, so good. I've ran a couple of iperf3 tests (60 seconds, trying both 
directions) and it doesn't crash.

Without the fixes I obtained a panic quite reliably, in less than 30 seconds.

Still trying. But the bugs you mentioned (lack of locking and deallocating, 
etc) seem to be consistent with the kind of failures I saw and their apparent 
randomness.

So, asking for spiritual counsel now. Would you use this driver  in a 
production environment instead of the 747 version downloaded from Emulex? I 
think the latter is giving slightly better performance but, anyway, I disable 
LRO and TSO because I see a horrible impact on NFS performance.

Cheers,





Borja.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fix Emulex oce driver in CURRENT

[Borja Marcos]

On Jul 15, 2014, at 1:36 PM, Stefano Garzarella wrote:

 So, asking for spiritual counsel now. Would you use this driver  in a 
 production environment instead of the 747 version downloaded from Emulex? I 
 think the latter is giving slightly better performance but, anyway, I disable 
 LRO and TSO because I see a horrible impact on NFS performance.
 
 
 I made a diff between the two versions (CURRENT and 747) and I saw that the 
 main difference is in the management of buf_ring through drbr API.
 In the CURRENT driver they use a new function drbr_peek() instead of 
 drbr_dequeue() and I think this is better.
 However, even in the 747 version seems to have the problem of the lack of 
 locking.

Well, definitely you saved my cake! So it was still a tickling time bomb.

Thank you very much!




Borja.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fix Emulex oce driver in CURRENT

[Borja Marcos]

On Jul 1, 2014, at 10:24 PM, Luigi Rizzo wrote:

 
 
 
 On Tue, Jul 1, 2014 at 8:58 PM, bor...@sarenet.es wrote:
 El 30.06.2014 18:36, Stefano Garzarella escribió:
 
 Hello,
 I had problems during some experiments with Emulex and oce driver in
 CURRENT.
 I found several bugs in the oce driver and this patch fixes them.
 
 At least with some cards, the driver simply does not work. It causes a panic 
 when there is some traffic.
 
 The relevant bug report is here.
 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183391
 
 The latest version available from the Emulex website works. But the version 
 bundled with 9.3 and at least -STABLE (which is the same version bundled with 
 -CURRENT) does cause panics on 10- and 9-
 
 ​i compared the code on the emulex website (10.0.747.0 ?) with the
 one in HEAD and it does not seem​ much different, but perhaps
 you have some other version in mind ?
 
 The bugs found by stefano exist also in the emulex version above.

Anyway

The fixed version is an instant panic when generating traffic (just use 
iperf3). Version 10.0.747.0  does _not_ panic.





Borja.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fix Emulex oce driver in CURRENT

[Borja Marcos]

On Jul 7, 2014, at 1:23 PM, Luigi Rizzo wrote:

 On Mon, Jul 7, 2014 at 1:03 PM, Borja Marcos bor...@sarenet.es wrote:
 we'll try to investigate, can you tell us more about the environment you use ?
 (FreeBSD version, card model (PCI id perhaps), iperf3 invocation line,
 interface configuration etc.)
 
 The main differences between 10.0.747.0 and the code in head (after
 our fix) is the use
 of drbr_enqueue/dequeue versus the peek/putback in the transmit routine.
 
 
 Both drivers still have issues when the link flaps because the
 transmit queue is not cleaned
 up properly (unlike what happens in the linux driver and all FreeBSD
 drivers for different
 hardware), so it might well be that you are seeing some side effect of
 that or other
 problem which manifests itself differently depending on the environment.
 
 'instant panic' by itself does not tell us anything about what could
 be the problem you experience (and we do not see it with either driver).

The environment details are here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183391

The way I produce an instant panic is:

1) Connect to another machine (cross connect cable)

2) iperf3 -s on the other machine 
(The other machine is different, it has an  ix card)

3) iperf3 -t 30 -P 4 -c 10.0.0.1 -N

In less than 30 seconds, panic.



mierda dumped core - see /var/crash/vmcore.0

Mon Jul  7 13:06:44 CEST 2014

FreeBSD mierda 10.0-STABLE FreeBSD 10.0-STABLE #2: Mon Jul  7 11:41:45 CEST 
2014 root@mierda:/usr/obj/usr/src/sys/GENERIC  amd64

panic: sbsndptr: sockbuf 0xf800a70489b0 and mbuf 0xf801a3326e00 clashing

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...

Unread portion of the kernel message buffer:
panic: sbsndptr: sockbuf 0xf800a70489b0 and mbuf 0xf801a3326e00 clashing
cpuid = 12
KDB: stack backtrace:
#0 0x8092a470 at kdb_backtrace+0x60
#1 0x808ef9c5 at panic+0x155
#2 0x80962710 at sbdroprecord_locked+0
#3 0x80a8ba8c at tcp_output+0xdbc
#4 0x80a8987f at tcp_do_segment+0x30ff
#5 0x80a85b34 at tcp_input+0xd04
#6 0x80a1af57 at ip_input+0x97
#7 0x809ba512 at netisr_dispatch_src+0x62
#8 0x809b1ae6 at ether_demux+0x126
#9 0x809b278e at ether_nh_input+0x35e
#10 0x809ba512 at netisr_dispatch_src+0x62
#11 0x81c19ab9 at oce_rx+0x3c9
#12 0x81c19536 at oce_rq_handler+0xb6
#13 0x81c1bb1c at oce_intr+0xdc
#14 0x80938b35 at taskqueue_run_locked+0xe5
#15 0x809395c8 at taskqueue_thread_loop+0xa8
#16 0x808c057a at fork_exit+0x9a
#17 0x80ccb51e at fork_trampoline+0xe
Uptime: 51m20s













Borja.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS secondarycache on SSD problem on r255173

[Borja Marcos]

On Sep 13, 2013, at 2:18 PM, Steven Hartland wrote:

 This is a recent bit of code by Justin cc'ed, so he's likely the best person 
 to
 investigate this one.

Hmm. There is still a lot of confusion surrounding all this, and it's a time 
bomb waiting to explode.

A friend had serious problems on 9.2 with the gnop trick in order to force a 4 
KB block size. After a reboot,
ZFS would insist on trying to find the .nop device for the ZIL which, of 
course, did no longer exist. In his case, for some reason,
ZFS didn't identify the labelled gpt/name or gptpd/uuid devices as valid, and 
the pool wouldn't attach. Curiously, it did identify the L2ARC 
without problems.

The cure was to disable GPT labels using loader.conf (I don't remember if he 
disabled kern.geom.label.gptid.enable, kern.geom.label.gpt.enable or both) in
order to force it to use the classical daXpY nomenclature.

As I said, this sounds like a time bomb in the works. There seems to be some 
confusion in the ZFS between the different naming schemes you
can use for a disk partition right now ( daXpY, gpt label or gptid).





Borja.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Bug? vm.stats.sys.v_syscall not updated

[Borja Marcos]

Hello,

I have tried to file PR, but the web pages give an authorization error.

There is a problem in -CURRENT. The vm.stats.sys.v_syscall from the system 
MIB is not updated. This variable was used at least by the systat command, 
and it happens to be used by an Orca (www.orcaware.com) data collector I am 
writing for FreeBSD.

Is this a bug? If it is not, is there another system call counter available?

Thanks in advance,




Borja.


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

MORE: Re: Bug? vm.stats.sys.v_syscall not updated

[Borja Marcos]

Looking at the kernel sources, I see that in /usr/src/sys/i386/i386/trap.c,

--- snip

/*
 * note: PCPU_LAZY_INC() can only be used if we can afford
 * occassional inaccuracy in the count.
 */
PCPU_LAZY_INC(cnt.v_syscall);

--- snip

This seems to be a macro to update a per-CPU variable. But, AFAIK, there is 
*only* one variable now. Is it correct? 

The ia64 version (/usr/src/sys/ia64/ia64) happily updates this variable:

 snip
syscall(int code, u_int64_t *args, struct trapframe *framep)
{
struct sysent *callp;
struct thread *td;
struct proc *p;
int error = 0;  
u_int64_t oldip, oldri;
u_int sticks;

cnt.v_syscall++;
 snip

What happens here? Is this a bug caught in the middle of a change?

BTW... Is there a major change in the sysctl MIB for 5.0-RELEASE? I am using 
it to get most of the information logged to Orca and I should take it into 
account.

Thanks,




Borja.


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