Re: kernel panics in in_lltable_lookup (with INVARIANTS)
On Fri, 21 Aug 2009 22:41:34 -0700 Brian Somers br...@awfulhak.org wrote:
On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers br...@freebsd.org wrote:
On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy km...@freebsd.org wrote:
Try this:
Index: sys/net/flowtable.c
===
--- sys/net/flowtable.c (revision 196382)
+++ sys/net/flowtable.c (working copy)
@@ -688,6 +688,12 @@
struct rtentry *rt = ro-ro_rt;
struct ifnet *ifp = rt-rt_ifp;
+ if (ifp-if_flags IFF_POINTOPOINT) {
+ RTFREE(rt);
+ ro-ro_rt = NULL;
+ return (ENOENT);
+ }
+
if (rt-rt_flags RTF_GATEWAY)
l3addr = rt-rt_gateway;
else
You'll need to apply this by hand as gmail munges the formatting.
-Kip
Hi,
That certainly stops the panic, however data routed to the tun
interface doesn't come out the back end and data written
to the back end doesn't come out the tun interface.
[.]
Maybe this problem isn't a routing problem. I'll
look into it further and figure out if the packet is getting to the tun
driver and if so, what it thinks it's doing with it.
I wasn't correct - the data *IS* being read out of the back of
the tunnel device. When I send the ICMP, it goes into the tun
device and comes out the back end as an AF_LINK packet. ppp
silently discards this (ironically I have a comment noting
that I should really track unidentified packet counts).
I'll try to figure out what in if_tun.c is corrupting the family next...
if_tun.c is fine. The data passed from if_output() has family
AF_LINK - hence the original panic from flowtable_lookup().
So the question is why is ip_output() sending AF_LINK traffic
instead of AF_INET traffic?.
Still looking
On Fri, Aug 21, 2009 at 16:43, Brian Somersbr...@freebsd.org wrote:
Hi,
I've been working on a fix to address an issue that came up with
our update of openssh-5. The issue is that openssh-5 now uses
pipe() to create stdin/stdout channels between sshd and the server
side program where it used to use socketpair(). Because it uses
pipe(), stdin is no longer bi-directional and cannot be used for both
input and output by a child process. This breaks the use of ssh
as a tunnel with ppp on either end (set device !ssh -e none host
ppp -direct label)
I talked with des@ for a while and then with the openssh folks and
have not been able to resolve the issues in openssh that made them
choose to enforce the use of pipe() over socketpair(). I now have a
patch to ppp that makes ppp detect that it's connected via pipe() and
causes it to use stdin for input and stdout for output (usually it
expects
just one descriptor). Although I'm happy with the patch and planned on
requesting permission to commit, I've bumped into a show-stopper
that seems unrelated, so I thought I'd ask here if anyone has seen
this or has any suggestions as to what the problem might be.
The issue
I'm seeing a panic when I send traffic through a ppp link:
panic string is: sin_family 18
Stack trace starts:
in_lltable_lookup()
llentry_update()
flowtable_lookup()
ip_output()
The panic is due to a KASSERT in in_lltable_lookup() that expects the
sockaddr to be AF_INET. Number 18 is AF_LINK.
AFAICT this is happening while setting up a temporary route for the
first outbound packet. I haven't been able to do much investigation
yet due to other patches in my tree that seem to have broken all my
kernel symbols, but once I get a clean rebuild I should be back in
business.
If anyone has any suggestions, I'm all ears!
Cheers.
--
Brian Somers br...@awfulhak.org
Don't _EVER_ lose your sense of humour ! br...@freebsd.org
signature.asc
Description: PGP signature
Re: Common interface for sensors/health monitoring
On Fri, Aug 21, 2009 at 11:17 PM, Oliver Pinter oliver.p...@gmail.comwrote: Hello! When I good know, no common interface exisit in current freebsd kernel, but some other sysctl interfece exisit: coretemp, aiboost ... ~ sysctl dev.coretemp dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.coretemp.2.%desc: CPU On-Die Thermal Sensors dev.coretemp.2.%driver: coretemp dev.coretemp.2.%parent: cpu2 dev.coretemp.3.%desc: CPU On-Die Thermal Sensors dev.coretemp.3.%driver: coretemp dev.coretemp.3.%parent: cpu3 ~ sysctl dev.acpi_aiboost dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER dev.acpi_aiboost.0.%driver: acpi_aiboost dev.acpi_aiboost.0.%location: handle=\_SB_.PCI0.SBRG.ASOC dev.acpi_aiboost.0.%pnpinfo: _HID=ATK0110 _UID=16843024 dev.acpi_aiboost.0.%parent: acpi0 dev.acpi_aiboost.0.temp0: 190 dev.acpi_aiboost.0.temp1: 300 dev.acpi_aiboost.0.volt0: 1144 dev.acpi_aiboost.0.volt1: 3328 dev.acpi_aiboost.0.volt2: 5064 dev.acpi_aiboost.0.volt3: 12096 dev.acpi_aiboost.0.fan0: 1962 dev.acpi_aiboost.0.fan1: 1180 dev.acpi_aiboost.0.fan2: 1278 dev.acpi_aiboost.0.fan3: 0 dev.acpi_aiboost.0.fan4: 0 but no common if.. Is there an acpi_dell or something like that? On 8/22/09, Aurélien Méré kind...@amc-os.com wrote: Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID statususage, network connectivity, UPS load, battery status runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. Thanks for your help and time, Aurélien +10 I was looking for the same info a time ago .. something that would allow me to gather all the info from the same place, but the only thing I came up with was the very same discussion about the sensors framework port and nothing else. Any info on any such proyect will be greatly apreciated Regards ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Aurélien Méré wrote: Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID statususage, network connectivity, UPS load, battery status runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. Thanks for your help and time, Aurélien ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Am 22.08.2009 um 08:03 schrieb Gonzalo Nemmi: On Fri, Aug 21, 2009 at 11:17 PM, Oliver Pinter oliver.p...@gmail.comwrote: Hello! When I good know, no common interface exisit in current freebsd kernel, but some other sysctl interfece exisit: coretemp, aiboost ... ~ sysctl dev.coretemp dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.coretemp.2.%desc: CPU On-Die Thermal Sensors dev.coretemp.2.%driver: coretemp dev.coretemp.2.%parent: cpu2 dev.coretemp.3.%desc: CPU On-Die Thermal Sensors dev.coretemp.3.%driver: coretemp dev.coretemp.3.%parent: cpu3 ~ sysctl dev.acpi_aiboost dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER dev.acpi_aiboost.0.%driver: acpi_aiboost dev.acpi_aiboost.0.%location: handle=\_SB_.PCI0.SBRG.ASOC dev.acpi_aiboost.0.%pnpinfo: _HID=ATK0110 _UID=16843024 dev.acpi_aiboost.0.%parent: acpi0 dev.acpi_aiboost.0.temp0: 190 dev.acpi_aiboost.0.temp1: 300 dev.acpi_aiboost.0.volt0: 1144 dev.acpi_aiboost.0.volt1: 3328 dev.acpi_aiboost.0.volt2: 5064 dev.acpi_aiboost.0.volt3: 12096 dev.acpi_aiboost.0.fan0: 1962 dev.acpi_aiboost.0.fan1: 1180 dev.acpi_aiboost.0.fan2: 1278 dev.acpi_aiboost.0.fan3: 0 dev.acpi_aiboost.0.fan4: 0 but no common if.. Is there an acpi_dell or something like that? On 8/22/09, Aurélien Méré kind...@amc-os.com wrote: Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID statususage, network connectivity, UPS load, battery status runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. Thanks for your help and time, Aurélien +10 I was looking for the same info a time ago .. something that would allow me to gather all the info from the same place, but the only thing I came up with was the very same discussion about the sensors framework port and nothing else. Any info on any such proyect will be greatly apreciated The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... - Marc Balmer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kernel panics in in_lltable_lookup (with INVARIANTS)
On Fri, 21 Aug 2009 23:23:13 -0700 Brian Somers br...@freebsd.org wrote:
On Fri, 21 Aug 2009 22:41:34 -0700 Brian Somers br...@awfulhak.org wrote:
On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers br...@freebsd.org wrote:
On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy km...@freebsd.org wrote:
Try this:
Index: sys/net/flowtable.c
===
--- sys/net/flowtable.c (revision 196382)
+++ sys/net/flowtable.c (working copy)
@@ -688,6 +688,12 @@
struct rtentry *rt = ro-ro_rt;
struct ifnet *ifp = rt-rt_ifp;
+ if (ifp-if_flags IFF_POINTOPOINT) {
+ RTFREE(rt);
+ ro-ro_rt = NULL;
+ return (ENOENT);
+ }
+
if (rt-rt_flags RTF_GATEWAY)
l3addr = rt-rt_gateway;
else
You'll need to apply this by hand as gmail munges the formatting.
-Kip
Hi,
That certainly stops the panic, however data routed to the tun
interface doesn't come out the back end and data written
to the back end doesn't come out the tun interface.
[.]
Maybe this problem isn't a routing problem. I'll
look into it further and figure out if the packet is getting to the tun
driver and if so, what it thinks it's doing with it.
I wasn't correct - the data *IS* being read out of the back of
the tunnel device. When I send the ICMP, it goes into the tun
device and comes out the back end as an AF_LINK packet. ppp
silently discards this (ironically I have a comment noting
that I should really track unidentified packet counts).
I'll try to figure out what in if_tun.c is corrupting the family next...
if_tun.c is fine. The data passed from if_output() has family
AF_LINK - hence the original panic from flowtable_lookup().
So the question is why is ip_output() sending AF_LINK traffic
instead of AF_INET traffic?.
Still looking
From what I can tell, this is what is happening:
ip_output() is called with ro == NULL.
ip_output() calls flowtable_lookup() with a zeroed 'ro'.
flowtable_lookup() calls ft-ft_rtalloc() (really rtalloc1_fib()) to
initialise 'ro' and ends up with ro-ro_rt-rt_gateway-sa_family
set to AF_LINK.
Your original patch frees ro-ro_rt and fails before calling
llentry_update() with ro-ro_rt-rt_gateway-sa_family !=
AF_INET.
Now, when flowtable_lookup() fails, ro-ro_rt is NULL and
ip_output()s 'dst' gets set up with family AF_INET. Unfortunately,
right after this, after checking for IP_SENDONES, IP_ROUTETOIF
and IN_MULTICAST, the ip_output() code decides to call
in_rtalloc_ign() (which eventually just calls rtalloc1_fib()) to
initialise ro-ro_rt and then sets dst to be ro-ro_rt-rt_gateway
-- which is *still* an AF_LINK address!
Finally ip_output() calls ifp-if_output() (really tunoutput()) with
dst's family set to AF_LINK, tunoutput() queues it to the tun
character device, ppp reads it and drops it on the floor 'cos it
doesn't know what to do with AF_LINK.
The tun driver is more or less the same as the -stable version,
so it seems that ip_output() is to blame. The only relevant part
that seems substantially different is rtalloc1_fib(), so right now
I'm guessing that the RTF_CLONING code in -stable always
clones the route with a gw family of AF_INET and expectations
are met after that.
I'll look some more on the weekend...
On Fri, Aug 21, 2009 at 16:43, Brian Somersbr...@freebsd.org wrote:
Hi,
I've been working on a fix to address an issue that came up with
our update of openssh-5. The issue is that openssh-5 now uses
pipe() to create stdin/stdout channels between sshd and the server
side program where it used to use socketpair(). Because it uses
pipe(), stdin is no longer bi-directional and cannot be used for both
input and output by a child process. This breaks the use of ssh
as a tunnel with ppp on either end (set device !ssh -e none host
ppp -direct label)
I talked with des@ for a while and then with the openssh folks and
have not been able to resolve the issues in openssh that made them
choose to enforce the use of pipe() over socketpair(). I now have a
patch to ppp that makes ppp detect that it's connected via pipe() and
causes it to use stdin for input and stdout for output (usually it
expects
just one descriptor). Although I'm happy with the patch and planned
on
requesting permission to commit, I've bumped into a show-stopper
that seems unrelated, so I thought I'd ask here if anyone has seen
this or has any suggestions as to what the problem might be.
The issue
I'm seeing a panic when I send traffic through a ppp link:
panic string is: sin_family 18
Stack trace starts:
Re: DTrace probes klds
On Fri, 21 Aug 2009, Alexander Leidinger wrote: Quoting Daniel O'Connor docon...@gsoft.com.au (from Thu, 20 Aug 2009 17:13:07 +0930): On Thu, 20 Aug 2009, Alexander Leidinger wrote: Quoting Daniel O'Connor docon...@gsoft.com.au (from Wed, 19 Aug 2009 23:31:33 +0930): Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Is it possible? the handbook implies not and I can't get it to work, but i could be doing it wrong.. I get fbt traces listed for KLDs (I get new entries for each load of the KLD which seems like a potential problem) but I can't specify an SDT_PROBE and have it work. Can you show us some example code? /* Recycle fbt as SDT_PROVIDER_DEFINE is said not to work */ SDT_PROBE_DEFINE(fbt, gsio, gsio_intr, test); SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 0, int); SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 1, int); I don't think you can define a fbt probe by hand. You can define a provider on your own via SDT_PROVIDER_DEFINE (in only one place/file), and then use this provider instead of fbt above. Let's assume you defined a gsio provider, then the SDT_PROBE_DEFINE could be SDT_PROBE_DEFINE(gsio, unique_part_of_name_of_file, gsio_intr, test); Yes, I only wanted to reuse fbt because the handbook says SDT_PROBE_DEFINE doesn't work as a KLD. If there's only one file, it does not make much sense to add an unique part of the name of the file, but if you have multiple files it can be helpful. But this is just an example, for example in GEOM it would make sense to name the provider geom, and instead of the file name use the module name, e.g. mirror, raid3, core/whatever, ... instead. Hmmm. I have tried that, but not joy :( SDT_PROVIDER_DEFINE(gsio); SDT_PROBE_DEFINE(gsio, main, gsio_intr, test); SDT_PROBE_ARGTYPE(gsio, main, gsio_intr, test, 0, int); SDT_PROBE_ARGTYPE(gsio, main, gsio_intr, test, 1, int); ... SDT_PROBE(gsio, main, gsio_intr, test, istat, 0, 0, 0, 0); I built my module with WITH_CTF=1 and I see that ctfconvert is run, however when I load it the Dtrace providers/providers aren't there. Building it into the kernel works but isn't ideal. Hmm, initially I was building my KLD outside of the tree, however when I build it with buildkernel load it dtrace -l crashes the system and I can't get a crashdump at the moment.. I'll try again when I can get to the console. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: kernel panics in in_lltable_lookup (with INVARIANTS)
On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers br...@freebsd.org wrote:
On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy km...@freebsd.org wrote:
Try this:
Index: sys/net/flowtable.c
===
--- sys/net/flowtable.c (revision 196382)
+++ sys/net/flowtable.c (working copy)
@@ -688,6 +688,12 @@
struct rtentry *rt = ro-ro_rt;
struct ifnet *ifp = rt-rt_ifp;
+ if (ifp-if_flags IFF_POINTOPOINT) {
+ RTFREE(rt);
+ ro-ro_rt = NULL;
+ return (ENOENT);
+ }
+
if (rt-rt_flags RTF_GATEWAY)
l3addr = rt-rt_gateway;
else
You'll need to apply this by hand as gmail munges the formatting.
-Kip
Hi,
That certainly stops the panic, however data routed to the tun
interface doesn't come out the back end and data written
to the back end doesn't come out the tun interface.
[.]
Maybe this problem isn't a routing problem. I'll
look into it further and figure out if the packet is getting to the tun
driver and if so, what it thinks it's doing with it.
I wasn't correct - the data *IS* being read out of the back of
the tunnel device. When I send the ICMP, it goes into the tun
device and comes out the back end as an AF_LINK packet. ppp
silently discards this (ironically I have a comment noting
that I should really track unidentified packet counts).
I'll try to figure out what in if_tun.c is corrupting the family next...
Cheers.
On Fri, Aug 21, 2009 at 16:43, Brian Somersbr...@freebsd.org wrote:
Hi,
I've been working on a fix to address an issue that came up with
our update of openssh-5. The issue is that openssh-5 now uses
pipe() to create stdin/stdout channels between sshd and the server
side program where it used to use socketpair(). Because it uses
pipe(), stdin is no longer bi-directional and cannot be used for both
input and output by a child process. This breaks the use of ssh
as a tunnel with ppp on either end (set device !ssh -e none host
ppp -direct label)
I talked with des@ for a while and then with the openssh folks and
have not been able to resolve the issues in openssh that made them
choose to enforce the use of pipe() over socketpair(). I now have a
patch to ppp that makes ppp detect that it's connected via pipe() and
causes it to use stdin for input and stdout for output (usually it expects
just one descriptor). Although I'm happy with the patch and planned on
requesting permission to commit, I've bumped into a show-stopper
that seems unrelated, so I thought I'd ask here if anyone has seen
this or has any suggestions as to what the problem might be.
The issue
I'm seeing a panic when I send traffic through a ppp link:
panic string is: sin_family 18
Stack trace starts:
in_lltable_lookup()
llentry_update()
flowtable_lookup()
ip_output()
The panic is due to a KASSERT in in_lltable_lookup() that expects the
sockaddr to be AF_INET. Number 18 is AF_LINK.
AFAICT this is happening while setting up a temporary route for the
first outbound packet. I haven't been able to do much investigation
yet due to other patches in my tree that seem to have broken all my
kernel symbols, but once I get a clean rebuild I should be back in
business.
If anyone has any suggestions, I'm all ears!
Cheers.
--
Brian Somers br...@awfulhak.org
Don't _EVER_ lose your sense of humour ! br...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009, Marc Balmer wrote: I was looking for the same info a time ago .. something that would allow me to gather all the info from the same place, but the only thing I came up with was the very same discussion about the sensors framework port and nothing else. Any info on any such proyect will be greatly apreciated The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... One of the things I'd particularly like to see is an alignment between kernel/user level monitoring frameworks and the SNMP model (especially relating to traps). The SNMP information model (MIBs, agents, traps, etc) has its limitations, but having a compatible model at all layers of the system will make it easier to store, manipulate, manage, and report this information consistently throughout the OS and larger distributed systems. Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009 08:50:23 +0200 Marc Balmer m...@msys.ch wrote: The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had This assumes the kernel is monitoring the device periodically (in the general case, as there are a lot of dump sensors which do not send events on their own). The framework as in the SoC did not provide this feature to keep the kernel part simple. You want to see a value, you poll the kernel for it, and the userland would have been responsible to fire up an event. For smart sensors which trigger an event on their own (interrupt), you can use the exiting kernel event framework (and the idea in the SoC was to use it for such sensors). The devd is the userland side of it. not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... The event stuff is in the kernel, go ahead and write a driver for your smart sensor which fires events on its own. Bye, Alexander. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. Bye, Alexander. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Am 22.08.2009 um 18:29 schrieb Alexander Leidinger: On Sat, 22 Aug 2009 08:50:23 +0200 Marc Balmer m...@msys.ch wrote: The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had This assumes the kernel is monitoring the device periodically (in the general case, as there are a lot of dump sensors which do not send events on their own). The framework as in the SoC did not provide this feature to keep the kernel part simple. You want to see a value, you poll the kernel for it, and the userland would have been responsible to fire up an event. For smart sensors which trigger an event on their own (interrupt), you can use the exiting kernel event framework (and the idea in the SoC was to use it for such sensors). The devd is the userland side of it. not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... The event stuff is in the kernel, go ahead and write a driver for your smart sensor which fires events on its own. Well, most of the sensors are likely I2C or 1-Wire devices and these can only be polled. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
* Alexander Leidinger alexan...@leidinger.net [090822 10:44] wrote: On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Alfred Perlstein wrote: * Alexander Leidinger alexan...@leidinger.net [090822 10:44] wrote: On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) I think that this kind of talk calls for boycotting certain device drivers! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
CFT: Patch for the Xen console driver
Hi folks,
Today I was doing some cleanups to our kernel message/debug console code
and I noticed we have only one driver in the tree that does some really
spooky things with its console device, namely the Xen console driver. I
did some cleanups and basically fixed the following:
- It now uses the CONSOLE_DRIVER() way to declare a driver, instead of
using CONS_DRIVER() (which has some arguments which are no-ops
nowadays), which means we can remove CONS_DRIVER() entirely.
- It doesn't use cn_checkc anymore. The driver had a cn_getc routine,
but it was never being called, because it was overlapped by cn_checkc.
cn_checkc is deprecated in favour of cn_getc, so I removed cn_getc and
renamed cn_checkc to cn_getc.
- It doesn't runtime patch the functions inside struct consdev anymore.
I'm planning on changing the consdev code to disallow drivers to patch
their own functions, because the structure containing them may be
shared between multiple console devices.
Because I don't have a system with Xen, I was only capable of
compile-testing the driver. Are there any (8.0-)users here who can test
the attached patch for me? Thanks!
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
--- sys/dev/xen/console/console.c
+++ sys/dev/xen/console/console.c
@@ -45,17 +45,15 @@
static void xcons_force_flush(void);
static void xencons_priv_interrupt(void *);
-static cn_probe_t xccnprobe;
-static cn_init_txccninit;
-static cn_getc_txccngetc;
-static cn_putc_txccnputc;
-static cn_putc_txccnputc_dom0;
-static cn_checkc_t xccncheckc;
+static cn_probe_t xc_cnprobe;
+static cn_init_txc_cninit;
+static cn_term_txc_cnterm;
+static cn_getc_txc_cngetc;
+static cn_putc_txc_cnputc;
#define XC_POLLTIME (hz/10)
-CONS_DRIVER(xc, xccnprobe, xccninit, NULL, xccngetc,
- xccncheckc, xccnputc, NULL);
+CONSOLE_DRIVER(xc);
static int xen_console_up;
static boolean_t xc_start_needed;
@@ -105,7 +103,7 @@
};
static void
-xccnprobe(struct consdev *cp)
+xc_cnprobe(struct consdev *cp)
{
cp-cn_pri = CN_REMOTE;
sprintf(cp-cn_name, %s0, driver_name);
@@ -113,37 +111,19 @@
static void
-xccninit(struct consdev *cp)
+xc_cninit(struct consdev *cp)
{
CN_LOCK_INIT(cn_mtx,XCONS LOCK);
}
-int
-xccngetc(struct consdev *dev)
-{
- int c;
- if (xc_mute)
- return 0;
- do {
- if ((c = xccncheckc(dev)) == -1) {
-#ifdef KDB
- if (!kdb_active)
-#endif
-/*
- * Polling without sleeping in Xen
- * doesn't work well. Sleeping gives
- * other things like clock a chance to
- * run
- */
-tsleep(cn_mtx, PWAIT | PCATCH,
-console sleep, XC_POLLTIME);
- }
- } while(c == -1);
- return c;
+
+static void
+xc_cnterm(struct consdev *cp)
+{
}
-int
-xccncheckc(struct consdev *dev)
+static int
+xc_cngetc(struct consdev *dev)
{
int ret = (xc_mute ? 0 : -1);
@@ -162,17 +142,27 @@
}
static void
-xccnputc(struct consdev *dev, int c)
+xc_cnputc_domu(struct consdev *dev, int c)
{
xcons_putc(c);
}
static void
-xccnputc_dom0(struct consdev *dev, int c)
+xc_cnputc_dom0(struct consdev *dev, int c)
{
HYPERVISOR_console_io(CONSOLEIO_write, 1, (char *)c);
}
+static void
+xc_cnputc(struct consdev *dev, int c)
+{
+
+ if (xen_start_info-flags SIF_INITDOMAIN)
+ xc_cnputc_dom0(dev, c);
+ else
+ xc_cnputc_domu(dev, c);
+}
+
extern int db_active;
static boolean_t
xcons_putc(int c)
@@ -226,10 +216,6 @@
{
int error;
- if (xen_start_info-flags SIF_INITDOMAIN) {
- xc_consdev.cn_putc = xccnputc_dom0;
- }
-
xccons = tty_alloc(xc_ttydevsw, NULL);
tty_makedev(xccons, NULL, xc%r, 0);
@@ -388,7 +374,7 @@
tp = (struct tty *)v;
tty_lock(tp);
- while ((c = xccncheckc(NULL)) != -1)
+ while ((c = xc_cngetc(NULL)) != -1)
ttydisc_rint(tp, c, 0);
if (xc_start_needed) {
pgpSduarhJMqE.pgp
Description: PGP signature
Re: Common interface for sensors/health monitoring
Stephen Montgomery-Smith wrote: Alfred Perlstein wrote: * Alexander Leidinger alexan...@leidinger.net [090822 10:44] wrote: On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) I think that this kind of talk calls for boycotting certain device drivers! In OpenBSD they have project sponsored healthware and sometimes you have to wait in a queue to get you notifications, and sometimes the queue is so long events have to get merged! Not for me! I want all my individual events to be lost After I get them. It's my right! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had This assumes the kernel is monitoring the device periodically (in the general case, as there are a lot of dump sensors which do not send events on their own). The framework as in the SoC did not provide this feature to keep the kernel part simple. You want to see a value, you poll the kernel for it, and the userland would have been responsible to fire up an event. In my pratical case, this is perfectly satisfying. Probably most of the controllers I work with don't even support event triggering, and we already have the scripts to trigger events depending on the polled values. I'm worried that today drivers don't exist or don't seem to be maintained to provide these values. So, I would be satisfied just by getting the values. I would be very satisfied if it was in a common interface. Heaven with triggers... I'm just afraid by reading your email that the situation doesn't seem to have evolved since the discussion regarding the SoC, maybe even more taboo, and that I'll have to keep writing my own software and drivers to get the data I want in the future if I want to get this data under FreeBSD.. Is it the case ? Thx Aurélien ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009, Julian Elischer wrote: Stephen Montgomery-Smith wrote: Alfred Perlstein wrote: * Alexander Leidinger alexan...@leidinger.net [090822 10:44] wrote: On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) I think that this kind of talk calls for boycotting certain device drivers! In OpenBSD they have project sponsored healthware and sometimes you have to wait in a queue to get you notifications, and sometimes the queue is so long events have to get merged! Not for me! I want all my individual events to be lost After I get them. It's my right! Perhaps you are getting too much information through the cable network. Your system might be getting all wee weed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
As terribly clever as you all are, can you please restrict the political commentary/humor/whatever to -chat? Thanks, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
