IFCAP_CANTCHANGE ? (Re: RFC: need one IFCAP bit for NETMAP)
On Tue, Jun 07, 2011 at 08:14:17AM +0200, Luigi Rizzo wrote:
> hi,
> in order to import netmap support into the tree (see
> http://info.iet.unipi.it/~luigi/netmap ), i need
> to use one of the if_cap{abilities|enable} bits to report
> that the interface supports this mode and record whether
> the mode is enabled or not.
>
> Bit 0x10 is currently the first unused bit so if
> there are no objections i will add the following
> to sys/net/if.h
>
> #define IFCAP_NETMAP0x10 /* netmap mode supported/enabled */
>
> and the following change to sbin/ifconfig/ifconfig.c
>
> -"\21VLAN_HWFILTER\23VLAN_HWTSO\24LINKSTATE"
> +"\21VLAN_HWFILTER\23VLAN_HWTSO\24LINKSTATE\25NETMAP"
>
> That's all you need, as netmap mode is not supposed to be
> set from sbin/ifconfig.
speaking of which, it occurs to me that while we have a
"CANTCHANGE" category for interface flags, we don't have
one for capabilities. Would it be ok to add one ?
Looking at the list in if.h, for example, it seems to me
that things like IFCAP_LINKSTATE or IFCAP_VLAN_MTU or IFCAP_JUMBO_MTU
shouldn't be modifiable through SIOCSIFCAP.
Of course if would be best to separate CANTCHANGE bits from
those that can be modified through ioctls, but that would
apply to interface flags as well, and i don't think it can be
done due to API change issues.
cheers
luigi
___
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: warning: 'inline' is not at beginning of declaration ?
On Thu, Jun 02, 2011, Arnaud Lacombe wrote: > > On a related topic, do we have any mechanism to provide > > per-subdir or per-file CFLAGS during kernel builds ? > > > I'd say no as the kernel per-se makes no use of , ooth, > some modules do. > > > I tried to put a Makefile.inc in a subdirectory but it > > did not help. > > > understandable, as Makefile.inc is sourced by , which is > only used by `sys/conf/kmod.mk'. There's a hack to do per-file CFLAGS in libc. We use this to compile the vendor sources gdtoa_*.c with warnings disabled, since the vendor disavows gcc's stylistic complaints. See src/lib/libc/Makefile. ___ 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: IPv4 broken on r222048
On Tue, Jun 7, 2011 at 11:13 AM, Bjoern A. Zeeb wrote: > On Jun 7, 2011, at 6:00 PM, Garrett Cooper wrote: > >> On Tue, Jun 7, 2011 at 10:41 AM, Bjoern A. Zeeb >> wrote: >>> >>> On Jun 7, 2011, at 5:29 PM, Garrett Cooper wrote: >>> Hi, I'm running into an issue where ifconfig isn't executing properly, and is emitting the following message: # ifconfig re0 inet w.x.y.z ifconfig: can't set link-level netmask or broadcast # >>> ... I haven't traced down what commit exactly is causing this, but the issue appears to be a purely userland based problem so far (I accidentally forgot to swap kernels before booting up the second time and the symptoms are exactly the same). >>> >>> Yes, you lost. My changes did that. You are the second to hit it. >>> Your kernel does not have "FEATURES()" present and the new user space >>> that came a couple of days later expect it and disable your IPv4 >>> because of that. >>> >>> The real problem is when people update the kernel, then update world >>> and then figure out they need to go back to kernel.old. >>> I'll add an UPDATING entry. >> >> That I would expect, but I just built the kernel last night, installed >> it, and am running it right now and I run into the same issue as I do >> with the older kernel :). Was there any magic foo that I needed to use >> to get FEATURES working properly, or was it supposed to be seamless? I >> don't know because I never had a need to fiddle around with the >> framework.. > > It's supposed to be seamless. Can you check if you have the following two? > sysctl kern.features.inet > sysctl kern.features.inet6 > > >> Looks like I need an old userland, because a new kernel/userland combo >> doesn't seem to work as advertised :/... > > I think I just found a good "recovery" idea -- I should disable the > features with rescue builds. That should give one a working > /rescue/ifconfig in all cases and should be sufficient to recover? That would be a good backup plan so people could at least avoid painting themselves into a corner by accident. Thanks! -Garrett ___ 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: IPv4 broken on r222048
On Jun 7, 2011, at 6:11 PM, Garrett Cooper wrote: > Answering my own question: > > sysctl kern.features.inet > sysctl kern.features.inet6 > > Hmmm... they turn up unknown OIDs. Need to do some digging to discover > why that's the case.. See if you kernel has the changes from: http://svnweb.freebsd.org/base?view=revision&revision=72 /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: IPv4 broken on r222048
On Jun 7, 2011, at 6:00 PM, Garrett Cooper wrote: > On Tue, Jun 7, 2011 at 10:41 AM, Bjoern A. Zeeb > wrote: >> >> On Jun 7, 2011, at 5:29 PM, Garrett Cooper wrote: >> >>> Hi, >>>I'm running into an issue where ifconfig isn't executing properly, >>> and is emitting the following message: >>> >>> # ifconfig re0 inet w.x.y.z >>> ifconfig: can't set link-level netmask or broadcast >>> # >> ... >>>I haven't traced down what commit exactly is causing this, but the >>> issue appears to be a purely userland based problem so far (I >>> accidentally forgot to swap kernels before booting up the second time >>> and the symptoms are exactly the same). >> >> Yes, you lost. My changes did that. You are the second to hit it. >> Your kernel does not have "FEATURES()" present and the new user space >> that came a couple of days later expect it and disable your IPv4 >> because of that. >> >> The real problem is when people update the kernel, then update world >> and then figure out they need to go back to kernel.old. >> I'll add an UPDATING entry. > > That I would expect, but I just built the kernel last night, installed > it, and am running it right now and I run into the same issue as I do > with the older kernel :). Was there any magic foo that I needed to use > to get FEATURES working properly, or was it supposed to be seamless? I > don't know because I never had a need to fiddle around with the > framework.. It's supposed to be seamless. Can you check if you have the following two? sysctl kern.features.inet sysctl kern.features.inet6 > Looks like I need an old userland, because a new kernel/userland combo > doesn't seem to work as advertised :/... I think I just found a good "recovery" idea -- I should disable the features with rescue builds. That should give one a working /rescue/ifconfig in all cases and should be sufficient to recover? Bjoern -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: IPv4 broken on r222048
On Tue, Jun 7, 2011 at 11:00 AM, Garrett Cooper wrote: > On Tue, Jun 7, 2011 at 10:41 AM, Bjoern A. Zeeb > wrote: >> >> On Jun 7, 2011, at 5:29 PM, Garrett Cooper wrote: >> >>> Hi, >>> I'm running into an issue where ifconfig isn't executing properly, >>> and is emitting the following message: >>> >>> # ifconfig re0 inet w.x.y.z >>> ifconfig: can't set link-level netmask or broadcast >>> # >> ... >>> I haven't traced down what commit exactly is causing this, but the >>> issue appears to be a purely userland based problem so far (I >>> accidentally forgot to swap kernels before booting up the second time >>> and the symptoms are exactly the same). >> >> Yes, you lost. My changes did that. You are the second to hit it. >> Your kernel does not have "FEATURES()" present and the new user space >> that came a couple of days later expect it and disable your IPv4 >> because of that. >> >> The real problem is when people update the kernel, then update world >> and then figure out they need to go back to kernel.old. >> I'll add an UPDATING entry. > > That I would expect, but I just built the kernel last night, installed > it, and am running it right now and I run into the same issue as I do > with the older kernel :). Was there any magic foo that I needed to use > to get FEATURES working properly, or was it supposed to be seamless? I > don't know because I never had a need to fiddle around with the > framework.. > > Is there a tool I can use (minus banging on the interfaces in C) to > determine what the features are on the machine to diagnose why things > aren't working for me? Answering my own question: sysctl kern.features.inet sysctl kern.features.inet6 Hmmm... they turn up unknown OIDs. Need to do some digging to discover why that's the case.. >> You need an old user land or a new kernel to recover. > > Looks like I need an old userland, because a new kernel/userland combo > doesn't seem to work as advertised :/... > >>> I have both INET and INET6 built into my kernel and userland, but >>> my immediate upstream router only supports IPv4 right now. I tried >>> building with WITHOUT_INET6=yes to see if it made a difference, and it >>> didn't. >>> I'll test any patches needed to remedy the issue. Thankfully I >>> have flash media I can use in the meantime to push code between my two >>> boxes :) >> >> Welcome to FreeBSD HEAD, being a developer and not following the rule;-) >> >> Sorry for the hassle though. > > It's ok -- that's why I have two near workstations -- one for daily > use and the other for testing :). Thanks, -Garrett ___ 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: IPv4 broken on r222048
On Tue, Jun 7, 2011 at 10:41 AM, Bjoern A. Zeeb wrote: > > On Jun 7, 2011, at 5:29 PM, Garrett Cooper wrote: > >> Hi, >> I'm running into an issue where ifconfig isn't executing properly, >> and is emitting the following message: >> >> # ifconfig re0 inet w.x.y.z >> ifconfig: can't set link-level netmask or broadcast >> # > ... >> I haven't traced down what commit exactly is causing this, but the >> issue appears to be a purely userland based problem so far (I >> accidentally forgot to swap kernels before booting up the second time >> and the symptoms are exactly the same). > > Yes, you lost. My changes did that. You are the second to hit it. > Your kernel does not have "FEATURES()" present and the new user space > that came a couple of days later expect it and disable your IPv4 > because of that. > > The real problem is when people update the kernel, then update world > and then figure out they need to go back to kernel.old. > I'll add an UPDATING entry. That I would expect, but I just built the kernel last night, installed it, and am running it right now and I run into the same issue as I do with the older kernel :). Was there any magic foo that I needed to use to get FEATURES working properly, or was it supposed to be seamless? I don't know because I never had a need to fiddle around with the framework.. Is there a tool I can use (minus banging on the interfaces in C) to determine what the features are on the machine to diagnose why things aren't working for me? > You need an old user land or a new kernel to recover. Looks like I need an old userland, because a new kernel/userland combo doesn't seem to work as advertised :/... >> I have both INET and INET6 built into my kernel and userland, but >> my immediate upstream router only supports IPv4 right now. I tried >> building with WITHOUT_INET6=yes to see if it made a difference, and it >> didn't. >> I'll test any patches needed to remedy the issue. Thankfully I >> have flash media I can use in the meantime to push code between my two >> boxes :) > > Welcome to FreeBSD HEAD, being a developer and not following the rule;-) > > Sorry for the hassle though. It's ok -- that's why I have two near workstations -- one for daily use and the other for testing :). Thanks! -Garrett ___ 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: NEW_PCIB? pcib1: failed to allocate initial I/O port window: 0x4000-0x4fff
On Monday, June 06, 2011 9:33:30 pm John wrote: > - John Baldwin's Original Message - > > On Sunday, June 05, 2011 8:23:53 pm John wrote: > > > Hi Folks, > > > > > >I just attempted to update an HP385G0 system from current as of > > > 4-15-2011 to 6-2-2011. The new system will not boot, and shows the > > > following message when it hangs: > > > > > > pcib1: at device 3.0 on pci0 > > > pcib1: failed to allocate initial I/O port window: 0x4000-0x4fff > > > > > >From a booting system, device 3.0 shows the following in dmesg: > > > > > > pcib1: at device 3.0 on pci0 > > > vgapci0: port 0x4400-0x44ff mem > > 0xf600-0xf6ff,0xf5ff-0xf5ff0fff at device 3.0 on pci1 > > > > > >From reading other msgs that seem related to this problem, I've > > > attached the dmesg, devinfo -ur, and devinfo -rv below. > > > > > >Thanks for any help solving this. > > > > Please try this patch: > > > Hi John, > >I applied your patch/rebuilt/installed/rebooted. The system seems > to get farther, but still locks up tight. A screen pic is here: > > http://people.freebsd.org/~jwd/dmesg.jpg > >The -v dmesg output looks right except for the 'MCA' text at the > bottom. Not sure where it's coming from. It's worth noting sometimes > the MCA doesn't show up, but it always locks up at that point now. Hmmm, an MCA is not a good sign. >In looking at the devinfo/dmesg output, I don't think I see any > actual overlapping areas, but do see multiple items within the 0x4000 > to 0x4fff range. I don't claim to be an expert though. Yes, there are multiple ranges. Would it be possible to use a serial port to capture a full verbose dmesg up to the point where it hangs? -- John Baldwin ___ 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: pcib allocation failure
On Monday, June 06, 2011 11:02:59 pm deeptec...@gmail.com wrote: > On Mon, Jun 6, 2011 at 4:52 PM, John Baldwin wrote: > > Can you try out this change. It is a possible "real" solution (or at least a > > stopgap until we start using multipass to untangle the resource mess a bit > > further): > [snip] > > that doesn't work. i get an allocation failure. It is expected to still get an allocation failure. Instead what the change does is avoid updating the registers for the window until after all the devices on the bus have been probed. Were you able to save a dmesg somehow from the boot with this patch? -- John Baldwin ___ 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: IPv4 broken on r222048
On Jun 7, 2011, at 5:29 PM, Garrett Cooper wrote: > Hi, >I'm running into an issue where ifconfig isn't executing properly, > and is emitting the following message: > > # ifconfig re0 inet w.x.y.z > ifconfig: can't set link-level netmask or broadcast > # ... >I haven't traced down what commit exactly is causing this, but the > issue appears to be a purely userland based problem so far (I > accidentally forgot to swap kernels before booting up the second time > and the symptoms are exactly the same). Yes, you lost. My changes did that. You are the second to hit it. Your kernel does not have "FEATURES()" present and the new user space that came a couple of days later expect it and disable your IPv4 because of that. The real problem is when people update the kernel, then update world and then figure out they need to go back to kernel.old. I'll add an UPDATING entry. You need an old user land or a new kernel to recover. >I have both INET and INET6 built into my kernel and userland, but > my immediate upstream router only supports IPv4 right now. I tried > building with WITHOUT_INET6=yes to see if it made a difference, and it > didn't. >I'll test any patches needed to remedy the issue. Thankfully I > have flash media I can use in the meantime to push code between my two > boxes :) Welcome to FreeBSD HEAD, being a developer and not following the rule;-) Sorry for the hassle though. Bjoern -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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"
IPv4 broken on r222048
Hi, I'm running into an issue where ifconfig isn't executing properly, and is emitting the following message: # ifconfig re0 inet w.x.y.z ifconfig: can't set link-level netmask or broadcast # This unfortunately also breaks 'dhclient re0' (in my case) as it calls ifconfig. Inserting some printfs in link_getaddr it looks like it's trying to test something incorrectly: # ifconfig re0 inet 192.168.20.3 which: 1, ADDR: 1 which: 3, ADDR: 1 ifconfig: can't set link-level netmask or broadcast # Attaching gdb to the process (because the link_getaddr functions are function pointers and I wanted to remove all obscurity), the failing call is originating from setifdstaddr. The abbreviated stack trace is: - af_link.c:77 - ifconfig.c:773 - ifconfig.c:579 - ifconfig.c:346 The actual line count in af_link.c is going to be fuzzed by 2 because of the printf I added. I haven't traced down what commit exactly is causing this, but the issue appears to be a purely userland based problem so far (I accidentally forgot to swap kernels before booting up the second time and the symptoms are exactly the same). I have both INET and INET6 built into my kernel and userland, but my immediate upstream router only supports IPv4 right now. I tried building with WITHOUT_INET6=yes to see if it made a difference, and it didn't. I'll test any patches needed to remedy the issue. Thankfully I have flash media I can use in the meantime to push code between my two boxes :). Thanks, -Garrett ___ 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[2]: 2 day GENERIC-current eat 2 CPU core at 100%
vmstat -i interrupt total rate irq16: uhci3 205 0 irq20: hpet0 147924380 1126 irq23: uhci0 ehci0 522517 3 total148447102 1130 Tue, 7 Jun 2011 10:34:01 +0200 письмо от Hans Petter Selasky : > On Tuesday 07 June 2011 10:09:47 Andrey Smagin wrote: > > I upgraded 2 day ago from 2010-current box on Intel D525MW. > > System very slow down after that. > > kern.hz=50 > > in systat -vmstat - 140hpet interrupts/s > > at top 25% in interrupts 25% in system > > because hyperthreading system found 4 cpu. > > What does vmstat -i output? > > --HPS > ___ > 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" ___ 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"
[head tinderbox] failure on ia64/ia64
TB --- 2011-06-07 14:27:06 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-07 14:27:06 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-06-07 14:27:06 - cleaning the object tree TB --- 2011-06-07 14:27:19 - cvsupping the source tree TB --- 2011-06-07 14:27:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-06-07 14:27:35 - building world TB --- 2011-06-07 14:27:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-07 14:27:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-07 14:27:35 - TARGET=ia64 TB --- 2011-06-07 14:27:35 - TARGET_ARCH=ia64 TB --- 2011-06-07 14:27:35 - TZ=UTC TB --- 2011-06-07 14:27:35 - __MAKE_CONF=/dev/null TB --- 2011-06-07 14:27:35 - cd /src TB --- 2011-06-07 14:27:35 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 7 14:27:35 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 7 15:52:00 UTC 2011 TB --- 2011-06-07 15:52:00 - generating LINT kernel config TB --- 2011-06-07 15:52:00 - cd /src/sys/ia64/conf TB --- 2011-06-07 15:52:00 - /usr/bin/make -B LINT TB --- 2011-06-07 15:52:00 - building LINT kernel TB --- 2011-06-07 15:52:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-07 15:52:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-07 15:52:00 - TARGET=ia64 TB --- 2011-06-07 15:52:00 - TARGET_ARCH=ia64 TB --- 2011-06-07 15:52:00 - TZ=UTC TB --- 2011-06-07 15:52:00 - __MAKE_CONF=/dev/null TB --- 2011-06-07 15:52:00 - cd /src TB --- 2011-06-07 15:52:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 7 15:52:01 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:1194: error: 'HAL_PHYERR_RADAR' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:1194: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:1194: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:1195: error: dereferencing pointer to incomplete type /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:1195: error: 'HAL_PHYERR_FALSE_RADAR_EXT' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:1202: error: dereferencing pointer to incomplete type /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:1209: error: dereferencing pointer to incomplete type /src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:1220: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-07 15:57:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-07 15:57:56 - ERROR: failed to build lint kernel TB --- 2011-06-07 15:57:57 - 4295.57 user 781.63 system 5450.22 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ 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: [poll / rfc] kdb_stop_cpus
on 04/06/2011 12:11 Robert N. M. Watson said the following: > > On 4 Jun 2011, at 09:22, Andriy Gapon wrote: >> commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016 >> >> generic_stop_cpus: move timeout detection code from under DIAGNOSTIC >> >> ... and also increase it a bit. IMO it's better to detect and report the >> (rather serious) condition and allow a system to proceed somehow rather than >> be stuck in an endless loop. > > Agreed on detecting and reporting. It would be good to confirm that it works > in > practice, however, What is your concern here? :) The code seems rather simple - the loop is no longer infinite. > and also that there are no false positives. I'm not sure > what the best test scenarios are for that. As to the false positives - I think that that can only be verified by practice (very wide testing), because that would greatly depend on hardware. Maybe we should use some time-based approach instead of the iteration count approach or maybe we should calibrate the iteration count based on hardware characteristics... -- Andriy Gapon ___ 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: [poll / rfc] kdb_stop_cpus
on 05/06/2011 01:35 Attilio Rao said the following:
> 2011/6/4 Andriy Gapon :
>> commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016
>>
>>generic_stop_cpus: move timeout detection code from under DIAGNOSTIC
>>
>>... and also increase it a bit.
>>IMO it's better to detect and report the (rather serious) condition and
>>allow a system to proceed somehow rather than be stuck in an endless
>>loop.
>>
>> diff --git a/sys/kern/subr_smp.c b/sys/kern/subr_smp.c
>> index ae52f4b..4bd766b 100644
>> --- a/sys/kern/subr_smp.c
>> +++ b/sys/kern/subr_smp.c
>> @@ -232,12 +232,10 @@ generic_stop_cpus(cpumask_t map, u_int type)
>>/* spin */
>>cpu_spinwait();
>>i++;
>> -#ifdef DIAGNOSTIC
>> - if (i == 10) {
>> + if (i == 1) {
>>printf("timeout stopping cpus\n");
>>break;
>>}
>> -#endif
>>}
>>
>>stopping_cpu = NOCPU;
>
> I'd also add the ability, once the deadlock is detected, to break in
> KDB, and put that under DIAGNOSTIC.
> I had such a patch and I used it to debug some deadlocks on shutdown
> code, but now it seems I can't find it anymore.
I think that this could be useful.
Of course, it would have to honor KDB_UNATTENDED.
However, I am not sure how to implement it safely. E.g. panic() should stop
other
CPUs before setting panicstr and if some CPU is stuck for good, then we would
just
be recursively calling panic() until triple-fault. Ditto for kdb_trap().
So if you could dig up your code for implementing this that would be useful.
--
Andriy Gapon
___
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: 2 day GENERIC-current eat 2 CPU core at 100%
On Tuesday 07 June 2011 10:09:47 Andrey Smagin wrote: > I upgraded 2 day ago from 2010-current box on Intel D525MW. > System very slow down after that. > kern.hz=50 > in systat -vmstat - 140hpet interrupts/s > at top 25% in interrupts 25% in system > because hyperthreading system found 4 cpu. What does vmstat -i output? --HPS ___ 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"
2 day GENERIC-current eat 2 CPU core at 100%
I upgraded 2 day ago from 2010-current box on Intel D525MW. System very slow down after that. kern.hz=50 in systat -vmstat - 140hpet interrupts/s at top 25% in interrupts 25% in system because hyperthreading system found 4 cpu.___ 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"
