Chrome crashing system (amd64-10.0-CURRENT)
For the last week or so, I've been unable to run chrome. Any attempt to start it up will cause the system either to freeze up or reboot. To make matters worse, no trace of what's happening is anywhere to be found. Nothing in any log files. The system doesn't drop into the kernel debugger, either. It's either a hard freeze or sudden reboot. I've tried rebuilding the chromium port, with both clang and gcc 4.6, to no avail. I've also updated the system sources several times this week and remade world/kernel. Nothing seems to help. I'm totally stumped as to how to determine what's going on here. Any suggestions as to how to obtain some useful info? Thanks! -- Conrad J. Sabatier conr...@cox.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 delete-old" performance.
> I recently ran "make delete-old" on a -current box and felt it was > rather slow. That prompted me to do some more careful experiments. > > On one box where I have both 8-stable and 9-stable available, there > was a ~30x slowdown (based on 5 runs, ignoring the first). I don't > have a -current world on that box so I can't directly compare but on > another pair of fairly similar boxes, I get a ~180x slowdown between > 8-stable and -current (and that figure is probably optimistic since > the -current box was idle whereas the 8-stable box was fairly busy). > > I realise that "make delete-old" isn't something you nede to do every > day but going from sub-second to multi-minute duration is quite > noticable. Can anyone suggest what has caused the change? The slowdown is probably due - at least in part - to two factors: - the list of files to be checked for removal has grown substantially, because missing entries for old knobs and new entries for new knobs have been added; and - a new (and slower) method of checking was added in: http://svnweb.FreeBSD.org/base?view=revision&revision=220255 because the old method broke down with the size of the new lists of files. Some changes could be made to lessen the affect of the latter. b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10 prognostication...
On 5/16/2012 6:02 PM, Outback Dingo wrote: Guess his next claim will be that the kernel was forked from minix, and userland came from QNX... some people are just plain (biting my tongue) You guys DO realize that's a troll website, right? And you're being seriously trolled.. right? *shakes head and walks away* Chuck Burns ___ 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 delete-old" performance.
On 2012-May-16 18:11:32 -0700, Devin Teske wrote: >Right now, I believe the most useful comparison between systems is >(assuming UFS is in play) the output of "tunefs -p" for the >filesystem that the slowness is appearing on. These systems all run ZFS and apart from the first run, there doesn't seem to be any disk activity at all. It looks like the kernel is the bottleneck. >SoftUpdates (and whether it's enabled or disabled) can play a huge >difference in how fast file-deletions are. I've already successfully run "make delete-old" so there are no actual file deletions. This is all just looking for files that aren't present. -- Peter Jeremy pgpI6smYwen8A.pgp Description: PGP signature
Re: "make delete-old" performance.
On May 16, 2012, at 4:06 PM, Peter Jeremy wrote: > I recently ran "make delete-old" on a -current box and felt it was > rather slow. That prompted me to do some more careful experiments. > > On one box where I have both 8-stable and 9-stable available, there > was a ~30x slowdown (based on 5 runs, ignoring the first). I don't > have a -current world on that box so I can't directly compare but on > another pair of fairly similar boxes, I get a ~180x slowdown between > 8-stable and -current (and that figure is probably optimistic since > the -current box was idle whereas the 8-stable box was fairly busy). > > I realise that "make delete-old" isn't something you nede to do every > day but going from sub-second to multi-minute duration is quite > noticable. Can anyone suggest what has caused the change? > > -- > Peter Jeremy Right now, I believe the most useful comparison between systems is (assuming UFS is in play) the output of "tunefs -p" for the filesystem that the slowness is appearing on. SoftUpdates (and whether it's enabled or disabled) can play a huge difference in how fast file-deletions are. Also note that SU+J may be interesting if-set in 9 (while not available in 8). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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"
"make delete-old" performance.
I recently ran "make delete-old" on a -current box and felt it was rather slow. That prompted me to do some more careful experiments. On one box where I have both 8-stable and 9-stable available, there was a ~30x slowdown (based on 5 runs, ignoring the first). I don't have a -current world on that box so I can't directly compare but on another pair of fairly similar boxes, I get a ~180x slowdown between 8-stable and -current (and that figure is probably optimistic since the -current box was idle whereas the 8-stable box was fairly busy). I realise that "make delete-old" isn't something you nede to do every day but going from sub-second to multi-minute duration is quite noticable. Can anyone suggest what has caused the change? -- Peter Jeremy pgpedlZA6ISMi.pgp Description: PGP signature
Re: FreeBSD 10 prognostication...
On Wed, May 16, 2012 at 5:44 PM, Thomas Mueller wrote: > Umm, it's about as factual as The Onion, except not as funny. FreeBSD > never had to "jettison two thirds of its code base and start from > scratch". Apple is not involved in FreeBSD development. No Mac OS X or > Darwin version "includes" FreeBSD. FreeBSD and Mac OS X will never > merge. FreeBSD was never acquired by WinDriver Systems or by anyone > else, although a company named WindRiver Systems (makers of the embedded > operating system VxWorks, not of Windows video drivers) did at one point > acquire BSDI, which had previously acquired Walnut Creek CD-ROM, which > was heavily involved in the early history of both FreeBSD and Slackware > Linux. The remains of Walnut Creek CD-ROM and BSDI are now known as > FreeBSD Mall and iXsystems (of PC-BSD and FreeNAS fame). > > DES > -- > Dag-Erling Smørgrav - d...@des.no > > I was a long-time subscriber to Slackware going back to Walnut Creek CDROM > days (Slackware 96 to the best of my memory, but < 3.0). > > I believe FreeBSD Mall and Slackware (store.slackware.com) are connected. I > had a difficult time terminating my Slackware subscription, customer service > ignoring me, thought I was going to have to have my credit card number > changed to jilt Slackware. I noticed the similarity in subscription > arrangement between FreeBSD Mall and store.slackware.com. > > Slackware package system is geared to binary packages rather than building > from source, and there is no tracking of dependencies. A package can be > installed even if dependencies are missing, and that even happened in > Slackware releases, as I found when I tried unsuccessfully to run gnumeric > many releases ago, got the message of missing library. Seeing the better > package managers in FreeBSD (ports), NetBSD (pkgsrc, and ported to other > (quasi-)Unix OSes), and several Linux distributions is what made me not want > to go further with Slackware. Multimedia files failing to play may have been > due to lack of proper package management. > > Tom Guess his next claim will be that the kernel was forked from minix, and userland came from QNX... some people are just plain (biting my tongue) > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r235510: recent buildworld fail
On 2012-05-16 20:48, O. Hartmann wrote:> When compiling world (make buildworld) I receive the bewlo error, which > seems very strange! > The error occured out of the blue on a FreeBSD 10.0-CURRENT/amd64 box. ... > /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol > `_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in > /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in > /usr/obj/usr/src/tmp/usr/lib/libstdc++.so > > looks like a "mixed up" between CLANG and legacy GCC 4.2.1, as far as I > remember this error was typical for a mismatch. Where did you read that? In any case, I think this may be a problem with one of the settings in your make.conf, not those in src.conf, specifically CFLAGS or CXXFLAGS. Can you please post those? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10 prognostication...
Umm, it's about as factual as The Onion, except not as funny. FreeBSD never had to "jettison two thirds of its code base and start from scratch". Apple is not involved in FreeBSD development. No Mac OS X or Darwin version "includes" FreeBSD. FreeBSD and Mac OS X will never merge. FreeBSD was never acquired by WinDriver Systems or by anyone else, although a company named WindRiver Systems (makers of the embedded operating system VxWorks, not of Windows video drivers) did at one point acquire BSDI, which had previously acquired Walnut Creek CD-ROM, which was heavily involved in the early history of both FreeBSD and Slackware Linux. The remains of Walnut Creek CD-ROM and BSDI are now known as FreeBSD Mall and iXsystems (of PC-BSD and FreeNAS fame). DES -- Dag-Erling Smørgrav - d...@des.no I was a long-time subscriber to Slackware going back to Walnut Creek CDROM days (Slackware 96 to the best of my memory, but < 3.0). I believe FreeBSD Mall and Slackware (store.slackware.com) are connected. I had a difficult time terminating my Slackware subscription, customer service ignoring me, thought I was going to have to have my credit card number changed to jilt Slackware. I noticed the similarity in subscription arrangement between FreeBSD Mall and store.slackware.com. Slackware package system is geared to binary packages rather than building from source, and there is no tracking of dependencies. A package can be installed even if dependencies are missing, and that even happened in Slackware releases, as I found when I tried unsuccessfully to run gnumeric many releases ago, got the message of missing library. Seeing the better package managers in FreeBSD (ports), NetBSD (pkgsrc, and ported to other (quasi-)Unix OSes), and several Linux distributions is what made me not want to go further with Slackware. Multimedia files failing to play may have been due to lack of proper package management. Tom ___ 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: buildkernel fails
On 2012-05-16 23:18, Joel Dahl wrote:> Hi, > I did a buildworld+buildkernel on my workstation today and buildkernel fails > with: > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -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 > -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > /usr/src/sys/dev/et/if_et.c > Bus error (core dumped) > *** [isci.ko.debug] Error code 138 > 1 error > *** [all] Error code 2 > 1 error > *** [modules-all] Error code 2 > ctfconvert -L VERSION -g if_et.o > 1 error > *** [buildkernel] Error code 2 > 1 error > *** [buildkernel] Error code 2 > 1 error > > My src tree is at the latest rev. No /usr/obj. I'm currently running > CURRENT from May, 5th. I think you may be hitting the libthr issue that was introduced in r234947 (Thu May 3 09:17:31 2012 UTC) and fixed in r235068 (Sat May 5 23:51:24 2012 UTC). This caused some programs to randomly bomb out with bus errors or other weirdness. Please try building and installing lib/libthr (from your updated source tree) before running the rest of the world/kernel build. ___ 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: buildkernel fails
On Wed, May 16, 2012 at 11:18:26PM +0200, Joel Dahl wrote: > Hi, > > I did a buildworld+buildkernel on my workstation today and buildkernel fails > with: > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -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 > -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > /usr/src/sys/dev/et/if_et.c > Bus error (core dumped) > *** [isci.ko.debug] Error code 138 > 1 error > *** [all] Error code 2 > 1 error > *** [modules-all] Error code 2 > ctfconvert -L VERSION -g if_et.o > 1 error > *** [buildkernel] Error code 2 > 1 error > *** [buildkernel] Error code 2 > 1 error > > My src tree is at the latest rev. No /usr/obj. I'm currently running > CURRENT from May, 5th. > > Any ideas? > Is this a GENERIC kernel? if_et requires miibus, so I'm curious if you have that device enabled in the kernel config. Glen ___ 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"
buildkernel fails
Hi, I did a buildworld+buildkernel on my workstation today and buildkernel fails with: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -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 -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/et/if_et.c Bus error (core dumped) *** [isci.ko.debug] Error code 138 1 error *** [all] Error code 2 1 error *** [modules-all] Error code 2 ctfconvert -L VERSION -g if_et.o 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error My src tree is at the latest rev. No /usr/obj. I'm currently running CURRENT from May, 5th. Any ideas? -- Joel ___ 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: ACPI 'driver bug: Unable to set devclass'
On Wednesday, May 16, 2012 12:18:25 pm Andriy Gapon wrote: > on 16/05/2012 17:50 John Baldwin said the following: > > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > >> Not sure what you disagree with... > >> First, the wildcard device is added to the child list during the walk. > >> Then, the unit 0 device is added to the list when acpi_timer identify is > >> executed. > >> Then, the wildcard device is probed and gets unit number of zero. > >> Then, the fixed device is being probed and the unit number conflict arises. > >> > >> Am I misunderstanding something? > > > > Yes. The third step will see that unit 0 is already in use and shouldn't > > reuse unit 0. > > > > Looks like I missed the call to devclass_add_device() in make_device(). > > Your guess: > > I wonder if this is related to the recent changes to set the unit number > > for CPUs? > > seems to be true. > > The device_t-s created for CPUs have NULL driver name / devclass, but a > non-wildcard unit number. So when such a device with unit number 0 is probed > by > acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the > identify. > Similarly we get conflicts for acpi_sysresource driver, because we do an early > probe-and-attach for this driver and the attached devices get some unit > numbers > (0, 1, etc). So when during the normal probe pass the "CPU" devices with > matching > unit numbers are passed to the driver the conflict results. > > I guess that it is an unorthodox use of newbus to specify a unit number > without > specifying a driver name... It's like saying "this device must be unit N > whatever > driver claims it (be it kbdN or diskN) just because I say so". Not sure if > this > ever makes sense and maybe we should prohibit such a combination (reject it > earlier). > I guess that in this particular case we already know that the devices are > really > CPU devices and are going to be claimed by acpi cpu driver. So we should pass > "cpu" as the name. Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() (and/or, not make the unit number in cpuX mean anything at all, but use a separate ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think the last approach is really the right way to fix this. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Ethernet Drivers: Question on ifp->if_ioctl invocation for SIOCADDMULTI and SIOCDELMULTI
Hi All,
When ifp->if_ioctl() is invoked for the ioctl cmd SIOCADDMULTI,
IN_MULTI_LOCK() is called in one of the functions in_joingroup() in the caller
stack.
>From netinet/in_var.h, line 357 : #define IN_MULTI_LOCK()
>mtx_lock(&in_multi_mtx)
>From netinet/in_mcast.c
1098 in_joingroup(struct ifnet *ifp, const struct in_addr *gina,
1099 /*const*/ struct in_mfilter *imf, struct in_multi **pinm)
1100 {
1101 int error;
1102
1103 IN_MULTI_LOCK();
1104 error = in_joingroup_locked(ifp, gina, imf, pinm);
1105 IN_MULTI_UNLOCK();
1106
This is also the case for SIOCDELMULTI, where the function holding
"in_multi_mtx" lock is in_leavegroup()
This poses a problem in the driver in that the hardware dependent function
performing it, is not allowed to sleep() in case it needs to poll some state.
Question:
1. If I want to implement any delays - for the above case - in the driver
using DELAY(usec) macro, is there a maximum amount of time that the driver is
allowed to complete this function? I am concerned that if it takes to too long
I might run into a soft_lockup() situation.
2. Is it o.k to defer the processing in a separate in a separate thread
which can sleep() ?
Thanks
David S.
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use this
information. If you have received this transmission in error, please notify the
sender immediately by reply e-mail and then delete this message.
___
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"
r235510: recent buildworld fail
When compiling world (make buildworld) I receive the bewlo error, which seems very strange! The error occured out of the blue on a FreeBSD 10.0-CURRENT/amd64 box. The line /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so looks like a "mixed up" between CLANG and legacy GCC 4.2.1, as far as I remember this error was typical for a mismatch. I can not imagine how this could be introduced on one of my systems. By the way, all FreeBSD 10.0-CURRENT boxes I have compiling under CLANG refuse compiling world - neither with make "-jXX buildworld" nor "make buildworl". This is my /etc/src.conf: WITH_CLANG= YES WITH_CLANG_EXTRAS= YES # WITH_BIND_LARGE_FILE= YES WITH_BIND_SIGCHASE= YES WITH_BIND_LIBS= YES # WITH_IDEA= YES WITH_HESIOD=YES # WITH_BSD_SORT= YES #WITH_BSD_GREP= YES #WITH_ICONV=YES # WITH_LIBCPLUSPLUS= YES # #WITH_OFED= YES # PORTS_MODULES= x11/nvidia-driver # MALLOC_PRODUCTION= YES What can I do to repair the system? Regards, Oliver [...] clang++ -O2 -pipe -O2 -fno-strict-aliasing -pipe -O3 -pipe -fno-strict-aliasing -march=native -Qunused-arguments -fstack-protector -Wsystem-headers -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o options.o output.o positions.o search.o version.o getline.o hash.o /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ifstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_Rep::_M_set_length_and_sharable(unsigned long)' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_check_length(unsigned long, unsigned long, char const*) const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_fstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_istream >::ignore()' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_copy(wchar_t*, wchar_t const*, unsigned long)' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_assign(char*, unsigned long, char)' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEv@GLIBCXX_3.4' changed from 243 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_fstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_move(wchar_t*, wchar_t const*, unsigned long)' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSbIwSt11char_traitsIwESaIwEE4_Rep26_M_set_length_and_sharableEm@GLIBCXX_3.4' changed from 19 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 24 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_move(char*, char const*, unsigned long)' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::istream::ignore()' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNKSs15_M_check_lengthEmmPKc@GLIBCXX_3.4' changed from 39 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 36 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ofstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_string, std::allocator >::_M_assign(wchar_t*, unsigned long, wchar_t)' /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthEmmPKc@GLIBCXX_3.4' changed from 39 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 36 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::basic_ifstream >::is_open() const' /usr/obj/usr/src/tmp/usr/lib/libstdc++.so:(*IND*+0x0): multiple definition of `std::string::_M_copy(char*, char const*, unsigned long)' /usr/obj/usr/s
[head tinderbox] failure on i386/i386
TB --- 2012-05-16 17:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-16 17:10:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-16 17:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-05-16 17:10:00 - cleaning the object tree TB --- 2012-05-16 17:10:00 - cvsupping the source tree TB --- 2012-05-16 17:10:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-05-16 17:12:09 - building world TB --- 2012-05-16 17:12:09 - CROSS_BUILD_TESTING=YES TB --- 2012-05-16 17:12:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-16 17:12:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-16 17:12:09 - SRCCONF=/dev/null TB --- 2012-05-16 17:12:09 - TARGET=i386 TB --- 2012-05-16 17:12:09 - TARGET_ARCH=i386 TB --- 2012-05-16 17:12:09 - TZ=UTC TB --- 2012-05-16 17:12:09 - __MAKE_CONF=/dev/null TB --- 2012-05-16 17:12:09 - cd /src TB --- 2012-05-16 17:12:09 - /usr/bin/make -B buildworld >>> World build started on Wed May 16 17:12:11 UTC 2012 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation -I. -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp c++ -O2 -pipe -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation -I. -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation/Instrumentation.cpp c++ -O2 -pipe -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation -I. -I/src/lib/clang/libllvminstrumentation/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvminstrumentation/../../../contrib/llvm/lib/Transforms/Instrumentation/OptimalEdgeProfiling.cpp /obj/i386.i386/src/tmp/usr/include/c++/4.2/bits/stl_algo.h: In function 'void std::__merge_without_buffer(_BidirectionalIterator, _BidirectionalIterator, _BidirectionalIterator, _Distance, _Distance, _Compare) [with _BidirectionalIterator = __gnu_cxx::__normal_iterator, double>*, std::vector, double>, std::allocator, double> > > >, _Distance = int, _Compare = llvm::MaximumSpanningTree::EdgeWeightCompare]': /obj/i386.i386/src/tmp/usr/include/c++/4.2/bits/stl_algo.h:3125: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /src/lib/clang/libllvminstrumentation. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-16 18:38:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-16 18:38:07 - ERROR: failed to build world TB --- 2012-05-16 18:38:07 - 4024.52 user 532.12 system 5287.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr..
Re: ACPI 'driver bug: Unable to set devclass'
on 16/05/2012 17:50 John Baldwin said the following: > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: >> Not sure what you disagree with... >> First, the wildcard device is added to the child list during the walk. >> Then, the unit 0 device is added to the list when acpi_timer identify is >> executed. >> Then, the wildcard device is probed and gets unit number of zero. >> Then, the fixed device is being probed and the unit number conflict arises. >> >> Am I misunderstanding something? > > Yes. The third step will see that unit 0 is already in use and shouldn't > reuse unit 0. > Looks like I missed the call to devclass_add_device() in make_device(). Your guess: > I wonder if this is related to the recent changes to set the unit number for > CPUs? seems to be true. The device_t-s created for CPUs have NULL driver name / devclass, but a non-wildcard unit number. So when such a device with unit number 0 is probed by acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the identify. Similarly we get conflicts for acpi_sysresource driver, because we do an early probe-and-attach for this driver and the attached devices get some unit numbers (0, 1, etc). So when during the normal probe pass the "CPU" devices with matching unit numbers are passed to the driver the conflict results. I guess that it is an unorthodox use of newbus to specify a unit number without specifying a driver name... It's like saying "this device must be unit N whatever driver claims it (be it kbdN or diskN) just because I say so". Not sure if this ever makes sense and maybe we should prohibit such a combination (reject it earlier). I guess that in this particular case we already know that the devices are really CPU devices and are going to be claimed by acpi cpu driver. So we should pass "cpu" as the name. -- 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: panic, seems related to r234386
Hello; On 05/12/12 17:49, Mateusz Guzik wrote: Gave this a spin and found what looks like a deadlock: http://people.freebsd.org/~pho/stress/log/ext2fs.txt Not a new problem, it would seem. Same issue with 8.3-PRERELEASE r232656M. pid 2680 (fts) holds lock for vnode cb4be414 and tries to lock cc0ac15c pid 2581 (openat) holds lock for vnode cc0ac15c and tries to lock cb4be414 openat calls rmdir foo/bar and ext2_rmdir unlocks and tries to lock again foo's vnode. This is fairly easly reproducible with concurrently running mkdir and fts testcase programs that are provided by stress2. I'll try to come up with a patch by the end of the week. Easier way to reproduce: mkdir from stress2 and "while true; do find /mnt> /dev/null; done" on another terminal. Assuming foo/bar directory tree, deadlock happens during removal of bar with simultaneous lookup of .. in bar. Proposed trivial patch: http://student.agh.edu.pl/~mjguzik/patches/ext2fs_rmdir-deadlock.patch If the lock cannot be acquired immediately unlocks 'bar' vnode and then locks both vnodes in order. After patching this I ran into another issue - wrong vnode type panics from cache_enter_time after calls by ext2_lookup. (It takes some time to reproduce this, testcase as before.) It looks like ext2_lookup is actually adapted version of ufs_lookup and lacks some bugfixes present in current ufs_lookup. I believe those bugfixes address this bug. Here is my attempt to fix the problem (based on ufs_lookup changes): http://student.agh.edu.pl/~mjguzik/patches/ext2fs_lookup-relookup.patch It is indeed extremely useful that UFS and ext2fs are so similar. The two bugfixes were committed as revision 235508, thanks! Pedro. ___ 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: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19
On Wed, May 16, 2012 at 11:08:05AM -0400, John Baldwin wrote:
> On Wednesday, May 16, 2012 4:45:51 am Anton Shterenlikht wrote:
> > On Tue, May 15, 2012 at 12:11:09PM -0400, John Baldwin wrote:
> > > On Monday, May 07, 2012 5:25:02 pm Anton Shterenlikht wrote:
> > > > On Mon, May 07, 2012 at 10:39:51AM -0400, John Baldwin wrote:
> > > > > On Friday, May 04, 2012 4:07:24 pm Anton Shterenlikht wrote:
> > > > > > On Fri, May 04, 2012 at 11:07:59AM -0400, John Baldwin wrote:
> > > > > > > On Friday, May 04, 2012 7:51:33 am Anton Shterenlikht wrote:
> > > > > > > > On Thu, May 03, 2012 at 02:46:18PM -0400, John Baldwin wrote:
> > > > > > > > > On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht
> > > > > > > > > wrote:
> > > > > > > > > > On Tue, May 01, 2012 at 12:35:26PM +0100, Anton
> > > > > > > > > > Shterenlikht wrote:
> > > > > > > > > > > On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > I also see:
> > > > > > > > > > > > >
> > > > > > > > > > > > > ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0exb
> > > > > > > > > > > > > ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00
> > > > > > > > > > > > > ata0: reset tp2 stat0=00 stat1=00 devices=0x1
> > > > > > > > > > > >
> > > > > > > > > > > > Hmmm, I don't know how to grok these lines, but does
> > > > > > > > > > > > your disk work
> > > > > > > at
> > > > > > > > > all now
> > > > > > > > > > > > with any kernel? It may be that your disk has died (or
> > > > > > > > > > > > a cable,
> > > > > > > etc.)
> > > > > > > > > and it
> > > > > > > > > > > > just happened to coincide with your upgrade?
> > > > > > > > > > >
> > > > > > > > > > > I reverted back to r231158, built world and generic
> > > > > > > > > > > kernel (minus all modules, i.e. "option
> > > > > > > > > > > MODULES_OVERRIDE=").
> > > > > > > > > > > This works, see the verbose boot dmesg at the end.
> > > > > > > > > > >
> > > > > > > > > > > I think I'll just do a binary search.
> > > > > > > > > >
> > > > > > > > > > I traced it to r233677.
> > > > > > > > > > The only change from 233676 to 233677 is
> > > > > > > > > > in /sys/dev/pci/pci.c
> > > > > > > > > >
> > > > > > > > > > My kernel is GENERIC with no modules
> > > > > > > > > > and with various bits removed, e.g. all raid devices
> > > > > > > > > > and PCI network devices, which I definitely
> > > > > > > > > > haven't got on this laptop.
> > > > > > > > > >
> > > > > > > > > > Below is the verbose boot with r233676.
> > > > > > > > > > Apparently at the beginning there's also
> > > > > > > > > > the previous unsuccessful boot with r233677.
> > > > > > > > > > Is this a new feature? I didn't know the
> > > > > > > > > > previous dmesg is preserved after a reboot.
> > > > > > > > > > Anyway, you can see clearly the error with r233677.
> > > > > > > > > >
> > > > > > > > > > I guess this is something to do with
> > > > > > > > > > ata -> ada change?
> > > > > > > > >
> > > > > > > > > I don't think so.
> > > > > > > > >
> > > > > > > > > Please try just this change:
> > > > > > > > >
> > > > > > > > > Index: pci.c
> > > > > > > > > ===
> > > > > > > > > --- pci.c (revision 234928)
> > > > > > > > > +++ pci.c (working copy)
> > > > > > > > > @@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t
> > > > > > > > > dev, int reg, s
> > > > > > > > >* from the parent.
> > > > > > > > >*/
> > > > > > > > > resource_list_delete(rl, type, reg);
> > > > > > > > > - } else {
> > > > > > > > > + start = 0;
> > > > > > > > > + device_printf(bus,
> > > > > > > > > + "pci%d:%d:%d:%d bar %#x failed to allocate",
> > > > > > > > > + pci_get_domain(dev), pci_get_bus(dev),
> > > > > > > > > pci_get_slot(dev),
> > > > > > > > > + pci_get_function(dev), reg);
> > > > > > > > > + } else
> > > > > > > > > start = rman_get_start(res);
> > > > > > > > > - pci_write_bar(dev, pm, start);
> > > > > > > > > - }
> > > > > > > > > + pci_write_bar(dev, pm, start);
> > > > > > > > > return (barlen);
> > > > > > > > > }
> > > > > > > > >
> > > > > > > >
> > > > > > > > That helped, thank you.
> > > > > > >
> > > > > > > Bizarre, can you get a regular dmesg with that change applied?
> > > > > >
> > > > >
> > > > > Hmm, I missed a newline at the end. :) Looks like this happened
> > > > > twice.
> > > > > I've added the relevant verbose boot messages from your earlier kernel
> > > > > below each one:
> > > > >
> > > > > > pci0: on pcib0
> > > > > > pci0: pci0:0:20:2 bar 0x10 failed to allocate
> > > > > > pcib1: at device 1.0 on pci0
> > > > >
> > > > > found-> vendor=0x1002, dev=0x4383, revid=0x00
> > > > > domain=0, bus=0, slot=20, func=2
> > > > > class=04-03-00, hdrtype=0x00, mfdev=0
> >
Re: xdm failing to start on FBSD 10.0 r2340030 erratically
On Mon, 9 Apr 2012, O. Hartmann wrote: Am 04/08/12 17:29, schrieb David Wolfskill: *snip* * I don't know that this is different, but it may well be: my xorg.conf includes a stanza: Section "ServerFlags" Option "AutoAddDevices" "False" EndSection I should go with this and try. But as far as I know, since I have USB devices (mouse, keyboard), unpluggin and pluggin them is then, without hal and dbus, not recognized anymore, isn't it? There was a discussion once going one for this subject. For posterity's sake, I wanted to mention that I use AutoAddDevices on my desktop, but for my laptop, I do not. However, I do not use HAL with either. Here are bits of my laptop's configuration to get it to use an external mouse without HAL. sysmouse(4) handles the mouse being added before or after the X server is running. Section "ServerLayout" ... InputDevice"Keyboard0" "CoreKeyboard" InputDevice"Synaptics Mouse" "CorePointer" InputDevice"SysMouse" "SendCoreEvents" ... EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier"Synaptics Mouse" Driver"synaptics" Option"Protocol" "psm" Option"Device" "/dev/psm0" EndSection Section "InputDevice" Identifier"SysMouse" Driver"mouse" Option"Protocol" "auto" Option"Device" "/dev/sysmouse" EndSection Sean -- s...@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: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19
On Wednesday, May 16, 2012 4:45:51 am Anton Shterenlikht wrote:
> On Tue, May 15, 2012 at 12:11:09PM -0400, John Baldwin wrote:
> > On Monday, May 07, 2012 5:25:02 pm Anton Shterenlikht wrote:
> > > On Mon, May 07, 2012 at 10:39:51AM -0400, John Baldwin wrote:
> > > > On Friday, May 04, 2012 4:07:24 pm Anton Shterenlikht wrote:
> > > > > On Fri, May 04, 2012 at 11:07:59AM -0400, John Baldwin wrote:
> > > > > > On Friday, May 04, 2012 7:51:33 am Anton Shterenlikht wrote:
> > > > > > > On Thu, May 03, 2012 at 02:46:18PM -0400, John Baldwin wrote:
> > > > > > > > On Thursday, May 03, 2012 11:35:19 am Anton Shterenlikht wrote:
> > > > > > > > > On Tue, May 01, 2012 at 12:35:26PM +0100, Anton Shterenlikht
> > > > > > > > > wrote:
> > > > > > > > > > On Mon, Apr 30, 2012 at 08:43:14AM -0400, John Baldwin
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > I also see:
> > > > > > > > > > > >
> > > > > > > > > > > > ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0exb
> > > > > > > > > > > > ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00
> > > > > > > > > > > > ata0: reset tp2 stat0=00 stat1=00 devices=0x1
> > > > > > > > > > >
> > > > > > > > > > > Hmmm, I don't know how to grok these lines, but does your
> > > > > > > > > > > disk work
> > > > > > at
> > > > > > > > all now
> > > > > > > > > > > with any kernel? It may be that your disk has died (or a
> > > > > > > > > > > cable,
> > > > > > etc.)
> > > > > > > > and it
> > > > > > > > > > > just happened to coincide with your upgrade?
> > > > > > > > > >
> > > > > > > > > > I reverted back to r231158, built world and generic
> > > > > > > > > > kernel (minus all modules, i.e. "option MODULES_OVERRIDE=").
> > > > > > > > > > This works, see the verbose boot dmesg at the end.
> > > > > > > > > >
> > > > > > > > > > I think I'll just do a binary search.
> > > > > > > > >
> > > > > > > > > I traced it to r233677.
> > > > > > > > > The only change from 233676 to 233677 is
> > > > > > > > > in /sys/dev/pci/pci.c
> > > > > > > > >
> > > > > > > > > My kernel is GENERIC with no modules
> > > > > > > > > and with various bits removed, e.g. all raid devices
> > > > > > > > > and PCI network devices, which I definitely
> > > > > > > > > haven't got on this laptop.
> > > > > > > > >
> > > > > > > > > Below is the verbose boot with r233676.
> > > > > > > > > Apparently at the beginning there's also
> > > > > > > > > the previous unsuccessful boot with r233677.
> > > > > > > > > Is this a new feature? I didn't know the
> > > > > > > > > previous dmesg is preserved after a reboot.
> > > > > > > > > Anyway, you can see clearly the error with r233677.
> > > > > > > > >
> > > > > > > > > I guess this is something to do with
> > > > > > > > > ata -> ada change?
> > > > > > > >
> > > > > > > > I don't think so.
> > > > > > > >
> > > > > > > > Please try just this change:
> > > > > > > >
> > > > > > > > Index: pci.c
> > > > > > > > ===
> > > > > > > > --- pci.c (revision 234928)
> > > > > > > > +++ pci.c (working copy)
> > > > > > > > @@ -2822,10 +2822,14 @@ pci_add_map(device_t bus, device_t dev,
> > > > > > > > int reg, s
> > > > > > > > * from the parent.
> > > > > > > > */
> > > > > > > > resource_list_delete(rl, type, reg);
> > > > > > > > - } else {
> > > > > > > > + start = 0;
> > > > > > > > + device_printf(bus,
> > > > > > > > + "pci%d:%d:%d:%d bar %#x failed to allocate",
> > > > > > > > + pci_get_domain(dev), pci_get_bus(dev),
> > > > > > > > pci_get_slot(dev),
> > > > > > > > + pci_get_function(dev), reg);
> > > > > > > > + } else
> > > > > > > > start = rman_get_start(res);
> > > > > > > > - pci_write_bar(dev, pm, start);
> > > > > > > > - }
> > > > > > > > + pci_write_bar(dev, pm, start);
> > > > > > > > return (barlen);
> > > > > > > > }
> > > > > > > >
> > > > > > >
> > > > > > > That helped, thank you.
> > > > > >
> > > > > > Bizarre, can you get a regular dmesg with that change applied?
> > > > >
> > > >
> > > > Hmm, I missed a newline at the end. :) Looks like this happened twice.
> > > > I've added the relevant verbose boot messages from your earlier kernel
> > > > below each one:
> > > >
> > > > > pci0: on pcib0
> > > > > pci0: pci0:0:20:2 bar 0x10 failed to allocate
> > > > > pcib1: at device 1.0 on pci0
> > > >
> > > > found-> vendor=0x1002, dev=0x4383, revid=0x00
> > > > domain=0, bus=0, slot=20, func=2
> > > > class=04-03-00, hdrtype=0x00, mfdev=0
> > > > cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords)
> > > > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> > > > intpin=a, irq=10
> > > > powerspec 2 supports D0 D3 current D0
> > > > map[10]: type Memory, range 64
Re: ACPI 'driver bug: Unable to set devclass'
On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > on 15/05/2012 17:34 John Baldwin said the following: > > On Monday, May 14, 2012 12:41:37 pm Andriy Gapon wrote: > >> on 14/05/2012 01:43 Bruce Cran said the following: > >>> On 13/05/2012 21:06, Andriy Gapon wrote: > Can you produce an equivalent snippet with verbose logging enabled? I > have a > suspicion that these messages are a byproduct from r231161. > >>> > >>> acpi0: reservation of fee0, 1000 (3) failed > >>> acpi0: reservation of 0, a (3) failed > >>> acpi0: reservation of 10, bbf0 (3) failed > >>> acpi_sysresource: acpi_sysresource0 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: > >>> (unknown)) > >>> acpi_timer: acpi_timer0 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) > >>> cpu0: on acpi0 > >>> ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 > >>> (20120420/tbutils-293) > >>> ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117) > >>> ACPI: Dynamic OEM Table Load: > >>> ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117) > >>> ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 3001 INTL 20051117) > >>> ACPI: Dynamic OEM Table Load: > >>> ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 3001 INTL 20051117) > >>> acpi_sysresource: acpi_sysresource2 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: > >>> (unknown)) > >>> cpu2: on acpi0 > >>> acpi_sysresource: acpi_sysresource1 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: > >>> (unknown)) > >>> cpu1: on acpi0 > >>> acpi_sysresource: acpi_sysresource3 already exists; skipping it > >>> driver bug: Unable to set devclass (class: acpi_sysresource devname: > >>> (unknown)) > >>> > >> > >> I think that the following is what happens here in the acpi_timer case. > >> Previously one acpi_timer device_t was added with an order of zero and a > >> fixed > >> unit number of zero in acpi_timer_identify(). Then, another acpi_timer > >> device_t > >> could be added when walking the ACPI device tree, that device would always > >> have a > >> later order and a wildcard unit number (-1). > >> Now both the "hardwired" device and "auto-probed" device are added with > >> the same > >> order of 2 and it also so happens that the hardwired device is after the > >> auto-probed in the device list. So first the auto-probed device just > >> takes the > >> unit number of zero because it is free and then the hardwired device fails > >> to > >> claim the same unit number. > > > > Eh. This should not be true. The unit 0 is reserved when > > device_add_child() > > is called in the acpi_timer identify routine. The wildcard device will not > > be > > assigned a unit number until device_probe_child time. > > Not sure what you disagree with... > First, the wildcard device is added to the child list during the walk. > Then, the unit 0 device is added to the list when acpi_timer identify is > executed. > Then, the wildcard device is probed and gets unit number of zero. > Then, the fixed device is being probed and the unit number conflict arises. > > Am I misunderstanding something? Yes. The third step will see that unit 0 is already in use and shouldn't reuse unit 0. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: wdog_kern_pat: liberate from SW_WATCHDOG
2012/5/16, Andriy Gapon : > on 16/05/2012 15:37 Attilio Rao said the following: >> 2012/5/16, Andriy Gapon : >>> >>> I would like to commit something like the following patch. >>> I think that in-kernel watchdog patting during crash dump is useful with >>> hardware watchdogs too. The code seems to work fine here. >>> In fact, I am not sure why wdog_kern_pat was originally tied to >>> SW_WATCHDOG. >> >> I didn't think I tested this with any hw watchdog. >> Which one you are using for tests? > > amdsbwd and ichwd > >> BTW, can you please skip adding the white lines? > > I thought that those calls were quite significant to be emphasized by > spacing. I don't think this is the right thing to do style-wise. But it is up to you. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: wdog_kern_pat: liberate from SW_WATCHDOG
on 16/05/2012 15:37 Attilio Rao said the following: > 2012/5/16, Andriy Gapon : >> >> I would like to commit something like the following patch. >> I think that in-kernel watchdog patting during crash dump is useful with >> hardware watchdogs too. The code seems to work fine here. >> In fact, I am not sure why wdog_kern_pat was originally tied to >> SW_WATCHDOG. > > I didn't think I tested this with any hw watchdog. > Which one you are using for tests? amdsbwd and ichwd > BTW, can you please skip adding the white lines? I thought that those calls were quite significant to be emphasized by spacing. -- 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: wdog_kern_pat: liberate from SW_WATCHDOG
2012/5/16, Andriy Gapon : > > I would like to commit something like the following patch. > I think that in-kernel watchdog patting during crash dump is useful with > hardware watchdogs too. The code seems to work fine here. > In fact, I am not sure why wdog_kern_pat was originally tied to > SW_WATCHDOG. I didn't think I tested this with any hw watchdog. Which one you are using for tests? BTW, can you please skip adding the white lines? Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: usb problems on HP DL980G7
- Hans Petter Selasky's Original Message - > On Friday 11 May 2012 02:54:19 John wrote: > > Hi Folks, > > > >We've been trying to bring freebsd up on a hp dl980g7 for awhile. > > Due to usb issues, we finally installed onto a revo card and > > installed it into the 980. The system consistently puts out the > > following messages: > > > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_NOMEM usbd_ctrl_transfer_setup: could not setup default USB > > transfer > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_NOMEM usbd_ctrl_transfer_setup: could not setup default USB > > transfer > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_NOMEM ugen0.2: at usbus0 (disconnected) > > uhub_reattach_port: could not allocate new device > > > >From dmesg: > > > > pci0: at device 20.0 (no driver > > attached) pcib12: at device 28.0 on pci0 > > pci3: on pcib12 > > pcib13: at device 28.4 on pci0 > > pci2: on pcib13 > > pci2: at device 0.0 (no driver attached) > > pci2: at device 0.2 (no driver attached) > > uhci0: port 0x3c00-0x3c1f irq 17 at device > > 0.4 on pci2 usbus0 on uhci0 > > uhci1: port 0x1000-0x101f irq > > 20 at device 29.0 on pci0 device_attach: uhci1 attach returned 12 > > uhci1: port 0x1020-0x103f irq > > 23 at device 29.1 on pci0 device_attach: uhci1 attach returned 12 > > uhci1: port 0x1040-0x105f irq > > 22 at device 29.2 on pci0 device_attach: uhci1 attach returned 12 > > uhci1: port 0x1060-0x107f irq > > 23 at device 29.3 on pci0 device_attach: uhci1 attach returned 12 > > ehci0: mem > > 0xa030-0xa03003ff irq 20 at device 29.7 on pci0 device_attach: ehci0 > > attach returned 12 > > > >Current - 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r235137M > > > >Nothing connected to usb on this systems works. > > > >Full dmesg is here: > > http://people.freebsd.org/~jwd/dl980g7/dmesg.boot.html > > > >Any help is appreciated. > > Hi, > > If you compile a kernel with options USB_DEBUG, there are some tunables under > hw.usb which can set various USB related delays. Try to double all USB > sysctls > having the keyword "delay". > > --HPS Hi, It turns out USB_DEBUG is already enabled in the GENERIC kernel config. # sysctl -a | grep usb | grep delay hw.usb.pr_recovery_delay: 250 hw.usb.pr_poll_delay: 50 Increased these to 500 and 100 respectively in /etc/sysctl.conf. After rebooting, the error still comes up regularly on the console. Is there anything else we should turn on/try? (and a usb keyboard still doesn't work) I didn't notice this near the top of the dmesg output previously. Could it be related? ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 (20120420/tbfadt-662) Thanks, John ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10 prognostication...
Vance Siemens writes: > Can you share a brief overview of what's wrong with it? Umm, it's about as factual as The Onion, except not as funny. FreeBSD never had to "jettison two thirds of its code base and start from scratch". Apple is not involved in FreeBSD development. No Mac OS X or Darwin version "includes" FreeBSD. FreeBSD and Mac OS X will never merge. FreeBSD was never acquired by WinDriver Systems or by anyone else, although a company named WindRiver Systems (makers of the embedded operating system VxWorks, not of Windows video drivers) did at one point acquire BSDI, which had previously acquired Walnut Creek CD-ROM, which was heavily involved in the early history of both FreeBSD and Slackware Linux. The remains of Walnut Creek CD-ROM and BSDI are now known as FreeBSD Mall and iXsystems (of PC-BSD and FreeNAS fame). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sockstat & jid patch
On Wed, May 16, 2012 at 03:12:50PM +1200, Andrew Thompson wrote: > Hi, > > > Here is a quick patch to limit the sockstat output to a specific jail > id, this is useful to verify which sockets a jail has open. A jid of 0 > will show the host system. > > This will result in an extra syscall per socket when -j is set but I > do not think warrants a process cache. > > Any objections? I think you should extend struct xsocket with jid. Unfortunately this breaks ABI so MFC is not possible. That being said, IMHO this patch can be committed to -STABLE if this feature is that important, but -CURRENT should get implementation mentioned earlier. I can try to write a patch in a couple of days (or this evening if I find the time). -- Mateusz Guzik ___ 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"
wdog_kern_pat: liberate from SW_WATCHDOG
I would like to commit something like the following patch.
I think that in-kernel watchdog patting during crash dump is useful with
hardware watchdogs too. The code seems to work fine here.
In fact, I am not sure why wdog_kern_pat was originally tied to SW_WATCHDOG.
commit 59329ca52f5e25266772f157e0640628b223d305
Author: Andriy Gapon
Date: Fri Nov 25 09:59:53 2011 +0200
[test] kernel watchdog patting makes sense with hardware watchdogs too
diff --git a/sys/amd64/amd64/minidump_machdep.c
b/sys/amd64/amd64/minidump_machdep.c
index 057d81d..9be642e 100644
--- a/sys/amd64/amd64/minidump_machdep.c
+++ b/sys/amd64/amd64/minidump_machdep.c
@@ -37,9 +37,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
-#ifdef SW_WATCHDOG
#include
-#endif
#include
#include
#include
@@ -177,9 +175,9 @@ blk_write
report_progress(progress, dumpsize);
counter &= (1<<24) - 1;
}
-#ifdef SW_WATCHDOG
+
wdog_kern_pat(WD_LASTVAL);
-#endif
+
if (ptr) {
error = dump_write(di, ptr, 0, dumplo, len);
if (error)
diff --git a/sys/i386/i386/minidump_machdep.c b/sys/i386/i386/minidump_machdep.c
index d57de3a..e0cd1ff 100644
--- a/sys/i386/i386/minidump_machdep.c
+++ b/sys/i386/i386/minidump_machdep.c
@@ -36,9 +36,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
-#ifdef SW_WATCHDOG
#include
-#endif
#include
#include
#include
@@ -143,9 +141,9 @@ blk_write
printf(" %lld", PG2MB(progress >> PAGE_SHIFT));
counter &= (1<<24) - 1;
}
-#ifdef SW_WATCHDOG
+
wdog_kern_pat(WD_LASTVAL);
-#endif
+
if (ptr) {
error = dump_write(di, ptr, 0, dumplo, len);
if (error)
diff --git a/sys/kern/kern_shutdown.c b/sys/kern/kern_shutdown.c
index 2f7a391..54eca2a 100644
--- a/sys/kern/kern_shutdown.c
+++ b/sys/kern/kern_shutdown.c
@@ -66,9 +66,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
-#ifdef SW_WATCHDOG
#include
-#endif
#include
@@ -334,9 +332,7 @@ kern_reboot(int howto)
waittime = 0;
-#ifdef SW_WATCHDOG
wdog_kern_pat(WD_LASTVAL);
-#endif
sys_sync(curthread, NULL);
/*
@@ -362,9 +358,8 @@ kern_reboot(int howto)
if (nbusy < pbusy)
iter = 0;
pbusy = nbusy;
-#ifdef SW_WATCHDOG
+
wdog_kern_pat(WD_LASTVAL);
-#endif
sys_sync(curthread, NULL);
#ifdef PREEMPTION
diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
index a06ba31..6e1333b 100644
--- a/sys/kern/vfs_subr.c
+++ b/sys/kern/vfs_subr.c
@@ -73,9 +73,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
-#ifdef SW_WATCHDOG
#include
-#endif
#include
@@ -1868,10 +1866,10 @@ sched_sync(void)
LIST_INSERT_HEAD(next, bo, bo_synclist);
continue;
}
-#ifdef SW_WATCHDOG
+
if (first_printf == 0)
wdog_kern_pat(WD_LASTVAL);
-#endif
+
}
if (!LIST_EMPTY(gslp)) {
mtx_unlock(&sync_mtx);
diff --git a/sys/x86/x86/dump_machdep.c b/sys/x86/x86/dump_machdep.c
index 4e6546d..5c874f4 100644
--- a/sys/x86/x86/dump_machdep.c
+++ b/sys/x86/x86/dump_machdep.c
@@ -36,9 +36,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
-#ifdef SW_WATCHDOG
#include
-#endif
#include
#include
#include
@@ -198,9 +196,9 @@ cb_dumpdata(struct md_pa *mdp, int seqnr, void *arg)
a = pa + i * PAGE_SIZE;
va = pmap_kenter_temporary(trunc_page(a), i);
}
-#ifdef SW_WATCHDOG
+
wdog_kern_pat(WD_LASTVAL);
-#endif
+
error = dump_write(di, va, 0, dumplo, sz);
if (error)
break;
--
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"
