Re: [CFT]RT28xx/RT30xx wireless was [CFR]RT305xF support, w/o attachment
rt28600: Ralink RT2790 PCIe mem 0xf7f0-0xf7f0 irq 17 at device 0.0 on pci3 rt28600: invalid EEPROM LNA gain #2: 0x00 rt28600: invalid EEPROM LNA gain #3: 0x00 rt28600: invalid EEPROM powersave level rt28600: MAC/BBP RT2860 (rev 0x28720200), RF RT3022 2.4G 2T2R Wow, your device have same revision 0x28720200 like embedded into RT3052F system on chip. So now I understand, why driver won't work with your card. I previously expect that this id related only for SoC version, but SoC version don't have many things that PCI version have (MCU, EEPROM, etc.) Hi, I have 0x28720200 calling rt2872_rf_set_chan() instead of rt2860_rf_set_chan(). And, 0x2000 for initial RT2860_REG_MAX_LEN value in rt2860_init_locked(). If these are correct I can patch the driver up. AK ___ 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: [CFT]RT28xx/RT30xx wireless was [CFR]RT305xF support, w/o attachment
On Thu, 31 Mar 2011 23:44:03 -0700 (PDT) PseudoCylon moonlightak...@yahoo.ca wrote: rt28600: Ralink RT2790 PCIe mem 0xf7f0-0xf7f0 irq 17 at device 0.0 on pci3 rt28600: invalid EEPROM LNA gain #2: 0x00 rt28600: invalid EEPROM LNA gain #3: 0x00 rt28600: invalid EEPROM powersave level rt28600: MAC/BBP RT2860 (rev 0x28720200), RF RT3022 2.4G 2T2R Wow, your device have same revision 0x28720200 like embedded into RT3052F system on chip. So now I understand, why driver won't work with your card. I previously expect that this id related only for SoC version, but SoC version don't have many things that PCI version have (MCU, EEPROM, etc.) Hi, I have 0x28720200 calling rt2872_rf_set_chan() instead of rt2860_rf_set_chan(). And, 0x2000 for initial RT2860_REG_MAX_LEN value in rt2860_init_locked(). If these are correct I can patch the driver up. Basic problem here is a usage external EEPROM data(instead read from real EEPROM) and direct BBP control(instead use MCU). So currently prefer to use Alexander Egorenkov version, until we done porting OpenBSD one and join it with ral(4) code. AK -- Alexandr Rybalko r...@dlink.ua aka Alex RAY r...@ddteam.net ___ 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: schedcpu() in /sys/kern/sched_4bsd.c calls thread_lock() on thread with un-initialized td_lock
Here is a larger patch:
Index: kern/kern_ktrace.c
===
--- kern/kern_ktrace.c (revision 220190)
+++ kern/kern_ktrace.c (working copy)
@@ -882,7 +882,8 @@
nfound = 0;
LIST_FOREACH(p, pg-pg_members, p_pglist) {
PROC_LOCK(p);
- if (p_cansee(td, p) != 0) {
+ if (p-p_state == PRS_NEW ||
+ p_cansee(td, p) != 0) {
PROC_UNLOCK(p);
continue;
}
Index: kern/kern_sig.c
===
--- kern/kern_sig.c (revision 220190)
+++ kern/kern_sig.c (working copy)
@@ -1799,7 +1799,8 @@
PGRP_LOCK_ASSERT(pgrp, MA_OWNED);
LIST_FOREACH(p, pgrp-pg_members, p_pglist) {
PROC_LOCK(p);
- if (checkctty == 0 || p-p_flag P_CONTROLT)
+ if (p-p_state == PRS_NORMAL
+ (checkctty == 0 || p-p_flag P_CONTROLT))
pksignal(p, sig, ksi);
PROC_UNLOCK(p);
}
@@ -3313,7 +3314,8 @@
PGRP_LOCK(sigio-sio_pgrp);
LIST_FOREACH(p, sigio-sio_pgrp-pg_members, p_pglist) {
PROC_LOCK(p);
- if (CANSIGIO(sigio-sio_ucred, p-p_ucred)
+ if (p-p_state == PRS_NORMAL
+ CANSIGIO(sigio-sio_ucred, p-p_ucred)
(checkctty == 0 || (p-p_flag P_CONTROLT)))
psignal(p, sig);
PROC_UNLOCK(p);
Index: kern/kern_clock.c
===
--- kern/kern_clock.c (revision 220190)
+++ kern/kern_clock.c (working copy)
@@ -201,6 +201,10 @@
tryl = 0;
FOREACH_PROC_IN_SYSTEM(p) {
PROC_LOCK(p);
+ if (p-p_state == PRS_NEW) {
+ PROC_UNLOCK(p);
+ continue;
+ }
FOREACH_THREAD_IN_PROC(p, td) {
/*
Index: kern/sched_4bsd.c
===
--- kern/sched_4bsd.c (revision 220190)
+++ kern/sched_4bsd.c (working copy)
@@ -463,6 +463,10 @@
sx_slock(allproc_lock);
FOREACH_PROC_IN_SYSTEM(p) {
PROC_LOCK(p);
+ if (p-p_state == PRS_NEW) {
+ PROC_UNLOCK(p);
+ continue;
+ }
FOREACH_THREAD_IN_PROC(p, td) {
awake = 0;
thread_lock(td);
Index: kern/kern_resource.c
===
--- kern/kern_resource.c (revision 220190)
+++ kern/kern_resource.c (working copy)
@@ -129,7 +129,8 @@
sx_sunlock(proctree_lock);
LIST_FOREACH(p, pg-pg_members, p_pglist) {
PROC_LOCK(p);
- if (p_cansee(td, p) == 0) {
+ if (p-p_state == PRS_NORMAL
+ p_cansee(td, p) == 0) {
if (p-p_nice low)
low = p-p_nice;
}
@@ -215,7 +216,8 @@
sx_sunlock(proctree_lock);
LIST_FOREACH(p, pg-pg_members, p_pglist) {
PROC_LOCK(p);
- if (p_cansee(td, p) == 0) {
+ if (p-p_state == PRS_NORMAL
+ p_cansee(td, p) == 0) {
error = donice(td, p, uap-prio);
found++;
}
@@ -230,7 +232,8 @@
sx_slock(allproc_lock);
FOREACH_PROC_IN_SYSTEM(p) {
PROC_LOCK(p);
- if (p-p_ucred-cr_uid == uap-who
+ if (p-p_state == PRS_NORMAL
+ p-p_ucred-cr_uid == uap-who
p_cansee(td, p) == 0) {
error = donice(td, p, uap-prio);
found++;
Index: vm/vm_glue.c
===
--- vm/vm_glue.c (revision 220190)
+++ vm/vm_glue.c (working copy)
@@ -730,7 +730,8 @@
sx_slock(allproc_lock);
FOREACH_PROC_IN_SYSTEM(p) {
PROC_LOCK(p);
- if (p-p_flag (P_SWAPPINGOUT | P_SWAPPINGIN | P_INMEM)) {
+ if (p-p_state == PRS_NEW ||
+ p-p_flag (P_SWAPPINGOUT | P_SWAPPINGIN | P_INMEM))
Re: Any success stories for HAST + ZFS?
Yes, you may hit it only on hast devices creation. The workaround is to avoid using 'hastctl role primary all', start providers one by one instead. Interesting to note that I just hit a lockup in hast (the discs froze up - could not run hastctl or zpool import, and could not kill them). I have two hast devices instead of one, but I am starting them individually instead of using 'all'. The copde includes all the latest patches which have gone into STABLE over the last few days, none of which look particularly controversial! I havent tried your atch yet, nor been able to reporduce the lockup, but thought you might be interested to know that I also had problems with multiple providers. cheers, -pete. ___ 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: issue with devstat_buildmatch(3) and certain strings
On 1 April 2011 01:03, Alexander Best arun...@freebsd.org wrote:
hi there,
devstat_buildmatch(3) crashes with certain strings. you can test this by
doing one of:
iostat -t ,
iostat -t ,,
iostat -t da,
iostat -t ,da,
iostat -t ,da
iostat -t da,scsi,
iostat -t ,da,scsi
iostat -t da,,scsi
[Someone told me, -hackers isn't appropriate for patches, Cc: -current.]
The problem is devstat(3) increments num_args regardless if strsep
returned NULL.
I think that should work (all your tests pass):
Index: lib/libdevstat/devstat.c
===
--- lib/libdevstat/devstat.c(revision 220102)
+++ lib/libdevstat/devstat.c(working copy)
@@ -1014,11 +1014,12 @@
* Break the (comma delimited) input string out into separate strings.
*/
for (tempstr = tstr, num_args = 0;
-(*tempstr = strsep(match_str, ,)) != NULL (num_args 5);
-num_args++)
- if (**tempstr != '\0')
+(*tempstr = strsep(match_str, ,)) != NULL (num_args 5); )
+ if (**tempstr != '\0') {
+ num_args++;
if (++tempstr = tstr[5])
break;
+ }
/* The user gave us too many type arguments */
if (num_args 3) {
Please review, and I will commit the patch.
--
wbr,
pluknet
___
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: issue with devstat_buildmatch(3) and certain strings
On 1 April 2011 15:37, Sergey Kandaurov pluk...@freebsd.org wrote:
On 1 April 2011 01:03, Alexander Best arun...@freebsd.org wrote:
hi there,
devstat_buildmatch(3) crashes with certain strings. you can test this by
doing one of:
iostat -t ,
iostat -t ,,
iostat -t da,
iostat -t ,da,
iostat -t ,da
iostat -t da,scsi,
iostat -t ,da,scsi
iostat -t da,,scsi
[Someone told me, -hackers isn't appropriate for patches, Cc: -current.]
The problem is devstat(3) increments num_args regardless if strsep
returned NULL.
I think that should work (all your tests pass):
Index: lib/libdevstat/devstat.c
===
--- lib/libdevstat/devstat.c (revision 220102)
+++ lib/libdevstat/devstat.c (working copy)
@@ -1014,11 +1014,12 @@
* Break the (comma delimited) input string out into separate strings.
*/
for (tempstr = tstr, num_args = 0;
- (*tempstr = strsep(match_str, ,)) != NULL (num_args 5);
- num_args++)
- if (**tempstr != '\0')
+ (*tempstr = strsep(match_str, ,)) != NULL (num_args 5); )
+ if (**tempstr != '\0') {
+ num_args++;
if (++tempstr = tstr[5])
BTW,
this game with pointers might prevent devstat(3) from work on big-endian.
break;
+ }
/* The user gave us too many type arguments */
if (num_args 3) {
Please review, and I will commit the patch.
--
wbr,
pluknet
___
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: issue with devstat_buildmatch(3) and certain strings
On Fri Apr 1 11, Sergey Kandaurov wrote:
On 1 April 2011 01:03, Alexander Best arun...@freebsd.org wrote:
hi there,
devstat_buildmatch(3) crashes with certain strings. you can test this by
doing one of:
iostat -t ,
iostat -t ,,
iostat -t da,
iostat -t ,da,
iostat -t ,da
iostat -t da,scsi,
iostat -t ,da,scsi
iostat -t da,,scsi
[Someone told me, -hackers isn't appropriate for patches, Cc: -current.]
The problem is devstat(3) increments num_args regardless if strsep
returned NULL.
I think that should work (all your tests pass):
Index: lib/libdevstat/devstat.c
===
--- lib/libdevstat/devstat.c(revision 220102)
+++ lib/libdevstat/devstat.c(working copy)
@@ -1014,11 +1014,12 @@
* Break the (comma delimited) input string out into separate strings.
*/
for (tempstr = tstr, num_args = 0;
-(*tempstr = strsep(match_str, ,)) != NULL (num_args 5);
-num_args++)
- if (**tempstr != '\0')
+(*tempstr = strsep(match_str, ,)) != NULL (num_args 5); )
^^
extra space?
+ if (**tempstr != '\0') {
+ num_args++;
if (++tempstr = tstr[5])
break;
+ }
/* The user gave us too many type arguments */
if (num_args 3) {
Please review, and I will commit the patch.
looking good. thanks. :)
--
wbr,
pluknet
--
a13x
___
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: bsdinstaller / partedit emacs key patch
On 03/31/11 22:39, Daniel O'Connor wrote: On 01/04/2011, at 5:09, Nathan Whitehorn wrote: On 03/29/11 20:50, Daniel O'Connor wrote: Hi, I noticed that the entry widgets in the bsdinstaller label editor don't understand various emacs keys (eg C-a, C-d, C-e). Here's a patch which adds the basics.. Unfortunately dialog doesn't have a key for delete all, delete left or delete right so I couldn't add C-u, C-w or C-k. Note that you can't just call dlg_parse_bindkey(* ^a BEGIN) because dialog modifies the string which crashes (seg fault). I'm happy to put this in, but it would be nice if you could try to get this into upstream dialog to avoid inconsistencies in various parts of the installation. I suspect it would be pretty bikeshed prone :( Is there a dialog mailing list? My google-fu failed and I can't find one. I suppose the alternative is to install a global rc file (ie /etc/dialogrc) with the following contents.. bindkey * ^a BEGIN bindkey * ^d DELETE_RIGHT bindkey * ^e FINAL Here's the website: http://invisible-island.net/dialog/dialog.html The nearest thing to a mailing list is the ncurses one, but I'd suggest just emailing the author. -Nathan ___ 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: Any success stories for HAST + ZFS?
On Fri, 01 Apr 2011 11:40:11 +0100 Pete French wrote: Yes, you may hit it only on hast devices creation. The workaround is to avoid using 'hastctl role primary all', start providers one by one instead. PF Interesting to note that I just hit a lockup in hast (the discs froze PF up - could not run hastctl or zpool import, and could not kill PF them). I have two hast devices instead of one, but I am starting them PF individually instead of using 'all'. The copde includes all the latest PF patches which have gone into STABLE over the last few days, none of which PF look particularly controversial! PF I havent tried your atch yet, nor been able to reporduce the lockup, but PF thought you might be interested to know that I also had problems with PF multiple providers. This looks like a different problem. If you have this again please provide the output of 'procstat -kka'. -- Mikolaj Golub ___ 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: multiple issues with devstat_*(9)
On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote:
hi there,
i think there are multiple issues with devstat. i found the following in
devicestat.h:
/*
* These types are intended to aid statistics gathering/display programs.
* The first 13 types (up to the 'target' flag) are identical numerically
* to the SCSI device type numbers. The next 3 types designate the device
* interface. Currently the choices are IDE, SCSI, and 'other'. The last
* flag specifies whether or not the given device is a passthrough device
* or not. If it is a passthrough device, the lower 4 bits specify which
* type of physical device lies under the passthrough device, and the next
* 4 bits specify the interface.
*/
typedef enum {
DEVSTAT_TYPE_DIRECT = 0x000,
DEVSTAT_TYPE_SEQUENTIAL = 0x001,
DEVSTAT_TYPE_PRINTER= 0x002,
DEVSTAT_TYPE_PROCESSOR = 0x003,
DEVSTAT_TYPE_WORM = 0x004,
DEVSTAT_TYPE_CDROM = 0x005,
DEVSTAT_TYPE_SCANNER= 0x006,
DEVSTAT_TYPE_OPTICAL= 0x007,
DEVSTAT_TYPE_CHANGER= 0x008,
DEVSTAT_TYPE_COMM = 0x009,
DEVSTAT_TYPE_ASC0 = 0x00a,
DEVSTAT_TYPE_ASC1 = 0x00b,
DEVSTAT_TYPE_STORARRAY = 0x00c,
DEVSTAT_TYPE_ENCLOSURE = 0x00d,
DEVSTAT_TYPE_FLOPPY = 0x00e,
DEVSTAT_TYPE_MASK = 0x00f,
DEVSTAT_TYPE_IF_SCSI= 0x010,
DEVSTAT_TYPE_IF_IDE = 0x020,
DEVSTAT_TYPE_IF_OTHER = 0x030,
DEVSTAT_TYPE_IF_MASK= 0x0f0,
DEVSTAT_TYPE_PASS = 0x100
} devstat_type_flags;
also the devstat(9) man page says:
Each device is given a device type. Pass-through devices have the same
underlying device type and interface as the device they provide an inter-
face for, but they also have the pass-through flag set. The base device
types are identical to the SCSI device type numbers, so with SCSI periph-
erals, the device type returned from an inquiry is usually ORed with the
SCSI interface type and the pass-through flag if appropriate. The device
type flags are as follows:
...so let's get started:
otaku% iostat -n100
ttyada0 ada1 md0 cd0
pass0pass1pass2 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s
KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
192 21.18 0 0.01 24.37 12 0.29 0.00 0 0.00 60.27 0 0.01
0.37 0 0.00 0.37 0 0.00 0.00 0 0.00 5 0 4 0 90
..so far so good
otaku% iostat -t da
ttyada0 ada1 md0 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
192 21.18 0 0.01 24.37 12 0.29 0.00 0 0.00 5 0 4 0 90
...not good! this should include two pass devices!
This is probably due to the hard drives being IDE (really ATA) rather than
SCSI. I agree this should show the pass devices.
otaku% iostat -t scsi
tty cd0 cpu
tin tout KB/t tps MB/s us ni sy in id
192 60.27 0 0.01 5 0 4 0 90
..what?
If cd0 is an ATAPI CD-ROM drive, then this shouldn't even show cd0 as all of
your devices are IDE/ATA, not SCSI.
otaku% iostat -t ide
ttycpu
tin tout us ni sy in id
192 5 0 4 0 90
otaku% iostat -t other
ttycpu
tin tout us ni sy in id
192 5 0 4 0 90
...what about md0? ada0? ada1? md0?
md0 is a memory disk, it is neither SCSI nor IDE. However, -t ide (or even
better, a -t ata), should show all of your other devices (adaX and cd0) along
with their passX devices I think.
otaku% iostat -t cd0
tty cd0 cpu
tin tout KB/t tps MB/s us ni sy in id
192 60.27 0 0.01 5 0 4 0 90
...this should also include a pass device
Agreed.
otaku% iostat -t pass
tty pass0pass1pass2 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
192 0.37 0 0.00 0.37 0 0.00 0.00 0 0.00 5 0 4 0 90
...this one's working as expected.
funny thing is i found the following in scsi_pass.c:
softc-device_stats = devstat_new_entry(pass,
periph-unit_number, 0,
DEVSTAT_NO_BLOCKSIZE
| (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0),
softc-pd_type |
DEVSTAT_TYPE_IF_SCSI |
DEVSTAT_TYPE_PASS,
DEVSTAT_PRIORITY_PASS);
...so pass* *should* show up under iostat -t scsi.
Hmm, pass devices for adaX should not be SCSI though, they should be ide I
think.
--
Re: Any success stories for HAST + ZFS?
The other 5% of the time, the hastd crashes occurred either when importing the ZFS pool, or when running multiple parallel rsyncs to the pool. hastd was always shown as the last running process in the backtrace onscreen. This is what I am seeing - did you manage to reproduce this with the patch, or does it fix the issue for you ? Am doing more test now, with only a single hast device to see if it is stable. Am Ok to run without mirroring across hast devices for now, but wouldnt like to do so long term! -pete. ___ 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: Any success stories for HAST + ZFS?
This looks like a different problem. If you have this again please provide the output of 'procstat -kka'. Will do... -pete. ___ 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: Any success stories for HAST + ZFS?
On Fri, Apr 1, 2011 at 4:22 AM, Pete French petefre...@ingresso.co.uk wrote: The other 5% of the time, the hastd crashes occurred either when importing the ZFS pool, or when running multiple parallel rsyncs to the pool. hastd was always shown as the last running process in the backtrace onscreen. This is what I am seeing - did you manage to reproduce this with the patch, or does it fix the issue for you ? Am doing more test now, with only a single hast device to see if it is stable. Am Ok to run without mirroring across hast devices for now, but wouldnt like to do so long term! I have not been able to crash or hang the box since applying Mikolaj's patch. I've tried the following: - destroy pool - create pool - destroy hast providers - create hast providers - switch from master to slave via hastctl using role secondary all - switch from slave to master via hastctl using role primary all - switch roles via hast-carp-switch which does one provider per second - import/export pool I've been running 6 parallel rsyncs for the past 48 hours, getting a consistent 200 Mbps of transfers, with just under 2 TB of deduped data in the pool, without any lockups. So far, so good. -- Freddie Cash fjwc...@gmail.com ___ 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: issue with devstat_buildmatch(3) and certain strings
On Apr 1, 2011, at 5:40 AM, Sergey Kandaurov wrote: if (++tempstr = tstr[5]) BTW, this game with pointers might prevent devstat(3) from work on big-endian. I'm very curious about your reasoning here. Warner ___ 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: issue with devstat_buildmatch(3) and certain strings
On 1 April 2011 18:50, Warner Losh i...@bsdimp.com wrote: On Apr 1, 2011, at 5:40 AM, Sergey Kandaurov wrote: if (++tempstr = tstr[5]) BTW, this game with pointers might prevent devstat(3) from work on big-endian. I'm very curious about your reasoning here. Warner I meant the above comparison of pointers might not work (I'm not sure, as I have no big-endian to test). Look: # iostat -t da,scsi,pass tempstr=0x7fffcfa0, tstr[5]=0x7fffcfc8 tempstr=0x7fffcfa8, tstr[5]=0x7fffcfc8 tempstr=0x7fffcfb0, tstr[5]=0x7fffcfc8 D'oh.. endianness doesn't matter with arrays *blush (Unless that's some system with decreasing memory addressing. Ok, nevermind.) -- wbr, pluknet ___ 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: Could /etc/rc.d/routing require bridge?
On Fri, Mar 25, 2011 at 03:41:53PM +0300, Alexander Pyhalov wrote: Hello. I'm just implementing the following network scheme on our freebsd hosts: 1) physical interface 2) for each vlanN on physical interface I create bridgeN and connect interface to the bridge 3) for each vnet jail which need access to vlanN I create epair and connect it to bridgeN 4) for real host I use the same scheme: I create epair and connect it to the bridge with necessary vlan. I have the following problem: routing is started before bridge creation, so in default configuration host is inaccessible. If I modify /etc/rc.d/routing script so that it requires bridge, everything is fine (I can reach my host). So what is a reason for /etc/rc.d/routing to miss dependency on bridge? It makes sense to me that routing woul depend on bridge. After all, it doesn't make much sense to configure routing until you have all your interfaces. -- Brooks pgpiVD7jlyv2n.pgp Description: PGP signature
Re: schedcpu() in /sys/kern/sched_4bsd.c calls thread_lock() on thread with un-initialized td_lock
On 3/31/11 2:31 PM, John Baldwin wrote: On Thursday, March 31, 2011 4:54:53 pm Julian Elischer wrote: http://svn.freebsd.org/viewvc/base/head/sys/kern/kern_fork.c?annotate=83366 FreeBSD has always used this process to find a free PID. SVN and CVS history does not lie. yep it's possible I'm remembering a change that never made it in... ___ 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
