Re: FS hang when creating snapshots on a UFS SU+J setup
Date: Mon, 9 Jan 2012 18:30:51 +0100 From: Yamagi Burmeister li...@yamagi.org To: j...@freebsd.org, mckus...@freebsd.org Cc: freebsd-current@freebsd.org, br...@bryce.net Subject: Re: FS hang when creating snapshots on a UFS SU+J setup Hello, I'm sorry to bother you, but you may not be aware of this thread and this problem. We are several people experiencing deadlocks, kernel panics and other problems when creating sanpshots on file systems with SU+J. It would be nice to get some feedback, e.g. how can we help debugging and / or fixing this problem. Thank you, Yamagi First step in debugging is to find out if the problem is SU+J specific. To find out, turn off SU+J but leave SU. This change is done by running: umount filesystem tunefs -j disable filesystem mount filesystem cd filesystem rm .sujournal You may want to run `fsck -f' on the filesystem while you have it unmounted just to be sure that it is clean. Then run your snapshot request to see if it still fails. If it works, then we have narrowed the problem down to something related to SU+J. If it fails then we have a broader issue to deal with. If you wish to go back to using SU+J after the test, you can reenable SU+J by running: umount filesystem tunefs -j enable filesystem mount filesystem When responding to me, it is best to use my mckus...@mckusick.com email as I tend to read it more regularly. Kirk McKusick ___ 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: Problem with ACPI / reboot: Black Screen? Part No 2
On Tue, Jan 10, 2012 at 7:12 PM, Fischer Markus mfisc...@reitzner.de wrote: Hello, I habe a BIG Problem with the ACPI Interface. The problem is the reboot command. The Shutdown command works. I don't think ``reboot`` is the command you want. If you want the computer to shut down, and then restart, you should use ``shutdown -r now``, which will invoke ``reboot`` at the appropriate point. Easy enough to check... Cheers 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
bus dma: a flag/quirk for page zero
Some hardware interfaces may reserve a special meaning for a (physical) memory address value of zero. One example is the OHCI specification where a zero value in CurrentBufferPointer doesn't mean a physical address, but has a reserved meaning. To be honest I don't have another example :) but don't preclude its existence. To deal with this peculiarity we could use a special flag/quirk that would instruct the bus dma code to never use the page zero for communication with the hardware. Here's a proof of concept patch that implements the idea: http://people.freebsd.org/~avg/usb-dma-pagezero.diff Some concerns: - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag - the patch implements the flag only for x86 at the moment - usb code uses the flag regardless of the actual controller type What do you think? -- 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: bus dma: a flag/quirk for page zero
I think it would be just simpler to disallow page zero usage period. Can you think of any case where physical page 0 is ever a valid DMA address? At the very least, require bounce buffers. On Tue, 10 Jan 2012, Andriy Gapon wrote: Some hardware interfaces may reserve a special meaning for a (physical) memory address value of zero. One example is the OHCI specification where a zero value in CurrentBufferPointer doesn't mean a physical address, but has a reserved meaning. To be honest I don't have another example :) but don't preclude its existence. To deal with this peculiarity we could use a special flag/quirk that would instruct the bus dma code to never use the page zero for communication with the hardware. Here's a proof of concept patch that implements the idea: http://people.freebsd.org/~avg/usb-dma-pagezero.diff Some concerns: - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag - the patch implements the flag only for x86 at the moment - usb code uses the flag regardless of the actual controller type What do you think? -- 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 ___ 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: bus dma: a flag/quirk for page zero
On Tue, 2012-01-10 at 22:18 +0200, Andriy Gapon wrote: Some hardware interfaces may reserve a special meaning for a (physical) memory address value of zero. One example is the OHCI specification where a zero value in CurrentBufferPointer doesn't mean a physical address, but has a reserved meaning. To be honest I don't have another example :) but don't preclude its existence. To deal with this peculiarity we could use a special flag/quirk that would instruct the bus dma code to never use the page zero for communication with the hardware. Here's a proof of concept patch that implements the idea: http://people.freebsd.org/~avg/usb-dma-pagezero.diff Some concerns: - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag - the patch implements the flag only for x86 at the moment - usb code uses the flag regardless of the actual controller type What do you think? I think another way to handle this, one that doesn't require modifying the busdma_machdep implementation for every architecture, would be for usb_dma_tag_create() to set lowaddr to zero and provide a filter func that filters based on both the value zero and the expression currently being passed as lowaddr. At least, I think that's how the filterfunc stuff is supposed to work, I've never actually coded a busdma filter. This has the advantage I call locality of strangeness. If only the OHCI hardware needs this strange processing, and it seems like in the future this strangeness will still be more the exception than the rule, then the strangeness is best kept close to the place where it's needed, rather than being spread out all over the place (lots of machdep places). -- Ian ___ 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 ia64/ia64
TB --- 2012-01-10 20:46:40 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-10 20:46:40 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-01-10 20:46:40 - cleaning the object tree TB --- 2012-01-10 20:47:04 - cvsupping the source tree TB --- 2012-01-10 20:47:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-01-10 20:47:19 - building world TB --- 2012-01-10 20:47:19 - CROSS_BUILD_TESTING=YES TB --- 2012-01-10 20:47:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-10 20:47:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-10 20:47:19 - SRCCONF=/dev/null TB --- 2012-01-10 20:47:19 - TARGET=ia64 TB --- 2012-01-10 20:47:19 - TARGET_ARCH=ia64 TB --- 2012-01-10 20:47:19 - TZ=UTC TB --- 2012-01-10 20:47:19 - __MAKE_CONF=/dev/null TB --- 2012-01-10 20:47:19 - cd /src TB --- 2012-01-10 20:47:19 - /usr/bin/make -B buildworld World build started on Tue Jan 10 20:47:20 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 [...] cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_class.c -o login_class.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_crypt.c -o login_crypt.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_ok.c -o login_ok.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_times.c -o login_times.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_tty.c -o login_tty.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/pidfile.c -o pidfile.o cc1: warnings being treated as errors /src/lib/libutil/pidfile.c:272: warning: no previous prototype for 'pidfile_fileno' *** Error code 1 Stop in /src/lib/libutil. *** 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-01-10 21:11:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-10 21:11:11 - ERROR: failed to build world TB --- 2012-01-10 21:11:11 - 1067.38 user 264.48 system 1470.57 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ 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: bus dma: a flag/quirk for page zero
on 10/01/2012 22:53 Ian Lepore said the following: On Tue, 2012-01-10 at 22:18 +0200, Andriy Gapon wrote: Some hardware interfaces may reserve a special meaning for a (physical) memory address value of zero. One example is the OHCI specification where a zero value in CurrentBufferPointer doesn't mean a physical address, but has a reserved meaning. To be honest I don't have another example :) but don't preclude its existence. To deal with this peculiarity we could use a special flag/quirk that would instruct the bus dma code to never use the page zero for communication with the hardware. Here's a proof of concept patch that implements the idea: http://people.freebsd.org/~avg/usb-dma-pagezero.diff Some concerns: - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag - the patch implements the flag only for x86 at the moment - usb code uses the flag regardless of the actual controller type What do you think? I think another way to handle this, one that doesn't require modifying the busdma_machdep implementation for every architecture, would be for usb_dma_tag_create() to set lowaddr to zero and provide a filter func that filters based on both the value zero and the expression currently being passed as lowaddr. At least, I think that's how the filterfunc stuff is supposed to work, I've never actually coded a busdma filter. This has still some problems: - filter func is called for the range (lowaddr, hiaddr], that is lowadr is not inclusive, as such there is no way to filter page zero - a bounce page could still be at the physical address zero - and overriding the above, even worse, bounce pages are allocated in the range below lowaddr, so with lowaddr of zero it's impossible to have any bounce pages This has the advantage I call locality of strangeness. If only the OHCI hardware needs this strange processing, and it seems like in the future this strangeness will still be more the exception than the rule, then the strangeness is best kept close to the place where it's needed, rather than being spread out all over the place (lots of machdep places). -- 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
memory barriers in bus_dmamap_sync() ?
I was glancing through manpages and implementations of bus_dma(9) and i am a bit unclear on what this API (in particular, bus_dmamap_sync() ) does in terms of memory barriers. I see that the x86/amd64 and ia64 code only does the bounce buffers. The mips seems to do some coherency-related calls. How do we guarantee, say, that a recently built packet is to memory before issuing the tx command to the NIC ? cheers luigi ___ 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: bus dma: a flag/quirk for page zero
on 10/01/2012 22:54 Matthew Jacob said the following: I think it would be just simpler to disallow page zero usage period. That would be simpler indeed. Can you think of any case where physical page 0 is ever a valid DMA address? Not sure if I got your question right. I think that it's possible that an arbitrary virtual page with data could reside at the physical address zero. One particular case that I ran into in practice is that at least amd64 dump code always includes page zero into a dump and the umass+usb code tries to do a direct dma from it. At the very least, require bounce buffers. Not sure if I got this suggestion in this terse form. Could you please explain? Thank you! On Tue, 10 Jan 2012, Andriy Gapon wrote: Some hardware interfaces may reserve a special meaning for a (physical) memory address value of zero. One example is the OHCI specification where a zero value in CurrentBufferPointer doesn't mean a physical address, but has a reserved meaning. To be honest I don't have another example :) but don't preclude its existence. To deal with this peculiarity we could use a special flag/quirk that would instruct the bus dma code to never use the page zero for communication with the hardware. Here's a proof of concept patch that implements the idea: http://people.freebsd.org/~avg/usb-dma-pagezero.diff Some concerns: - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag - the patch implements the flag only for x86 at the moment - usb code uses the flag regardless of the actual controller type What do you think? -- 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 -- 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: bus dma: a flag/quirk for page zero
On Tue, 2012-01-10 at 23:15 +0200, Andriy Gapon wrote: on 10/01/2012 22:53 Ian Lepore said the following: On Tue, 2012-01-10 at 22:18 +0200, Andriy Gapon wrote: Some hardware interfaces may reserve a special meaning for a (physical) memory address value of zero. One example is the OHCI specification where a zero value in CurrentBufferPointer doesn't mean a physical address, but has a reserved meaning. To be honest I don't have another example :) but don't preclude its existence. To deal with this peculiarity we could use a special flag/quirk that would instruct the bus dma code to never use the page zero for communication with the hardware. Here's a proof of concept patch that implements the idea: http://people.freebsd.org/~avg/usb-dma-pagezero.diff Some concerns: - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag - the patch implements the flag only for x86 at the moment - usb code uses the flag regardless of the actual controller type What do you think? I think another way to handle this, one that doesn't require modifying the busdma_machdep implementation for every architecture, would be for usb_dma_tag_create() to set lowaddr to zero and provide a filter func that filters based on both the value zero and the expression currently being passed as lowaddr. At least, I think that's how the filterfunc stuff is supposed to work, I've never actually coded a busdma filter. This has still some problems: - filter func is called for the range (lowaddr, hiaddr], that is lowadr is not inclusive, as such there is no way to filter page zero - a bounce page could still be at the physical address zero - and overriding the above, even worse, bounce pages are allocated in the range below lowaddr, so with lowaddr of zero it's impossible to have any bounce pages Wow, I didn't realize. That almost reads like a list of bugs in the current busdma design. It seems especially wrong to assume that no hardware in the world now or ever would have its range of DMA-able addresses in the middle of its physical address space. I'll throw one more idea out, (because it just popped into my head, not because I think it's the best possible idea)... Could the problems you list be circumvented (for this situation and maybe others) with a new flag BUS_DMA_ALWAYS_FILTER that makes the filter function run regardless of the low/high addr values? That would add the flexibility to handle any arbitary kinds of ranges no matter what hardware or strange requirements come along. -- Ian ___ 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 mips/mips
TB --- 2012-01-10 21:11:12 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-10 21:11:12 - starting HEAD tinderbox run for mips/mips TB --- 2012-01-10 21:11:12 - cleaning the object tree TB --- 2012-01-10 21:11:19 - cvsupping the source tree TB --- 2012-01-10 21:11:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-01-10 21:11:32 - building world TB --- 2012-01-10 21:11:32 - CROSS_BUILD_TESTING=YES TB --- 2012-01-10 21:11:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-10 21:11:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-10 21:11:32 - SRCCONF=/dev/null TB --- 2012-01-10 21:11:32 - TARGET=mips TB --- 2012-01-10 21:11:32 - TARGET_ARCH=mips TB --- 2012-01-10 21:11:32 - TZ=UTC TB --- 2012-01-10 21:11:32 - __MAKE_CONF=/dev/null TB --- 2012-01-10 21:11:32 - cd /src TB --- 2012-01-10 21:11:32 - /usr/bin/make -B buildworld World build started on Tue Jan 10 21:11:32 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 [...] cc -O -pipe -G0 -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_class.c -o login_class.o cc -O -pipe -G0 -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_crypt.c -o login_crypt.o cc -O -pipe -G0 -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_ok.c -o login_ok.o cc -O -pipe -G0 -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_times.c -o login_times.o cc -O -pipe -G0 -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_tty.c -o login_tty.o cc -O -pipe -G0 -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/pidfile.c -o pidfile.o cc1: warnings being treated as errors /src/lib/libutil/pidfile.c:272: warning: no previous prototype for 'pidfile_fileno' *** Error code 1 Stop in /src/lib/libutil. *** 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-01-10 21:32:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-10 21:32:00 - ERROR: failed to build world TB --- 2012-01-10 21:32:00 - 878.45 user 251.62 system 1248.00 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ 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: couldn't log on to my -CURRENT machine after upgrade to latest PAM
If at any point in this conversation I seemed to make _no sense at all_, it was because I conflated it with a completely different OpenPAM issue (error reporting in openpam_dynamic.c) which has been on my mind lately. Sorry about that. I will attempt to address both issues in the next release, which I intend to roll in February. 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: memory barriers in bus_dmamap_sync() ?
On Tue, 2012-01-10 at 22:37 +0100, Luigi Rizzo wrote: I was glancing through manpages and implementations of bus_dma(9) and i am a bit unclear on what this API (in particular, bus_dmamap_sync() ) does in terms of memory barriers. I see that the x86/amd64 and ia64 code only does the bounce buffers. The mips seems to do some coherency-related calls. How do we guarantee, say, that a recently built packet is to memory before issuing the tx command to the NIC ? cheers luigi I've always assumed that when the concept of a memory barrier means anything for a given architecture, it's implied that the bus_dmamap_sync() call has to invoke it as needed to ensure the DMA operation picks up the right data. Maybe it would be good if the manpage said that straight out. The ARM implementations do use the memory barrier operations, in the form of a call to cpu_drain_writebuf() in the busdma_machdep code. The ARM specification says that the CPU is stopped until all buffered data is written to memory for that operation. -- Ian ___ 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: memory barriers in bus_dmamap_sync() ?
On 10 January 2012 13:37, Luigi Rizzo ri...@iet.unipi.it wrote: I was glancing through manpages and implementations of bus_dma(9) and i am a bit unclear on what this API (in particular, bus_dmamap_sync() ) does in terms of memory barriers. I see that the x86/amd64 and ia64 code only does the bounce buffers. The mips seems to do some coherency-related calls. How do we guarantee, say, that a recently built packet is to memory before issuing the tx command to the NIC ? The drivers should be good examples of doing the right thing. You just do pre-map and post-map calls as appropriate. Some devices don't bother with this on register accesses and this is a bug. (eg, ath/ath_hal.) Others (eg iwn) do explicit flushes where needed. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc/powerpc
TB --- 2012-01-10 21:32:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-10 21:32:00 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-01-10 21:32:00 - cleaning the object tree TB --- 2012-01-10 21:32:19 - cvsupping the source tree TB --- 2012-01-10 21:32:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-01-10 21:32:31 - building world TB --- 2012-01-10 21:32:31 - CROSS_BUILD_TESTING=YES TB --- 2012-01-10 21:32:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-10 21:32:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-10 21:32:31 - SRCCONF=/dev/null TB --- 2012-01-10 21:32:31 - TARGET=powerpc TB --- 2012-01-10 21:32:31 - TARGET_ARCH=powerpc TB --- 2012-01-10 21:32:31 - TZ=UTC TB --- 2012-01-10 21:32:31 - __MAKE_CONF=/dev/null TB --- 2012-01-10 21:32:31 - cd /src TB --- 2012-01-10 21:32:31 - /usr/bin/make -B buildworld World build started on Tue Jan 10 21:32:32 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 [...] cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_class.c -o login_class.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_crypt.c -o login_crypt.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_ok.c -o login_ok.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_times.c -o login_times.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_tty.c -o login_tty.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/pidfile.c -o pidfile.o cc1: warnings being treated as errors /src/lib/libutil/pidfile.c:272: warning: no previous prototype for 'pidfile_fileno' *** Error code 1 Stop in /src/lib/libutil. *** 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-01-10 21:56:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-10 21:56:53 - ERROR: failed to build world TB --- 2012-01-10 21:56:53 - 1097.79 user 257.83 system 1492.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
[head tinderbox] failure on powerpc64/powerpc
TB --- 2012-01-10 21:38:04 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-10 21:38:04 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-01-10 21:38:04 - cleaning the object tree TB --- 2012-01-10 21:38:24 - cvsupping the source tree TB --- 2012-01-10 21:38:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-01-10 21:38:36 - building world TB --- 2012-01-10 21:38:36 - CROSS_BUILD_TESTING=YES TB --- 2012-01-10 21:38:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-10 21:38:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-10 21:38:36 - SRCCONF=/dev/null TB --- 2012-01-10 21:38:36 - TARGET=powerpc TB --- 2012-01-10 21:38:36 - TARGET_ARCH=powerpc64 TB --- 2012-01-10 21:38:36 - TZ=UTC TB --- 2012-01-10 21:38:36 - __MAKE_CONF=/dev/null TB --- 2012-01-10 21:38:36 - cd /src TB --- 2012-01-10 21:38:36 - /usr/bin/make -B buildworld World build started on Tue Jan 10 21:38:37 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 [...] cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_class.c -o login_class.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_crypt.c -o login_crypt.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_ok.c -o login_ok.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_times.c -o login_times.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/login_tty.c -o login_tty.o cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/pidfile.c -o pidfile.o cc1: warnings being treated as errors /src/lib/libutil/pidfile.c:272: warning: no previous prototype for 'pidfile_fileno' *** Error code 1 Stop in /src/lib/libutil. *** 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-01-10 22:04:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-10 22:04:07 - ERROR: failed to build world TB --- 2012-01-10 22:04:07 - 1164.58 user 266.92 system 1563.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
Re: bus dma: a flag/quirk for page zero
on 10/01/2012 23:27 Ian Lepore said the following: On Tue, 2012-01-10 at 23:15 +0200, Andriy Gapon wrote: This has still some problems: - filter func is called for the range (lowaddr, hiaddr], that is lowadr is not inclusive, as such there is no way to filter page zero - a bounce page could still be at the physical address zero - and overriding the above, even worse, bounce pages are allocated in the range below lowaddr, so with lowaddr of zero it's impossible to have any bounce pages Wow, I didn't realize. That almost reads like a list of bugs in the current busdma design. It seems especially wrong to assume that no hardware in the world now or ever would have its range of DMA-able addresses in the middle of its physical address space. I am tempted to agree with you here, but since this is my first encounter with the bus dma api I prefer to be cautious. I think that there should be good reasons, even if historical, why the current api is the way it is. E.g. I can not think of a good efficient way to allocate proper bounce page if the whole memory range is subject to filtering. Incremental try and error doesn't sound efficient... I'll throw one more idea out, (because it just popped into my head, not because I think it's the best possible idea)... Could the problems you list be circumvented (for this situation and maybe others) with a new flag BUS_DMA_ALWAYS_FILTER that makes the filter function run regardless of the low/high addr values? That would add the flexibility to handle any arbitary kinds of ranges no matter what hardware or strange requirements come along. This should/could work, but it has the original problem that it has to be implemented for all archs separately. And also the algorithm for allocating bounce pages in this case needs to be devised. -- 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: bus dma: a flag/quirk for page zero
At the very least, require bounce buffers. Not sure if I got this suggestion in this terse form. Could you please explain? Physical address zero can be DMA'd, but via bounce buffers. bcopy from address zero up through a pagesize to a bounce buffer, do the dma from there (read case), write case the opposite order ___ 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: memory barriers in bus_dmamap_sync() ?
On Tue, Jan 10, 2012 at 01:52:49PM -0800, Adrian Chadd wrote:
On 10 January 2012 13:37, Luigi Rizzo ri...@iet.unipi.it wrote:
I was glancing through manpages and implementations of bus_dma(9)
and i am a bit unclear on what this API (in particular, bus_dmamap_sync() )
does in terms of memory barriers.
I see that the x86/amd64 and ia64 code only does the bounce buffers.
The mips seems to do some coherency-related calls.
How do we guarantee, say, that a recently built packet is
to memory before issuing the tx command to the NIC ?
The drivers should be good examples of doing the right thing. You just
do pre-map and post-map calls as appropriate.
Some devices don't bother with this on register accesses and this is a
bug. (eg, ath/ath_hal.) Others (eg iwn) do explicit flushes where
needed.
so you are saying that drivers are correct unless they are buggy :)
Anyways... i see that some drivers use wmb() and rmb() and redefine
their own version, usually based on lfence/sfence even on i386
#define rmb() __asm volatile(lfence ::: memory)
#define wmb() __asm volatile(sfence ::: memory)
whereas the standard definitions are slightly different, e.g.
sys/i386/include/atomic.h:
#define rmb() __asm __volatile(lock; addl $0,(%%esp) : : :
memory)
#define wmb() __asm __volatile(lock; addl $0,(%%esp) : : :
memory)
and our bus_space API in sys/x86/include/bus.h is a bit unclear to
me (other than the fact that having 4 unused arguments don't really
encourage its use...)
static __inline void
bus_space_barrier(bus_space_tag_t tag __unused, bus_space_handle_t bsh
__unused,
bus_size_t offset __unused, bus_size_t len __unused, int
flags)
{
#ifdef __GNUCLIKE_ASM
if (flags BUS_SPACE_BARRIER_READ)
#ifdef __amd64__
__asm __volatile(lock; addl $0,0(%%rsp) : : : memory);
#else
__asm __volatile(lock; addl $0,0(%%esp) : : : memory);
#endif
else
__asm __volatile( : : : memory);
#endif
}
cheers
luigi
___
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: bus dma: a flag/quirk for page zero
on 11/01/2012 00:23 Matthew Jacob said the following: At the very least, require bounce buffers. Not sure if I got this suggestion in this terse form. Could you please explain? Physical address zero can be DMA'd, but via bounce buffers. bcopy from address zero up through a pagesize to a bounce buffer, do the dma from there (read case), write case the opposite order Ah, right. I think that that's what the patch tries to do (among other things) if the flag is set. -- 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: [head tinderbox] failure on powerpc64/powerpc
On Jan 10, 2012, at 4:04 PM, FreeBSD Tinderbox wrote: cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/pidfile.c -o pidfile.o cc1: warnings being treated as errors /src/lib/libutil/pidfile.c:272: warning: no previous prototype for 'pidfile_fileno' *** Error code 1 Stop in /src/lib/libutil. *** Error code 1 I'm not sure how I broke the build -- src/lib/libutil/libutil.h has the pidfile_fileno() prototype. Guy This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure. ___ 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
Very fresh (two days ago) 10-current becomes completely unresponsive under load
Hello, FreeBSD. I have home router+AP based on Soekris net5501 (500Mhz GEODE CPU, 512MiB of RAM). It is equipped with vrX NICs (4 of them on-board, one is used as upstream to my ISP, other are unconnectd), em0 PCI board (legacy driver, downstream to my home network) and PCI ath0 (WiFi, for my home wireless network). ISP is connected with PPPoE, mpd 5.6 is used. It is shaped to 40Mbit by ISP. Alos, I have IPv6 tunnel to Hurricane Electric. Box does PPPoE/ipfw/ipfw-nat, DNS (bind from base system), dhcpd, hostapd, nut (network client for UPS, UPS is connected to other box) and it's all. It has serial console to my other computer (no VGA//KBD console on this hardware). I'm running 10-CURRENT to have access to latest ath (WiFi) code. I've used version from 23 Nov 2011 till yesterday, without any significant problems. Then it was upgraded to sources csupped 9 of Jan 2011. And now under network load (it could be loaded up to 75% CPU according to my previous experience, I never seen more than that), it becomes totally unresponsive. It could be pinged. But SSH connection takes tens of minutes. Typing login and wassword on serical console could take 2-5 minutes too. DNS timeouts become frequent. It is alive. But unresponsive. I even could not run top on it in such moments, as it doesn't response to typing, even if I logged in before this problem. After some time it answers and works normal for 2-3 minutes (ssh, serial console, etc.) but after that it hangs again. No any special messages on console or in demsg output. OH! I have top running right now, when it hangs. 0% idle time, LA becomes 20 when it have only 35 processes at all, but there is no specific process consuming CPU. Kernel config is stripped down GENERIC, with SHED_ULE. And I never have such problems with 10-CURRENT from 23 Nov 2011. -- // Black Lion AKA Lev Serebryakov l...@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: couldn't log on to my -CURRENT machine after upgrade to latest PAM
On 10 Jan, Dag-Erling Smørgrav wrote: If at any point in this conversation I seemed to make _no sense at all_, it was because I conflated it with a completely different OpenPAM issue (error reporting in openpam_dynamic.c) which has been on my mind lately. Sorry about that. I will attempt to address both issues in the next release, which I intend to roll in February. Yeah, I didn't see where the change in question would affect error handling, but I think my first patch suggestion would ignore errors. I thought you were commenting on that in your followup messsage. ___ 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: Very fresh (two days ago) 10-current becomes completely unresponsive under load
Hello, Lev. You wrote 11 января 2012 г., 3:05:29: OH! I have top running right now, when it hangs. 0% idle time, LA becomes 20 when it have only 35 processes at all, but there is no specific process consuming CPU. Ok, it seems, that here is a problem (CPU time : PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND 12 root -16- 0K 8K sleep 18:35 30.18% ng_queue And after that 5 minutes without updates, than normal numbers. It seems, that root of problem is: (a) netgraph in this version of kernel OR (b) new mpd 5.6 (previous version had 5.5). P.S. Adding net@ and mav@ to CC, original posting with all data is in current@ -- // Black Lion AKA Lev Serebryakov l...@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: Very fresh (two days ago) 10-current becomes completely unresponsive under load
On 01/11/12 01:21, Lev Serebryakov wrote: Hello, Lev. You wrote 11 января 2012 г., 3:05:29: OH! I have top running right now, when it hangs. 0% idle time, LA becomes 20 when it have only 35 processes at all, but there is no specific process consuming CPU. Ok, it seems, that here is a problem (CPU time : PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND 12 root -16- 0K 8K sleep 18:35 30.18% ng_queue And after that 5 minutes without updates, than normal numbers. It seems, that root of problem is: (a) netgraph in this version of kernel OR (b) new mpd 5.6 (previous version had 5.5). I remember no changes in mpd-5.6 that I would expect to cause this. Any way it should be trivial to check -- just build 5.5. What do you have configured in mpd configuration and netgraph at all? AFAIR for plain PPPoE it is not very typical to use ng_queue at all as it doesn't requires stack unwrapping and at least few years ago stack size was sufficient to run all processing in one pass. -- Alexander Motin ___ 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: Very fresh (two days ago) 10-current becomes completely unresponsive under load
On 01/10/12 17:21, Lev Serebryakov wrote: Hello, Lev. You wrote 11 января 2012 г., 3:05:29: OH! I have top running right now, when it hangs. 0% idle time, LA becomes 20 when it have only 35 processes at all, but there is no specific process consuming CPU. Ok, it seems, that here is a problem (CPU time : PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND 12 root -16- 0K 8K sleep 18:35 30.18% ng_queue And after that 5 minutes without updates, than normal numbers. It seems, that root of problem is: (a) netgraph in this version of kernel OR (b) new mpd 5.6 (previous version had 5.5). P.S. Adding net@ and mav@ to CC, original posting with all data is in current@ If it were me, I would also try with the older 44BSD scheduler, just to see what happens. -- Chuck Burns The Southern Libertarian http://www.thesouthernlibertarian.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Very fresh (two days ago) 10-current becomes completely unresponsive under load
Hello, Alexander. You wrote 11 января 2012 г., 3:35:44: I remember no changes in mpd-5.6 that I would expect to cause this. Any way it should be trivial to check -- just build 5.5. I'll try tomorrow. What do you have configured in mpd configuration and netgraph at all? AFAIR for plain PPPoE it is not very typical to use ng_queue at all as it doesn't requires stack unwrapping and at least few years ago stack size was sufficient to run all processing in one pass. I've sent config to you directly. BTW, I've never seen ng_queue in top 10 lines before. Interrupts? For sure. Soft interurpts (netisr)? Yes. ng_queue? Never. -- // Black Lion AKA Lev Serebryakov l...@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: Very fresh (two days ago) 10-current becomes completely unresponsive under load
Hi, I'd suggest verifying that it's _just_ a kernel update that messes with it. And once you've verified that, what about doing some kernel source version bisecting to narrow down when the relevant change went in that's caused your regression? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Could you please try this: # cd /usr/src/contrib # mv openpam openpam.orig # svn export svn://svn.des.no/openpam/trunk@526 openpam # cd ../lib/libpam # make depend make all make install In addition to the pam.conf issue, the major changes relative to head are reduced log spam, improved log messages in certain error conditions, and a different default password prompt for remote logins. 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: FS hang when creating snapshots on a UFS SU+J setup
Le mar 10/01/12 19:30, Kirk McKusick mckus...@mckusick.com a écrit: Date: Mon, 9 Jan 2012 18:30:51 +0100 From: Yamagi Burmeister lists@yamagi .org To: jeff@freebsd .org, mckusick @freebsd.org Cc: f reebsd-curr...@freebsd.org, bryce@bryce.n et Subject: Re: FS hang when creating snapshots on a UFS SU+J setup Hello, I'm sorry to bother you, but you may not be aware of this thread and this problem. We are several people experiencing deadlocks, kernel panics and other problems when creating sanpshots on file systems with SU+J. It would be nice to get some feedback, e.g. how can we help debugging and / or fixing this problem. Thank you, Yamagi First step in debugging is to find out if the problem is SU+J specific. To find out, turn off SU+J but leave SU. This change is done by running: umount filesystem tunefs -j disable filesystem mount filesystem cd filesystem rm .sujournal You may want to run `fsck -f' on the filesystem while you have it unmounted just to be sure that it is clean. Then run your snapshot request to see if it still fails. If it works, then we have narrowed the problem down to something related to SU+J. If it fails then we have a broader issue to deal with. If you wish to go back to using SU+J after the test, you can reenable SU+J by running: umount filesystem tunefs -j enable filesystem mount filesystem When responding to me, it is best to use my mckusic k...@mckusick.com email as I tend to read it more regularly. Kirk McKusick ___ f reebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Hi, Agree that i wasn't disable journaling completely before doing a clean full FSCK. Taking actions requested, i wasn't able to recover this race condition with SUJ. but snapshot still OK with only SU : So here are some few investigations i have taken: (Sorry being too long) This test system was freshly installed by ISO 9.0 RC1 (18 OCTOBER / after the fix) and is csuped on 9_RELENG (40G avail) very basic setup, just dovecot running, on GENERIC. Operations and results: Since it's the rootfs: Clean shutdown, boot single, disable SUJ, mount in RW and remove the .sujournal and the bad snapshots file, clean halt. I reboot in single again, then fsck_ufs -y /dev/ufs/ROOTFS I got some very minor fixup with freeblock count wrong and summary information bad and BLK missing in bitmaps. After a normal reboot, issue a successful snapshot without softupdate journaling just su. I reboot in single again, and reactivate SUJ then reboot in normal mode. Issue snapshot: and again mksnap_ffs eating all cpu, not suspendable, not killable. So i try to figure out what's going on: with systat -v / gstat / top -SCHP and strace / truss / ktrace on ramfs and nfs for tracking mksanp_ffs: Here some results: gstat : 26 seconds intense io activity: like normal snapshot. Bad spare snapshot file created ( UFS label (ROOTFS) not present and some garbage on the beginning. real and sparse size of file 'very' near to a normal snapshot file. Truss begin showing info then hang before being usefull. mksnap_ffs is in running / runnable mode eating 100% cpu in kernel mode, 0% in user mode. systat : hang top still running correctly : 15 to 25 % CPU in interrupt SWI4 : CLOCK ( CPU 2 cores ) strace : only for i386 :-( ktrace: block before showing valuable info, even on remote nfs. regular process hanging on suspfs. hard power cycle: After normal reboot , after regular SUJ FIXUP: Got Panic at the login prompt: ( bg_fsck not started ) panic: ffs_sync: rofs mod ( it's physical machine , no screen shots, ) backtrace show ffs_write_suspend+0x...before the ffs_sync So i retry to reboot with the 9 RC1 CD in live mode, disable suj, disable su, fsck, renable su, suj, mount the fs,without doing something on it, issue a snapshot ( still in live mode) , and this time, the snapshot was OK even with SUJ. So i wrongly figure out that touching the root fs in single user is not as best as touching it with a live CD. But after returning in normal operation, this race is still there. After various tracking tests, and rebooting in normal mode after the SUJ standard recovery: I sometime got a double panic after the login prompt panic:ffs_blkfree_cg and just after the backtrace softdep_process_worklist ... - panic: bufwrite: bufwrite is not busy. I also saw, when there is more io activity while taking snapshot, a kernel panic saying: panic: softdep_deallocate_dependencies: dangling deps Sure something wrong in this setup, because SUJ snapshot work well on other systems and on 9.0-RELEASE so i am lost in cyberspace :-) If i don't issue snapshot , the system is very stable, even with heavy activity. (Smartd has never showing bad things.) Since it's not a production system, i can fresh
Anyone is currently using the rc_fast_and_loose rc.conf variable?
Good day. Sorry for cross-posting, but this question is really belongs to all three lists. Crawling over the rc.d scripts I had found the rc_fast_and_loose variable that affects the way rc.d scripts are processed inside /etc/rc script. There are some problems with certain rc.d script and this variable: they are described in my post to freebsd-rc@, http://lists.freebsd.org/pipermail/freebsd-rc/2011-December/002617.html The question is: does anyone uses rc_fast_and_loose? It seems to be undocumented and not referenced in any scripts and/or manuals. There are at least two ways of proceeding: fix rc.d scripts to work with fast_and_loose and just to eliminate it from rc.subr, so it will be good to know if the second way won't hurt anyone. Thanks. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpP3Gj4wQ9va.pgp Description: PGP signature
