Re: Thoughts on TMPFS no longer being considered highly experimental
On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c (revision 221113) +++ tmpfs_vfsops.c (working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); The things I am aware of: - there is a races on the lookup. They were papered over in r212305, but the bug was not really fixed, AFAIR. - the tmpfs does double-buffering for the mapped vnodes. This is quite insulting for the memory-backed fs, isn't it ? I have a patch, but it is still under review. - I believe Peter Holm has more test cases that fails with tmpfs. He would have more details. I somewhat remember some panic on execve(2) the binary located on tmpfs. I ran the TMPFS tests I have and so far I only spotted the mmap(2) problem: http://people.freebsd.org/~pho/stress/log/tmpfs/ Removing the warning will not make the issues coming away. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4DoGEACgkQC3+MBN1Mb4j9wwCg0V37VuQUw5heAl/Z/iAlO+h0 SmAAoJf/+BF533SS0hUjGsscsSAqUApX =5GKO -END PGP SIGNATURE- -- Peter ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on arm/arm
TB --- 2011-06-24 09:30:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-24 09:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-06-24 09:30:00 - cleaning the object tree TB --- 2011-06-24 09:30:21 - cvsupping the source tree TB --- 2011-06-24 09:30:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-06-24 09:30:46 - building world TB --- 2011-06-24 09:30:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 09:30:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 09:30:46 - TARGET=arm TB --- 2011-06-24 09:30:46 - TARGET_ARCH=arm TB --- 2011-06-24 09:30:46 - TZ=UTC TB --- 2011-06-24 09:30:46 - __MAKE_CONF=/dev/null TB --- 2011-06-24 09:30:46 - cd /src TB --- 2011-06-24 09:30:46 - /usr/bin/make -B buildworld World build started on Fri Jun 24 09:30:47 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Jun 24 10:25:42 UTC 2011 TB --- 2011-06-24 10:25:43 - WARNING: no kernel config for LINT TB --- 2011-06-24 10:25:43 - cd /src/sys/arm/conf TB --- 2011-06-24 10:25:43 - /usr/sbin/config -m AVILA TB --- 2011-06-24 10:25:43 - building AVILA kernel TB --- 2011-06-24 10:25:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 10:25:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 10:25:43 - TARGET=arm TB --- 2011-06-24 10:25:43 - TARGET_ARCH=arm TB --- 2011-06-24 10:25:43 - TZ=UTC TB --- 2011-06-24 10:25:43 - __MAKE_CONF=/dev/null TB --- 2011-06-24 10:25:43 - cd /src TB --- 2011-06-24 10:25:43 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Fri Jun 24 10:25:43 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for AVILA completed on Fri Jun 24 10:28:59 UTC 2011 TB --- 2011-06-24 10:28:59 - cd /src/sys/arm/conf TB --- 2011-06-24 10:28:59 - /usr/sbin/config -m BWCT TB --- 2011-06-24 10:28:59 - building BWCT kernel TB --- 2011-06-24 10:28:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 10:28:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 10:28:59 - TARGET=arm TB --- 2011-06-24 10:28:59 - TARGET_ARCH=arm TB --- 2011-06-24 10:28:59 - TZ=UTC TB --- 2011-06-24 10:28:59 - __MAKE_CONF=/dev/null TB --- 2011-06-24 10:28:59 - cd /src TB --- 2011-06-24 10:28:59 - /usr/bin/make -B buildkernel KERNCONF=BWCT Kernel build for BWCT started on Fri Jun 24 10:28:59 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for BWCT completed on Fri Jun 24 10:31:00 UTC 2011 TB --- 2011-06-24 10:31:00 - cd /src/sys/arm/conf TB --- 2011-06-24 10:31:00 - /usr/sbin/config -m CAMBRIA TB --- 2011-06-24 10:31:00 - building CAMBRIA kernel TB --- 2011-06-24 10:31:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 10:31:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 10:31:00 - TARGET=arm TB --- 2011-06-24 10:31:00 - TARGET_ARCH=arm TB --- 2011-06-24 10:31:00 - TZ=UTC TB --- 2011-06-24 10:31:00 - __MAKE_CONF=/dev/null TB --- 2011-06-24 10:31:00 - cd /src TB --- 2011-06-24 10:31:00 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA Kernel build for CAMBRIA started on Fri Jun 24 10:31:00 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah.c:897: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_setTxQProps': /src/sys/dev/ath/ath_hal/ah.c:870: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_get_mimo_chan_noise': /src/sys/dev/ath/ath_hal/ah.c:1003: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_getChanNoise': /src/sys/dev/ath/ath_hal/ah.c:929: undefined reference to `ath_hal_debug' ah.o:/src/sys/dev/ath/ath_hal/ah.c:223: more undefined references to `ath_hal_debug' follow *** Error code 1 Stop in /obj/arm.arm/src/sys/CAMBRIA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-24 10:33:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-24 10:33:43 - ERROR: failed to build CAMBRIA kernel TB --- 2011-06-24 10:33:43 - 2743.54 user 796.68 system 3822.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
Re: misc/157903: automated kldload for USB class devices
On Friday 24 June 2011 09:22:57 Robert Millan wrote: 2011/6/24 Hans Petter Selasky hsela...@c2i.net: Updated bus_auto.conf: http://hselasky.homeunix.org:8192/bus_auto.conf Very nice. But why not use variable names instead of hardcoding numbers? It makes the output much easier to understand. To save memory. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
On Fri, Jun 24, 2011 at 12:30:16PM +0200, Peter Holm wrote: On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c(revision 221113) +++ tmpfs_vfsops.c(working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); The things I am aware of: - there is a races on the lookup. They were papered over in r212305, but the bug was not really fixed, AFAIR. - the tmpfs does double-buffering for the mapped vnodes. This is quite insulting for the memory-backed fs, isn't it ? I have a patch, but it is still under review. - I believe Peter Holm has more test cases that fails with tmpfs. He would have more details. I somewhat remember some panic on execve(2) the binary located on tmpfs. I ran the TMPFS tests I have and so far I only spotted the mmap(2) problem: http://people.freebsd.org/~pho/stress/log/tmpfs/ It would be indeed good if the issue was the only remaining problem. The deadlock in tmpfs6.txt is caused by doing copyin() while having a page busied. This should be fixed indirectly by the patch to avoid double-buffering, I uploaded the latest version at http://people.freebsd.org/~kib/misc/tmpfs.5.patch Removing the warning will not make the issues coming away. pgpG7yzLh0Ehi.pgp Description: PGP signature
Re: misc/157903: automated kldload for USB class devices
2011/6/24 Hans Petter Selasky hsela...@c2i.net: Updated bus_auto.conf: http://hselasky.homeunix.org:8192/bus_auto.conf Very nice. But why not use variable names instead of hardcoding numbers? It makes the output much easier to understand. -- Robert Millan ___ 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
MFC
Hello all i have a question regarding MFC At the svn page from head most revisions comments contain a line like MFC after:x weeks or x days. or x months. Is this done automaticly, or is this still done by the auther. I came to this question, because of the following. http://svnweb.freebsd.org/base?view=revisionrevision=217174 MFC after 3 weeks, but it looks likei t still has not been MFC'd That is 4 months ago And if so are there more patches that goes not into STABLE? Regards, Johan Hendriks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MFC
on 24/06/2011 14:44 Johan Hendriks said the following: Hello all i have a question regarding MFC At the svn page from head most revisions comments contain a line like MFC after:x weeks or x days. or x months. Is this done automaticly, or is this still done by the auther. It's done manually. 'MFC after' only states original intent. Sometimes developers forget to do MFC; sometimes they discover new circumstances which prevent MFC; etc. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release: doesn't work for me, getting
Attempting to run: make release resulted in 'looping' until a kernel compile directory sys/amd64/compile/* was removed. Maybe I missed something in the docs. -kim ___ 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: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On Thu, Jun 23, 2011 at 11:01:17PM -0400, Justin T. Gibbs wrote: To test this theory, apply the following patch. I do not know if this is safe for changer devices, but I will review the changer code if this patch fixes ache's problem. I don't have changers. One of the plain ATA DVDs is read-only (cd0, which is not detected now) and another one is read-write (cd1, detected). I try the patch but nothing is changed in the picture. cd0 still not detected, xpt_thrd sleep in ccb_scan and g_event sleep in caplck. Here is probe from the old kernel which works, just in case, nothing unusual with it: cd0 at ata2 bus 0 scbus2 target 0 lun 0 cd0: ASUS DVD-E616A 1.08 Removable CD-ROM SCSI-0 device cd0: 100.000MB/s transfers (UDMA5, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Unplugging power from it allows to boot normally. Inserting media does not help too. --- //depot/vendor/FreeBSD/head/sys/cam/scsi/scsi_cd.c2011-05-07 10:06:43.0 -0600 +++ /home/justing/perforce/vendor/FreeBSD/head/sys/cam/scsi/scsi_cd.c 2011-05-07 10:06:43.0 -0600 @@ -687,6 +687,10 @@ else softc-minimum_command_size = 6; + /* + * Refcount and block open attempts until we are setup + * Can't block + */ (void)cam_periph_hold(periph, PRIBIO); cam_periph_unlock(periph); /* @@ -747,7 +751,6 @@ softc-disk-d_hba_subdevice = cpi.hba_subdevice; disk_create(softc-disk, DISK_VERSION); cam_periph_lock(periph); - cam_periph_unhold(periph); /* * Add an async callback so that we get @@ -972,12 +975,6 @@ cdregisterexit: - /* - * Refcount and block open attempts until we are setup - * Can't block - */ - (void)cam_periph_hold(periph, PRIBIO); - if ((softc-flags CD_FLAG_CHANGER) == 0) xpt_schedule(periph, CAM_PRIORITY_DEV); else ___ 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 -- 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: misc/157903: automated kldload for USB class devices
On Friday 24 June 2011 14:59:37 Robert Millan wrote: 2011/6/24 Hans Petter Selasky hsela...@c2i.net: Very nice. But why not use variable names instead of hardcoding numbers? It makes the output much easier to understand. To save memory. I haven't inspected devd code, but I was under the assumption that variables only lived untill resolved. What would be the point of keeping them in memory after devd has finished parsing the config files? Hi, I haven't checked that, though if you want the readable version, then you need to check the source code. However I could add some code to print a vendor ID comment, based on usbdevs. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
On Fri, Jun 24, 2011 at 02:06:27PM +0300, Kostik Belousov wrote:
On Fri, Jun 24, 2011 at 12:30:16PM +0200, Peter Holm wrote:
On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote:
On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote:
Does anyone object to this patch?
David Wolfskill and I have run TMPFS on a number of machines for two
years with no problems.
I may have missed something, but I'm not aware of any serious PRs on
TMPFS either.
Index: tmpfs_vfsops.c
===
--- tmpfs_vfsops.c (revision 221113)
+++ tmpfs_vfsops.c (working copy)
@@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
return EOPNOTSUPP;
}
- printf(WARNING: TMPFS is considered to be a highly
experimental
- feature in FreeBSD.\n);
-
vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY);
error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred);
VOP_UNLOCK(mp-mnt_vnodecovered, 0);
The things I am aware of:
- there is a races on the lookup. They were papered over in r212305,
but the bug was not really fixed, AFAIR.
- the tmpfs does double-buffering for the mapped vnodes. This is quite
insulting for the memory-backed fs, isn't it ? I have a patch, but it is
still under review.
- I believe Peter Holm has more test cases that fails with tmpfs. He
would have more details. I somewhat remember some panic on execve(2) the
binary located on tmpfs.
I ran the TMPFS tests I have and so far I only spotted the mmap(2)
problem:
http://people.freebsd.org/~pho/stress/log/tmpfs/
It would be indeed good if the issue was the only remaining problem.
Well, more testing is needed for sure.
The deadlock in tmpfs6.txt is caused by doing copyin() while having
a page busied. This should be fixed indirectly by the patch to
avoid double-buffering, I uploaded the latest version at
http://people.freebsd.org/~kib/misc/tmpfs.5.patch
Removing the warning will not make the issues coming away.
This doesn't compile:
=== tmpfs (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/src/sys/i386/compile/PHO/opt_global.h -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common -g -I/usr/src/sys/i386/compile/PHO
-mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse
-mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999
-fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option -c
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
cc1: warnings being treated as errors
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c: In function
'tmpfs_reg_resize':
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:911: warning: 'uobj' is
used uninitialized in this function
*** Error code 1
886 int
887 tmpfs_reg_resize(struct vnode *vp, off_t newsize)
888 {
889 struct tmpfs_mount *tmp;
890 struct tmpfs_node *node;
891 vm_object_t uobj;
892 vm_page_t m;
893 vm_pindex_t newpages, oldpages;
894 off_t oldsize;
895 size_t zerolen;
896
897 MPASS(vp-v_type == VREG);
898 MPASS(newsize = 0);
899
900 node = VP_TO_TMPFS_NODE(vp);
901 tmp = VFS_TO_TMPFS(vp-v_mount);
902
903 /*
904 * Convert the old and new sizes to the number of pages needed to
905 * store them. It may happen that we do not need to do anything
906 * because the last allocated page can accommodate the change on
907 * its own.
908 */
909 oldsize = node-tn_size;
910 oldpages = OFF_TO_IDX(oldsize + PAGE_MASK);
911 MPASS(oldpages == uobj-size);
912 newpages = OFF_TO_IDX(newsize + PAGE_MASK);
913 if (newpages oldpages
914 newpages - oldpages TMPFS_PAGES_AVAIL(tmp))
915 return (ENOSPC);
916
917 TMPFS_LOCK(tmp);
918 tmp-tm_pages_used += (newpages - oldpages);
919 TMPFS_UNLOCK(tmp);
920
921 node-tn_size = newsize;
922 VM_OBJECT_LOCK(uobj);
- Peter
___
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: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
I forget to mention that the place is the same as trace shows: g_event_procbody-g_run_events-g_new_provider_event-g_dev_taste- g_dev_attrchanged-g_access-g_disk_access-cdopen-cam_periph_hold and it sleeps. On Fri, Jun 24, 2011 at 05:08:27PM +0400, Andrey Chernov wrote: On Thu, Jun 23, 2011 at 11:01:17PM -0400, Justin T. Gibbs wrote: To test this theory, apply the following patch. I do not know if this is safe for changer devices, but I will review the changer code if this patch fixes ache's problem. I don't have changers. One of the plain ATA DVDs is read-only (cd0, which is not detected now) and another one is read-write (cd1, detected). I try the patch but nothing is changed in the picture. cd0 still not detected, xpt_thrd sleep in ccb_scan and g_event sleep in caplck. Here is probe from the old kernel which works, just in case, nothing unusual with it: cd0 at ata2 bus 0 scbus2 target 0 lun 0 cd0: ASUS DVD-E616A 1.08 Removable CD-ROM SCSI-0 device cd0: 100.000MB/s transfers (UDMA5, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Unplugging power from it allows to boot normally. Inserting media does not help too. --- //depot/vendor/FreeBSD/head/sys/cam/scsi/scsi_cd.c 2011-05-07 10:06:43.0 -0600 +++ /home/justing/perforce/vendor/FreeBSD/head/sys/cam/scsi/scsi_cd.c 2011-05-07 10:06:43.0 -0600 @@ -687,6 +687,10 @@ else softc-minimum_command_size = 6; + /* +* Refcount and block open attempts until we are setup +* Can't block +*/ (void)cam_periph_hold(periph, PRIBIO); cam_periph_unlock(periph); /* @@ -747,7 +751,6 @@ softc-disk-d_hba_subdevice = cpi.hba_subdevice; disk_create(softc-disk, DISK_VERSION); cam_periph_lock(periph); - cam_periph_unhold(periph); /* * Add an async callback so that we get @@ -972,12 +975,6 @@ cdregisterexit: - /* -* Refcount and block open attempts until we are setup -* Can't block -*/ - (void)cam_periph_hold(periph, PRIBIO); - if ((softc-flags CD_FLAG_CHANGER) == 0) xpt_schedule(periph, CAM_PRIORITY_DEV); else ___ 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 -- 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 -- 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: misc/157903: automated kldload for USB class devices
2011/6/24 Hans Petter Selasky hsela...@c2i.net: Very nice. But why not use variable names instead of hardcoding numbers? It makes the output much easier to understand. To save memory. I haven't inspected devd code, but I was under the assumption that variables only lived untill resolved. What would be the point of keeping them in memory after devd has finished parsing the config files? -- Robert Millan ___ 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
[Testing wanted] USB patch for HAL
Hi, It appears there are some bugs in the USB2 HAL implementation. For example the parent USB device is not always correctly set and there are problems with dynamic attach/detach of USB devices in hald. For users of 9-current and 8-stable: Copy the attached file to /usr/ports/sysutils/hal/files/ Then rebuild HAL. Does it fix any USB/HAL related problems? For example related to multimedia/webcamd, lshal, mouse, keyboard etc. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Testing wanted] USB patch for HAL
On 24 June 2011 17:31, Hans Petter Selasky hsela...@c2i.net wrote: Hi, [...] There're no attached file. Please check content type for attachments. I think, if you'll make shar archive, it'll be better. -- Eir Nym [...] --HPS ___ freebsd-gn...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-gnome To unsubscribe, send any mail to freebsd-gnome-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: [Testing wanted] USB patch for HAL
On Friday 24 June 2011 15:51:03 Eir Nym wrote: On 24 June 2011 17:31, Hans Petter Selasky hsela...@c2i.net wrote: Hi, [...] There're no attached file. Please check content type for attachments. I think, if you'll make shar archive, it'll be better. Look here: http://hselasky.homeunix.org:8192/patch-hald_freebsd_hf-usb2.c --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
On Fri, Jun 24, 2011 at 03:21:05PM +0200, Peter Holm wrote: On Fri, Jun 24, 2011 at 02:06:27PM +0300, Kostik Belousov wrote: On Fri, Jun 24, 2011 at 12:30:16PM +0200, Peter Holm wrote: On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c(revision 221113) +++ tmpfs_vfsops.c(working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); The things I am aware of: - there is a races on the lookup. They were papered over in r212305, but the bug was not really fixed, AFAIR. - the tmpfs does double-buffering for the mapped vnodes. This is quite insulting for the memory-backed fs, isn't it ? I have a patch, but it is still under review. - I believe Peter Holm has more test cases that fails with tmpfs. He would have more details. I somewhat remember some panic on execve(2) the binary located on tmpfs. I ran the TMPFS tests I have and so far I only spotted the mmap(2) problem: http://people.freebsd.org/~pho/stress/log/tmpfs/ It would be indeed good if the issue was the only remaining problem. Well, more testing is needed for sure. The deadlock in tmpfs6.txt is caused by doing copyin() while having a page busied. This should be fixed indirectly by the patch to avoid double-buffering, I uploaded the latest version at http://people.freebsd.org/~kib/misc/tmpfs.5.patch Removing the warning will not make the issues coming away. This doesn't compile: === tmpfs (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/src/sys/i386/compile/PHO/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/src/sys/i386/compile/PHO -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c cc1: warnings being treated as errors /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c: In function 'tmpfs_reg_resize': /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:911: warning: 'uobj' is used uninitialized in this function *** Error code 1 Yes, the patch has rotten. Please try http://people.freebsd.org/~kib/misc/tmpfs.6.patch pgpBvmO286bc6.pgp Description: PGP signature
Re: [Testing wanted] USB patch for HAL
24.06.2011 17:31, Hans Petter Selasky пишет: Hi, It appears there are some bugs in the USB2 HAL implementation. For example the parent USB device is not always correctly set and there are problems with dynamic attach/detach of USB devices in hald. For users of 9-current and 8-stable: Copy the attached file to /usr/ports/sysutils/hal/files/ Then rebuild HAL. Does it fix any USB/HAL related problems? For example related to multimedia/webcamd, lshal, mouse, keyboard etc. --HPS Thanks a lot! My mouse, usb-sticks and usb-hdd now appeared again after reattach with this patch how it was before. It's on 9-current. PS. Maybe there is the same magic that will make my battery indicator state changes when i replug AC power? :) I understand that this not related with USB2, but it worked before on 8-stable. Does anybody expecting the same trouble? -- Regards, Ruslan ___ 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: Thoughts on TMPFS no longer being considered highly experimental
On Fri, Jun 24, 2011 at 05:50:43PM +0300, Kostik Belousov wrote: On Fri, Jun 24, 2011 at 03:21:05PM +0200, Peter Holm wrote: On Fri, Jun 24, 2011 at 02:06:27PM +0300, Kostik Belousov wrote: On Fri, Jun 24, 2011 at 12:30:16PM +0200, Peter Holm wrote: On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c (revision 221113) +++ tmpfs_vfsops.c (working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); The things I am aware of: - there is a races on the lookup. They were papered over in r212305, but the bug was not really fixed, AFAIR. - the tmpfs does double-buffering for the mapped vnodes. This is quite insulting for the memory-backed fs, isn't it ? I have a patch, but it is still under review. - I believe Peter Holm has more test cases that fails with tmpfs. He would have more details. I somewhat remember some panic on execve(2) the binary located on tmpfs. I ran the TMPFS tests I have and so far I only spotted the mmap(2) problem: http://people.freebsd.org/~pho/stress/log/tmpfs/ It would be indeed good if the issue was the only remaining problem. Well, more testing is needed for sure. The deadlock in tmpfs6.txt is caused by doing copyin() while having a page busied. This should be fixed indirectly by the patch to avoid double-buffering, I uploaded the latest version at http://people.freebsd.org/~kib/misc/tmpfs.5.patch Removing the warning will not make the issues coming away. This doesn't compile: === tmpfs (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/src/sys/i386/compile/PHO/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/src/sys/i386/compile/PHO -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c cc1: warnings being treated as errors /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c: In function 'tmpfs_reg_resize': /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:911: warning: 'uobj' is used uninitialized in this function *** Error code 1 Yes, the patch has rotten. Please try http://people.freebsd.org/~kib/misc/tmpfs.6.patch Got a panic: Not a vnode object quite fast: http://people.freebsd.org/~pho/stress/log/kostik441.txt - Peter ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on arm/arm
TB --- 2011-06-24 15:20:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-24 15:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-06-24 15:20:00 - cleaning the object tree TB --- 2011-06-24 15:20:20 - cvsupping the source tree TB --- 2011-06-24 15:20:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-06-24 15:21:08 - building world TB --- 2011-06-24 15:21:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 15:21:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 15:21:08 - TARGET=arm TB --- 2011-06-24 15:21:08 - TARGET_ARCH=arm TB --- 2011-06-24 15:21:08 - TZ=UTC TB --- 2011-06-24 15:21:08 - __MAKE_CONF=/dev/null TB --- 2011-06-24 15:21:08 - cd /src TB --- 2011-06-24 15:21:08 - /usr/bin/make -B buildworld World build started on Fri Jun 24 15:21:09 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Jun 24 16:14:37 UTC 2011 TB --- 2011-06-24 16:14:37 - WARNING: no kernel config for LINT TB --- 2011-06-24 16:14:37 - cd /src/sys/arm/conf TB --- 2011-06-24 16:14:37 - /usr/sbin/config -m AVILA TB --- 2011-06-24 16:14:38 - building AVILA kernel TB --- 2011-06-24 16:14:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 16:14:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 16:14:38 - TARGET=arm TB --- 2011-06-24 16:14:38 - TARGET_ARCH=arm TB --- 2011-06-24 16:14:38 - TZ=UTC TB --- 2011-06-24 16:14:38 - __MAKE_CONF=/dev/null TB --- 2011-06-24 16:14:38 - cd /src TB --- 2011-06-24 16:14:38 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Fri Jun 24 16:14:38 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for AVILA completed on Fri Jun 24 16:17:30 UTC 2011 TB --- 2011-06-24 16:17:31 - cd /src/sys/arm/conf TB --- 2011-06-24 16:17:31 - /usr/sbin/config -m BWCT TB --- 2011-06-24 16:17:31 - building BWCT kernel TB --- 2011-06-24 16:17:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 16:17:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 16:17:31 - TARGET=arm TB --- 2011-06-24 16:17:31 - TARGET_ARCH=arm TB --- 2011-06-24 16:17:31 - TZ=UTC TB --- 2011-06-24 16:17:31 - __MAKE_CONF=/dev/null TB --- 2011-06-24 16:17:31 - cd /src TB --- 2011-06-24 16:17:31 - /usr/bin/make -B buildkernel KERNCONF=BWCT Kernel build for BWCT started on Fri Jun 24 16:17:31 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for BWCT completed on Fri Jun 24 16:19:30 UTC 2011 TB --- 2011-06-24 16:19:30 - cd /src/sys/arm/conf TB --- 2011-06-24 16:19:30 - /usr/sbin/config -m CAMBRIA TB --- 2011-06-24 16:19:30 - building CAMBRIA kernel TB --- 2011-06-24 16:19:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 16:19:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 16:19:30 - TARGET=arm TB --- 2011-06-24 16:19:30 - TARGET_ARCH=arm TB --- 2011-06-24 16:19:30 - TZ=UTC TB --- 2011-06-24 16:19:30 - __MAKE_CONF=/dev/null TB --- 2011-06-24 16:19:30 - cd /src TB --- 2011-06-24 16:19:30 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA Kernel build for CAMBRIA started on Fri Jun 24 16:19:31 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah.c:897: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_setTxQProps': /src/sys/dev/ath/ath_hal/ah.c:870: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_get_mimo_chan_noise': /src/sys/dev/ath/ath_hal/ah.c:1003: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_getChanNoise': /src/sys/dev/ath/ath_hal/ah.c:929: undefined reference to `ath_hal_debug' ah.o:/src/sys/dev/ath/ath_hal/ah.c:223: more undefined references to `ath_hal_debug' follow *** Error code 1 Stop in /obj/arm.arm/src/sys/CAMBRIA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-24 16:22:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-24 16:22:10 - ERROR: failed to build CAMBRIA kernel TB --- 2011-06-24 16:22:10 - 2658.50 user 773.13 system 3729.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
virtualbox-ose 4.0.8 fails
Hi everyone, I am trying to compile virtualbox-ose 4.0.8 but it fails with /out/freebsd.amd64/debug -DVBOX -DVBOX_WITH_DEBUGGER -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\ -DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\ -DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\ -DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\ -DRT_LOCK_STRICT -DRT_LOCK_STRICT_ORDER -DDEBUG -DDEBUG_gkontos -DDEBUG_USERNAME=gkontos -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DIN_RING3 -DUNICODE -DNDEBUG=1 -DVBOX_WITH_XPCOM -DVBOX_MAIN_SETTINGS_ADDONS -DIN_VMM_STATIC -DVBOX_WITH_SYS_V_IPC_SESSION_WATCHER -DVBOX_WITH_RAW_MODE -DVBOX_WITH_NETFLT -DVBOX_WITH_CROGL -DVBOX_WITH_GUEST_PROPS -DVBOX_WITH_GUEST_CONTROL -DVBOX_WITH_HOSTNETIF_API -DVBOX_WITH_VDE -DVBOX_WITH_NEW_SYS_V_KEYGEN -DVBOX_WITH_VBOXSDL -DVBOX_WITH_HEADLESS -DVBOX_WITH_QTGUI -DVBOX_WITH_HGCM -DVBOX_WITH_ALSA -DVBOX_WITH_E1000 -DVBOX_WITH_VIRTIO -DVBOX_WITH_AHCI -DVBOX_WITH_LSILOGIC -DVBOX_WITH_RESOURCE_USAGE_API -DVBOX_WITH_PDM_ASYNC_COMPLETION -DVBOX_WITH_EXTPACK -DVBOX_WITH_VUSB -DVBOX_WITH_S3 -DVBOX_WITH_USB -DVBOX_WITH_NEW_USB_CODE_ON_DARWIN -DVBOX_WITH_HOSTNETIF_API -DVBOX_USE_LIBHAL -Wp,-MD,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.0.8_OSE/out/freebsd.amd64/debug/obj/VBoxSVC/src-server/freebsd/HostHardwareFreeBSD.o.dep -Wp,-MT,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.0.8_OSE/out/freebsd.amd64/debug/obj/VBoxSVC/src-server/freebsd/HostHardwareFreeBSD.o -Wp,-MP -o /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.0.8_OSE/out/freebsd.amd64/debug/obj/VBoxSVC/src-server/freebsd/HostHardwareFreeBSD.o /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.0.8_OSE/src/VBox/Main/src-server/freebsd/HostHardwareFreeBSD.cpp kmk: *** Waiting for unfinished jobs kmk: *** Exiting with status 2 *** Error code 2 Stop in /usr/ports/emulators/virtualbox-ose. *** Error code 1 Stop in /usr/ports/emulators/virtualbox-ose. I have even try to build with debug symbols but I don't see anything different. The system is running GENERIC kernel with debug options disabled. options COMPAT_FREEBSD32 Is included in the kernel as I saw that this has caused similar problems in the past. Any help would be appreciated -- George Kontostanos aisecure.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: make release: doesn't work for me, getting
On Fri, Jun 24, 2011 at 8:47 AM, Kim Culhan w8hd...@gmail.com wrote: Attempting to run: make release resulted in 'looping' until a kernel compile directory sys/amd64/compile/* was removed. Maybe I missed something in the docs. -kim ___ 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 http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025326.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
Re: virtualbox-ose 4.0.8 fails
On 06/24/11 09:41, George Kontostanos wrote: Hi everyone, I am trying to compile virtualbox-ose 4.0.8 but it fails with /out/freebsd.amd64/debug -DVBOX -DVBOX_WITH_DEBUGGER -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\ -DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\ -DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\ -DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\ -DRT_LOCK_STRICT -DRT_LOCK_STRICT_ORDER -DDEBUG -DDEBUG_gkontos -DDEBUG_USERNAME=gkontos -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DIN_RING3 -DUNICODE -DNDEBUG=1 -DVBOX_WITH_XPCOM -DVBOX_MAIN_SETTINGS_ADDONS -DIN_VMM_STATIC -DVBOX_WITH_SYS_V_IPC_SESSION_WATCHER -DVBOX_WITH_RAW_MODE -DVBOX_WITH_NETFLT -DVBOX_WITH_CROGL -DVBOX_WITH_GUEST_PROPS -DVBOX_WITH_GUEST_CONTROL -DVBOX_WITH_HOSTNETIF_API -DVBOX_WITH_VDE -DVBOX_WITH_NEW_SYS_V_KEYGEN -DVBOX_WITH_VBOXSDL -DVBOX_WITH_HEADLESS -DVBOX_WITH_QTGUI -DVBOX_WITH_HGCM -DVBOX_WITH_ALSA -DVBOX_WITH_E1000 -DVBOX_WITH_VIRTIO -DVBOX_WITH_AHCI -DVBOX_WITH_LSILOGIC -DVBOX_WITH_RESOURCE_USAGE_API -DVBOX_WITH_PDM_ASYNC_COMPLETION -DVBOX_WITH_EXTPACK -DVBOX_WITH_VUSB -DVBOX_WITH_S3 -DVBOX_WITH_USB -DVBOX_WITH_NEW_USB_CODE_ON_DARWIN -DVBOX_WITH_HOSTNETIF_API -DVBOX_USE_LIBHAL -Wp,-MD,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.0.8_OSE/out/freebsd.amd64/debug/obj/VBoxSVC/src-server/freebsd/HostHardwareFreeBSD.o.dep -Wp,-MT,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.0.8_OSE/out/freebsd.amd64/debug/obj/VBoxSVC/src-server/freebsd/HostHardwareFreeBSD.o -Wp,-MP -o /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.0.8_OSE/out/freebsd.amd64/debug/obj/VBoxSVC/src-server/freebsd/HostHardwareFreeBSD.o /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.0.8_OSE/src/VBox/Main/src-server/freebsd/HostHardwareFreeBSD.cpp kmk: *** Waiting for unfinished jobs kmk: *** Exiting with status 2 *** Error code 2 Stop in /usr/ports/emulators/virtualbox-ose. *** Error code 1 Stop in /usr/ports/emulators/virtualbox-ose. I have even try to build with debug symbols but I don't see anything different. The system is running GENERIC kernel with debug options disabled. options COMPAT_FREEBSD32 Is included in the kernel as I saw that this has caused similar problems in the past. Any help would be appreciated It fails a couple ways actually, first on an isDVD in a disk system request...commenting out the inq_(something, not in front of machine with recent svn) parts of that code yields virtualbox compiling, but failing during kmod compile due to the recent change (without revision bump) from cpumask_t to cpuset_t. It seems like recent CAM changes and CPU change are going to require some changes to virtualbox in HostHardwareFreeBSD.c and mp-r0drv.c at least. Even though OS revision was not bumped, perhaps Makefile can switch on presence of cpuset userland utility? Luckily I only csup'd a machine I don't really need Vbox on, so I'm holding back all other machines until Vbox maintainers sort out the issue. Matt ___ 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: misc/157903: automated kldload for USB class devices
On Jun 24, 2011, at 7:11 AM, Hans Petter Selasky wrote: On Friday 24 June 2011 14:59:37 Robert Millan wrote: 2011/6/24 Hans Petter Selasky hsela...@c2i.net: Very nice. But why not use variable names instead of hardcoding numbers? It makes the output much easier to understand. To save memory. I haven't inspected devd code, but I was under the assumption that variables only lived untill resolved. What would be the point of keeping them in memory after devd has finished parsing the config files? Hi, I haven't checked that, though if you want the readable version, then you need to check the source code. However I could add some code to print a vendor ID comment, based on usbdevs. devd keeps them in memory and expands them when the commands are executed. It will use more memory and be slower if you have lots of variables. Now much more memory and how much slower? I kinda doubt you'd notice on modern gear. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: virtualbox-ose 4.0.8 fails
On Friday 24 June 2011 01:14 pm, Matt wrote: It fails a couple ways actually, first on an isDVD in a disk system request...commenting out the inq_(something, not in front of machine with recent svn) parts of that code yields virtualbox compiling, but failing during kmod compile due to the recent change (without revision bump) from cpumask_t to cpuset_t. It seems like recent CAM changes and CPU change are going to require some changes to virtualbox in HostHardwareFreeBSD.c and mp-r0drv.c at least. Even though OS revision was not bumped, perhaps Makefile can switch on presence of cpuset userland utility? Luckily I only csup'd a machine I don't really need Vbox on, so I'm holding back all other machines until Vbox maintainers sort out the issue. You should be able to build the kmod with this patch. http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-mp-r0drv-freebsd.c Just drop this patch in ports/emulators/virtualbox-ose-kmod/files and rebuild. Please note the revision wasn't set right for the obvious reason, though. Do we really need revision bump, BTW? Current means no seat belt anyway. ;-) Cheers, Jung-uk Kim ___ 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: virtualbox-ose 4.0.8 fails
On 06/24/11 10:52, Jung-uk Kim wrote: On Friday 24 June 2011 01:14 pm, Matt wrote: It fails a couple ways actually, first on an isDVD in a disk system request...commenting out the inq_(something, not in front of machine with recent svn) parts of that code yields virtualbox compiling, but failing during kmod compile due to the recent change (without revision bump) from cpumask_t to cpuset_t. It seems like recent CAM changes and CPU change are going to require some changes to virtualbox in HostHardwareFreeBSD.c and mp-r0drv.c at least. Even though OS revision was not bumped, perhaps Makefile can switch on presence of cpuset userland utility? Luckily I only csup'd a machine I don't really need Vbox on, so I'm holding back all other machines until Vbox maintainers sort out the issue. You should be able to build the kmod with this patch. http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-mp-r0drv-freebsd.c Just drop this patch in ports/emulators/virtualbox-ose-kmod/files and rebuild. Please note the revision wasn't set right for the obvious reason, though. Do we really need revision bump, BTW? Current means no seat belt anyway. ;-) Cheers, Jung-uk Kim Thanks for the patch. I had read a comment somewhere complaining about detecting cpuset_t or cpumask_t regarding osrevision. Not really an issue, because it can be tested for without a bump. Who needs seatbelts anyway... :). CURRENT a cold beer is good enough for my home systems. Certainly prevents boredom anyway. The Virtualbox error (not kmod error) looked like it was using an undefined struct to determine drive types, which I assume has been removed. If you the make output into a file and search for isDVD, you'll find that particular error, if still present. I just commented out the parts of the struct we don't have anymore, and it did compile...definitely could be dangerous, I haven't actually launched virtualbox with that fix...it could make for subtle or major problems. Your mileage seatbelt may vary :) Matt Matt ___ 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: virtualbox-ose 4.0.8 fails
You should be able to build the kmod with this patch. http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-mp-r0drv-freebsd.c Just drop this patch in ports/emulators/virtualbox-ose-kmod/files and rebuild. Please note the revision wasn't set right for the obvious reason, though. Do we really need revision bump, BTW? Current means no seat belt anyway. ;-) Cheers, Jung-uk Kim Yes the module build fine with this. Any ideas regarding the virtualbox itself ? Cheers -- George Kontostanos aisecure.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: virtualbox-ose 4.0.8 fails
On Friday 24 June 2011 02:40 pm, George Kontostanos wrote: You should be able to build the kmod with this patch. http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-free bsd-mp-r0drv-freebsd.c Just drop this patch in ports/emulators/virtualbox-ose-kmod/files and rebuild. Please note the revision wasn't set right for the obvious reason, though. �Do we really need revision bump, BTW? �Current means no seat belt anyway. ;-) Cheers, Jung-uk Kim Yes the module build fine with this. Good. Any ideas regarding the virtualbox itself ? I am rebuilding world/kernel now. After that, I'll rebuild virtualbox-ose and try to fix it unless someone beat me to it. :-) Jung-uk Kim ___ 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: virtualbox-ose 4.0.8 fails
On Fri, Jun 24, 2011 at 9:51 PM, Jung-uk Kim j...@freebsd.org wrote: Any ideas regarding the virtualbox itself ? I am rebuilding world/kernel now. After that, I'll rebuild virtualbox-ose and try to fix it unless someone beat me to it. :-) Jung-uk Kim Brilliant !!! -- George Kontostanos aisecure.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: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On Jun 23, 2011, at 11:18 PM, Scott Long wrote:
On Jun 23, 2011, at 9:01 PM, Justin T. Gibbs wrote:
On 6/22/11 4:09 PM, Kenneth D. Merry wrote:
On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
On Tue, Jun 21, 2011 at 09:54:04PM -0600, Kenneth D. Merry wrote:
These two are interesting:
http://img825.imageshack.us/img825/1249/21062011014m.jpg
http://img839.imageshack.us/img839/3791/21062011015.jpg
It looks like the GEOM event thread is stuck inside the cd(4)
driver. The
cd(4) driver is trying to acquire the peripheral lock, and is sleeping
until it gets it.
What isn't clear is who is holding it.
...
The GEOM event thread is stuck sleeping in the mtx_sleep() call above. So
that tells me that one of several things is going on:
- There is a path in the cd(4) driver where it can call cam_periph_hold()
but not cam_periph_unhold().
- There is another thread in the system that has called cam_periph_hold(),
and has gotten stuck before it can call cam_periph_unhold().
- The hold/unhold logic is broken, and there is a case where a thread
waiting for the lock can miss the wakeup. After looking at the code, I
don't think this is the case, but I may have missed something.
So it is probably one of the first two cases.
...
I have a theory for the cause of this hang.
The commit that triggers this problem added calls to g_access() during the
geom_dev probe. I believe this hit a race in cdregister() where
the periph hold lock is dropped around the changer probe code. Why the
periph hold lock is dropped there, I do not know as I haven't fully
reviewed the changer probe code.
Are you talking about this?
disk_create(softc-disk, DISK_VERSION);
cam_periph_lock(periph);
cam_periph_unhold(periph);
[...]
if (((cgd-ccb_h.target_lun 0)
((softc-quirks CD_Q_NO_CHANGER) == 0))
|| ((softc-quirks CD_Q_CHANGER) != 0)) {
The unhold there compliments the hold that was done prior to disk_create().
The hold/unhold is done as a hack around the need to drop the periph/sim
mutex while calling disk_create(), due to the later's insistence on using
blocking calls. I've wanted to re-think how that pattern is done (it's the
same gross hack in nearly all of the periph drivers), but haven't gotten
around to it. If the 'hold' semaphore needs to be held longer to prevent the
race that you're theorizing, then it should be possible to simply extend its
coverage in the code block, but I'm not sure if it'll result in an unintended
deadlock with the changer enumeration/matching code. I _think_ that it'll be
ok, but the density of magic in the code is a bit overwhelming at this time
of night =-)
Actually, what's probably happening is that the sim/periph lock is being
dropped but the hold semaphore is held, disk_create() is called, which kicks
off GEOM to do GEOM-ish things including the new g_access() call. It tries to
call cdopen(), which grabs the periph/sim mutex in order to then get the hold
semaphore, and winds up sleeping because the semaphore is already held in
cdregister(). If/when disk_create() returns, cdregister() winds up waiting for
the periph lock because it's held by cdopen(), and now you have a deadlock
between the two.
Again, this is my fault for being lazy and not re-organzing the periph drivers
so that disk_create() is safely called without shady locking hacks. I don't
think that extending the coverage of the hold semaphore is going to help in
this case. The periphs need to adopt a new pattern where disk_create() isn't
called until the periph is completely initialized and ready for periph_open()
to be called without any locking gymnastics.
Scott
___
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: WITHOUT_INSTALLLIB broken?
On Thu, 16 Jun 2011 20:18:33 + Ruslan Ermilov r...@freebsd.org wrote: On Thu, Jun 16, 2011 at 05:09:05PM +0400, Eir Nym wrote: On 16 June 2011 16:55, Ruslan Ermilov r...@freebsd.org wrote: On Thu, Jun 16, 2011 at 01:50:17PM +0200, Milan Obuch wrote: Hi, I encountered an error when WITHOUT_INSTALLLIB option is specified for 'make buildworld' process. I documented this issue with build logs at my page, http://www.dino.sk/build/2011-06-16-log1 and http://www.dino.sk/build/2011-06-16-log2 show how to test this. At this time, there is no /etc/make.conf nor /etc/src.conf. Any idea what's wrong with libegacy.a here? This option wasn't designed for build, only for install. It's like WITHOUT_TOOLCHAIN, which is documented to not work for build targets. Should this be simply ignored for build targets? build targets utilize install targets internally, so this is hardly doable. Could then this be documented in file /usr/src/tools/build/options/WITHOUT_INSTALLLIB, possibly the same way as in /usr/src/tools/build/options/WITHOUT_TOOLCHAIN? It does not tell 'The option does not work for build targets' currently. Regards, Milan ___ 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: Thoughts on TMPFS no longer being considered highly experimental
On Fri, Jun 24, 2011 at 06:20:03PM +0200, Peter Holm wrote: Got a panic: Not a vnode object quite fast: http://people.freebsd.org/~pho/stress/log/kostik441.txt Ah, yes, this is an assertion that was added in the r209702. http://people.freebsd.org/~kib/misc/tmpfs.7.patch pgpfCkfwvYyso.pgp Description: PGP signature
Re: virtualbox-ose 4.0.8 fails
On Friday 24 June 2011 02:58 pm, George Kontostanos wrote: On Fri, Jun 24, 2011 at 9:51 PM, Jung-uk Kim j...@freebsd.org wrote: Any ideas regarding the virtualbox itself ? I am rebuilding world/kernel now. �After that, I'll rebuild virtualbox-ose and try to fix it unless someone beat me to it. :-) Jung-uk Kim Brilliant !!! Please try this patch: http://people.freebsd.org/~jkim/patch-src-VBox-Main-src-server-freebsd-HostHardwareFreeBSD.cpp Just drop this in ports/emulators/virtualbox-ose/files and rebuild. Cheers, Jung-uk Kim ___ 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: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On 6/24/11 3:35 PM, Scott Long wrote:
On Jun 23, 2011, at 11:18 PM, Scott Long wrote:
On Jun 23, 2011, at 9:01 PM, Justin T. Gibbs wrote:
On 6/22/11 4:09 PM, Kenneth D. Merry wrote:
On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
On Tue, Jun 21, 2011 at 09:54:04PM -0600, Kenneth D. Merry wrote:
These two are interesting:
http://img825.imageshack.us/img825/1249/21062011014m.jpg
http://img839.imageshack.us/img839/3791/21062011015.jpg
It looks like the GEOM event thread is stuck inside the cd(4)
driver. The
cd(4) driver is trying to acquire the peripheral lock, and is
sleeping
until it gets it.
What isn't clear is who is holding it.
...
The GEOM event thread is stuck sleeping in the mtx_sleep() call
above. So
that tells me that one of several things is going on:
- There is a path in the cd(4) driver where it can call
cam_periph_hold()
but not cam_periph_unhold().
- There is another thread in the system that has called
cam_periph_hold(),
and has gotten stuck before it can call cam_periph_unhold().
- The hold/unhold logic is broken, and there is a case where a thread
waiting for the lock can miss the wakeup. After looking at the code, I
don't think this is the case, but I may have missed something.
So it is probably one of the first two cases.
...
I have a theory for the cause of this hang.
The commit that triggers this problem added calls to g_access()
during the
geom_dev probe. I believe this hit a race in cdregister() where
the periph hold lock is dropped around the changer probe code. Why the
periph hold lock is dropped there, I do not know as I haven't fully
reviewed the changer probe code.
Are you talking about this?
disk_create(softc-disk, DISK_VERSION);
cam_periph_lock(periph);
cam_periph_unhold(periph);
[...]
if (((cgd-ccb_h.target_lun 0)
((softc-quirks CD_Q_NO_CHANGER) == 0))
|| ((softc-quirks CD_Q_CHANGER) != 0)) {
The unhold there compliments the hold that was done prior to
disk_create().
The hold/unhold is done as a hack around the need to drop the periph/sim
mutex while calling disk_create(), due to the later's insistence on using
blocking calls. I've wanted to re-think how that pattern is done (it's
the same gross hack in nearly all of the periph drivers), but haven't
gotten around to it. If the 'hold' semaphore needs to be held longer to
prevent the race that you're theorizing, then it should be possible to
simply extend its coverage in the code block, but I'm not sure if it'll
result in an unintended deadlock with the changer enumeration/matching
code. I _think_ that it'll be ok, but the density of magic in the code
is a bit overwhelming at this time of night =-)
The cd driver is the only one that temporarily drops the periph hold
semaphore before scheduling and completing the probe processing. I think
the above race could happen but that there is something else causing the
current hang ache is experiencing.
Actually, what's probably happening is that the sim/periph lock is being
dropped but the hold semaphore is held, disk_create() is called, which
kicks off GEOM to do GEOM-ish things including the new g_access() call.
It tries to call cdopen(), which grabs the periph/sim mutex in order to
then get the hold semaphore, and winds up sleeping because the semaphore
is already held in cdregister(). If/when disk_create() returns,
cdregister() winds up waiting for the periph lock because it's held by
cdopen(), and now you have a deadlock between the two.
The sim mutex is dropped while waiting for the periph hold semaphore, so
I don't understand the deadlock you are describing.
If there is still a traditional deadlock here, I'd expect to find a thread
somewhere blocking on a mutex required to release the periph lock semaphore.
Ache hasn't reported a substantive change to the ddb output, just that
instead of g_eli blocked in open, it is now g_dev.
Instead, I believe that either one of the GEOM taste methods is leaking an
access reference (so cdclose() is not called), or the CD driver is failing
to release the hold semaphore during probing. Setting kern.geom.debugflags
to '4' will trace the access calls and allow the GEOM side to be ruled out.
If GEOM is exonerated, we can add tracing to cam_perihp_(un)hold to track
this down further.
--
Justin
___
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
sys/boot/i386/boot2 (install) fail
On r223514M, kernel installed Ok, then after reboot and attempt to installworld I first get a failure that btxld is not found. So I add that to ITOOLS and then I get this. Any ideas? Thanks, Doug === sys/boot/i386/boot2 (install) as --32 -o boot2.o boot2.s ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/local/obj/home/svn/head/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/local/obj/home/svn/head/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=13c1 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1c51 text=200 data=1a51 org=0 entry=0 ls: not found arithmetic expression: expecting primary: 7680- *** Error code 2 Stop in /home/svn/head/sys/boot/i386/boot2. *** Error code 1 -- 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
[RFT] Automatic load of USB kernel modules
Hi, I've been working today on getting auto load of USB kernel modules working properly. I've identified and fixed several issues since the initial patch by Robert Millan was posted. I would like to request testing of the attached patch before I commit it. The patch is about only having ukbd, ums and umass per default in the kernel GENERIC config file(s). The 9-current kernel version you need to checkout is: http://svn.freebsd.org/changeset/base/223519 And you need to make sure you have the file mentioned in the commit above under /etc/devd/ else the new stuff will not work. No userspace changes except the bus_auto.conf file is required. At the present moment ukbd and ums will not auto load because they don't export any USB device entries. This will get fixed before the final auto load commit. --HPS === sys/i386/conf/GENERIC == --- sys/i386/conf/GENERIC (revision 223494) +++ sys/i386/conf/GENERIC (local) @@ -310,39 +310,9 @@ device ehci # EHCI PCI-USB interface (USB 2.0) device xhci # XHCI PCI-USB interface (USB 3.0) device usb # USB Bus (required) -#device udbp # USB Double Bulk Pipe devices (needs netgraph) -device uhid # Human Interface Devices -device ukbd # Keyboard -device ulpt # Printer -device umass # Disks/Mass storage - Requires scbus and da -device ums # Mouse -device urio # Diamond Rio 500 MP3 player -# USB Serial devices -device u3g # USB-based 3G modems (Option, Huawei, Sierra) -device uark # Technologies ARK3116 based serial adapters -device ubsa # Belkin F5U103 and compatible serial adapters -device uftdi # For FTDI usb serial adapters -device uipaq # Some WinCE based devices -device uplcom # Prolific PL-2303 serial adapters -device uslcom # SI Labs CP2101/CP2102 serial adapters -device uvisor # Visor and Palm devices -device uvscom # USB serial support for DDI pocket's PHS -# USB Ethernet, requires miibus -device aue # ADMtek USB Ethernet -device axe # ASIX Electronics USB Ethernet -device cdce # Generic USB over Ethernet -device cue # CATC USB Ethernet -device kue # Kawasaki LSI USB Ethernet -device rue # RealTek RTL8150 USB Ethernet -device udav # Davicom DM9601E USB -# USB Wireless -device rum # Ralink Technology RT2501USB wireless NICs -device run # Ralink Technology RT2700/RT2800/RT3000 NICs. -device uath # Atheros AR5523 wireless NICs -device upgt # Conexant/Intersil PrismGT wireless NICs. -device ural # Ralink Technology RT2500USB wireless NICs -device urtw # Realtek RTL8187B/L wireless NICs -device zyd # ZyDAS zb1211/zb1211b wireless NICs +device ukbd # USB Keyboard +device ums # USB Mouse +device umass # USB Disks/Mass storage - Requires scbus and da # FireWire support device firewire # FireWire bus code @@ -357,5 +327,4 @@ device snd_es137x # Ensoniq AudioPCI ES137x device snd_hda # Intel High Definition Audio device snd_ich # Intel, NVidia and other ICH AC'97 Audio -device snd_uaudio # USB Audio device snd_via8233 # VIA VT8233x Audio === sys/amd64/conf/GENERIC == --- sys/amd64/conf/GENERIC (revision 223494) +++ sys/amd64/conf/GENERIC (local) @@ -297,39 +297,9 @@ device ehci # EHCI PCI-USB interface (USB 2.0) device xhci # XHCI PCI-USB interface (USB 3.0) device usb # USB Bus (required) -#device udbp # USB Double Bulk Pipe devices (needs netgraph) -device uhid # Human Interface Devices -device ukbd # Keyboard -device ulpt # Printer -device umass # Disks/Mass storage - Requires scbus and da -device ums # Mouse -device urio # Diamond Rio 500 MP3 player -# USB Serial devices -device u3g # USB-based 3G modems (Option, Huawei, Sierra) -device uark # Technologies ARK3116 based serial adapters -device ubsa # Belkin F5U103 and compatible serial adapters -device uftdi # For FTDI usb serial adapters -device uipaq # Some WinCE based devices -device uplcom # Prolific PL-2303 serial adapters -device uslcom # SI Labs CP2101/CP2102 serial adapters -device uvisor # Visor and Palm devices -device uvscom # USB serial support for DDI pocket's PHS -# USB Ethernet, requires miibus -device aue # ADMtek USB Ethernet -device axe # ASIX Electronics USB Ethernet -device cdce # Generic USB over Ethernet -device cue # CATC USB Ethernet -device kue # Kawasaki LSI USB Ethernet -device rue # RealTek RTL8150 USB Ethernet -device udav # Davicom DM9601E USB -# USB Wireless -device rum # Ralink Technology RT2501USB wireless NICs -device run # Ralink Technology RT2700/RT2800/RT3000 NICs. -device uath # Atheros AR5523 wireless NICs -device upgt # Conexant/Intersil PrismGT wireless NICs. -device ural # Ralink Technology RT2500USB wireless NICs -device urtw # Realtek RTL8187B/L wireless NICs -device zyd # ZyDAS zb1211/zb1211b wireless NICs +device ukbd # USB Keyboard +device ums # USB Mouse +device umass # USB
Re: virtualbox-ose 4.0.8 fails
On Fri, Jun 24, 2011 at 11:11 PM, Jung-uk Kim j...@freebsd.org wrote: On Friday 24 June 2011 02:58 pm, George Kontostanos wrote: On Fri, Jun 24, 2011 at 9:51 PM, Jung-uk Kim j...@freebsd.org wrote: Any ideas regarding the virtualbox itself ? I am rebuilding world/kernel now. After that, I'll rebuild virtualbox-ose and try to fix it unless someone beat me to it. :-) Jung-uk Kim Brilliant !!! Please try this patch: http://people.freebsd.org/~jkim/patch-src-VBox-Main-src-server-freebsd-HostHardwareFreeBSD.cpp Just drop this in ports/emulators/virtualbox-ose/files and rebuild. Cheers, Jung-uk Kim Excellent work! Best Regards, -- George Kontostanos aisecure.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
[head tinderbox] failure on arm/arm
TB --- 2011-06-24 21:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-24 21:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-06-24 21:10:00 - cleaning the object tree TB --- 2011-06-24 21:10:20 - cvsupping the source tree TB --- 2011-06-24 21:10:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-06-24 21:10:50 - building world TB --- 2011-06-24 21:10:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 21:10:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 21:10:50 - TARGET=arm TB --- 2011-06-24 21:10:50 - TARGET_ARCH=arm TB --- 2011-06-24 21:10:50 - TZ=UTC TB --- 2011-06-24 21:10:50 - __MAKE_CONF=/dev/null TB --- 2011-06-24 21:10:50 - cd /src TB --- 2011-06-24 21:10:50 - /usr/bin/make -B buildworld World build started on Fri Jun 24 21:10:50 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Jun 24 22:05:13 UTC 2011 TB --- 2011-06-24 22:05:13 - WARNING: no kernel config for LINT TB --- 2011-06-24 22:05:13 - cd /src/sys/arm/conf TB --- 2011-06-24 22:05:13 - /usr/sbin/config -m AVILA TB --- 2011-06-24 22:05:13 - building AVILA kernel TB --- 2011-06-24 22:05:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 22:05:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 22:05:13 - TARGET=arm TB --- 2011-06-24 22:05:13 - TARGET_ARCH=arm TB --- 2011-06-24 22:05:13 - TZ=UTC TB --- 2011-06-24 22:05:13 - __MAKE_CONF=/dev/null TB --- 2011-06-24 22:05:13 - cd /src TB --- 2011-06-24 22:05:13 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Fri Jun 24 22:05:13 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for AVILA completed on Fri Jun 24 22:08:05 UTC 2011 TB --- 2011-06-24 22:08:05 - cd /src/sys/arm/conf TB --- 2011-06-24 22:08:05 - /usr/sbin/config -m BWCT TB --- 2011-06-24 22:08:05 - building BWCT kernel TB --- 2011-06-24 22:08:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 22:08:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 22:08:05 - TARGET=arm TB --- 2011-06-24 22:08:05 - TARGET_ARCH=arm TB --- 2011-06-24 22:08:05 - TZ=UTC TB --- 2011-06-24 22:08:05 - __MAKE_CONF=/dev/null TB --- 2011-06-24 22:08:05 - cd /src TB --- 2011-06-24 22:08:05 - /usr/bin/make -B buildkernel KERNCONF=BWCT Kernel build for BWCT started on Fri Jun 24 22:08:05 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for BWCT completed on Fri Jun 24 22:10:03 UTC 2011 TB --- 2011-06-24 22:10:03 - cd /src/sys/arm/conf TB --- 2011-06-24 22:10:03 - /usr/sbin/config -m CAMBRIA TB --- 2011-06-24 22:10:03 - building CAMBRIA kernel TB --- 2011-06-24 22:10:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 22:10:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 22:10:03 - TARGET=arm TB --- 2011-06-24 22:10:03 - TARGET_ARCH=arm TB --- 2011-06-24 22:10:03 - TZ=UTC TB --- 2011-06-24 22:10:03 - __MAKE_CONF=/dev/null TB --- 2011-06-24 22:10:03 - cd /src TB --- 2011-06-24 22:10:03 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA Kernel build for CAMBRIA started on Fri Jun 24 22:10:03 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah.c:897: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_setTxQProps': /src/sys/dev/ath/ath_hal/ah.c:870: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_get_mimo_chan_noise': /src/sys/dev/ath/ath_hal/ah.c:1003: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_getChanNoise': /src/sys/dev/ath/ath_hal/ah.c:929: undefined reference to `ath_hal_debug' ah.o:/src/sys/dev/ath/ath_hal/ah.c:223: more undefined references to `ath_hal_debug' follow *** Error code 1 Stop in /obj/arm.arm/src/sys/CAMBRIA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-24 22:12:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-24 22:12:43 - ERROR: failed to build CAMBRIA kernel TB --- 2011-06-24 22:12:43 - 2697.48 user 785.24 system 3763.68 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
Re: [RFT] Automatic load of USB kernel modules
Hey Hans, Given that all this stuff is really new and shiny, and we're really close to the feature freeze, I'm not sure enabling it by default is the prudent action. Warner On Jun 24, 2011, at 3:42 PM, Hans Petter Selasky wrote: Hi, I've been working today on getting auto load of USB kernel modules working properly. I've identified and fixed several issues since the initial patch by Robert Millan was posted. I would like to request testing of the attached patch before I commit it. The patch is about only having ukbd, ums and umass per default in the kernel GENERIC config file(s). The 9-current kernel version you need to checkout is: http://svn.freebsd.org/changeset/base/223519 And you need to make sure you have the file mentioned in the commit above under /etc/devd/ else the new stuff will not work. No userspace changes except the bus_auto.conf file is required. At the present moment ukbd and ums will not auto load because they don't export any USB device entries. This will get fixed before the final auto load commit. --HPS === sys/i386/conf/GENERIC == --- sys/i386/conf/GENERIC (revision 223494) +++ sys/i386/conf/GENERIC (local) @@ -310,39 +310,9 @@ deviceehci# EHCI PCI-USB interface (USB 2.0) devicexhci# XHCI PCI-USB interface (USB 3.0) deviceusb # USB Bus (required) -#device udbp# USB Double Bulk Pipe devices (needs netgraph) -device uhid# Human Interface Devices -device ukbd# Keyboard -device ulpt# Printer -device umass # Disks/Mass storage - Requires scbus and da -device ums # Mouse -device urio# Diamond Rio 500 MP3 player -# USB Serial devices -device u3g # USB-based 3G modems (Option, Huawei, Sierra) -device uark# Technologies ARK3116 based serial adapters -device ubsa# Belkin F5U103 and compatible serial adapters -device uftdi # For FTDI usb serial adapters -device uipaq # Some WinCE based devices -device uplcom # Prolific PL-2303 serial adapters -device uslcom # SI Labs CP2101/CP2102 serial adapters -device uvisor # Visor and Palm devices -device uvscom # USB serial support for DDI pocket's PHS -# USB Ethernet, requires miibus -device aue # ADMtek USB Ethernet -device axe # ASIX Electronics USB Ethernet -device cdce# Generic USB over Ethernet -device cue # CATC USB Ethernet -device kue # Kawasaki LSI USB Ethernet -device rue # RealTek RTL8150 USB Ethernet -device udav# Davicom DM9601E USB -# USB Wireless -device rum # Ralink Technology RT2501USB wireless NICs -device run # Ralink Technology RT2700/RT2800/RT3000 NICs. -device uath# Atheros AR5523 wireless NICs -device upgt# Conexant/Intersil PrismGT wireless NICs. -device ural# Ralink Technology RT2500USB wireless NICs -device urtw# Realtek RTL8187B/L wireless NICs -device zyd # ZyDAS zb1211/zb1211b wireless NICs +device ukbd# USB Keyboard +device ums # USB Mouse +device umass # USB Disks/Mass storage - Requires scbus and da # FireWire support devicefirewire# FireWire bus code @@ -357,5 +327,4 @@ devicesnd_es137x # Ensoniq AudioPCI ES137x devicesnd_hda # Intel High Definition Audio devicesnd_ich # Intel, NVidia and other ICH AC'97 Audio -device snd_uaudio # USB Audio devicesnd_via8233 # VIA VT8233x Audio === sys/amd64/conf/GENERIC == --- sys/amd64/conf/GENERIC(revision 223494) +++ sys/amd64/conf/GENERIC(local) @@ -297,39 +297,9 @@ deviceehci# EHCI PCI-USB interface (USB 2.0) devicexhci# XHCI PCI-USB interface (USB 3.0) deviceusb # USB Bus (required) -#device udbp# USB Double Bulk Pipe devices (needs netgraph) -device uhid# Human Interface Devices -device ukbd# Keyboard -device
Re: [RFT] Automatic load of USB kernel modules
On Saturday 25 June 2011 00:15:17 Warner Losh wrote: Hey Hans, Given that all this stuff is really new and shiny, and we're really close to the feature freeze, I'm not sure enabling it by default is the prudent action. Yes, you might be right. I'm not saying it should be enabled by default. BTW: How can we disable a .conf file from being picked up by devd? Or do I need to delete it from svn ? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On Fri, Jun 24, 2011 at 04:20:24PM -0400, Justin T. Gibbs wrote: Instead, I believe that either one of the GEOM taste methods is leaking an access reference (so cdclose() is not called), or the CD driver is failing to release the hold semaphore during probing. Setting kern.geom.debugflags to '4' will trace the access calls and allow the GEOM side to be ruled out. If GEOM is exonerated, we can add tracing to cam_perihp_(un)hold to track this down further. No problem. I just set kern.geom.debugflags=4 in loader.conf and here is new photo (with recent kernel, no patches): http://img803.imageshack.us/img803/4679/25062011006.jpg I skip all noisy parts related to ada0 and ada1 partitions probes. As you can see, only 3 cd0-related geom call issued, right before cd1 probe shown. Strange thing is that I see no single cd1-related geom call, but it may be because of hang. -- 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: [RFT] Automatic load of USB kernel modules
On Fri, Jun 24, 2011 at 5:23 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Saturday 25 June 2011 00:15:17 Warner Losh wrote: Hey Hans, Given that all this stuff is really new and shiny, and we're really close to the feature freeze, I'm not sure enabling it by default is the prudent action. Yes, you might be right. I'm not saying it should be enabled by default. BTW: How can we disable a .conf file from being picked up by devd? Or do I need to delete it from svn ? Maybe move it to src/etc/defaults/? Cheers, Mezz --HPS -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: current status of digi driver
On 2011-Jun-23 17:55:15 -0400, David Boyd david.b...@insightbb.com wrote: It appears that there was also agreement that (at least) some of the drivers, digi included, would be converted soon after 8.0-RELEASE. That came down to developer time and it appeared that I was the only person interested in it. Is there any plan to bring digi forward? See kern/158086 (which updates digi(4)) and kern/152254 (which re- implements TTY functionality that was lost with TTYng). Both include patches that should work on either 8.x or -current. Of the two, the latter is more urgent because it impacts the KBI. We have about 55 modem ports over ten 8-port Xr cards (PCI) that connect remote sites via dial-up. I've only got access to PCI Xem cards that are used for serial console concentration so it would be useful for you to test both the Xr cards and dial-in support. -- Peter Jeremy pgpDc4xeak2p9.pgp Description: PGP signature
Re: [head tinderbox] failure on arm/arm
Fixed! Sorry. Adrian On 25 June 2011 06:12, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2011-06-24 21:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-24 21:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-06-24 21:10:00 - cleaning the object tree TB --- 2011-06-24 21:10:20 - cvsupping the source tree TB --- 2011-06-24 21:10:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-06-24 21:10:50 - building world TB --- 2011-06-24 21:10:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 21:10:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 21:10:50 - TARGET=arm TB --- 2011-06-24 21:10:50 - TARGET_ARCH=arm TB --- 2011-06-24 21:10:50 - TZ=UTC TB --- 2011-06-24 21:10:50 - __MAKE_CONF=/dev/null TB --- 2011-06-24 21:10:50 - cd /src TB --- 2011-06-24 21:10:50 - /usr/bin/make -B buildworld World build started on Fri Jun 24 21:10:50 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Jun 24 22:05:13 UTC 2011 TB --- 2011-06-24 22:05:13 - WARNING: no kernel config for LINT TB --- 2011-06-24 22:05:13 - cd /src/sys/arm/conf TB --- 2011-06-24 22:05:13 - /usr/sbin/config -m AVILA TB --- 2011-06-24 22:05:13 - building AVILA kernel TB --- 2011-06-24 22:05:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 22:05:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 22:05:13 - TARGET=arm TB --- 2011-06-24 22:05:13 - TARGET_ARCH=arm TB --- 2011-06-24 22:05:13 - TZ=UTC TB --- 2011-06-24 22:05:13 - __MAKE_CONF=/dev/null TB --- 2011-06-24 22:05:13 - cd /src TB --- 2011-06-24 22:05:13 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Fri Jun 24 22:05:13 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for AVILA completed on Fri Jun 24 22:08:05 UTC 2011 TB --- 2011-06-24 22:08:05 - cd /src/sys/arm/conf TB --- 2011-06-24 22:08:05 - /usr/sbin/config -m BWCT TB --- 2011-06-24 22:08:05 - building BWCT kernel TB --- 2011-06-24 22:08:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 22:08:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 22:08:05 - TARGET=arm TB --- 2011-06-24 22:08:05 - TARGET_ARCH=arm TB --- 2011-06-24 22:08:05 - TZ=UTC TB --- 2011-06-24 22:08:05 - __MAKE_CONF=/dev/null TB --- 2011-06-24 22:08:05 - cd /src TB --- 2011-06-24 22:08:05 - /usr/bin/make -B buildkernel KERNCONF=BWCT Kernel build for BWCT started on Fri Jun 24 22:08:05 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for BWCT completed on Fri Jun 24 22:10:03 UTC 2011 TB --- 2011-06-24 22:10:03 - cd /src/sys/arm/conf TB --- 2011-06-24 22:10:03 - /usr/sbin/config -m CAMBRIA TB --- 2011-06-24 22:10:03 - building CAMBRIA kernel TB --- 2011-06-24 22:10:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-24 22:10:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-24 22:10:03 - TARGET=arm TB --- 2011-06-24 22:10:03 - TARGET_ARCH=arm TB --- 2011-06-24 22:10:03 - TZ=UTC TB --- 2011-06-24 22:10:03 - __MAKE_CONF=/dev/null TB --- 2011-06-24 22:10:03 - cd /src TB --- 2011-06-24 22:10:03 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA Kernel build for CAMBRIA started on Fri Jun 24 22:10:03 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah.c:897: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_setTxQProps': /src/sys/dev/ath/ath_hal/ah.c:870: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_get_mimo_chan_noise': /src/sys/dev/ath/ath_hal/ah.c:1003: undefined reference to `ath_hal_debug' ah.o: In function `ath_hal_getChanNoise': /src/sys/dev/ath/ath_hal/ah.c:929: undefined reference to `ath_hal_debug' ah.o:/src/sys/dev/ath/ath_hal/ah.c:223: more undefined references to `ath_hal_debug' follow *** Error code 1 Stop in /obj/arm.arm/src/sys/CAMBRIA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-24 22:12:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-24 22:12:43 - ERROR: failed to build CAMBRIA kernel TB --- 2011-06-24 22:12:43 - 2697.48 user 785.24 system 3763.68 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full
Re: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On 6/24/11 6:26 PM, Andrey Chernov wrote: On Fri, Jun 24, 2011 at 04:20:24PM -0400, Justin T. Gibbs wrote: Instead, I believe that either one of the GEOM taste methods is leaking an access reference (so cdclose() is not called), or the CD driver is failing to release the hold semaphore during probing. Setting kern.geom.debugflags to '4' will trace the access calls and allow the GEOM side to be ruled out. If GEOM is exonerated, we can add tracing to cam_perihp_(un)hold to track this down further. No problem. I just set kern.geom.debugflags=4 in loader.conf and here is new photo (with recent kernel, no patches): http://img803.imageshack.us/img803/4679/25062011006.jpg I skip all noisy parts related to ada0 and ada1 partitions probes. As you can see, only 3 cd0-related geom call issued, right before cd1 probe shown. Strange thing is that I see no single cd1-related geom call, but it may be because of hang. The GEOM processing is serialized, so that is not unexpected. What your logs are telling me is that the probe for CD0 is hanging. I don't know why. Are you positive it is this specific SVN revision that prevents cd0 from probing properly and not one of my previous CAM commits? Just getting to multi-user doesn't mean we're ok here. My GEOM changes may make the system hang earlier, but you'll need to test access to cd0 even if you get to multi-user mode to be sure that the device is functioning correctly. I just want to be positive that we're barking up the right tree. -- Justin ___ 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: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On Fri, Jun 24, 2011 at 09:09:08PM -0400, Justin T. Gibbs wrote: No problem. I just set kern.geom.debugflags=4 in loader.conf and here is new photo (with recent kernel, no patches): http://img803.imageshack.us/img803/4679/25062011006.jpg I skip all noisy parts related to ada0 and ada1 partitions probes. As you can see, only 3 cd0-related geom call issued, right before cd1 probe shown. Strange thing is that I see no single cd1-related geom call, but it may be because of hang. The GEOM processing is serialized, so that is not unexpected. What your logs are telling me is that the probe for CD0 is hanging. I don't know why. Could you just postpone GEOM calls after any probe will be completed? It seems GEOM goes here even before probe and waits for probe forever. What probe waits in the same time is unclear for me (ccb_scan), but CD devices are slow and may not survive such multisleeping, missing some responses in the middle. Are you positive it is this specific SVN revision that prevents cd0 from probing properly and not one of my previous CAM commits? Just getting to multi-user doesn't mean we're ok here. My GEOM changes may make the system hang earlier, but you'll need to test access to cd0 even if you get to multi-user mode to be sure that the device is functioning correctly. I just want to be positive that we're barking up the right tree. I use splitting by half method to find exact date which boots, then see the next commit above that date. Pre-commit kernel goes to multiuser and network is alive. I don't test CDs are working, I'll do that later and report it. -- 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: Exactly that commit (was Re: Latest -current 100% hang at the late boot stage)
On Sat, Jun 25, 2011 at 08:39:17AM +0400, Andrey Chernov wrote: Are you positive it is this specific SVN revision that prevents cd0 from probing properly and not one of my previous CAM commits? Just getting to multi-user doesn't mean we're ok here. My GEOM changes may make the system hang earlier, but you'll need to test access to cd0 even if you get to multi-user mode to be sure that the device is functioning correctly. I just want to be positive that we're barking up the right tree. I use splitting by half method to find exact date which boots, then see the next commit above that date. Pre-commit kernel goes to multiuser and network is alive. I don't test CDs are working, I'll do that later and report it. Just test it, kernel dated src-sys date=2011.06.14.12.00.00 Both DVDs are mounted normally and files are readable on both. Here is g_* debugging and cd* related parts from dmesg of working kernel (with few lines before/after to hint the place). As you can see, cd0-probe appears far later in dmesg, but cd0-geom (not much later cd1-geom) is earlier thing: ... ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 ada0: SAMSUNG HD502HJ 1AJ10001 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled g_access(0xc652fe40(cd0), 1, 0, 0) open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xc65d4500(cd0) g_disk_access(cd0, 1, 0, 0) ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad10 ada1 at ahcich3 bus 0 scbus4 target 0 lun 0 ada1: ST31500341AS CC1H ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad12 ... Timecounter TSC-low frequency 14077952 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. cd1 at ata2 bus 0 scbus2 target 1 lun 0 cd1: PLEXTOR DVDR PX-740A 1.02 Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present uhub0: 2 ports with 2 removable, self powered ... uhub7: 6 ports with 6 removable, self powered cd0 at ata2 bus 0 scbus2 target 0 lun 0 cd0: ASUS DVD-E616A 1.08 Removable CD-ROM SCSI-0 device cd0: 100.000MB/s transfers (UDMA5, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed g_access(0xc652fe40(cd0), -1, 0, 0) open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xc65d4500(cd0) g_disk_access(cd0, -1, 0, 0) g_access(0xc652fe00(cd0), 1, 0, 0) open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xc65d4500(cd0) g_disk_access(cd0, 1, 0, 0) g_access(0xc652fe00(cd0), -1, 0, 0) open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xc65d4500(cd0) g_disk_access(cd0, -1, 0, 0) g_access(0xc652fdc0(cd0), 1, 0, 0) open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xc65d4500(cd0) g_disk_access(cd0, 1, 0, 0) g_access(0xc652fdc0(cd0), -1, 0, 0) open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xc65d4500(cd0) g_disk_access(cd0, -1, 0, 0) g_access(0xc652fd40(cd1), 1, 0, 0) open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xc65d4280(cd1) g_disk_access(cd1, 1, 0, 0) g_access(0xc652fd40(cd1), -1, 0, 0) open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xc65d4280(cd1) g_disk_access(cd1, -1, 0, 0) g_access(0xc652fd00(cd1), 1, 0, 0) open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xc65d4280(cd1) g_disk_access(cd1, 1, 0, 0) g_access(0xc652fd00(cd1), -1, 0, 0) open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xc65d4280(cd1) g_disk_access(cd1, -1, 0, 0) g_access(0xc652fcc0(cd1), 1, 0, 0) open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xc65d4280(cd1) g_disk_access(cd1, 1, 0, 0) g_access(0xc652fcc0(cd1), -1, 0, 0) open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xc65d4280(cd1) g_disk_access(cd1, -1, 0, 0) g_access(0xc6b1c040(ada0), 1, 0, 0) ... -- 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
