Re: gptzfsboot error using HP Smart Array P410i Controller
on 13/10/2011 00:33 Christoph Hoffmann said the following: Hello Daniel, Last time I checked up on the issue was on the 23rd of September, it was not fixed then. I was able to to boot from drive 0x80 after adding: *** zfsboot.c.origFri Sep 23 18:03:26 2011 --- zfsboot.c Fri Sep 23 18:47:44 2011 *** *** 459,464 --- 459,465 heap_end = (char *) PTOV(bios_basemem); } + printf(Hello! I am a hack.\n); dsk = malloc(sizeof(struct dsk)); dsk-drive = *(uint8_t *)PTOV(ARGS); dsk-type = dsk-drive DRV_HARD ? TYPE_AD : TYPE_FD; I am inclined to think that this is related to the way how we compile this code, especially when run on the following particular processor: 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is enabled Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz QPI Speed: 5.8 GT/s. Can you try the latest code in head? I've removed all the optimization/pessimization compiler flags for gpt/zfs boot blocks that at times seemed to do more harm than good. -- 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: iwn panic with 9.0-BETA3-amd64
On Friday 07 October 2011 16:18:47 Niclas Zeising wrote: This might or might not be related, but, I'm having trouble with the iwn firmware crashing. I also have a clang built kernel (and userland) buildwith CPUTYPE=core2. My iwn device is iwn0: Intel(R) Wireless WiFi Link 4965 mem 0xe400-0xe4001fff irq 17 at device 0.0 on pci16 and the firmware gives the following output when it dies. iwn0: iwn_intr: fatal firmware error firmware error log: error type = NMI_INTERRUPT_WDG (0x0004) program counter = 0x046C source line = 0x00D0 This is a known issue with the 4965's firmware. I have yet to find a reliable solution for that.. As a workaround you can disable background scan with ifconfig wlan0 -bgscan The only way to restore the firmware is to reboot the computer. No need to reboot, killing the VAP and recreating it should get you going again. -- Bernhard ___ 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: gptzfsboot error using HP Smart Array P410i Controller
On 13.10.11 00:33, Christoph Hoffmann wrote: I am inclined to think that this is related to the way how we compile this code, especially when run on the following particular processor: 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is enabled Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz QPI Speed: 5.8 GT/s. For me, this happens on CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.10-MHz K8-class CPU) On HP DL360 G7 I try to boot -stable. Daniel ___ 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: BTX halted when booting 9.0-BETA3 (Root On ZFS)
On 2011-Oct-12 16:59:21 +0200, Jean-Sébastien Pédron jean-sebastien.ped...@dumbbell.fr wrote: For a couple of days now, I can't boot FreeBSD 9-BETA3 on my laptop. ... I built world from SVN revision 226141. But now, kernel, zfsboot and zfsloader are those from 9.0-BETA3's DVD1. The zpool is version 28 and the zfs filesystems are version 5. r226141 is head. Did you build a 10-current or RELENG_9 world? It all started when I copied a directory containing around 3.5GB of JPEG images, while building world (I can't remember if the build was finished, maybe it was waiting for install). This was quite slow (but I can't give you numbers). When I then ran make installkernel, I found it to be really slow two (maybe 1-2 seconds per module). I continued with installworld in single user, then rebooted. How full is your zpool? Has it ever been quite full (~90%)? What I tried so far: o reinstall zfsboot from 9.0-BETA3 I presume you mean dd'ing it into the front of boot slice. o restore zfsloader.old What is zfsloader.old at this point? The one from r226141? o zfs scrub (no error) This means your pool is OK and you've run afoul of limitations in zfsboot. I suspect you have two options: 1) Do a send|recv to rebuild your root pool. 2) Build (and install) a new zfsboot with the patches mentioned in http://lists.freebsd.org/pipermail/freebsd-fs/2011-September/012448.html I thought those patches had been committed but it seems they haven't been. -- Peter Jeremy pgp3YvBtbE9Dl.pgp Description: PGP signature
9.x installer and GPT vs geom
Hello all. I just used the 9.0 B3 installer, and it defaults to GPT, which is nice. However, and there has been some discussions about it, it would be nice if the installer warns me that i could get in trouble if i want to use gmirror and the like. Also i find it a little strange that the default mode, GPT in this case is in some sort not compatible with the other default geom structure. For a newcomer or for people who use gmirror and glabel on a regular basis because there somewhat default, it could strike them if they start using the default GPT. It is not logical. Two default ways to do things that are in a way not compatible. So a warning at the installer level could make a lot of users aware of this, and they can decide what to do, use GPT or go back to the old MBR. They can start looking at the mailling list and so on to make the right decision is GPT acceptable for me or not. And not install FreeBSD and find out later that you could not use your old gmirror and glabel tactics without corrupting the GPT structure. Just my thoughts about this. regards, Johan Hendriks ___ 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: 9.x installer and GPT vs geom
On 10/13/11 10:39, Johan Hendriks wrote: Hello all. I just used the 9.0 B3 installer, and it defaults to GPT, which is nice. However, and there has been some discussions about it, it would be nice if the installer warns me that i could get in trouble if i want to use gmirror and the like. Also i find it a little strange that the default mode, GPT in this case is in some sort not compatible with the other default geom structure. For a newcomer or for people who use gmirror and glabel on a regular basis because there somewhat default, it could strike them if they start using the default GPT. It is not logical. Two default ways to do things that are in a way not compatible. So a warning at the installer level could make a lot of users aware of this, and they can decide what to do, use GPT or go back to the old MBR. They can start looking at the mailling list and so on to make the right decision is GPT acceptable for me or not. And not install FreeBSD and find out later that you could not use your old gmirror and glabel tactics without corrupting the GPT structure. Just my thoughts about this. regards, Johan Hendriks Shouldn't be there also a warning that GPT can not be used with the FreeBSD native bootselector? I had trouble installing FreeBSD 9.0-CURRENT a while ago with default being GPT on my notebook and also wanting a Windows 7/x64 for presentations, selectable via the FreeBSD bootselector. This was possible with MBR, but it seems gone with GPT. Regards, Oliver ___ 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
incorrect use of pidfile(3)
I looked at some of the programs that use pidfile(3) in base, and they pretty much all get it wrong. Consider these two scenarios: 1) common case process A process B main() pidfile_open() - success perform_initialization() daemon() pidfile_write() - success perform_work() main() pidfile_open() - EEXIST exit() 2) very unlikely but still possible case process A process B main() pidfile_open() - success main() perform_initialization()pidfile_open() - EAGAIN daemon()perform_initialization() pidfile_write() - successdaemon() perform_work() perform_work() The problem is that most of them (at least the ones I checked) ignore a pidfile_open() failure unless errno == EEXIST. How do we fix this? My suggestion is to loop until pidfile_open() succeeds or errno != EAGAIN. Does anyone have any objections to that approach? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: 9 hangs with idletick = 0
Dag-Erling Smørgrav d...@des.no writes: I've just built a kernel with KTR support, and with KTR_SPARE2, KTR_INTR and KTR_SCHED enabled by default. I'll see what turns up. I'm also going to try machdep.idle=hlt with kern.eventtimer.idletick=0, and using a PCI re(4) instead of the on-board msk(4) while running with default settings. Great, the bug does not occur when KTR is enabled. The machine has been up for 14+ hours without crashing, despite plenty of network activity, which usually triggers a freeze within minutes. It looks like there may still be short freezes (a few seconds at a time). I'm thinking of instrumenting fetch(1) to record any instances of fread() taking more than, say, half a second. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: incorrect use of pidfile(3)
On Thu, Oct 13, 2011 at 12:54:38PM +0200, Dag-Erling Smørgrav wrote: I looked at some of the programs that use pidfile(3) in base, and they pretty much all get it wrong. Consider these two scenarios: 1) common case process A process B main() pidfile_open() - success perform_initialization() daemon() pidfile_write() - success perform_work() main() pidfile_open() - EEXIST exit() 2) very unlikely but still possible case process A process B main() pidfile_open() - success main() perform_initialization()pidfile_open() - EAGAIN daemon()perform_initialization() pidfile_write() - successdaemon() perform_work() perform_work() The problem is that most of them (at least the ones I checked) ignore a pidfile_open() failure unless errno == EEXIST. How do we fix this? My suggestion is to loop until pidfile_open() succeeds or errno != EAGAIN. Does anyone have any objections to that approach? I think we already do that internally in pidfile_open(). Can you take a look at the source and confirm that this is what you mean? -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgp8t7uJHg24p.pgp Description: PGP signature
Re: incorrect use of pidfile(3)
Pawel Jakub Dawidek p...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no writes:
How do we fix this? My suggestion is to loop until pidfile_open()
succeeds or errno != EAGAIN. Does anyone have any objections to that
approach?
I think we already do that internally in pidfile_open(). Can you take a look
at
the source and confirm that this is what you mean?
No, it doesn't; pidfile_open(3) returns NULL with errno == EAGAIN if the
pidfile is locked but empty, as is the case in the window between a
successful pidfile_open(3) and the first pidfile_write(3). This is
documented in the man page:
[EAGAIN] Some process already holds the lock on the given pid‐
file, but the file is truncated. Most likely, the
existing daemon is writing new PID into the file.
I have a patch that adds a pidfile to dhclient(8), where I do this:
for (;;) {
pidfile = pidfile_open(path_dhclient_pidfile, 0600, otherpid);
if (pidfile != NULL || errno != EAGAIN)
break;
sleep(1);
}
if (pidfile == NULL) {
if (errno == EEXIST)
error(dhclient already running, pid: %d., otherpid);
warning(Cannot open or create pidfile: %m);
}
I'm not sure I agree with the common idiom (which I copied here) of
ignoring all other errors than EEXIST, but that's a different story.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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: 9 hangs with idletick = 0
In message 86lispaztm@ds4.des.no, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: Dag-Erling Sm=C3=B8rgrav d...@des.no writes: I've just built a kernel with KTR support, and with KTR_SPARE2, KTR_INTR and KTR_SCHED enabled by default. I'll see what turns up. I'm also going to try machdep.idle=3Dhlt with kern.eventtimer.idletick=3D0, and us= ing a PCI re(4) instead of the on-board msk(4) while running with default settings. Great, the bug does not occur when KTR is enabled. The machine has been up for 14+ hours without crashing, despite plenty of network activity, which usually triggers a freeze within minutes. For what it's worth, I regularly (=every 10-12 days or so) see all timer activity in the system die and have to use the 4-sec power-switch to get the system down. This is on: FreeBSD critter.freebsd.dk 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r224239M: Fri Aug 19 14:35:16 UTC 2011 p...@critter.freebsd.dk:/sys/amd64/compile/CRITTER amd64 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: incorrect use of pidfile(3)
2011/10/13 Dag-Erling Smørgrav d...@des.no:
Pawel Jakub Dawidek p...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no writes:
How do we fix this? My suggestion is to loop until pidfile_open()
succeeds or errno != EAGAIN. Does anyone have any objections to that
approach?
I think we already do that internally in pidfile_open(). Can you take a look
at
the source and confirm that this is what you mean?
No, it doesn't; pidfile_open(3) returns NULL with errno == EAGAIN if the
pidfile is locked but empty, as is the case in the window between a
successful pidfile_open(3) and the first pidfile_write(3). This is
documented in the man page:
[EAGAIN] Some process already holds the lock on the given pid‐
file, but the file is truncated. Most likely, the
existing daemon is writing new PID into the file.
I have a patch that adds a pidfile to dhclient(8), where I do this:
for (;;) {
pidfile = pidfile_open(path_dhclient_pidfile, 0600, otherpid);
if (pidfile != NULL || errno != EAGAIN)
break;
sleep(1);
}
if (pidfile == NULL) {
if (errno == EEXIST)
error(dhclient already running, pid: %d., otherpid);
warning(Cannot open or create pidfile: %m);
}
I'm not sure I agree with the common idiom (which I copied here) of
ignoring all other errors than EEXIST, but that's a different story.
You are also ignoring the return value of sleep(1), which would tell
you if the call was interrupted by a signal handler. This can be fine
for dhclient(8) but other utilities might require some guards against
such interruptions.
--
The flames are all long gone, but the pain lingers on
___
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: incorrect use of pidfile(3)
After discussing this with pjd@ on IRC, I arrived at the attached patch,
which increases the length of time pidfile_open() itself waits (I hadn't
noticed that it already looped) and sets *pidptr to -1 if it fails to read
a pid.
DES
--
Dag-Erling Smørgrav - d...@des.no
Index: lib/libutil/pidfile.c
===
--- lib/libutil/pidfile.c (revision 226271)
+++ lib/libutil/pidfile.c (working copy)
@@ -118,22 +118,19 @@
*/
fd = flopen(pfh-pf_path,
O_WRONLY | O_CREAT | O_TRUNC | O_NONBLOCK, mode);
- if (fd == -1) {
- count = 0;
+ if (fd == -1 errno == EWOULDBLOCK pidptr != NULL) {
+ *pidptr = -1;
+ count = 20;
rqtp.tv_sec = 0;
rqtp.tv_nsec = 500;
- if (errno == EWOULDBLOCK pidptr != NULL) {
- again:
+ for (;;) {
errno = pidfile_read(pfh-pf_path, pidptr);
- if (errno == 0)
-errno = EEXIST;
- else if (errno == EAGAIN) {
-if (++count = 3) {
- nanosleep(rqtp, 0);
- goto again;
-}
- }
+ if (errno != EAGAIN || --count == 0)
+break;
+ nanosleep(rqtp, 0);
}
+ if (errno == 0)
+ errno = EEXIST;
free(pfh);
return (NULL);
}
___
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: 9.x installer and GPT vs geom
On 10/13/11 04:25, O. Hartmann wrote: On 10/13/11 10:39, Johan Hendriks wrote: Hello all. I just used the 9.0 B3 installer, and it defaults to GPT, which is nice. However, and there has been some discussions about it, it would be nice if the installer warns me that i could get in trouble if i want to use gmirror and the like. Also i find it a little strange that the default mode, GPT in this case is in some sort not compatible with the other default geom structure. For a newcomer or for people who use gmirror and glabel on a regular basis because there somewhat default, it could strike them if they start using the default GPT. It is not logical. Two default ways to do things that are in a way not compatible. So a warning at the installer level could make a lot of users aware of this, and they can decide what to do, use GPT or go back to the old MBR. They can start looking at the mailling list and so on to make the right decision is GPT acceptable for me or not. And not install FreeBSD and find out later that you could not use your old gmirror and glabel tactics without corrupting the GPT structure. Just my thoughts about this. regards, Johan Hendriks Shouldn't be there also a warning that GPT can not be used with the FreeBSD native bootselector? I had trouble installing FreeBSD 9.0-CURRENT a while ago with default being GPT on my notebook and also wanting a Windows 7/x64 for presentations, selectable via the FreeBSD bootselector. This was possible with MBR, but it seems gone with GPT. If you install onto an already MBR-formatted disk (say, you're dual-booting), it will use MBR as the default, not GPT. It only uses GPT as the default if you (a) put in a totally blank disk or (b) say you want to dedicate the disk entirely to FreeBSD. -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: BTX halted when booting 9.0-BETA3 (Root On ZFS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13.10.2011 11:03, Peter Jeremy wrote: I built world from SVN revision 226141. (...) r226141 is head. Did you build a 10-current or RELENG_9 world? I built stable/9. Sorry, the revision I mention is wrong because I have one checkout of /base/ (with head/ and stable/9 inside). I always run svn update from this directory, so when I do svn info in stable/9, it indicates the last revision for the entire checkout, which as in head as you pointed out. I checked with svn log and the last revision is 226115. Sorry for the mistake. How full is your zpool? Has it ever been quite full (~90%)? Yes, it's pretty full right now ( 95%). What I tried so far: o reinstall zfsboot from 9.0-BETA3 I presume you mean dd'ing it into the front of boot slice. Yes, as described in the RootOnZFS guide. What is zfsloader.old at this point? The one from r226141? Now, I have zfsboot and zfsloader from 9.0-BETA3's DVD1. The problem is the same with the one from r226115. I suspect you have two options: 1) Do a send|recv to rebuild your root pool. 2) Build (and install) a new zfsboot with the patches mentioned in http://lists.freebsd.org/pipermail/freebsd-fs/2011-September/012448.html I thought those patches had been committed but it seems they haven't been. I tried this patch but it doesn't fix the problem. Andriy suggested me to try tools/tools/zfsboottest and this tool reads the files properly. Peter, I'll try to send/recv as soon as I have access to a storage with enough space. Thank you for your help! - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6W6c0ACgkQa+xGJsFYOlMLOACguADWl0oTovV2S8Io5evSQ0EX JNoAoMyoWtmHpEiLcTAQUkxWGZy/KQhb =3BKE -END PGP SIGNATURE- ___ 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: incorrect use of pidfile(3)
On Thu, Oct 13, 2011 at 02:54:16PM +0200, Dag-Erling Smørgrav wrote:
After discussing this with pjd@ on IRC, I arrived at the attached patch,
which increases the length of time pidfile_open() itself waits (I hadn't
noticed that it already looped) and sets *pidptr to -1 if it fails to read
a pid.
I'm still in opinion that EWOULDBLOCK and EAGAIN (which is the same
value on FreeBSD) should be converted to EEXIST on pidfile_open()
return.
Also if we now have for loop, why not to put count in there?
I'm not very happy about touching pidptr in case of error other than
EEXIST. This is not documented, but a bit unexpected anyway.
I'm happy with increasing the timeout.
Index: lib/libutil/pidfile.c
===
--- lib/libutil/pidfile.c (revision 226271)
+++ lib/libutil/pidfile.c (working copy)
@@ -118,22 +118,19 @@
*/
fd = flopen(pfh-pf_path,
O_WRONLY | O_CREAT | O_TRUNC | O_NONBLOCK, mode);
- if (fd == -1) {
- count = 0;
+ if (fd == -1 errno == EWOULDBLOCK pidptr != NULL) {
+ *pidptr = -1;
+ count = 20;
rqtp.tv_sec = 0;
rqtp.tv_nsec = 500;
- if (errno == EWOULDBLOCK pidptr != NULL) {
- again:
+ for (;;) {
errno = pidfile_read(pfh-pf_path, pidptr);
- if (errno == 0)
- errno = EEXIST;
- else if (errno == EAGAIN) {
- if (++count = 3) {
- nanosleep(rqtp, 0);
- goto again;
- }
- }
+ if (errno != EAGAIN || --count == 0)
+ break;
+ nanosleep(rqtp, 0);
}
+ if (errno == 0)
+ errno = EEXIST;
free(pfh);
return (NULL);
}
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com
pgpIlSX6pcKvL.pgp
Description: PGP signature
Re: incorrect use of pidfile(3)
Pawel Jakub Dawidek p...@freebsd.org writes: I'm still in opinion that EWOULDBLOCK and EAGAIN (which is the same value on FreeBSD) should be converted to EEXIST on pidfile_open() return. The historical (and documented) behavior is to return EAGAIN. Also if we now have for loop, why not to put count in there? Because if we do, there will be a nanosleep after the last pidfile_read() attempt. We need to break the loop after pidfile_read() failed but before nanosleep(). I'm not very happy about touching pidptr in case of error other than EEXIST. This is not documented, but a bit unexpected anyway. Well, it was your idea, I just moved it to before the loop :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: 9 hangs with idletick = 0
Poul-Henning Kamp p...@phk.freebsd.dk writes: For what it's worth, I regularly (=every 10-12 days or so) see all timer activity in the system die and have to use the 4-sec power-switch to get the system down. Could you check if network activity (e.g. downloading an ISO) triggers it, and if so, if it goes away when you set the kern.eventtimer.idletick sysctl to 0? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: 9 hangs with idletick = 0
2011/10/13 Dag-Erling Smørgrav d...@des.no: Poul-Henning Kamp p...@phk.freebsd.dk writes: For what it's worth, I regularly (=every 10-12 days or so) see all timer activity in the system die and have to use the 4-sec power-switch to get the system down. Could you check if network activity (e.g. downloading an ISO) triggers it, and if so, if it goes away when you set the kern.eventtimer.idletick sysctl to 0? Don't you mean 'set it to 1' ? adrian ___ 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: 9 hangs with idletick = 0
In message 86lisp9dzn@ds4.des.no, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: Poul-Henning Kamp p...@phk.freebsd.dk writes: For what it's worth, I regularly (=3Devery 10-12 days or so) see all timer activity in the system die and have to use the 4-sec power-switch to get the system down. Could you check if network activity (e.g. downloading an ISO) triggers it, and if so, if it goes away when you set the kern.eventtimer.idletick sysctl to 0? I have never seen any correlation, mostly because I usually don't notice it right away, but only when something like top(1) doesn't update and similar. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
usb related wtf-ness
Here's something from a recentish -head. This is the same behaviour as my beta2/beta3 boxes. This time, however, it's on a MIPS board. It's quite possible this _isn't_ a USB problem but is a scsi or cam layer problem. The root is on /dev/da0, a USB device. usbus0: 480Mbps High Speed USB v2.0 ugen0.1: Atheros at usbus0 uhub0: Atheros EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0 uhub0: 2 ports with 2 removable, self powered ugen0.2: Generic at usbus0 umass0: Generic USB Storage, class 0/0, rev 2.00/94.51, addr 2 on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:da0s1a []... mountroot: waiting for device da0s1a ... da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Generic STORAGE DEVICE 9451 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3902MB (7991296 512 byte sectors: 255H 63S/T 497C) Then, I plug in a second USB storage device: ugen0.3: JMicron at usbus0 umass1: MSC Bulk-Only Transfer on usbus0 umass1: SCSI over Bulk-Only; quirks = 0x umass1:1:1:-1: Attached to scbus1 da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 da1: SAMSUNG HM160HI Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) Then: adrian-home-mips# fdisk load: 0.00 cmd: tcsh 1544 [vnread] 3.47r 0.00u 0.00s 0% 3472k (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 6d 69 d0 0 0 40 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: HARDWARE FAILURE asc:4b,0 (Data phase error) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 6d 69 d0 0 0 40 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Invalidating pack (da0:umass-sim0:0:0:0): oustanding 0 load: 0.00 cmd: tg_vfs_done():da0s1a[READ(offset=3667099648, length=32768)]error = 6 csh 1544 [vnreadvnode_pager_getpages: I/O read error ] 4.37r 0.00u 0.00s 0% 3472k /sbin/fdisk: Input/output error. adrian-home-mips# bsdlabel g_vfs_done():da0s1a[READ(offset=373664, length=32768)]error = 6 vnode_pager_getpages: I/O read error /sbin/bsdlabel: Input/output error. adrian-home-mips# usbdevs usbdevs: Command not found. adrian-home-mips# usbconfig -l g_vfs_done():da0s1a[READ(offset=1594703872, length=16384)]error = 6 vnode_pager_getpages: I/O read error /usr/sbin/usbconfig: Input/output error. .. what the? :) adrian ___ 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: 9.x installer and GPT vs geom
Nathan Whitehorn schreef: On 10/13/11 04:25, O. Hartmann wrote: On 10/13/11 10:39, Johan Hendriks wrote: Hello all. I just used the 9.0 B3 installer, and it defaults to GPT, which is nice. However, and there has been some discussions about it, it would be nice if the installer warns me that i could get in trouble if i want to use gmirror and the like. Also i find it a little strange that the default mode, GPT in this case is in some sort not compatible with the other default geom structure. For a newcomer or for people who use gmirror and glabel on a regular basis because there somewhat default, it could strike them if they start using the default GPT. It is not logical. Two default ways to do things that are in a way not compatible. So a warning at the installer level could make a lot of users aware of this, and they can decide what to do, use GPT or go back to the old MBR. They can start looking at the mailling list and so on to make the right decision is GPT acceptable for me or not. And not install FreeBSD and find out later that you could not use your old gmirror and glabel tactics without corrupting the GPT structure. Just my thoughts about this. regards, Johan Hendriks Shouldn't be there also a warning that GPT can not be used with the FreeBSD native bootselector? I had trouble installing FreeBSD 9.0-CURRENT a while ago with default being GPT on my notebook and also wanting a Windows 7/x64 for presentations, selectable via the FreeBSD bootselector. This was possible with MBR, but it seems gone with GPT. If you install onto an already MBR-formatted disk (say, you're dual-booting), it will use MBR as the default, not GPT. It only uses GPT as the default if you (a) put in a totally blank disk or (b) say you want to dedicate the disk entirely to FreeBSD. -Nathan And that is what most people do, use an entire new disk, and use that whole disk for FreeBSD. Me included, if i install a new server that is the way i do it. I think most people do it that way. If they must install a new server i think the most users will use the defaults the installer gives them. And because there are a lot of people who use gmirror to mirror the whole disk, they get bitten by the GPT vs geom metadata issue. If however the installer warns people, they know things have changed, so they can investigate, and then they will hopefully find the threads regarding GPT, gmirror and glabel, and the problems that could arise. There is a lot on the internet about it already. Forums.freebsd.org included. So a warning (or pointer) is at place as far as i am concerned. regards Johan Hendriks ___ 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: 9 hangs with idletick = 0
Adrian Chadd adr...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: Could you check if network activity (e.g. downloading an ISO) triggers it, and if so, if it goes away when you set the kern.eventtimer.idletick sysctl to 0? Don't you mean 'set it to 1' ? Uh, yes :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
[RFC] Prepend timestamp in msgbuf
From: Arnaud Lacombe lacom...@gmail.com
Hi folks,
There is many case recently when I really wished timestamp were present in the
post-mortem msgbuf. Such situation could be when userland application segfault
potentially triggering a panic/crash, or have information about the time-wise
location of a given message (kernel or userland).
Attached patch is available in the git repository at:
git://github.com/lacombar/freebsd.git master/topic/msgbuf-timestamp
Arnaud Lacombe (3):
msgbuf(4): convert `msg_needsnl' to a bit flag
msgbuf(4): add logic to prepend timestamp on new line
msgbuf(4): add a sysctl to toggle timestamp prepend
sys/kern/subr_msgbuf.c | 53 ---
sys/sys/msgbuf.h |4 ++-
2 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c
index cd9c551..b2f0e1a 100644
--- a/sys/kern/subr_msgbuf.c
+++ b/sys/kern/subr_msgbuf.c
@@ -34,6 +34,7 @@
#include sys/lock.h
#include sys/mutex.h
#include sys/msgbuf.h
+#include sys/sysctl.h
/*
* Maximum number conversion buffer length: uintmax_t in base 2, plus
@@ -47,6 +48,13 @@
static u_int msgbuf_cksum(struct msgbuf *mbp);
/*
+ *
+ */
+static int msgbuf_show_timestamp = 1;
+SYSCTL_INT(_kern, OID_AUTO, msgbuf_show_timestamp, CTLFLAG_RW,
+msgbuf_show_timestamp, 0, Show timestamp in msgbuf);
+
+/*
* Initialize a message buffer of the specified size at the specified
* location. This also zeros the buffer area.
*/
@@ -60,7 +68,7 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size)
msgbuf_clear(mbp);
mbp-msg_magic = MSG_MAGIC;
mbp-msg_lastpri = -1;
- mbp-msg_needsnl = 0;
+ mbp-msg_flags = 0;
bzero(mbp-msg_lock, sizeof(mbp-msg_lock));
mtx_init(mbp-msg_lock, msgbuf, NULL, MTX_SPIN);
}
@@ -95,7 +103,7 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size)
mbp-msg_lastpri = -1;
/* Assume that the old message buffer didn't end in a newline. */
- mbp-msg_needsnl = 1;
+ mbp-msg_flags |= MSGBUF_NEEDNL;
bzero(mbp-msg_lock, sizeof(mbp-msg_lock));
mtx_init(mbp-msg_lock, msgbuf, NULL, MTX_SPIN);
}
@@ -134,7 +142,7 @@ msgbuf_getcount(struct msgbuf *mbp)
* The caller should hold the message buffer spinlock.
*/
static inline void
-msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c)
+__msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c)
{
u_int pos;
@@ -149,6 +157,34 @@ msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c)
*seq = MSGBUF_SEQNORM(mbp, *seq + 1);
}
+static inline void
+msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c)
+{
+
+ if (msgbuf_show_timestamp mbp-msg_flags MSGBUF_NEXT_NEW_LINE) {
+ char buf[32], *bufp;
+ struct timespec ts;
+ int err;
+
+ buf[0] = '\0';
+ getnanouptime(ts);
+ err = snprintf(buf, sizeof buf, [%d.%ld] , ts.tv_sec,
ts.tv_nsec / 1000);
+
+ bufp = buf;
+ while (*bufp != '\0') {
+ __msgbuf_do_addchar(mbp, seq, *bufp);
+ bufp++;
+ }
+
+ mbp-msg_flags = ~MSGBUF_NEXT_NEW_LINE;
+ }
+
+ __msgbuf_do_addchar(mbp, seq, c);
+
+ if (c == '\n')
+ mbp-msg_flags |= MSGBUF_NEXT_NEW_LINE;
+}
+
/*
* Append a character to a message buffer.
*/
@@ -207,10 +243,10 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str, int
filter_cr)
* did not end with a newline. If that is the case, we need to
* insert a newline before this string.
*/
- if (mbp-msg_lastpri != pri mbp-msg_needsnl != 0) {
+ if (mbp-msg_lastpri != pri (mbp-msg_flags MSGBUF_NEEDNL) != 0) {
msgbuf_do_addchar(mbp, seq, '\n');
- mbp-msg_needsnl = 0;
+ mbp-msg_flags = ~MSGBUF_NEEDNL;
}
for (i = 0; i len; i++) {
@@ -219,7 +255,7 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str, int
filter_cr)
* (and therefore prefix_len != 0), then we need a priority
* prefix for this line.
*/
- if (mbp-msg_needsnl == 0 prefix_len != 0) {
+ if ((mbp-msg_flags MSGBUF_NEEDNL) == 0 prefix_len != 0) {
int j;
for (j = 0; j prefix_len; j++)
@@ -242,9 +278,9 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str, int
filter_cr)
* we need to insert a new prefix or insert a newline later.
*/
if (str[i] == '\n')
- mbp-msg_needsnl = 0;
+ mbp-msg_flags = ~MSGBUF_NEEDNL;
else
- mbp-msg_needsnl = 1;
+ mbp-msg_flags |= MSGBUF_NEEDNL;
msgbuf_do_addchar(mbp, seq, str[i]);
}
@@ -395,3 +431,4 @@
Re: [RFC] Prepend timestamp in msgbuf
Hi,
On Thu, Oct 13, 2011 at 2:00 PM, lacom...@gmail.com wrote:
From: Arnaud Lacombe lacom...@gmail.com
Hi folks,
There is many case recently when I really wished timestamp were present in the
post-mortem msgbuf. Such situation could be when userland application segfault
potentially triggering a panic/crash, or have information about the time-wise
location of a given message (kernel or userland).
Attached patch is available in the git repository at:
git://github.com/lacombar/freebsd.git master/topic/msgbuf-timestamp
Arnaud Lacombe (3):
msgbuf(4): convert `msg_needsnl' to a bit flag
msgbuf(4): add logic to prepend timestamp on new line
msgbuf(4): add a sysctl to toggle timestamp prepend
sys/kern/subr_msgbuf.c | 53 ---
sys/sys/msgbuf.h | 4 ++-
2 files changed, 48 insertions(+), 9 deletions(-)
also tracked as:
http://www.freebsd.org/cgi/query-pr.cgi?pr=161553
- Arnaud
diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c
index cd9c551..b2f0e1a 100644
--- a/sys/kern/subr_msgbuf.c
+++ b/sys/kern/subr_msgbuf.c
@@ -34,6 +34,7 @@
#include sys/lock.h
#include sys/mutex.h
#include sys/msgbuf.h
+#include sys/sysctl.h
/*
* Maximum number conversion buffer length: uintmax_t in base 2, plus
@@ -47,6 +48,13 @@
static u_int msgbuf_cksum(struct msgbuf *mbp);
/*
+ *
+ */
+static int msgbuf_show_timestamp = 1;
+SYSCTL_INT(_kern, OID_AUTO, msgbuf_show_timestamp, CTLFLAG_RW,
+ msgbuf_show_timestamp, 0, Show timestamp in msgbuf);
+
+/*
* Initialize a message buffer of the specified size at the specified
* location. This also zeros the buffer area.
*/
@@ -60,7 +68,7 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size)
msgbuf_clear(mbp);
mbp-msg_magic = MSG_MAGIC;
mbp-msg_lastpri = -1;
- mbp-msg_needsnl = 0;
+ mbp-msg_flags = 0;
bzero(mbp-msg_lock, sizeof(mbp-msg_lock));
mtx_init(mbp-msg_lock, msgbuf, NULL, MTX_SPIN);
}
@@ -95,7 +103,7 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size)
mbp-msg_lastpri = -1;
/* Assume that the old message buffer didn't end in a newline. */
- mbp-msg_needsnl = 1;
+ mbp-msg_flags |= MSGBUF_NEEDNL;
bzero(mbp-msg_lock, sizeof(mbp-msg_lock));
mtx_init(mbp-msg_lock, msgbuf, NULL, MTX_SPIN);
}
@@ -134,7 +142,7 @@ msgbuf_getcount(struct msgbuf *mbp)
* The caller should hold the message buffer spinlock.
*/
static inline void
-msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c)
+__msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c)
{
u_int pos;
@@ -149,6 +157,34 @@ msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c)
*seq = MSGBUF_SEQNORM(mbp, *seq + 1);
}
+static inline void
+msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c)
+{
+
+ if (msgbuf_show_timestamp mbp-msg_flags MSGBUF_NEXT_NEW_LINE) {
+ char buf[32], *bufp;
+ struct timespec ts;
+ int err;
+
+ buf[0] = '\0';
+ getnanouptime(ts);
+ err = snprintf(buf, sizeof buf, [%d.%ld] , ts.tv_sec,
ts.tv_nsec / 1000);
+
+ bufp = buf;
+ while (*bufp != '\0') {
+ __msgbuf_do_addchar(mbp, seq, *bufp);
+ bufp++;
+ }
+
+ mbp-msg_flags = ~MSGBUF_NEXT_NEW_LINE;
+ }
+
+ __msgbuf_do_addchar(mbp, seq, c);
+
+ if (c == '\n')
+ mbp-msg_flags |= MSGBUF_NEXT_NEW_LINE;
+}
+
/*
* Append a character to a message buffer.
*/
@@ -207,10 +243,10 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str,
int filter_cr)
* did not end with a newline. If that is the case, we need to
* insert a newline before this string.
*/
- if (mbp-msg_lastpri != pri mbp-msg_needsnl != 0) {
+ if (mbp-msg_lastpri != pri (mbp-msg_flags MSGBUF_NEEDNL) != 0)
{
msgbuf_do_addchar(mbp, seq, '\n');
- mbp-msg_needsnl = 0;
+ mbp-msg_flags = ~MSGBUF_NEEDNL;
}
for (i = 0; i len; i++) {
@@ -219,7 +255,7 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str, int
filter_cr)
* (and therefore prefix_len != 0), then we need a priority
* prefix for this line.
*/
- if (mbp-msg_needsnl == 0 prefix_len != 0) {
+ if ((mbp-msg_flags MSGBUF_NEEDNL) == 0 prefix_len != 0)
{
int j;
for (j = 0; j prefix_len; j++)
@@ -242,9 +278,9 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str, int
filter_cr)
* we need to insert a new prefix or insert a newline later.
*/
if (str[i] == '\n')
- mbp-msg_needsnl = 0;
+
Compatibility with 8.0
Hi Current, Should the new Beta 3 have options COMPAT_FREEBSD8 in the GENERIC kernel config file? Or, does this happen when it goes RC? Ta Peg ___ 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: Compatibility with 8.0
Hi, On Thu, Oct 13, 2011 at 5:12 PM, Pegasus Mc Cleaft k...@mthelicon.com wrote: Hi Current, Should the new Beta 3 have options COMPAT_FREEBSD8 in the GENERIC kernel config file? Or, does this happen when it goes RC? What would you expect this option to cover ? I'd assume that no ABI[0] have been broken between FreeBSD 8 and FreeBSD 9. If ABI had been broken, the developer should have been responsible enough to create the proper compatibility shim and would already have introduced COMPAT_FREEBSD9. Of course, this leaves options for ABI being broken, compatibility shim introduced, but COMPAT_FREEBSD9 not introduced :) - Arnaud [0]: all the mentions of ABI exclude KVM. Ta Peg ___ 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
Re: FreeBSD 9.0-BETA3 Available...
On 10/12/2011 06:47, Ken Smith wrote: On Wed, 2011-10-12 at 14:39 +0100, Bruce Cran wrote: On 29/09/2011 02:42, Ken Smith wrote: MD5 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) = 2ce7b93d28fd7ff37965893f1af3f7fc MD5 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) = 4affc701f2052edc548274f090e49235 MD5 (FreeBSD-9.0-BETA3-amd64-memstick.img) = e260f2f2122326cb9a93ac83eb006c1c The -dvd1.iso files seem to be less than a CD, at 610MB. Are they expected to contain more data over time, or could 'dvd' be removed? I was planning on them having package sets. The new installer doesn't support installing packages like sysinstall had but if I provide Gnome, KDE, and perhaps a small set of other stuff it would be useful to people with crummy network connectivity. They could install the packages from the DVD instead of needing to have everything downloaded. Is there still going to be a CD-sized installer? I find this really useful both at home, and also for virtualized installs. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: Fixed: ichwd failure to attach
On 10/12/2011 08:20, Michael Butler wrote: SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: Intel ICH10DO watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 r226340, smp, amd64 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
Hello list, I just upgraded my home workstation to 9.0-beta3 amd64. It seems like my web browsers are preferring ipv4 over ipv6 after the upgrade, I tested Firefox and Opera. After digging into rc.conf(5) I found this bit: If ``AUTO'' is specified, it attempts to read a file /etc/ip6addrctl.conf first. If this file is found, ip6addrctl(8) reads and installs it. If not found, a policy is automatically set according to ipv6_activate_all_interfaces variable; if the variable is set to ``YES'' the IPv6-preferred one is used. Otherwise IPv4-preferred. The default value of ip6addrctl_enable and ip6addrctl_policy are ``YES'' and ``AUTO'', respectively. I already have ipv6_activate_all_interfaces=YES in /etc/rc.conf so ip6addrctl_policy _should_ be ip6addrctl_policy if I am reading this correctly. But my browsers still prefer ipv4. Is this a bug, or do the manpage need updating ? Before the upgrade to 9 I was running 8-stable which preferred ipv6 like I would expect. Thank you in advance, Thomas Steen Rasmussen ___ 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: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
On 14.10.2011 00:31, Thomas Steen Rasmussen wrote: Hello list, I just upgraded my home workstation to 9.0-beta3 amd64. It seems like my web browsers are preferring ipv4 over ipv6 after the upgrade, My laptop is also running 9.0-beta3 amd64 and I observe the same behaviour there, so this doesn't seem like an issue with a specific machine. On IRC I was advised to include h...@freebsd.org as cc in this thread. Best regards Thomas Steen Rasmussen ___ 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: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
Thomas Steen Rasmussen tho...@gibfest.dk wrote in 4e9766c0.1020...@gibfest.dk: th Hello list, th th I just upgraded my home workstation to 9.0-beta3 amd64. It seems th like my web browsers are preferring ipv4 over ipv6 after the upgrade, th I tested Firefox and Opera. After digging into rc.conf(5) I found this bit: th th If ``AUTO'' is specified, it attempts to read a file th /etc/ip6addrctl.conf first. If this file is found, th ip6addrctl(8) reads and installs it. If not found, a policy th is automatically set according to th ipv6_activate_all_interfaces variable; if the variable is set th to ``YES'' the IPv6-preferred one is used. Otherwise th IPv4-preferred. th th The default value of ip6addrctl_enable and ip6addrctl_policy th are ``YES'' and ``AUTO'', respectively. th th I already have ipv6_activate_all_interfaces=YES in /etc/rc.conf th so ip6addrctl_policy _should_ be ip6addrctl_policy if I am reading th this correctly. But my browsers still prefer ipv4. Is this a bug, or th do the manpage need updating ? Can you please send me the results of the following commands: % ifconfig % grep ^ipv6 /etc/rc.conf % grep ipv6= /etc/rc.conf % ip6addrctl show # /bin/sh -x /etc/rc.d/ip6addrctl start -- Hiroki pgp9Ararm4uMe.pgp Description: PGP signature
Re: [RFC] Prepend timestamp in msgbuf
On 14 October 2011 02:40, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Thu, Oct 13, 2011 at 2:00 PM, lacom...@gmail.com wrote: From: Arnaud Lacombe lacom...@gmail.com Hi folks, There is many case recently when I really wished timestamp were present in the post-mortem msgbuf. Such situation could be when userland application segfault potentially triggering a panic/crash, or have information about the time-wise location of a given message (kernel or userland). Nice! Once the -head dust settles and 9.0-rel makes it out the door, I'd like to see this make an appearance. Adrian ___ 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: incorrect use of pidfile(3)
Why not import daemontools? It's public domain these days. Pidfiles are a hacky mess. UNIX already has a way to track processes which avoids all these issues, with very little overhead. Jos ___ 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
