Re: 9-stable: My AR5B95 not reconized anymore.
Oh, right. I swear, i read UPDATING, just missed that particular note. Adding device ath_pci fixed my problem. Thanks all. ___ 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-stable: My AR5B95 not reconized anymore.
On 26 September 2011 16:09, arrowdodger 6year...@gmail.com wrote: Oh, right. I swear, i read UPDATING, just missed that particular note. Adding device ath_pci fixed my problem. Thanks all. Please let me / freebsd-wireless@ know if things work :) I'd like some assurances that the wireless in 9.0 is stable and performs well! 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: FreeBSD 9.0-BETA2 memstick USB image hangs my BIOS
.. and as a side note, PCBSD 9.0-BETA2 USB install booted fine on the same machine (Although I needed a larger flash disk, as it's 100 megabytes larger than what my 4 gigabyte USB flash drives advertise.) I'll try dumping FreeBSD on the same USB flash disk once PCBSD is installed, just to eliminate the USB disk itself as an issue. 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: FreeBSD 9.0-BETA2 memstick USB image hangs my BIOS
.. because PCBSD 9.0 uses a FreeBSD partition inside an MBR/DOS partition scheme, rather than GPT inside MBR/DOS. Something tells me this is going to cause problems.. Adrian On 26 September 2011 16:38, Adrian Chadd adr...@freebsd.org wrote: .. and as a side note, PCBSD 9.0-BETA2 USB install booted fine on the same machine (Although I needed a larger flash disk, as it's 100 megabytes larger than what my 4 gigabyte USB flash drives advertise.) I'll try dumping FreeBSD on the same USB flash disk once PCBSD is installed, just to eliminate the USB disk itself as an issue. 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.0 beta2 the new bsdinstaller
On 23/09/2011 04:49, Matthew D. Fuller wrote: On Wed, Sep 21, 2011 at 08:26:47AM + I heard the voice of Thomas Mueller, and lo! it spake thus: I don't think there is any particular advantage in aligning GPT partitions on 1 MB boundaries. No, but it's bg, and rund! (http://dilbert.com/fast/1994-03-24/) ... and both Windows and Linux do it that way so to avoid any possible future problems, we should too. signature.asc Description: OpenPGP digital signature
Re: Unusually high LA without any load at FreeBSD9-BETA2
On Tue, Sep 06, 2011 at 08:32:55PM +0300, Alex Kozlov wrote: On Tue, Sep 06, 2011 at 05:22:02PM +, Poul-Henning Kamp wrote: We should kille the load avarage as a measure for system activity, it only has any relevance if you run heavy CPU bound processes. It may be true, but in current kernel from beginning of june I would I mean stable kernel from beginning of june... see la about 0,01 in this situation. Note that cpu idling: dev.cpu.0.freq: 300 dev.cpu.0.freq_levels: 2200/35000 1925/30625 1650/26250 1600/23000 1400/20125 1200/15000 1050/13125 900/11250 750/9375 600/7500 450/5625 300/3750 150/1875 dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 [...] 11 root2 155 ki31 0K32K CPU11 29.4H 200.00% idle I think process accounting get broken or something like this. I updated to BETA-3, disabled all unnecessary modules (sound, net, wifi, ahci), boot in single user (no tricky programs, no external influence) and left laptop for 12+ hours, when I returned LA: 0,62 0,74 0,72 Anyone else observed something like that? If I boot from another flash with 8-STABLE from june, after a few hours I get LA: 0,01 0,00 0,00 , as expected. -- Adios ___ 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
Point Cloud Library (PCL)
Hello. Does anyone knows whether there is a port of the Point Cloud Library (PCL), which seems to be a subproject of OpenCV? Any hints or tips are welcome. 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
System sendmail build fails with updated cyrus-sasl2 port
This is for 9 BETA2 or 10-CURRENT. Please fix it on either side. Apparently minor types mismatch within sasl_callback_t type. cc -O2 -pipe -march=pentium4 -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include -DSASL=2 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/main.c cc1: warnings being treated as errors /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/main.c:112: warning: initialization from incompatible pointer type /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/main.c:113: warning: initialization from incompatible pointer type *** Error code 1 -- http://ache.vniz.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: ath / 802.11n performance issues and timer code
On Sunday, September 25, 2011 5:48:31 am Adrian Chadd wrote: Nope, it has the opposite effect: * Increased latency may make aggregation better (for TX) but it limits throughput because TCP senses a latency increase; I suspect this matters more. Have you tried comparing UDP throughput in the two cases? One behavioral difference of a periodic timer vs a deadline timer is that if you ask to delay for 1 clock tick, that can be anywhere from 0us to 1000us (with hz == 1000) when using the periodic timer (because you can set the callout at any time within a tick, but the callout will fire at the start of the next tick). However, for a deadline timer, the TCP timer will always fire 1000us after you set the timer. -- 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: 9.0 beta2 the new bsdinstaller
On Sunday, September 25, 2011 4:16:51 am Thomas Mueller wrote: Other issue is the 64 KB boot partition, which does not boot for me. There ought to be an option, or is there already, to omit the boot partition. Sysinstall had such an option, to not install the boot loader, since user could already have another boot manager such as LILO or grub (legacy or grub2). Does the 64 KB boot partition have to be the first partition on the disk in order to be functional? One might want to use a different boot loader, such as grub2, and what about the EFI system partition that is very different from a 64 KB FreeBSD boot partition? The GPT boot-from-BIOS mode requires the 64 KB boot partition. At some point when we have an EFI loader we will not need a boot partition for GPT, though instead you will need a larger EFI partition. -- 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: Experiences with FreeBSD 9.0-BETA2
On Sunday, September 25, 2011 8:52:37 pm Brett Glass wrote: First thing I noticed, when running the new FreeBSD installer from a memory stick image, is that disk partitioning was odd. It abandoned standard UNIX parlance, calling what are traditionally called slices partitions. It also diverged from past practice by creating one big UFS filesystem rather than the usual separate partitions for /, /tmp, /var, /usr. It then made a separate slice (to use the traditional terminology) for swap, rather than including it in the slice that contained the big file system. This seemed odd; if the file system was being lumped together in one place, why break out the swap to an entirely separate slice? I can't speak to the one-big-fs bit (there was another thread long ago about that). However, as to the partitioning bit, bsdinstall is defaulting to using the newer GPT scheme instead of an MBR with a nested BSD label. It is simpler (only LBAs, no C/H/S dance), more extensible (partition table can be sized at creation time), supports larger disks (64-bit LBAs, which neither MBR nor the BSD label support), and is the x86 disk layout scheme of the future (EFI mandates GPT). It is actually more like a traditional BSD system that would have only had a BSD label (and no MBR) on the disk. -- 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: Choosing between DELAY(useconds) and pause()
On Friday, September 23, 2011 11:21:06 am Gavin Atkinson wrote: On Thu, 2011-09-22 at 20:07 +0200, Hans Petter Selasky wrote: On Thursday 22 September 2011 19:55:23 David Somayajulu wrote: It appears that the pause() function cannot be used in driver functions which are invoked early in the boot process. Is there is a kernel api which a device driver can use to determine whether to use pause() or DELAY(), for delays which are say greater than 10hz - may be even 1 hz ? Maybe you want to use something like this: if (cold) DELAY() else pause() In your code. Note that this still shouldn't be done in your suspend/resume paths, as cold isn't set there, however there also appears to be no guarantee that pause() will ever return (as you could be running after the timer has been suspended, or before it resumes). I'm not sure what the correct answer is for suspend/resume code. Hmmm, on x86 the timers are explicitly shutdown after the DEVICE_SUSPEND() pass over the tree and re-enabled before DEVICE_RESUME(). Perhaps this has changed in HEAD though with the eventtimers stuff. I do think it is best however, to use DELAY() in the suspend/resume path always regardless. -- 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: ath / 802.11n performance issues and timer code
On 26 September 2011 21:17, John Baldwin j...@freebsd.org wrote: On Sunday, September 25, 2011 5:48:31 am Adrian Chadd wrote: Nope, it has the opposite effect: * Increased latency may make aggregation better (for TX) but it limits throughput because TCP senses a latency increase; I suspect this matters more. Have you tried comparing UDP throughput in the two cases? Yes, UDP performance from the MIPS boards (running iperf) is just plain silly and low. It's better from the i386 based eeepc (I can get around 200mbit before things croak it, but I _should_ be able to schedule ~ 250mbit with maximum aggregation and no airtime errors / retries, which I _can_ achieve in controlled conditions.) I haven't yet dug into that. It may be related. One behavioral difference of a periodic timer vs a deadline timer is that if you ask to delay for 1 clock tick, that can be anywhere from 0us to 1000us (with hz == 1000) when using the periodic timer (because you can set the callout at any time within a tick, but the callout will fire at the start of the next tick). However, for a deadline timer, the TCP timer will always fire 1000us after you set the timer. Right. Hm, what about scheduling in general though? Ie, if I'm scheduling a taskqueue run, the taskqueue caller does: * lock queue * schedule next task queue * call wakeup_one Which should wake up a/the taskqueue thread in question and have it immediately run the next task on the queue. The taskqueue doesn't have any form of timer/callout; it's just a submit this to get run. When will it be run? I hope not at the next tick, not if the CPU is free. 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
[PATCH] dtrace crashes when trying to trace fbt probes
Hi, Ryan, I came across the similar problem on 8-stable when I run
# dtrace -lv
the panic message says:
page fault just happened at fbt.c
if (*lc.ctfoffp == NULL) { // page fault
/*
* Initialise the CTF object and function symindx to
* byte offset array.
*/
if (fbt_ctfoff_init(ctl, lc) != 0)
return;
/* Initialise the CTF type to byte offset array. */
if (fbt_typoff_init(lc) != 0)
return;
}
And I came across the similar problem on 9-current only once, but when I
recompile the kernel,
it does not reproduce. I will try your patch on 8-stable, but could you tell
me where did you meet
the problem, and what is your module without CTF data?
___
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: ath / 802.11n performance issues and timer code
On Monday, September 26, 2011 10:10:27 am Adrian Chadd wrote: On 26 September 2011 21:17, John Baldwin j...@freebsd.org wrote: On Sunday, September 25, 2011 5:48:31 am Adrian Chadd wrote: Nope, it has the opposite effect: * Increased latency may make aggregation better (for TX) but it limits throughput because TCP senses a latency increase; I suspect this matters more. Have you tried comparing UDP throughput in the two cases? Yes, UDP performance from the MIPS boards (running iperf) is just plain silly and low. It's better from the i386 based eeepc (I can get around 200mbit before things croak it, but I _should_ be able to schedule ~ 250mbit with maximum aggregation and no airtime errors / retries, which I _can_ achieve in controlled conditions.) I meant do the timer settings affect UDP performance? I.e. does idletick=1 change UDP performance at all? One behavioral difference of a periodic timer vs a deadline timer is that if you ask to delay for 1 clock tick, that can be anywhere from 0us to 1000us (with hz == 1000) when using the periodic timer (because you can set the callout at any time within a tick, but the callout will fire at the start of the next tick). However, for a deadline timer, the TCP timer will always fire 1000us after you set the timer. Right. Hm, what about scheduling in general though? Ie, if I'm scheduling a taskqueue run, the taskqueue caller does: * lock queue * schedule next task queue * call wakeup_one Which should wake up a/the taskqueue thread in question and have it immediately run the next task on the queue. The taskqueue doesn't have any form of timer/callout; it's just a submit this to get run. When will it be run? I hope not at the next tick, not if the CPU is free. No, that scheduling is synchronous. Anytime a thread is scheduled the scheduler will check if it should preempt the current thread to run the new thread. -- 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: ath / 802.11n performance issues and timer code
On 26 September 2011 22:53, John Baldwin j...@freebsd.org wrote: I meant do the timer settings affect UDP performance? I.e. does idletick=1 change UDP performance at all? I'll check that and get back to you. But please keep in mind that the first time I tried this and saw immediate results was with the device in hostap mode - where ethernet and wlan0 are bridged via if_bridge. There's no TCP or UDP state being handled at all. Which should wake up a/the taskqueue thread in question and have it immediately run the next task on the queue. The taskqueue doesn't have any form of timer/callout; it's just a submit this to get run. When will it be run? I hope not at the next tick, not if the CPU is free. No, that scheduling is synchronous. Anytime a thread is scheduled the scheduler will check if it should preempt the current thread to run the new thread. I admit I don't quite understand yet the scheduler and event/timer handling code. What about if nothing is currently scheduled and the CPU is idle? When will the idle process get tickled? I assume it would preempt the idle process immediately and run the taskqueue kernel thread, right? Would there ever be a situation where it doesn't do this? 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: System sendmail build fails with updated cyrus-sasl2 port
Hi,
On Mon, 26 Sep 2011 15:58:03 +0400
Andrey Chernov a...@freebsd.org said:
ache This is for 9 BETA2 or 10-CURRENT.
ache Please fix it on either side. Apparently minor types mismatch within
ache sasl_callback_t type.
ache cc -O2 -pipe -march=pentium4
ache -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src
ache -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB
ache -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1
ache -I/usr/local/include -DSASL=2 -std=gnu99 -fstack-protector
ache -Wsystem-headers -Werror -Wno-pointer-sign -c
ache /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/main.c
ache cc1: warnings being treated as errors
ache /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/main.c:112:
warning:
ache initialization from incompatible pointer type
ache /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/main.c:113:
warning:
ache initialization from incompatible pointer type
ache *** Error code 1
It seems 2.1.25 requires to cast to sasl_callback_ft. How about the
attached patch?
Index: contrib/sendmail/src/main.c
diff -u -p contrib/sendmail/src/main.c.orig contrib/sendmail/src/main.c
--- contrib/sendmail/src/main.c.orig 2011-06-22 13:00:26.0 +0900
+++ contrib/sendmail/src/main.c 2011-09-27 00:32:34.0 +0900
@@ -109,8 +109,8 @@ GIDSET_T InitialGidSet[NGROUPS_MAX];
#if SASL
static sasl_callback_t srvcallbacks[] =
{
- { SASL_CB_VERIFYFILE, safesaslfile, NULL },
- { SASL_CB_PROXY_POLICY, proxy_policy, NULL },
+ { SASL_CB_VERIFYFILE, (sasl_callback_ft)safesaslfile, NULL },
+ { SASL_CB_PROXY_POLICY, (sasl_callback_ft)proxy_policy, NULL },
{ SASL_CB_LIST_END, NULL, NULL }
};
#endif /* SASL */
Index: contrib/sendmail/src/sendmail.h
diff -u contrib/sendmail/src/sendmail.h.orig contrib/sendmail/src/sendmail.h
--- contrib/sendmail/src/sendmail.h.orig 2011-06-22 13:00:27.0 +0900
+++ contrib/sendmail/src/sendmail.h 2011-09-27 00:57:43.0 +0900
@@ -133,10 +133,15 @@
# if SASL == 2 || SASL = 2
# include sasl/sasl.h
+# include sasl/saslplug.h
# include sasl/saslutil.h
+# if SASL_VERSION_FULL 0x020119
+typedef int (*sasl_callback_ft)(void);
+# endif
# else /* SASL == 2 || SASL = 2 */
# include sasl.h
# include saslutil.h
+typedef int (*sasl_callback_ft)(void);
# endif /* SASL == 2 || SASL = 2 */
# if defined(SASL_VERSION_MAJOR) defined(SASL_VERSION_MINOR) defined(SASL_VERSION_STEP)
# define SASL_VERSION (SASL_VERSION_MAJOR * 1) + (SASL_VERSION_MINOR * 100) + SASL_VERSION_STEP
Index: contrib/sendmail/src/usersmtp.c
diff -u -p contrib/sendmail/src/usersmtp.c.orig contrib/sendmail/src/usersmtp.c
--- contrib/sendmail/src/usersmtp.c.orig 2011-09-27 00:51:44.0 +0900
+++ contrib/sendmail/src/usersmtp.c 2011-09-27 00:51:52.0 +0900
@@ -524,15 +524,15 @@ static int attemptauth __P((MAILER *, MC
static sasl_callback_t callbacks[] =
{
- { SASL_CB_GETREALM, saslgetrealm, NULL },
+ { SASL_CB_GETREALM, (sasl_callback_ft)saslgetrealm, NULL },
#define CB_GETREALM_IDX 0
- { SASL_CB_PASS, getsecret, NULL },
+ { SASL_CB_PASS, (sasl_callback_ft)getsecret, NULL },
#define CB_PASS_IDX 1
- { SASL_CB_USER, getsimple, NULL },
+ { SASL_CB_USER, (sasl_callback_ft)getsimple, NULL },
#define CB_USER_IDX 2
- { SASL_CB_AUTHNAME, getsimple, NULL },
+ { SASL_CB_AUTHNAME, (sasl_callback_ft)getsimple, NULL },
#define CB_AUTHNAME_IDX 3
- { SASL_CB_VERIFYFILE, safesaslfile, NULL },
+ { SASL_CB_VERIFYFILE, (sasl_callback_ft)safesaslfile, NULL },
#define CB_SAFESASL_IDX 4
{ SASL_CB_LIST_END, NULL, NULL }
};
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
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-stable: My AR5B95 not reconized anymore.
On Mon, Sep 26, 2011 at 1:12 AM, Adrian Chadd adr...@freebsd.org wrote: On 26 September 2011 16:09, arrowdodger 6year...@gmail.com wrote: Oh, right. I swear, i read UPDATING, just missed that particular note. Adding device ath_pci fixed my problem. Thanks all. Please let me / freebsd-wireless@ know if things work :) I'd like some assurances that the wireless in 9.0 is stable and performs well! Adrian If my contract to return to work is approved, I'll try 9.0 on the ThinkPad T43 with an Atheros 5212. I run the card in hostap mode part time, so I will test that, as well. I recall a tread on problems with the 5212 on current month or so ago. Is it believed to be working OK, now? Or have others reported it as OK both in normal and hostap mode? (No need to repeat tests others have already run.) -- R. Kevin Oberman, Network Engineer - Retired (for the moment) E-mail: kob6...@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: ath / 802.11n performance issues and timer code
On Monday, September 26, 2011 11:30:27 am Adrian Chadd wrote: On 26 September 2011 22:53, John Baldwin j...@freebsd.org wrote: I meant do the timer settings affect UDP performance? I.e. does idletick=1 change UDP performance at all? I'll check that and get back to you. But please keep in mind that the first time I tried this and saw immediate results was with the device in hostap mode - where ethernet and wlan0 are bridged via if_bridge. There's no TCP or UDP state being handled at all. Which should wake up a/the taskqueue thread in question and have it immediately run the next task on the queue. The taskqueue doesn't have any form of timer/callout; it's just a submit this to get run. When will it be run? I hope not at the next tick, not if the CPU is free. No, that scheduling is synchronous. Anytime a thread is scheduled the scheduler will check if it should preempt the current thread to run the new thread. I admit I don't quite understand yet the scheduler and event/timer handling code. What about if nothing is currently scheduled and the CPU is idle? When will the idle process get tickled? I assume it would preempt the idle process immediately and run the taskqueue kernel thread, right? Would there ever be a situation where it doesn't do this? The idle thread is just like any other thread in this case. It will preempt when it schedules the thread to run. The idle thread is only chosen by the scheduler when there are no runnable threads. -- 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: Experiences with FreeBSD 9.0-BETA2
On Mon, 26 Sep 2011, John Baldwin wrote: On Sunday, September 25, 2011 8:52:37 pm Brett Glass wrote: First thing I noticed, when running the new FreeBSD installer from a memory stick image, is that disk partitioning was odd. It abandoned standard UNIX parlance, calling what are traditionally called slices partitions. It also diverged from past practice by creating one big UFS filesystem rather than the usual separate partitions for /, /tmp, /var, /usr. It then made a separate slice (to use the traditional terminology) for swap, rather than including it in the slice that contained the big file system. This seemed odd; if the file system was being lumped together in one place, why break out the swap to an entirely separate slice? I can't speak to the one-big-fs bit (there was another thread long ago about that). However, as to the partitioning bit, bsdinstall is defaulting to using The question of how to layout and split filesystems was discussed at the filesystems working group of the devsummit at BSDCan this may. (http://wiki.freebsd.org/201105DevSummit/FileSystems down to Filesystem Layout near the bottom) Though one big root did not garner a huge amount of support, neither were there particularly compelling arguments against it (if I remember correctly). It's certainly easier to write an autopartitioner for, so I don't really blame Nathan for having chosen it initially. -Ben Kaduk ___ 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: Experiences with FreeBSD 9.0-BETA2
On Mon, 26 Sep 2011, Adrian Chadd wrote: I agree, the lack of a virtual/emergency terminal seems a bit silly. I'm not sure about the cons25 versus xterm stuff - you're not the first person to report this. Guys/girls/other (Hi SF!) - why is this? :) It shouldn't be that hard to submit a patch to enable those extra vtys? While one's at it, having the primary installer dialogs be on not-vt0 (i.e. not the console) would eliminate the issue where LOR spew takes out parts of the dialog. -Ben Kaduk ___ 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: Experiences with FreeBSD 9.0-BETA2
Hi, On Mon, Sep 26, 2011 at 2:03 PM, Benjamin Kaduk ka...@mit.edu wrote: On Mon, 26 Sep 2011, John Baldwin wrote: On Sunday, September 25, 2011 8:52:37 pm Brett Glass wrote: First thing I noticed, when running the new FreeBSD installer from a memory stick image, is that disk partitioning was odd. It abandoned standard UNIX parlance, calling what are traditionally called slices partitions. It also diverged from past practice by creating one big UFS filesystem rather than the usual separate partitions for /, /tmp, /var, /usr. It then made a separate slice (to use the traditional terminology) for swap, rather than including it in the slice that contained the big file system. This seemed odd; if the file system was being lumped together in one place, why break out the swap to an entirely separate slice? I can't speak to the one-big-fs bit (there was another thread long ago about that). However, as to the partitioning bit, bsdinstall is defaulting to using The question of how to layout and split filesystems was discussed at the filesystems working group of the devsummit at BSDCan this may. (http://wiki.freebsd.org/201105DevSummit/FileSystems down to Filesystem Layout near the bottom) Though one big root did not garner a huge amount of support, neither were there particularly compelling arguments against it (if I remember correctly). It's certainly easier to write an autopartitioner for, so I don't really blame Nathan for having chosen it initially. What's the point of running a vote if it's to finally not care about it ? You had got 4 people wanting to go right, 9 to go straight, 2 to go left, and the driver goes left. - Arnaud -Ben Kaduk ___ 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: Experiences with FreeBSD 9.0-BETA2
On Mon, 26 Sep 2011, Arnaud Lacombe wrote: Hi, On Mon, Sep 26, 2011 at 2:03 PM, Benjamin Kaduk ka...@mit.edu wrote: The question of how to layout and split filesystems was discussed at the filesystems working group of the devsummit at BSDCan this may. (http://wiki.freebsd.org/201105DevSummit/FileSystems down to Filesystem Layout near the bottom) Though one big root did not garner a huge amount of support, neither were there particularly compelling arguments against it (if I remember correctly). It's certainly easier to write an autopartitioner for, so I don't really blame Nathan for having chosen it initially. What's the point of running a vote if it's to finally not care about it ? You had got 4 people wanting to go right, 9 to go straight, 2 to go left, and the driver goes left. Not at all. Firstly, the driver (as you put it) was not at this session, and in fact the installer was imported *before* this session, so the driver went left before people were even talking about it. (My reading of the svn log is that the one big root was just part of the initial import and not given a whole lot of thought.) Secondly, it was not a vote; it was more of a straw poll, and no strong opinions were really voiced. Thirdly, no one was tasked with going off and telling Nathan the results of it, so (since he wasn't there) I find it hard to blame him for failing to go and scour the entire devsummit wiki to see if something relevant to the installer might possibly have happened then. -Ben Kaduk___ 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: System sendmail build fails with updated cyrus-sasl2 port
On Tue, Sep 27, 2011 at 01:23:32AM +0900, Hajimu UMEMOTO wrote: It seems 2.1.25 requires to cast to sasl_callback_ft. How about the attached patch? Thanx, it works now. IMHO it should be MFCed to stable-9 ASAP (and to sendmail trunk too). -- http://ache.vniz.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
FreeBSD 9-Beta3 on X300 problems.
Hello. I upgrade my FreeBSD 8.2-Release to FreeBSD 9-Beta and pkg_delete -f -a and add new (that same) pkgs with pkg_add. And system, xorgs, wine, opera, java, flash works ok, but... I find two things that dont works ;/ 1. Suspend. On FreeBSD 8.2 when i make ifconfig wlan0 down, and use zzz from X.org all works. Suspend/resume. Now when i make this same, system go to console and suspend. When i try to resume. System show console, but when i try to press ALT+F9 i get long beeep and system hang ;/ I found on Google that i can try, to make uhci as a module, and first unload it, and then suspend system. But when i try to kldload uhci system go to dbg and hangs ;/ 2. Kadu/Gnu Gadu. I dont know why, but when i run kadu / gnu gadu and try to connect to Gadu-Gadu network software segments ;/ Kadu with signal 6, GnuGadu with signal 11. I try to use old gadulib, or recompie it. But this doesn't help ;/ [cr4sh@x300 ~]$ uname -a FreeBSD x300 9.0-BETA3 FreeBSD 9.0-BETA3 #2: Mon Sep 26 00:25:30 CEST 2011 cr4sh@x300:/sys/amd64/compile/GENERIC amd64 Regards. ___ 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 9-Beta3 on X300 2 problems
Hello. I upgrade my FreeBSD 8.2-Release to FreeBSD 9-Beta and pkg_delete -f -a and add new (that same) pkgs with pkg_add. And system, xorgs, wine, opera, java, flash works ok, but... I find two things that dont works ;/ 1. Suspend. On FreeBSD 8.2 when i make ifconfig wlan0 down, and use zzz from X.org all works. Suspend/resume. Now when i make this same, system go to console and suspend. When i try to resume. System show console, but when i try to press ALT+F9 i get long beeep and system hang ;/ I found on Google that i can try, to make uhci as a module, and first unload it, and then suspend system. But when i try to kldload uhci system go to dbg and hangs ;/ 2. Kadu/Gnu Gadu. I dont know why, but when i run kadu / gnu gadu and try to connect to Gadu-Gadu network software segments ;/ Kadu with signal 6, GnuGadu with signal 11. I try to use old gadulib, or recompie it. But this doesn't help ;/ [cr4sh@x300 ~]$ uname -a FreeBSD x300 9.0-BETA3 FreeBSD 9.0-BETA3 #2: Mon Sep 26 00:25:30 CEST 2011 cr4sh@x300:/sys/amd64/compile/GENERIC amd64 Regards. ___ 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: Experiences with FreeBSD 9.0-BETA2
At 12:03 PM 9/26/2011, Benjamin Kaduk wrote: On Mon, 26 Sep 2011, John Baldwin wrote: I can't speak to the one-big-fs bit (there was another thread long ago about that). However, as to the partitioning bit, bsdinstall is defaulting to using The question of how to layout and split filesystems was discussed at the filesystems working group of the devsummit at BSDCan this may. (http://wiki.freebsd.org/201105DevSummit/FileSystems down to Filesystem Layout near the bottom) Though one big root did not garner a huge amount of support, neither were there particularly compelling arguments against it (if I remember correctly). It's certainly easier to write an autopartitioner for, so I don't really blame Nathan for having chosen it initially. My personal preference would be to place portions of the directory tree which contain critical configuration information and are not written in normal use -- e.g. /etc and /boot -- in one or more separate partitions. This would make it possible to mount them read-only unless the system configuration was being changed, new software was being installed, or a new kernel was being generated. This would protect them not only from malicious tampering but also from being scrambled by buggy userland software. And since it would not be written during normal operation, it would survive 100% intact even if journaling and/or serialization of metadata updates (e.g. softupdates) were to fail. Unfortunately, due to past history, /usr is mixed-use. It normally contains both configuration information -- e.g. /usr/local/etc -- and more volatile data such as users' home directories. This prevents /usr/local/etc, which also contains mission-critical configuration information, from being protected if you just protect /. Some proprietary Unices have fixed this historical flaw in the traditional hierarchy by moving /usr/local/etc to another location and them symlinking it back to where seasoned administrators expect it to be, thus honoring POLA. The three open source, old school BSDs (Free, Net, Open) have not done this to date, but it's something that should be considered in the long run. It would certainly make the creation of embedded systems easier, as well as enhancing security in multi-user systems! If I wrote an installer, my preference would be to have it create one partition that contained critical configuration information and software (and could be mounted read-only) and one that contained the rest of the usual directory tree (and could be mounted read-write). It could do the symlinking trick mentioned above to bring parts of /usr over to the read-only administrative partition. The only cleanup task that would remain would be to make sure that no ports were configured to place their logs, pid files, etc. in directories such as /usr/local/etc. (Most already do not.) --Brett ___ 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: Experiences with FreeBSD 9.0-BETA2
Hi, On Mon, Sep 26, 2011 at 4:34 PM, Brett Glass br...@lariat.net wrote: At 12:03 PM 9/26/2011, Benjamin Kaduk wrote: On Mon, 26 Sep 2011, John Baldwin wrote: I can't speak to the one-big-fs bit (there was another thread long ago about that). However, as to the partitioning bit, bsdinstall is defaulting to using The question of how to layout and split filesystems was discussed at the filesystems working group of the devsummit at BSDCan this may. (http://wiki.freebsd.org/201105DevSummit/FileSystems down to Filesystem Layout near the bottom) Though one big root did not garner a huge amount of support, neither were there particularly compelling arguments against it (if I remember correctly). It's certainly easier to write an autopartitioner for, so I don't really blame Nathan for having chosen it initially. My personal preference would be to place portions of the directory tree which contain critical configuration information and are not written in normal use -- e.g. /etc and /boot -- The problem with /boot on a dedicated partition is the the kernel, since at least 8.x, is installed by default with a vast majority of crap. That's all the .symbols, that 99% of FreeBSD users will never uses. Beside that, the auto-partitionner refuses to work on 1G drive, which is really ridiculous... FreeBSD 9.0BETA2 bases + games fit in 310MB, crap taken out. - Arnaud ___ 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 9.0-BETA 2, camcontrol readcap, no passthrough device found
Hi, I am running this version: 9.0-BETA2 FreeBSD 9.0-BETA2 #23 r225745: Fri Sep 23 19:45:09 PDT 2011 I found this behavior: % camcontrol devlist ST380815AS 4.ADA at scbus2 target 0 lun 0 (pass0,ada0) TEAC DVD-ROM DV28SV R.0A at scbus3 target 0 lun 0 (pass1,cd0) % camcontrol readcap 0:0:0 camcontrol: cam_open_btl: no passthrough device found at 0:0:0 % camcontrol readcap 0:0 camcontrol: cam_open_btl: no passthrough device found at 0:0:0 % ls /dev/pass* /dev/pass0 /dev/pass1 % camcontrol readcap pass0 % camcontrol readcap pass0 (pass0:ahcich0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (pass0:ahcich0:0:0:0): CAM status: CCB request was invalid Is this a bug? What should the proper syntax for camcontrol readcap be? These are the devices, as shown in the dmesg.boot output: ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0: ST380815AS 4.ADA ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 76293MB (15625 512 byte sectors: 16H 63S/T 16383C) cd0 at ahcich1 bus 0 scbus3 target 0 lun 0 cd0: TEAC DVD-ROM DV28SV R.0A Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) -- Craig Rodrigues rodr...@crodrigues.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: Experiences with FreeBSD 9.0-BETA2
Hi, On Sun, Sep 25, 2011 at 11:34 PM, Arnaud Lacombe lacom...@gmail.com wrote: [...] 2) I saw many warnings of lock order reversals under the GENERIC kernel, in particular in the file system code. These obviously should be fixed before release. Where did you report them ? [btw, they might already be known.] FWIW, I've experienced 3 LOR in less than 15min. of usage, I'd assume all were fs related: 1) during partitioning. I've been unable to retrieve the backtrace. 2) when halting the system, already reported in [0] 3) while `rm -rf /boot/kernel/*.symbols', already reported in [1] - Arnaud [0]: http://ipv4.sources.zabbadoz.net/freebsd/lor/280.html [1]: http://ipv4.sources.zabbadoz.net/freebsd/lor/261.html ___ 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
BHyVe web page
Hi, I have created a web page for the BSD Hypervisor (BHyVe) project: http://wiki.freebsd.org/BHyVe This page contains pointers to how to get the BHyVe code, build it, etc. It will be updated with more documentation over time. Please send followup questions to freebsd-virtualizat...@freebsd.org . -- Craig Rodrigues rodr...@crodrigues.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: Experiences with FreeBSD 9.0-BETA2
On Mon, 26 Sep 2011, Brett Glass wrote: At 12:03 PM 9/26/2011, Benjamin Kaduk wrote: On Mon, 26 Sep 2011, John Baldwin wrote: I can't speak to the one-big-fs bit (there was another thread long ago about that). However, as to the partitioning bit, bsdinstall is defaulting to using The question of how to layout and split filesystems was discussed at the filesystems working group of the devsummit at BSDCan this may. (http://wiki.freebsd.org/201105DevSummit/FileSystems down to Filesystem Layout near the bottom) Though one big root did not garner a huge amount of support, neither were there particularly compelling arguments against it (if I remember correctly). It's certainly easier to write an autopartitioner for, so I don't really blame Nathan for having chosen it initially. My personal preference would be to place portions of the directory tree which contain critical configuration information and are not written in normal use -- e.g. /etc and /boot -- in one or more separate partitions. This would make it possible to mount them read-only unless the system configuration was being changed, new software was being installed, or a new kernel was being generated. This would protect them not only from malicious tampering but also from being scrambled by buggy userland software. And since it would not be written during normal operation, it would survive 100% intact even if journaling and/or serialization of metadata updates (e.g. softupdates) were to fail. Unfortunately, due to past history, /usr is mixed-use. It normally contains both configuration information -- e.g. /usr/local/etc -- and more volatile data such as users' home directories. This prevents /usr/local/etc, which also contains mission-critical configuration information, from being protected if you just protect /. Some proprietary Unices have fixed this historical flaw in the traditional hierarchy by moving /usr/local/etc to another location and them symlinking it back to where seasoned administrators expect it to be, thus honoring POLA. The three open source, old school BSDs (Free, Net, Open) have not done this to date, but it's something that should be considered in the long run. It would certainly make the creation of embedded systems easier, as well as enhancing security in multi-user systems! If I wrote an installer, my preference would be to have it create one partition that contained critical configuration information and software (and could be mounted read-only) and one that contained the rest of the usual directory tree (and could be mounted read-write). It could do the symlinking trick mentioned above to bring parts of /usr over to the read-only administrative partition. The only cleanup task that would remain would be to make sure that no ports were configured to place their logs, pid files, etc. in directories such as /usr/local/etc. (Most already do not.) There was also general sentiment that the rise of ZFS would allow just this sort of fine-grained partitioning, which is a huge advantage of its ability to create datasets on the fly. This perception that ZFS is most of the future probably contributed to the lack of strong opinions regarding the default UFS partition scheme. -Ben Kaduk ___ 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-BETA 2, camcontrol readcap, no passthrough device found
On Mon, Sep 26, 2011 at 03:14:29PM -0700, Craig Rodrigues wrote: Hi, I am running this version: 9.0-BETA2 FreeBSD 9.0-BETA2 #23 r225745: Fri Sep 23 19:45:09 PDT 2011 I found this behavior: % camcontrol devlist ST380815AS 4.ADA at scbus2 target 0 lun 0 (pass0,ada0) TEAC DVD-ROM DV28SV R.0A at scbus3 target 0 lun 0 (pass1,cd0) % camcontrol readcap 0:0:0 camcontrol: cam_open_btl: no passthrough device found at 0:0:0 % camcontrol readcap 0:0 camcontrol: cam_open_btl: no passthrough device found at 0:0:0 Surely the device ID in bus/target/LUN format should be 2:0:0 for the Seagate hard disk? Gary ___ 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: Experiences with FreeBSD 9.0-BETA2
On 09/26/2011 15:38, Benjamin Kaduk wrote: This perception that ZFS is most of the future probably contributed to the lack of strong opinions regarding the default UFS partition scheme. Can we please stop saying that there were no contrary opinions stated? I personally expressed a preference (call it strong if that helps) for split partition scheme, as did several other people, all with worked examples. Nathan chose to go one big partition in spite of that input. Given that he was the one doing the work on the installer I personally decided to take a step back and see how it played out. But let's not pretend that this wasn't Nathan's decision. Meanwhile, if based on feedback from early adopters we need to tweak the layout, that's not life threatening. There is still time. Doug -- 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: FreeBSD 9-Beta3 on X300 problems.
2. Kadu/Gnu Gadu. I dont know why, but when i run kadu / gnu gadu and try to connect to Gadu-Gadu network software segments ;/ Kadu with signal 6, GnuGadu with signal 11. I try to use old gadulib, or recompie it. But this doesn't help ;/ I run portmaster -y --no-confirm --packages-if-newer -m 'BATCH=yes' -d -a And... its works;) [cr4sh@x300 ~]$ uname -a FreeBSD x300 9.0-BETA3 FreeBSD 9.0-BETA3 #2: Mon Sep 26 00:25:30 CEST 2011 cr4sh@x300:/sys/amd64/compile/GENERIC amd64 Regards. ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-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: Experiences with FreeBSD 9.0-BETA2
On Mon, 26 Sep 2011, Doug Barton wrote: On 09/26/2011 15:38, Benjamin Kaduk wrote: This perception that ZFS is most of the future probably contributed to the lack of strong opinions regarding the default UFS partition scheme. Can we please stop saying that there were no contrary opinions stated? I My apologies; my statements refer only to the filesystems working group of the BSDCan devsummit. I seem to recall that you couldn't make it to BSDCan ... personally expressed a preference (call it strong if that helps) for split partition scheme, as did several other people, all with worked examples. Nathan chose to go one big partition in spite of that input. Given that he was the one doing the work on the installer I personally decided to take a step back and see how it played out. But let's not pretend that this wasn't Nathan's decision. Meanwhile, if based on feedback from early adopters we need to tweak the layout, that's not life threatening. There is still time. Yes, it was clearly Nathan's decision. And there is still time. -Ben Kaduk ___ 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-BETA 2, camcontrol readcap, no passthrough device found
On Mon, Sep 26, 2011 at 3:39 PM, Gary Palmer gpal...@freebsd.org wrote: Surely the device ID in bus/target/LUN format should be 2:0:0 for the Seagate hard disk? Ah, OK. Here is what I get now: These are the devices, as shown in the dmesg.boot output: ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0: ST380815AS 4.ADA ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 76293MB (15625 512 byte sectors: 16H 63S/T 16383C) cd0 at ahcich1 bus 0 scbus3 target 0 lun 0 cd0: TEAC DVD-ROM DV28SV R.0A Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) % camcontrol devlist ST380815AS 4.ADA at scbus2 target 0 lun 0 (pass0,ada0) TEAC DVD-ROM DV28SV R.0A at scbus3 target 0 lun 0 (pass1,cd0) % camcontrol readcap 2:0:0 (pass0:ahcich0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (pass0:ahcich0:0:0:0): CAM status: CCB request was invalid % camcontrol readcap 3:0:0 (pass1:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (pass1:ahcich1:0:0:0): CAM status: SCSI Status Error (pass1:ahcich1:0:0:0): SCSI status: Check Condition (pass1:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) % ls /dev/pass* /dev/pass0 /dev/pass1 Is camcontrol readcap supposed to work for an ATA disk? -- Craig Rodrigues rodr...@crodrigues.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: SCSI descriptor sense changes, testing needed
On Sat, Sep 24, 2011 at 21:27:22 +0200, Fabian Keil wrote: Kenneth D. Merry k...@freebsd.org wrote: I have attached a set of patches against head that implement SCSI descriptor sense support for CAM. Anyway, I'd appreciate any testing and feedback on these changes. As I said, they will probably be in 9.0, so if there are any issues it would be better to find them now. :) I've been using the patch on a ThinkPad R500 since yesterday and just reverted it today again to get my kernel closer to HEAD before looking into some (probably unrelated) panics. I didn't notice it while using the patch, but it looks like the kernel wasn't able to pick up cd0 anymore: Hmm. I don't think any of the changes would have caused this, but evidently something did... Let's see if we can debug it... I have attached a patch to add some debugging output, and I see at least one interesting thing in the logs below. Can you re-apply the descriptor sense patch, and then try the attached debugging patch as well? fk@r500 ~ $grep -h new dis /var/log/messages /var/log/messages.[123] | sort Sep 21 23:40:23 r500 kernel: GEOM: new disk da0 Sep 21 23:40:30 r500 kernel: GEOM: new disk da1 Sep 21 23:45:21 r500 kernel: GEOM: new disk ada0 Sep 21 23:45:21 r500 kernel: GEOM: new disk cd0 Sep 21 23:45:21 r500 kernel: GEOM: new disk da0 Sep 21 23:45:21 r500 kernel: GEOM: new disk da1 Sep 21 23:52:44 r500 kernel: GEOM: new disk ada0 Sep 21 23:52:44 r500 kernel: GEOM: new disk cd0 Sep 21 23:53:14 r500 kernel: GEOM: new disk da0 Sep 21 23:56:23 r500 kernel: GEOM: new disk da1 Sep 22 21:14:17 r500 kernel: GEOM: new disk ada0 Sep 22 21:14:17 r500 kernel: GEOM: new disk cd0 Sep 22 22:10:20 r500 kernel: GEOM: new disk da0 [patch applied] Sep 22 23:29:45 r500 kernel: GEOM: new disk da0 Sep 23 14:38:31 r500 kernel: GEOM: new disk ada0 Sep 23 17:19:40 r500 kernel: GEOM: new disk da0 Sep 23 19:20:21 r500 kernel: GEOM: new disk da0 Sep 23 19:20:42 r500 kernel: GEOM: new disk da1 Sep 23 22:58:56 r500 kernel: GEOM: new disk da0 Sep 24 09:31:02 r500 kernel: GEOM: new disk ada0 Sep 24 14:17:22 r500 kernel: GEOM: new disk da0 Sep 24 14:44:03 r500 kernel: GEOM: new disk ada0 Sep 24 14:44:03 r500 kernel: GEOM: new disk da0 Sep 24 14:53:30 r500 kernel: GEOM: new disk ada0 Sep 24 15:03:24 r500 kernel: GEOM: new disk da0 Sep 24 15:06:03 r500 kernel: GEOM: new disk da0 Sep 24 15:13:57 r500 kernel: GEOM: new disk ada0 Sep 24 15:14:16 r500 kernel: GEOM: new disk da0 Sep 24 15:27:11 r500 kernel: GEOM: new disk ada0 Sep 24 15:28:05 r500 kernel: GEOM: new disk da0 Sep 24 15:32:10 r500 kernel: GEOM: new disk ada0 Sep 24 15:32:10 r500 kernel: GEOM: new disk da0 Sep 24 15:38:16 r500 kernel: GEOM: new disk ada0 Sep 24 15:38:16 r500 kernel: GEOM: new disk da0 Sep 24 15:43:33 r500 kernel: GEOM: new disk ada0 Sep 24 15:43:33 r500 kernel: GEOM: new disk da0 Sep 24 15:49:30 r500 kernel: GEOM: new disk ada0 [patch reverted] Sep 24 19:32:51 r500 kernel: GEOM: new disk ada0 Sep 24 19:32:51 r500 kernel: GEOM: new disk cd0 Sep 24 19:32:51 r500 kernel: GEOM: new disk da0 Sep 24 19:38:07 r500 kernel: GEOM: new disk ada0 Sep 24 19:38:07 r500 kernel: GEOM: new disk cd0 Without the patch I'm used to getting the following kernel messages when booting (without a disc in cd0): Sep 24 19:32:51 r500 kernel: ahcich0: AHCI reset: device ready after 100ms Sep 24 19:32:51 r500 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: Sep 24 19:32:51 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 24 19:32:51 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 19:32:51 r500 kernel: GEOM: new disk cd0 Sep 24 19:32:51 r500 kernel: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 Sep 24 19:32:51 r500 kernel: pass0: HITACHI HTS543225L9SA00 FBEZC4EC ATA-8 SATA 1.x device Sep 24 19:32:51 r500 kernel: pass0: Serial Number 090509FB2F32LLEY6D8A Sep 24 19:32:51 r500 kernel: pass0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) Sep 24 19:32:51 r500 kernel: pass0: Command Queueing enabled Sep 24 19:32:51 r500 kernel: pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 Sep 24 19:32:51 r500 kernel: pass1: HL-DT-ST DVDRAM GSA-T50N RX05 Removable CD-ROM SCSI-0 device Sep 24 19:32:51 r500 kernel: pass1: Serial Number M2R96NC0647 Sep 24 19:32:51 r500 kernel: pass1: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condition Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Retrying command (per sense data) Sep 24 19:32:51 r500 kernel: ada0
Re: FreeBSD 9-Beta3 on X300 problems.
[majority of CC'd lists removed...] On 9/26/11 7:02 PM, crsnet.pl wrote: 2. Kadu/Gnu Gadu. I dont know why, but when i run kadu / gnu gadu and try to connect to Gadu-Gadu network software segments ;/ Kadu with signal 6, GnuGadu with signal 11. I try to use old gadulib, or recompie it. But this doesn't help ;/ I run portmaster -y --no-confirm --packages-if-newer -m 'BATCH=yes' -d -a And... its works;) There was a shared library bump between 9.0-BETA2 and 9.0-BETA3, which portmaster likely rebuilt the necessary dependencies. -- Glen Barber ___ 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-BETA 2, camcontrol readcap, no passthrough device found
On Mon, Sep 26, 2011 at 3:39 PM, Gary Palmer gpal...@freebsd.org wrote: On Mon, Sep 26, 2011 at 03:14:29PM -0700, Craig Rodrigues wrote: Hi, I am running this version: 9.0-BETA2 FreeBSD 9.0-BETA2 #23 r225745: Fri Sep 23 19:45:09 PDT 2011 I found this behavior: % camcontrol devlist ST380815AS 4.ADA at scbus2 target 0 lun 0 (pass0,ada0) TEAC DVD-ROM DV28SV R.0A at scbus3 target 0 lun 0 (pass1,cd0) % camcontrol readcap 0:0:0 camcontrol: cam_open_btl: no passthrough device found at 0:0:0 % camcontrol readcap 0:0 camcontrol: cam_open_btl: no passthrough device found at 0:0:0 Surely the device ID in bus/target/LUN format should be 2:0:0 for the Seagate hard disk? It doesn't work for me either using the correct target -- probably a bug in the driver. 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: Experiences with FreeBSD 9.0-BETA2
On Mon, 26 Sep 2011, Arnaud Lacombe wrote: Hi, On Mon, Sep 26, 2011 at 4:34 PM, Brett Glass br...@lariat.net wrote: My personal preference would be to place portions of the directory tree which contain critical configuration information and are not written in normal use -- e.g. /etc and /boot -- The problem with /boot on a dedicated partition is the the kernel, since at least 8.x, is installed by default with a vast majority of crap. That's all the .symbols, that 99% of FreeBSD users will never uses. My recollection is that this is because kensmith forgot to take 'makeoptions DEBUG=-g' out of GENERIC when branching stable/8, and no one noticed until a couple of releases in, at which point it seemed consistent with POLA to just keep it there. Unfortunately I am not having much luck digging through mail archives trying to confirm that. I don't remember whether the plan was to turn it off on stable/9 or not. Beside that, the auto-partitionner refuses to work on 1G drive, which is really ridiculous... FreeBSD 9.0BETA2 bases + games fit in 310MB, crap taken out. Can you even buy a spinning disk less than 50GB these days? If you have hardware of that nature, you are almost certainly going to want to customize other aspects of the system (and if it's an under-provisioned system, are you really going to be doing this customization in-place?), at which point removing the extra stuff is minimal extra work. If a developer has to ask a user to do something (e.g. compile) in order to debug something, there is a huge hit in the response rate; having the symbols available in the general case can be helpful. -Ben Kaduk ___ 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: Experiences with FreeBSD 9.0-BETA2
.. I do FreeBSD installs on 1GB flash disks. You know, so I don't have to nuke the windows install. Just so I can test out things. :) If people would like to see a more detailed partition editor, please supply patches to bsdinstall to do so. :-) I'd love to have multiple options - use all for one partition, do sysinstall-style auto partitioning. This is much more fun with GPT partitions where there's no 6 slice limit, right? 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: FreeBSD 9-Beta3 on X300 2 problems
Hi, Please try to do this without wlan loaded at all (not just down, but build your wifi support as a module.) Then try without X, see whether it's related to that or not. (And you haven't told us what your hardware is.) 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: Experiences with FreeBSD 9.0-BETA2
On Mon, Sep 26, 2011 at 5:17 PM, Adrian Chadd adr...@freebsd.org wrote: .. I do FreeBSD installs on 1GB flash disks. You know, so I don't have to nuke the windows install. Just so I can test out things. :) If people would like to see a more detailed partition editor, please supply patches to bsdinstall to do so. :-) I'd love to have multiple options - use all for one partition, do sysinstall-style auto partitioning. This is much more fun with GPT partitions where there's no 6 slice limit, right? MBR has a 4 slice limit. 6 would have been very nice! GPT allows 256 partitions. Whee! My current system disk has 7 real partitions. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@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: FreeBSD 9-Beta3 on X300 problems.
On 09/26/2011 16:02, crsnet.pl wrote: 2. Kadu/Gnu Gadu. I dont know why, but when i run kadu / gnu gadu and try to connect to Gadu-Gadu network software segments ;/ Kadu with signal 6, GnuGadu with signal 11. I try to use old gadulib, or recompie it. But this doesn't help ;/ I run portmaster -y --no-confirm --packages-if-newer -m 'BATCH=yes' -d -a The -y option is meaningless in that context, FYI. And... its works;) I'm glad to hear that at least. :) -- 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: ath / 802.11n performance issues and timer code
I spoke with John last night. This little gem popped up in the KTR trace. * the scheduler switches to the idle task * The interrupt comes in for ath0 * it gets added to the run queue * .. but then the idle task keeps running .. * .. until an arge0 interrupt comes in. There's also three statclock ticks too, in quick succession. Mav/John: the trace is at http://people.freebsd.org/~adrian/ath/ktr.4.sorted.txt . This includes KTR_SCHED, KTR_PROC, KTR_SPARE2 and KTR_INTR. Adrian 5772 (0x80907000) 2173896521 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_synch.c.453: mi_switch: new thread 100026 (td_sched 0x809072e8, pid 11, int2 arge0) 5773 (0x80907000) 2173896836 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_intr.c.1253: intr_event_execute_handlers: pid 11 exec 0x803665b8(0xc087d000) for arge0 flg=8000 5774 (0x80907000) 2173929763 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_synch.c.435: mi_switch: old thread 100026 (td_sched 0x809072e8, pid 11, int2 arge0) 5775 (0x80907000) 2173929941 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_synch.c.443: KTRGRAPH group:thread, id:int2 arge0 tid 100026, state:iwait, attributes: prio:8, wmesg:(null), lockname:(null) 5776 (0x80907000) 2173930059 /data/freebsd/mips/if_ath_tx/src/sys/kern/sched_4bsd.c.259: KTRGRAPH group:load, id:global load, counter:0, attributes: none 5777 (0x80629c80) 2173930552 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_synch.c.450: KTRGRAPH group:thread, id:idle tid 12, state:running, attributes: prio:255 5778 (0x80629c80) 2173930690 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_synch.c.453: mi_switch: new thread 12 (td_sched 0x80629f68, pid 10, idle) 5779 (0x80629c80) 2173931360 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clocksource.c.762: idle at 0:now 4606.6f61caa4e07acc40 5780 (0x80629c80) 2173932827 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_intr.c.1426: intr_event_handle: exec 0x803641a4(0x80908180) for pcib0 5781 (0x80629c80) 2173933777 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_intr.c.914: intr_event_schedule_thread: schedule pid 11 (pci intr0: ath0) 5782 (0x80629c80) 2173933969 /data/freebsd/mips/if_ath_tx/src/sys/kern/sched_4bsd.c.1314: KTRGRAPH group:thread, id:pci intr0: ath0 tid 100023, state:runq add, attributes: prio:8, linkedto:idle tid 12 5783 (0x80629c80) 2173934091 /data/freebsd/mips/if_ath_tx/src/sys/kern/sched_4bsd.c.1316: KTRGRAPH group:thread, id:idle tid 12, point:wokeup, attributes: linkedto:pci intr0: ath0 tid 100023 5784 (0x80629c80) 2173934402 /data/freebsd/mips/if_ath_tx/src/sys/kern/sched_4bsd.c.251: KTRGRAPH group:load, id:global load, counter:1, attributes: none 5785 (0x80629c80) 2173935012 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clocksource.c.266: skip at 0: 85 5786 (0x80629c80) 2173935793 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clocksource.c.312: next at 0:next 4606.853c3a57fce2f2be by 0 5787 (0x80629c80) 2173935909 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clocksource.c.428: load at 0:next 4606.853c3a57fce2f2be eq 0 5788 (0x80629c80) 2179937582 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_intr.c.1426: intr_event_handle: exec 0x803652e8(0xc087d000) for arge0 5789 (0x80629c80) 2179938312 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_intr.c.914: intr_event_schedule_thread: schedule pid 11 (int2 arge0) 5790 (0x80629c80) 2179938447 /data/freebsd/mips/if_ath_tx/src/sys/kern/sched_4bsd.c.1314: KTRGRAPH group:thread, id:int2 arge0 tid 100026, state:runq add, attributes: prio:8, linkedto:idle tid 12 5791 (0x80629c80) 2179938569 /data/freebsd/mips/if_ath_tx/src/sys/kern/sched_4bsd.c.1316: KTRGRAPH group:thread, id:idle tid 12, point:wokeup, attributes: linkedto:int2 arge0 tid 100026 5792 (0x80629c80) 2179938719 /data/freebsd/mips/if_ath_tx/src/sys/kern/sched_4bsd.c.251: KTRGRAPH group:load, id:global load, counter:2, attributes: none 5793 (0x80629c80) 2179939169 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clocksource.c.791: active at 0: now 4606.73a77ad6245cfbb0 5794 (0x80629c80) 2179939379 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clocksource.c.186: handle at 0: now 4606.73a77ad6245cfbb0 5795 (0x80629c80) 2179942746 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clock.c.748: KTRGRAPH group:thread, id:idle tid 12, point:statclock, attributes: prio:255, stathz:127 5796 (0x80629c80) 2179943526 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clock.c.748: KTRGRAPH group:thread, id:idle tid 12, point:statclock, attributes: prio:255, stathz:127 5797 (0x80629c80) 2179943866 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clock.c.748: KTRGRAPH group:thread, id:idle tid 12, point:statclock, attributes: prio:255, stathz:127 5798 (0x80629c80) 217993 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clocksource.c.312: next at 0:next 4606.73d3c7a7dc1e5786 by 0 5799 (0x80629c80) 2179944558 /data/freebsd/mips/if_ath_tx/src/sys/kern/kern_clocksource.c.428: load at 0:next 4606.73d3c7a7dc1e5786 eq 0 5800 (0x80629c80)
Re: Experiences with FreeBSD 9.0-BETA2
Hi, On Mon, Sep 26, 2011 at 7:48 PM, Benjamin Kaduk ka...@mit.edu wrote: On Mon, 26 Sep 2011, Arnaud Lacombe wrote: Hi, On Mon, Sep 26, 2011 at 4:34 PM, Brett Glass br...@lariat.net wrote: My personal preference would be to place portions of the directory tree which contain critical configuration information and are not written in normal use -- e.g. /etc and /boot -- The problem with /boot on a dedicated partition is the the kernel, since at least 8.x, is installed by default with a vast majority of crap. That's all the .symbols, that 99% of FreeBSD users will never uses. My recollection is that this is because kensmith forgot to take 'makeoptions DEBUG=-g' out of GENERIC when branching stable/8, and no one noticed until a couple of releases in, at which point it seemed consistent with POLA to just keep it there. Unfortunately I am not having much luck digging through mail archives trying to confirm that. I don't remember whether the plan was to turn it off on stable/9 or not. Beside that, the auto-partitionner refuses to work on 1G drive, which is really ridiculous... FreeBSD 9.0BETA2 bases + games fit in 310MB, crap taken out. Can you even buy a spinning disk less than 50GB these days? The storage world is not limited to spinning hardware. Take a 512MB CF, put it in a soekris box, and you got an embedded system capable of doing a whole bunch of stuff. Now, FreeBSD may no longer want to target such niche usage. If you have hardware of that nature, you are almost certainly going to want to customize other aspects of the system (and if it's an under-provisioned system, are you really going to be doing this customization in-place?), at which point removing the extra stuff is minimal extra work. If a developer has to ask a user to do something (e.g. compile) in order to debug something, there is a huge hit in the response rate; having the symbols available in the general case can be helpful. Then why don't you provide symbols for the whole system, including binaries and libraries ? At least be consistent in your argument... And, yes, I have patches for that. - Arnaud ___ 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
ead...@freebsd.org wrote: Synopsis: 9.0 burncd error caused by change to cd0 from acd0 State-Changed-From-To: open-analyzed State-Changed-By: eadler State-Changed-When: Mon Sep 26 23:24:00 UTC 2011 State-Changed-Why: requires only a release notes entry; use cdrecord instead of burncd http://www.freebsd.org/cgi/query-pr.cgi?pr=160979 Your solution is very un-professional. What your solution purposes to do is do nothing. I think your judgment is flawed and a larger group of your peers need to review your judgment in this case. burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. You do not knowingly leave a non-working utility in the system, period, or not provide a included replacement for a popular utility as this one. The alternative is to fix burncd or backout the acd0 to cd0 change from 9.0 which may be the most desired solution because its obvious that no one researched the impact this change may have. This change may impact many ports that access cd/dvd drives for read and write access. burncd may be a very small worm in a large can of big worms. ___ 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: Experiences with FreeBSD 9.0-BETA2
Hi, On Mon, Sep 26, 2011 at 8:17 PM, Adrian Chadd adr...@freebsd.org wrote: .. I do FreeBSD installs on 1GB flash disks. You know, so I don't have to nuke the windows install. Just so I can test out things. :) If people would like to see a more detailed partition editor, please supply patches to bsdinstall to do so. :-) I'd love to have multiple options - use all for one partition, do sysinstall-style auto partitioning. This is much more fun with GPT partitions where there's no 6 slice limit, right? Yes, if you forgot about BSD disklabel. I do not really know where your 6 slice limit comes from, I used to have FreeBSD 5.x system with slices up to 'i' or 'j'. Now I concede that GPT looks sexier compared to the BSD label mess. - Arnaud ___ 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: Experiences with FreeBSD 9.0-BETA2
On Mon, Sep 26, 2011 at 5:59 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Mon, Sep 26, 2011 at 7:48 PM, Benjamin Kaduk ka...@mit.edu wrote: On Mon, 26 Sep 2011, Arnaud Lacombe wrote: Hi, On Mon, Sep 26, 2011 at 4:34 PM, Brett Glass br...@lariat.net wrote: My personal preference would be to place portions of the directory tree which contain critical configuration information and are not written in normal use -- e.g. /etc and /boot -- The problem with /boot on a dedicated partition is the the kernel, since at least 8.x, is installed by default with a vast majority of crap. That's all the .symbols, that 99% of FreeBSD users will never uses. My recollection is that this is because kensmith forgot to take 'makeoptions DEBUG=-g' out of GENERIC when branching stable/8, and no one noticed until a couple of releases in, at which point it seemed consistent with POLA to just keep it there. Unfortunately I am not having much luck digging through mail archives trying to confirm that. I don't remember whether the plan was to turn it off on stable/9 or not. Beside that, the auto-partitionner refuses to work on 1G drive, which is really ridiculous... FreeBSD 9.0BETA2 bases + games fit in 310MB, crap taken out. Can you even buy a spinning disk less than 50GB these days? The storage world is not limited to spinning hardware. Take a 512MB CF, put it in a soekris box, and you got an embedded system capable of doing a whole bunch of stuff. Now, FreeBSD may no longer want to target such niche usage. If you have hardware of that nature, you are almost certainly going to want to customize other aspects of the system (and if it's an under-provisioned system, are you really going to be doing this customization in-place?), at which point removing the extra stuff is minimal extra work. If a developer has to ask a user to do something (e.g. compile) in order to debug something, there is a huge hit in the response rate; having the symbols available in the general case can be helpful. Then why don't you provide symbols for the whole system, including binaries and libraries ? At least be consistent in your argument... And, yes, I have patches for that. For embedded this doesn't make sense with limited storage -- but that's what binutils enables: http://stackoverflow.com/questions/866721/how-to-generate-gcc-debug-symbol-outside-the-build-target . I've linked against debug symbols when doing debugging with gdb and I can definitely attest to the fact that it's convenient and works well when trying to produce tiny embedded images. 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
The alternative is to fix burncd or backout the acd0 to cd0 change from 9.0 which may be the most desired solution because its obvious that no one researched the impact this change may have. This change may impact many ports that access cd/dvd drives for read and write access. burncd may be a very small worm in a large can of big worms. This should be discussed on a mailing list and only one mailing list. Please don't cross post. I'm leaving it on -current because it seems the the most appropriate of all the lists CCed. Please don't CC me on replies unless a consensus is reached (and the PR needs to be changed). -- Eitan Adler Ports committer Bugbusting team ___ 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: Experiences with FreeBSD 9.0-BETA2
On Mon, 26 Sep 2011, Arnaud Lacombe wrote: Hi, The storage world is not limited to spinning hardware. Take a 512MB CF, put it in a soekris box, and you got an embedded system capable of doing a whole bunch of stuff. Now, FreeBSD may no longer want to target such niche usage. Sure we do! See nanobsd.sh and http://www.freebsd.org/doc/en/articles/nanobsd/index.html But the point is, if you are running an embedded system, it is almost certainly in your best interest to tune it a bit, to reduce disk/power/memory usage -- the default install should not feel too constrained by the limits of embedded systems. If you have hardware of that nature, you are almost certainly going to want to customize other aspects of the system (and if it's an under-provisioned system, are you really going to be doing this customization in-place?), at which point removing the extra stuff is minimal extra work. If a developer has to ask a user to do something (e.g. compile) in order to debug something, there is a huge hit in the response rate; having the symbols available in the general case can be helpful. Then why don't you provide symbols for the whole system, including binaries and libraries ? At least be consistent in your argument... And, yes, I have patches for that. Not really my argument; chance and POLA, really. But that's not my call to make. (Are the patches public/in a PR?) -Ben___ 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 9/26/11 8:59 PM, Fbsd8 wrote: ead...@freebsd.org wrote: Synopsis: 9.0 burncd error caused by change to cd0 from acd0 State-Changed-Why: requires only a release notes entry; use cdrecord instead of burncd The alternative is to fix burncd or backout the acd0 to cd0 change from 9.0 which may be the most desired solution because its obvious that no one researched the impact this change may have. /dev/cd0 is available through the atapicam(4) kernel module. Documenting this is not sufficient? -- Glen Barber ___ 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: Experiences with FreeBSD 9.0-BETA2
I just filed a bunch of PRs to make sure these comments don't get (too)
lost: 16104{6,7,8,9} and 161050.
-Ben Kaduk
___
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: Experiences with FreeBSD 9.0-BETA2
Hi, On Mon, Sep 26, 2011 at 9:13 PM, Benjamin Kaduk ka...@mit.edu wrote: On Mon, 26 Sep 2011, Arnaud Lacombe wrote: [...] Then why don't you provide symbols for the whole system, including binaries and libraries ? At least be consistent in your argument... And, yes, I have patches for that. Not really my argument; chance and POLA, really. But that's not my call to make. (Are the patches public/in a PR?) not yet, I need to split my local git branch into topic branches and put that on github. It was on my todo-list of this evening. - Arnaud ___ 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 09/26/2011 17:59, Fbsd8 wrote: Your solution is very un-professional. Good thing we're all volunteers. :) What your solution purposes to do is do nothing. I think your judgment is flawed and a larger group of your peers need to review your judgment in this case. Ok, done. Eitan is right. burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. I think you misunderstand the situation. So here are a few hopefully helpful facts: 1. The fact that something is in the base, or in the ports, has absolutely no bearing on whether one piece of software is fundamentally more useful or valuable than another. 2. burncd has only ever worked with a subset of the legacy ATA hardware. 3. ATA-CAM is on by default in FreeBSD 9 (which means that rather than acd0 as an ATA device you'll have cd0 as a SCSI device). 4. However, ATA-CAM is not mandatory, which means that leaving burncd in the base for those that want to continue using the legacy ATA interface is a perfectly reasonable course of action. 5. For those that wish to use the default ATA-CAM interface the cdrecord port provides a mature, full-featured solution. Even if it were possible to import it into the base, doing so would be a step in the wrong direction. You do not knowingly leave a non-working utility in the system, period, That makes sense, however see above. or not provide a included replacement for a popular utility as this one. The alternative already exists. The fact that it's not in the base has no relevance. I hope this clears up your confusion. If you have any further questions please direct them to freebsd-questi...@freebsd.org only. Doug -- 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 6:28 PM, Doug Barton do...@freebsd.org wrote: burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. I think you misunderstand the situation. So here are a few hopefully helpful facts: 1. The fact that something is in the base, or in the ports, has absolutely no bearing on whether one piece of software is fundamentally more useful or valuable than another. Hi, I have used burncd on many releases of FreeBSD, on many machines without problem. I can see the fact that burncd suddenly failing to work on ATAPI hardware could annoy and confused end-users. Fbsd8 has a valid point. Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out a more useful error message? ERROR: burncd does not work when ATAPI-CAM driver enabled. Install the sysutils/cdrtools port and use cdrecord instead. Please refer to http://www.freebsd.org/doc/handbook/creating-cds.html#CDRECORD; While it is necessary to document all these things in release notes, documentation, etc., I don't always read every single last line of documentation or release notes when using a system, and I suspect many end-users are the same. :) I am a big fan of having the system issue diagnostic errors that give the user a clue how to remedy the problem, or pointers to relevant information. I even put Please in the error message to be nice. :) -- Craig Rodrigues rodr...@crodrigues.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: Experiences with FreeBSD 9.0-BETA2
At 04:38 PM 9/26/2011, Benjamin Kaduk wrote: There was also general sentiment that the rise of ZFS would allow just this sort of fine-grained partitioning, which is a huge advantage of its ability to create datasets on the fly. This perception that ZFS is most of the future probably contributed to the lack of strong opinions regarding the default UFS partition scheme. Unfortunately, because ZFS is licensed under a viral license (not the GPL, but nonetheless one that isn't compatible with the BSD philosophy), I wouldn't want to see this happen. I'd rather see Hammer backported from Dragonfly. --Brett ___ 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 09/26/2011 18:43, Craig Rodrigues wrote: On Mon, Sep 26, 2011 at 6:28 PM, Doug Barton do...@freebsd.org wrote: burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. I think you misunderstand the situation. So here are a few hopefully helpful facts: 1. The fact that something is in the base, or in the ports, has absolutely no bearing on whether one piece of software is fundamentally more useful or valuable than another. Hi, I have used burncd on many releases of FreeBSD, on many machines without problem. I can see the fact that burncd suddenly failing to work on ATAPI hardware could annoy and confused end-users. It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which is a SCSI device. The fact that it's emulated doesn't matter. Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out a more useful error message? Sure, as soon as someone volunteers to create that patch. No one is *trying* to annoy users, but things change around here because people are interested in changing them. hth, Doug -- 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 6:58 PM, Doug Barton do...@freebsd.org wrote:
I have used burncd on many releases of FreeBSD, on many machines
without problem. I can see the fact that burncd suddenly failing to
work on ATAPI hardware could annoy and confused end-users.
It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which
is a SCSI device. The fact that it's emulated doesn't matter.
True, but the subtlety of that distinction will be lost on a lot of end-users
not familiar with the implementation of the FreeBSD storage implementation.
To them burncd just doesn't work, when it used to.
Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out
a more useful error message?
Sure, as soon as someone volunteers to create that patch. No one is
*trying* to annoy users, but things change around here because people
are interested in changing them.
I am not familiar enough with the ATA_CAM work. Is there a a sysctl or ioctl
that can be queried from userspace to detect if ATA_CAM is configured
in the kernel?
I would suggest something like:
flag = query for hw.ata.ata_cam_enabled sysctl;
if (flag == 1) {
printf(ERROR: ATA_CAM enabled, etc., etc.)
exit(1);
}
I only see these sysctls on a system with ATA_CAM enabled:
hw.ata.setmax: 0
hw.ata.wc: 1
hw.ata.atapi_dma: 1
hw.ata.ata_dma_check_80pin: 1
hw.ata.ata_dma: 1
dev.atapci.0.%desc: Intel ATA controller
dev.atapci.0.%driver: atapci
dev.atapci.0.%location: slot=3 function=2
dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x29b6 subvendor=0x1028
subdevice=0x0211 class=0x010185
dev.atapci.0.%parent: pci0
dev.ata.2.%desc: ATA channel 0
dev.ata.2.%driver: ata
dev.ata.2.%location: channel=0
dev.ata.2.%parent: atapci0
dev.ata.3.%desc: ATA channel 1
dev.ata.3.%driver: ata
dev.ata.3.%location: channel=1
dev.ata.3.%parent: atapci0
dev.ata.0.%driver: ata
dev.ata.0.%parent: isa0
dev.ata.1.%driver: ata
dev.ata.1.%parent: isa0
--
Craig Rodrigues
rodr...@crodrigues.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: Experiences with FreeBSD 9.0-BETA2
On Mon, Sep 26, 2011 at 09:11:12PM -0400, Arnaud Lacombe wrote: Hi, On Mon, Sep 26, 2011 at 8:17 PM, Adrian Chadd adr...@freebsd.org wrote: .. I do FreeBSD installs on 1GB flash disks. You know, so I don't have to nuke the windows install. Just so I can test out things. :) If people would like to see a more detailed partition editor, please supply patches to bsdinstall to do so. :-) I'd love to have multiple options - use all for one partition, do sysinstall-style auto partitioning. This is much more fun with GPT partitions where there's no 6 slice limit, right? Yes, if you forgot about BSD disklabel. I do not really know where your 6 slice limit comes from, I used to have FreeBSD 5.x system with slices up to 'i' or 'j'. BSD disklabel is limited to a maximum of 8 slices per MBR partition. The 'c' slice is reserved for the entire disk which leaves you with 7 usable. Not sure where the 6 number comes from unless you always block 'b' off for swap, or perhaps Adrian was meaning the old rule in sysinstall that seemed to only used the 'a' slice for the root partition. Theoretically you could probably end up with 28 slices (7 slices for each of 4 MBR partitions), maybe more if you delve into the murky underworld of extended partitions. man disklabel shows that the highest slice can be 'h', and I believe its correct. Gary ___ 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: Experiences with FreeBSD 9.0-BETA2
.. I'm allowed to make mistakes you know. The point was, 7+1 partitions isn't a lot. :) ___ 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: Failure upgrading from 8-stable to current (9.0-Beta2)
Hi
For me patch do not working
because tzsetup uses old tzsetup
I use this:
--- share/zoneinfo/Makefile (revision 224989)
+++ share/zoneinfo/Makefile (working copy)
@@ -72,7 +72,8 @@
optC=-C ${DESTDIR}; \
fi; \
echo Updating /etc/localtime; \
- tzsetup $${optC} -r; \
+ /usr/obj/usr/src/usr.sbin/tzsetup/tzsetup
$${optC} -r; \
fi; \
else \
echo Run tzsetup(8) manually to update /etc/localtime.; \
or run before world install
/usr/obj/usr/src/usr.sbin/tzsetup/tzsetup
I think it will be enough
--
С уважением,
Коньков mailto:kes-...@yandex.ru
___
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: Failure upgrading from 8-stable to current (9.0-Beta2)
2011/9/26 Коньков Евгений kes-...@yandex.ru:
Hi
For me patch do not working
because tzsetup uses old tzsetup
I use this:
--- share/zoneinfo/Makefile (revision 224989)
+++ share/zoneinfo/Makefile (working copy)
@@ -72,7 +72,8 @@
optC=-C ${DESTDIR}; \
fi; \
echo Updating /etc/localtime; \
- tzsetup $${optC} -r; \
+ /usr/obj/usr/src/usr.sbin/tzsetup/tzsetup
$${optC} -r; \
fi; \
else \
echo Run tzsetup(8) manually to update /etc/localtime.; \
or run before world install
/usr/obj/usr/src/usr.sbin/tzsetup/tzsetup
I think it will be enough
Or the patch attached to
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/160596 -- still open
after 3 weeks...
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: ath / 802.11n performance issues and timer code
Hi John/Alex. The AR71xx MIPS kernels didn't include PREEMPTION. This seems a bit silly, as it's needed by sched_4bsd to actually compile in the code in maybe_preempt(). So I added it, and it simply increased CPU use without fixing the issue. But yes, maybe_preempt() is now setting td_owepreempt. This however doesn't fix it. I have a gem of a trace here: http://people.freebsd.org/~adrian/ath/ktr.7.sorted.txt . I've added some ath interrupt and RX tasklet trace points. Look for RXEOL and work your way backwards. The course of events: * 2128: switch to idle * 2130: ath0 intr comes in * 2132/2133: put on runq, wakeup ath0 netisr * 2134: maybe_preempt gets called, so hopefully td_owepreempt is going on * 2136: skip in kern_clocksource.c * 2139: the clock0 interrupt comes in - the latency between 2138 and 2139 is huge (70ms?) At this point it schedules clock0 swi, where 11 statclock entries get recorded. Then it calls my ath netisr routine, but by this point RXEOL (end of RX descriptor list) has occured. Now, there was an ath0 interrupt just before this. Is it possible that two quick successive ath0 interrupts are triggering some strange behaviour? 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: ath / 802.11n performance issues and timer code
.. erm, sys/mips/mips/machdep.c:
/*
* call platform specific code to halt (until next interrupt) for the idle loop
*/
void
cpu_idle(int busy)
{
KASSERT((mips_rd_status() MIPS_SR_INT_IE) != 0,
(interrupts disabled in idle process.));
KASSERT((mips_rd_status() MIPS_INT_MASK) != 0,
(all interrupts masked in idle process.));
if (!busy) {
critical_enter();
cpu_idleclock();
}
__asm __volatile (wait);
if (!busy) {
cpu_activeclock();
critical_exit();
}
}
.. does that look right?
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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, 26 Sep 2011, Craig Rodrigues wrote:
On Mon, Sep 26, 2011 at 6:58 PM, Doug Barton do...@freebsd.org wrote:
I have used burncd on many releases of FreeBSD, on many machines
without problem. I can see the fact that burncd suddenly failing to
work on ATAPI hardware could annoy and confused end-users.
It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which
is a SCSI device. The fact that it's emulated doesn't matter.
True, but the subtlety of that distinction will be lost on a lot of end-users
not familiar with the implementation of the FreeBSD storage implementation.
To them burncd just doesn't work, when it used to.
Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out
a more useful error message?
Sure, as soon as someone volunteers to create that patch. No one is
*trying* to annoy users, but things change around here because people
are interested in changing them.
I am not familiar enough with the ATA_CAM work. Is there a a sysctl or ioctl
that can be queried from userspace to detect if ATA_CAM is configured
in the kernel?
I would suggest something like:
...
Please fix it and move on.
Thanks,
-Garrett
$ usr.sbin/burncd/burncd -f /dev/cd0 blank
burncd: device provided not an acd(4) device: /dev/cd0.
Please verify that your kernel is built with acd(4) and the beforementioned
device is supported by acd(4).Index: usr.sbin/burncd/burncd.c
===
--- usr.sbin/burncd/burncd.c(revision 225704)
+++ usr.sbin/burncd/burncd.c(working copy)
@@ -159,8 +159,16 @@
if ((fd = open(dev, O_RDWR, 0)) 0)
err(EX_NOINPUT, open(%s), dev);
- if (ioctl(fd, CDRIOCGETBLOCKSIZE, saved_block_size) 0)
- err(EX_IOERR, ioctl(CDRIOCGETBLOCKSIZE));
+ if (ioctl(fd, CDRIOCGETBLOCKSIZE, saved_block_size) 0) {
+ if (errno == ENOTTY)
+ errx(EX_IOERR,
+ device provided not an acd(4) device: %s.\n\n
+ Please verify that your kernel is built with
+ acd(4) and the beforementioned device is
+ supported by acd(4)., dev);
+ else
+ err(EX_IOERR, ioctl(CDRIOCGETBLOCKSIZE));
+ }
if (ioctl(fd, CDRIOCWRITESPEED, speed) 0)
err(EX_IOERR, ioctl(CDRIOCWRITESPEED));
___
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: ath / 802.11n performance issues and timer code
.. and as a follow up (and cc'ing attillo and freebsd-mips, in case it's relevant to other platforms and there's a MIPS specific thing to fix): * 2128: mi_switch to idle * 2129: kern_clocksource.c:762 - ie, cpu_idleclock() has been called * 2130: the ath interrupt comes in * 2134: it's skipped for now as the idle thread is in a critical section * 2136: kern_clocksource.c:266 - ie, getnextcpuevent(), inside cpu_idleclock(). What I bet is happening is this race between the critical section + cpu_idleclock() and the ath0 interrupt: * idle gets scheduled * critical_enter() is called in the mips cpu_idle() routine * the ath interrupt comes in here and gets handled, but since we're in a critical section, it won't preempt things * the cpu_idleclock() code completes without releasing the preemption, and the only thing that wakes up from that wait is the next interrupt (clock, arge0, etc.) 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 8:30 PM, Garrett Cooper yaneg...@gmail.com wrote: ... Please fix it and move on. Thanks, -Garrett $ usr.sbin/burncd/burncd -f /dev/cd0 blank burncd: device provided not an acd(4) device: /dev/cd0. Please verify that your kernel is built with acd(4) and the beforementioned device is supported by acd(4). Hi, That patch is an improvement over the existing behavior. However, we may want to go a bit farther. Here are some possible scenarios: (1) User has a system with ATAPI CD-ROM only. (2) User has a system with ATAPI CD-ROM *and* USB CD-ROM. (3) User has a system with USB CD-ROM only. (4) User has a system with ATAPI CD-ROM and SCSI CD-ROM (5) User has a system with SCSI CD-ROM only I would guess that (1) is the most common scenario, and end-users will definitely encounter it and complain. In the case of (1), it would be nice if we could fail if we try to burn to /dev/cd0, as per your patch, but still check to see if ATA_CAM is enabled in the kernel, and print out a message with pointers for using cdrtools. With your patch, a user will see a message about acd(4), and try to get it to compile/kldload/whatever acd(4) on their system, and then not get it to work because ATA_CAM is enabled. Adding notes to the burncd man page that burncd will not work on ATAPI devices if ATA_CAM is enabled would be good to do also. If the long term plan is to get rid of the old ATA subsystem, and completely move to ATA_CAM, then we should put a deprecation warning in the burncd man page as well, to give users a further heads-up. -- Craig Rodrigues rodr...@crodrigues.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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, 26 Sep 2011, Craig Rodrigues wrote: On Mon, Sep 26, 2011 at 8:30 PM, Garrett Cooper yaneg...@gmail.com wrote: ... Please fix it and move on. Thanks, -Garrett $ usr.sbin/burncd/burncd -f /dev/cd0 blank burncd: device provided not an acd(4) device: /dev/cd0. Please verify that your kernel is built with acd(4) and the beforementioned device is supported by acd(4). Hi, That patch is an improvement over the existing behavior. However, we may want to go a bit farther. Here are some possible scenarios: (1) User has a system with ATAPI CD-ROM only. Covered. (2) User has a system with ATAPI CD-ROM *and* USB CD-ROM. First case covered. Second case requires cdrecord anyhow, so don't care. (3) User has a system with USB CD-ROM only. Second case requires cdrecord anyhow, so don't care. (4) User has a system with ATAPI CD-ROM and SCSI CD-ROM Same as (2). (5) User has a system with SCSI CD-ROM only Same as (3). I would guess that (1) is the most common scenario, and end-users will definitely encounter it and complain. In the case of (1), it would be nice if we could fail if we try to burn to /dev/cd0, as per your patch, but still check to see if ATA_CAM is enabled in the kernel, and print out a message with pointers for using cdrtools. With your patch, a user will see a message about acd(4), and try to get it to compile/kldload/whatever acd(4) on their system, and then not get it to work because ATA_CAM is enabled. Adding notes to the burncd man page that burncd will not work on ATAPI devices if ATA_CAM is enabled would be good to do also. If the long term plan is to get rid of the old ATA subsystem, and completely move to ATA_CAM, then we should put a deprecation warning in the burncd man page as well, to give users a further heads-up. Noting something in the documentation is fine. The point is that there's a lot of wasted electrons being tossed about about a fairly trivial issue: most of the apps that burn/use CDs were converted over to some logic long ago that matches cdrecord. The only apps that haven't really been (atacontrol, burncd) were abandoned because the developer isn't an active maintainer. 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
.. and if someone would like to contribute patches to burncd to update it, I think there'd be at least one committer here who would be happy to help you get your changes into the tree. :-) 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: Experiences with FreeBSD 9.0-BETA2
On Mon, 26 Sep 2011, Gary Palmer wrote: BSD disklabel is limited to a maximum of 8 slices per MBR partition. Careful. disklabel/bsdlabel creates FreeBSD partitions, up to 8 per MBR partition (FreeBSD slice). Instead of three different things that share two names, GPT only has partitions. ___ 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: Experiences with FreeBSD 9.0-BETA2
On Mon, Sep 26, 2011 at 7:20 PM, Adrian Chadd adr...@freebsd.org wrote: .. I'm allowed to make mistakes you know. The point was, 7+1 partitions isn't a lot. :) Just in case someone new is reading this and getting confused. I believe those taking part mostly understand this as well as or better than I do. MBR allows 4 slices (which Windows and most of the world call partitions). Windows also allows the creation of Extended Partitions, but FreeBSD does not support these. They result in device named with an 's' for slice. E.g. da0s1. BSDlabel will subdivide what FreeBSD calls a slice into a number of what FreeBSD calls partitions. Each is tagged with a single letter. E.g. da0s1a. You can have up to 8 partitions, but 'c' isgenerally reserved for the whole slice, so you really have 7+1 or 7 useful partitions. Under GPT, partitions are partitions and you can have 128 of them. (I previously said 256. 128 is correct. Sorry. They are denoted by appending 'p' for partition followed by the number of the partition index which starts with '1'. E.g. da0p1. gpart(8) will support both MBR and GPT structures., but to deal with MBR disks, you slice the disk to create slices and then partition the slices. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@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
HEADS UP: ports/ and 10.0-CURRENT
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be expected, ports/ is going to be essentially unusable for a while. The issue stems from configure scripts (to choose something completely at random) assuming that FreeBSD would never jump to a double-digit major version number, and as such, various regexps for freebsd1* (ie: FreeBSD 1.1.x) are now matching freebsd10. This is going to be some fairly fundamental breakage. However, until such time as 9.0-RELEASE is completely out of the door, with autotools hat on, I will _not_ be committing any changes to infrastructural ports to fix this. That is to say, until 9.0-R happens, and for some considerable period afterwards, ya'll can pretty much expect ports/ to be non-functional on HEAD. PRs mentioning this will be gleefully closed referencing this message. -aDe Reply-To set to me. Please honor it. ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett a...@freebsd.org wrote: With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be expected, ports/ is going to be essentially unusable for a while. The issue stems from configure scripts (to choose something completely at random) assuming that FreeBSD would never jump to a double-digit major version number, and as such, various regexps for freebsd1* (ie: FreeBSD 1.1.x) are now matching freebsd10. This is going to be some fairly fundamental breakage. However, until such time as 9.0-RELEASE is completely out of the door, with autotools hat on, I will _not_ be committing any changes to infrastructural ports to fix this. That is to say, until 9.0-R happens, and for some considerable period afterwards, ya'll can pretty much expect ports/ to be non-functional on HEAD. PRs mentioning this will be gleefully closed referencing this message. aDe, Could an entry to this effect be added to UPDATING (with a matching entry when ports/ is unbroken). Anyone running CURRENT should be reading your message, but I'm a belt and suspenders type of guy on this sort of thing. Backing out of CURRENT and moving to 9-STABLE can be a REAL pain that will likely rapidly get worse as HEAD gets less and less frozen. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@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: HEADS UP: ports/ and 10.0-CURRENT
On Mon, Sep 26, 2011 at 9:56 PM, Kevin Oberman kob6...@gmail.com wrote: On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett a...@freebsd.org wrote: With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be expected, ports/ is going to be essentially unusable for a while. The issue stems from configure scripts (to choose something completely at random) assuming that FreeBSD would never jump to a double-digit major version number, and as such, various regexps for freebsd1* (ie: FreeBSD 1.1.x) are now matching freebsd10. This is going to be some fairly fundamental breakage. However, until such time as 9.0-RELEASE is completely out of the door, with autotools hat on, I will _not_ be committing any changes to infrastructural ports to fix this. That is to say, until 9.0-R happens, and for some considerable period afterwards, ya'll can pretty much expect ports/ to be non-functional on HEAD. PRs mentioning this will be gleefully closed referencing this message. aDe, Could an entry to this effect be added to UPDATING (with a matching entry when ports/ is unbroken). Being a pessimist, ports will never be fully unbroken unless all the thousands of autotools based ports as fixed, due to unfortunately code duplication. That being said, I think that a note in /usr/ports/UPDATING as well as /usr/src/UPDATING is a VERY good idea. Anyone running CURRENT should be reading your message, but I'm a belt and suspenders type of guy on this sort of thing. Backing out of CURRENT and moving to 9-STABLE can be a REAL pain that will likely rapidly get worse as HEAD gets less and less frozen. It's not the FreeBSD dev's fault. Unfortunately the autotools folks were microoptimizing and didn't consider that the future would come sooner than it actually did. 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: HEADS UP: ports/ and 10.0-CURRENT
On Mon, Sep 26, 2011 at 10:01 PM, Garrett Cooper yaneg...@gmail.com wrote: It's not the FreeBSD dev's fault. Unfortunately the autotools folks were microoptimizing and didn't consider that the future would come sooner than it actually did. Garrett, First, I'm not complaining or criticizing any of the developers and I am very grateful to aDe for maintaining them as I get a headache every time I start looking at them. I am baffled in my attempts to parse didn't consider that the future would come sooner than it actually did. Is that what you really meant, because it's self-contradictory? Or am I just confused. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@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: HEADS UP: ports/ and 10.0-CURRENT
On Mon, Sep 26, 2011 at 10:15 PM, Kevin Oberman kob6...@gmail.com wrote: On Mon, Sep 26, 2011 at 10:01 PM, Garrett Cooper yaneg...@gmail.com wrote: It's not the FreeBSD dev's fault. Unfortunately the autotools folks were microoptimizing and didn't consider that the future would come sooner than it actually did. First, I'm not complaining or criticizing any of the developers and I am very grateful to aDe for maintaining them as I get a headache every time I start looking at them. I am baffled in my attempts to parse didn't consider that the future would come sooner than it actually did. Is that what you really meant, because it's self-contradictory? Or am I just confused. It just means that folks didn't plan ahead and didn't think up proper contingency plans. FWIW FreeBSD has developed faster in the last couple of years than most folks would have expected -- including myself -- and the release cycles reflect that change. That's more of what I was addressing in my previous reply. Corner cases are the bane of all software developers. -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
kernel panic with swap zone exhausted, increase kern.maxswzone
My computer recently paniced and broke into ddb after spamming my console with swap zone exhausted, increase kern.maxswzone Immediately prior to the panic X was killed and I was able to switch to vty1 and log in as root (I planned on killing runaway programs) I called doadump and have the saved textdump, vmcore.0 and kernel available to provide any relevant information. They are fairly large so I'll provide them upon request. I'm running FreeBSD radar 9.0-BETA2 FreeBSD 9.0-BETA2 #0 r225471M: Mon Sep 12 20:43:44 EDT 2011 eitan@radar:/usr/obj/usr/src/head/sys/EADLER amd64 This is the diff between my kernel and GENERIC: http://people.freebsd.org/~eadler/files/diff-my-kernel-and-generic.diff gdb bt #0 doadump (textdump=0x31d622d0) at /usr/src/head/sys/kern/kern_shutdown.c:260 #1 0x802ea54c in db_fncall (dummy1=Variable dummy1 is not available. ) at /usr/src/head/sys/ddb/db_command.c:572 #2 0x802ea881 in db_command (last_cmdp=0x80e5a6c0, cmd_table=Variable cmd_table is not available. ) at /usr/src/head/sys/ddb/db_command.c:448 #3 0x802eaad0 in db_command_loop () at /usr/src/head/sys/ddb/db_command.c:501 #4 0x802ecc19 in db_trap (type=Variable type is not available. ) at /usr/src/head/sys/ddb/db_main.c:229 #5 0x807731f1 in kdb_trap (type=0x3, code=0x0, tf=0xff8231d62500) at /usr/src/head/sys/kern/subr_kdb.c:631 #6 0x809c0e36 in trap (frame=0xff8231d62500) at /usr/src/head/sys/amd64/amd64/trap.c:590 #7 0x809ab5df in calltrap () at /usr/src/head/sys/amd64/amd64/exception.S:228 #8 0x80772f9b in kdb_enter (why=0x80aec7a0 panic, msg=0x80 Address 0x80 out of bounds) at cpufunc.h:63 #9 0x8073db00 in panic (fmt=Variable fmt is not available. ) at /usr/src/head/sys/kern/kern_shutdown.c:599 #10 0x807836f8 in propagate_priority (td=0xfe011de2a000) at /usr/src/head/sys/kern/subr_turnstile.c:222 #11 0x80784842 in turnstile_wait (ts=0xfe006685e900, owner=0xfe011de2a000, queue=0x0) at /usr/src/head/sys/kern/subr_turnstile.c:738 #12 0x8072ed16 in _mtx_lock_sleep (m=0xfe00804100f8, tid=0xfe01c2425460, opts=Variable opts is not a vailable. ) at /usr/src/head/sys/kern/kern_mutex.c:447 #13 0x8072ee20 in _mtx_lock_flags (m=Variable m is not available. ) at /usr/src/head/sys/kern/kern_mutex.c:203 #14 0x80740443 in sigexit (td=0xfe01c2425460, sig=0xb) at /usr/src/head/sys/kern/kern_sig.c:3269 #15 0x80741ed0 in postsig (sig=Variable sig is not available. ) at /usr/src/head/sys/kern/kern_sig.c:2765 #16 0x8078210b in ast (framep=0xff8231d62c50) at /usr/src/head/sys/kern/subr_trap.c:232 #17 0x809ac639 in doreti_ast () at /usr/src/head/sys/amd64/amd64/exception.S:674 #18 0x0060aa10 in ?? () #19 0x000801063000 in ?? () -- Eitan Adler ___ 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
