Re: armv7-on-aarch64 stuck at urdlck
On 23.07.2024 11:36, Konstantin Belousov wrote: On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: The good news is that I'm finally able to generate a working/locking test case. The culprit (at least for me) is if "-mcpu" is used when compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf). If it is not used, libthr is broken (regardless of -O level or debug/normal build), but -mcpu=cortex-a15 will always produce a working libthr. I think this is very significant progress. Do you plan to drill down more to see what is going on? So the problem is now clear, and I fear it may apply to other architectures as well. dlopen_object() (from rtld_elf), https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, holds the rtld_bind_lock write lock for almost the entire time a new library is loaded. If the code uses a yet unresolved symbol to load the library, the rtl_bind() function attempts to get read lock of rtld_bind_lock and a deadlock occurs. In this case, it round_up() in _thr_stack_fix_protection, https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. Issued by __aeabi_uidiv (since not all armv7 processors support HW divide). Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols used by rtld_eld and libthr beforehand. Michal
Re: CURRENT, usr/src on git, howto "mergemaster"?
On 04.01.2021 19:59, Steve Kargl wrote: On Mon, Jan 04, 2021 at 10:30:28AM -0800, Enji Cooper wrote: On Jan 4, 2021, at 10:19, Warner Losh wrote: mergemaster has been on its way out since well before the switch to git. It's been disfavored for at least a decade and basically unmaintained in the base for maybe last 5 years. Apart from major breakage, only doc changes have happened in that time. Adding to this: it has no maintainer, it’s less featureful, and it lacks tests. Once I switched to etcupdate a few years back I never looked back at mergemaster. I honestly think it should be deprecated in 13.x and removed in 14.x. It’s been several major releases since it’s been unofficially deprecated. -Enji For something that has been disfavored for a decade, unmaintained for at least 5 years, and now seemly unofficially deprecated, it seems strange that /usr/src/UPDATING does not mention etcupdate in the COMMON ITEMS section. % svn info UPDATING | grep -i vision Revision: 367909 % svn blame UPDATING ... 64477 imp To rebuild everything and install it on the current system. 64477 imp --- ... 262619 jmg mergemaster -Fp [5] 262619 jmg mergemaster -Fi [4] % svn log -r 262619 r262619 | jmg | 2014-02-28 11:51:47 -0800 (Fri, 28 Feb 2014) | 3 lines since -F is safe, and an update from 10-HEAD to 10-STABLE is sooo bloody anoying w/o it.. recommend people use -F too... etcupdate first appeared in the tree on 2012-07-13 (r238423) Moreover mergemaster is still officially documented and recommend as only right method in FreeBSD handbook. See https://www.freebsd.org/doc/handbook/makeworld.html. World is moving, we may have new tools but each deprecation should be, in this order: 1) well announced 2) adjusted in the handbook 3) implemeted Michal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem compiling git from ports
On 01.01.2021 21:19, Filippo Moretti wrote: It worked thank youFilippo On Friday, January 1, 2021, 5:25:10 PM GMT+1, Milan Obuch wrote: On Fri, 1 Jan 2021 16:11:52 + (UTC), Filippo Moretti wrote: I run again portmaster and I have the same error as previously reportedFilippo On Friday, January 1, 2021, 4:05:18 PM GMT+1, Filippo Moretti wrote: Ufs It exits with a different error: ===> Installing contributed scripts /bin/mkdir -p /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib cp -f -R /usr/ports/devel/git/work-default/git-2.30.0/contrib/* /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib ln: /usr/ports/devel/git/work-default/stage/usr/local/etc/bash_completion.d//git-completion.bash: File exists *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/git *** Error code 1 Stop. make: stopped in /usr/ports/devel/git I remember seeing this too. I worked around that using options: cat /var/db/ports/devel_git/options # This file is auto-generated by 'make config'. # Options for git-2.29.2 _OPTIONS_READ=git-2.29.2 _FILE_COMPLETE_OPTIONS_LIST=CONTRIB CURL CVS GITWEB GUI HTMLDOCS ICONV NLS P4 PERL SEND_EMAIL SUBTREE SVN PCRE PCRE2 OPTIONS_FILE_SET+=CONTRIB OPTIONS_FILE_SET+=CURL OPTIONS_FILE_SET+=CVS OPTIONS_FILE_UNSET+=GITWEB OPTIONS_FILE_UNSET+=GUI OPTIONS_FILE_UNSET+=HTMLDOCS OPTIONS_FILE_SET+=ICONV OPTIONS_FILE_UNSET+=NLS OPTIONS_FILE_SET+=P4 OPTIONS_FILE_SET+=PERL OPTIONS_FILE_SET+=SEND_EMAIL OPTIONS_FILE_UNSET+=SUBTREE OPTIONS_FILE_UNSET+=SVN OPTIONS_FILE_SET+=PCRE OPTIONS_FILE_UNSET+=PCRE2 Regards, Milan This is not related to cache fast lookup, but it is dependency bug of ruby ports. My portmaster -ad session failed with the same issue. I noticed that rubby has been update from 2.6 to 2.7 as part of this sesion. # pkg which /usr/local/bin/asciidoctor /usr/local/bin/asciidoctor was installed by package rubygem-asciidoctor-2.0.10 # ls -l /usr/local/bin/asciidoctor -rwxr-xr-x 1 root wheel 560 Jun 7 2020 /usr/local/bin/asciidoctor # /usr/local/bin/asciidoctor /usr/local/bin/asciidoctor: Command not found # ls -l /usr/local/bin/asciidoctor -rwxr-xr-x 1 root wheel 560 Jun 7 2020 /usr/local/bin/asciidoctor root@tegra210:/usr/ports # more /usr/local/bin/asciidoctor #!/usr/local/bin/ruby26 # # This file was generated by RubyGems. # # The application 'asciidoctor' is installed as part of a gem, and # this file is here to facilitate running it. # ... # ls -l /usr/local/bin/ruby26 ls: /usr/local/bin/ruby26: No such file or directory # portmaster -d rubygem-asciidoctor-2.0.10 ... Installing ruby27-gems-3.0.8... pkg-static: ruby27-gems-3.0.8 conflicts with ruby26-gems-3.0.8 (installs files into the same place). Problematic file: /usr/local/bin/gem ... # pkg info | grep ruby26 ruby26-gems-3.0.8 Package management framework for the Ruby language # pkg delete -f ruby26-gems # portmaster -d rubygem-asciidoctor-2.0.10 # /usr/local/bin/asciidoctor Usage: asciidoctor [OPTION]... FILE... Michal ... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld fails ( stopped in /usr/src/lib/libsysdecode )
On 30.11.2020 13:11, Johan Hendriks wrote: On 30/11/2020 12:29, Hans Petter Selasky wrote: On 11/30/20 11:43 AM, Johan Hendriks wrote: My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to r368182 I did a make cleanworld && make cleanworld to make sure i use a fresh build but it errors out with the following message. This is a known issue and will be fixed. --HPS Thank you for the conformation. And thank you all for your work on FreeBSD. regards Johan Fixed in r368187. Sorry for troubles. Michal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3
On 19.10.2020 22:39, Mark Johnston wrote:
> On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote:
>>
>>
>> On 06.10.2020 15:37, Mark Johnston wrote:
>>> On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote:
>>>> Still seeing non-current pmap panics on the Pi3, this time a B+ running
>>>> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master)
>>>> during a -j4 buildworld. The backtrace reports
>>>>
>>>> panic: non-current pmap 0xa00020eab8f0
>>>
>>> Could you show the output of "show procvm" from the debugger?
>>
>> I see same panic too, in my case its very rare - typical scenario is
>> rebuild of kf5 ports (~250, 2 days of full load). Any idea how to debug
>> this?
>> Michal
>
> I suspect that there is some race involving the pmap switching in
> vmspace_exit(), but I can't see it. In the example below, presumably
> process 22604 on CPU 0 is also exiting? Could you show the backtrace?>
> It would also be useful to see the value of PCPU_GET(curpmap) at the
> time of the panic. I'm not sure if there's a way to get that from DDB,
> but I suspect it should be equal to &vmspace0->vm_pmap.
Mark,
I think that I found problem.
The PCPU_GET() is not (and is not supposed to be) an atomic operation,
it expects that thread is at least pinned.
This is not true for pmap_remove_pages() - so I think that the KASSERT
is racy and shoud be removed (or at least covered by
sched_pin()/sched_unpin() pair).
What do you think?
>
> I think vmspace_exit() should issue a release fence with the cmpset and
> an acquire fence when handling the refcnt == 1 case,
Yep, true, fully agree.
Michal
but I don't see why
> that would make a difference here. So, if you can test a debug patch,
> this one will yield a bit more debug info. If you can provide access to
> a vmcore and kernel debug symbols, that'd be even better.
>
> diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c
> index 284f00b3cc0d..3c53ae3b4c1e 100644
> --- a/sys/arm64/arm64/pmap.c
> +++ b/sys/arm64/arm64/pmap.c
> @@ -4838,7 +4838,8 @@ pmap_remove_pages(pmap_t pmap)
> int allfree, field, freed, idx, lvl;
> vm_paddr_t pa;
>
> - KASSERT(pmap == PCPU_GET(curpmap), ("non-current pmap %p", pmap));
> + KASSERT(pmap == PCPU_GET(curpmap),
> + ("non-current pmap %p %p", pmap, PCPU_GET(curpmap)));
>
> lock = NULL;
>
> diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
> index c20005ae64cf..0ad415e3b88c 100644
> --- a/sys/vm/vm_map.c
> +++ b/sys/vm/vm_map.c
> @@ -358,7 +358,10 @@ vmspace_exit(struct thread *td)
> p = td->td_proc;
> vm = p->p_vmspace;
> atomic_add_int(&vmspace0.vm_refcnt, 1);
> - refcnt = vm->vm_refcnt;
> + refcnt = atomic_load_int(&vm->vm_refcnt);
> +
> + KASSERT(vmspace_pmap(vm) == PCPU_GET(curpmap),
> + ("non-current pmap %p %p", pmap, PCPU_GET(curpmap)));
> do {
> if (refcnt > 1 && p->p_vmspace != &vmspace0) {
> /* Switch now since other proc might free vmspace */
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3
On 06.10.2020 15:37, Mark Johnston wrote: > On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote: >> Still seeing non-current pmap panics on the Pi3, this time a B+ running >> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master) >> during a -j4 buildworld. The backtrace reports >> >> panic: non-current pmap 0xa00020eab8f0 > > Could you show the output of "show procvm" from the debugger? I see same panic too, in my case its very rare - typical scenario is rebuild of kf5 ports (~250, 2 days of full load). Any idea how to debug this? Michal panic: non-current pmap 0xa00012e92a80 cpuid = 2 time = 1602831265 KDB: stack backtrace: db_trace_self() at db_fetch_ksymtab+0x148 pc = 0x005f655c lr = 0x00148804 sp = 0x6dc41200 fp = 0x6dc41400 db_fetch_ksymtab() at kdb_backtrace+0x38 pc = 0x00148804 lr = 0x0036d3c0 sp = 0x6dc41410 fp = 0x6dc414d0 kdb_backtrace() at vpanic+0x19c pc = 0x0036d3c0 lr = 0x0032b320 sp = 0x6dc414e0 fp = 0x6dc41530 vpanic() at panic+0x44 pc = 0x0032b320 lr = 0x0032af3c sp = 0x6dc41540 fp = 0x6dc415f0 panic() at pmap_remove_pages+0x5c0 pc = 0x0032af3c lr = 0x0060bf0c sp = 0x6dc41600 fp = 0x6dc41660 pmap_remove_pages() at vmspace_exit+0xb0 pc = 0x0060bf0c lr = 0x005b988c sp = 0x6dc41670 fp = 0x6dc416d0 vmspace_exit() at exit1+0x4fc pc = 0x005b988c lr = 0x002e3fcc sp = 0x6dc416e0 fp = 0x6dc41740 exit1() at sys_sys_exit+0x10 pc = 0x002e3fcc lr = 0x002e3acc sp = 0x6dc41750 fp = 0x6dc417a0 sys_sys_exit() at unhandled_exception+0x57c pc = 0x002e3acc lr = 0x0061258c sp = 0x6dc417b0 fp = 0x6dc417c0 unhandled_exception() at do_el0_sync+0x324 pc = 0x0061258c lr = 0x00611f64 sp = 0x6dc417d0 fp = 0x6dc41800 do_el0_sync() at do_el0_sync+0x128 pc = 0x00611f64 lr = 0x00611d68 sp = 0x6dc41810 fp = 0x6dc41830 do_el0_sync() at handle_el0_sync+0x90 pc = 0x00611d68 lr = 0x005f8a24 sp = 0x6dc41840 fp = 0x6dc41980 handle_el0_sync() at 0x407a5ed0 pc = 0x005f8a24 lr = 0x407a5ed0 sp = 0x6dc41990 fp = 0xbcb0 KDB: enter: panic [ thread pid 22603 tid 100099 ] Stopped at 0x4077df30: undefined 5442 db> show all pcpu Current CPU: 2 cpuid= 0 dynamic pcpu = 0x66c880 curthread= 0xa000b39eb000: pid 22604 tid 100139 critnest 1 "msgfmt" curpcb = 0x6dd09aa0 fpcurthread = 0xa000b39eb000: pid 22604 "msgfmt" idlethread = 0xa12ad5a0: tid 13 "idle: cpu0" spin locks held: cpuid= 1 dynamic pcpu = 0x45bfc880 curthread= 0xa000da4185a0: pid 22605 tid 101155 critnest 1 "cmake" curpcb = 0x6e02caa0 fpcurthread = 0xa000da4185a0: pid 22605 "cmake" idlethread = 0xa12ad000: tid 14 "idle: cpu1" spin locks held: cpuid= 2 dynamic pcpu = 0x45c00880 curthread= 0xa00012c4c000: pid 22603 tid 100099 critnest 1 "msgfmt" curpcb = 0x6dc41aa0 fpcurthread = 0xa00012c4c5a0: pid 22307 "cmake" idlethread = 0xa12aa5a0: tid 15 "idle: cpu2" spin locks held: cpuid= 3 dynamic pcpu = 0x45c04880 curthread= 0xa788d5a0: pid 7 tid 100039 critnest 1 "doneq0" curpcb = 0x40372aa0 fpcurthread = 0xa00012c4c000: pid 22603 "msgfmt" idlethread = 0xa12aa000: tid 16 "idle: cpu3" spin locks held: db> show procvm p = 0xa00012e5d000, vmspace = 0xa00012e92960, map = 0xa00012e92960, pmap = 0xa00012e92a80 Task map 0xa00012e92960: pmap=0xa00012e92a80, nentries=88, version=170 map entry 0xa0002353b6c0: start=0x20, end=0x208000, eflags=0xc0c, prot=1/7/copy, object=0xa000ba1cec60, offset=0x0, copy (needed) Object 0xa000ba1cec60: type=2, size=0x13, res=19, ref=4, flags=0x1000 ruid -1 charge 0 sref=0, backing_object(0)=(0)+0x0 map entry 0xa000457c3180: start=0x217000, end=0x222000, eflags=0xc0c, prot=5/7/copy, object=0xa000ba1cec60, offset=0x7000, copy (needed) map entry 0xa000b3caa600: start=0x231000, end=0x232000, eflags=0, prot=1/7/copy, object=0xa0004b376c60, offset=0x0, obj ruid 0 charge 1000 Object 0xa0004b376c60: type=0, size=0x1, res=1, ref=1, flags=0x3010 ruid 0 charge 1000 sref=0, ba
Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect)
On 12.07.2020 8:37, Mark Millard via freebsd-arm wrote: > > >> On 2020-Jul-11, at 15:12, Mark Millard wrote: >> >> >>> >>> On 2020-Jul-11, at 14:45, Robert Crowston wrote: >>> >>> So what is the mistake I made here? >>> >>> Should I have given a globally unique name as the first argument to >>> DRIVER_MODULE()? I didn't see that in the man page, and other examples of >>> pcib drivers apparently get away with it. >>> >>> I did notice the weird message about "driver already loaded from kernel". I >>> wondered if that meant I was dragging in code to the core kernel, that >>> would otherwise live in an external module? >>> >>> Let me know how I can help fix it! >>> >>> -- RHC. >> >> It is not an area of expertise for me. I've spent hours just >> getting to the point of sending the notes that I have sent. >> > > Having found no evidence of any likely disaster from trying > the experiment, I've tried: > > # svnlite diff /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c > Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c > === > --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (revision 363021) > +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (working copy) > @@ -739,5 +739,5 @@ > sizeof(struct bcm_pcib_softc), generic_pcie_fdt_driver); > > static devclass_t bcm_pcib_devclass; > -DRIVER_MODULE(pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, 0); > +DRIVER_MODULE(bcm_pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, 0); > > > This was enough of a change for Ethernet and USB to become available > again on the OverDrive 1000. > > Apparently one must search all existing DRIVER_MODULE use and then > pick naming to have the new DRIVER_MODULE(NAME,BUSNAME,... end up > with the NAME,BUSNAME as a unique combination of names (or > combinations for when there is BUSNAME0, BUSNAME1, . . .). > > I also updated the USB3 SSD I use for booting either RPi4 > or Rock64. Be warned that the RPi4 boots are via > UEFI v1.16 use instead of by sysutils/u-boot-rpi4 use. > I do not have things set up for sysutils/u-boot-rpi4 as > stands. > > The SSD booted both contexts fine and the USB worked like > normal. On the Rock64, the built-in EtherNet also worked > fine. For the RPi4, a USB3 EtherNet adapter is used and > it worked fine. > > If someone checks sysutils/u-boot-rpi4 operation and finds > that it works, then I expect that such a patch as above is > all that is required. > > Note: If future bcmD's need similar code, care will > need to be taken naming in DRIVER_MODULE(,... > for them so that uniqueness is maintained. My use of > "bcm_" to match the context is not the only prefix that > would lead to unique naming currently. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > Fixed in r363121. Thanks for the report. Michal Meloun ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r351589 ses no longer attaches
Hi Alexander, thank you for quick response. I confirm that r354923 fixes this issue in 12-STABLE. # dmesg | grep ^ses ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0 ses0: pass1,ada1 in 'Slot 01', SATA Slot: scbus1 target 0 ses0: pass2,ada2 in 'Slot 02', SATA Slot: scbus2 target 0 ses0: pass3,ada3 in 'Slot 03', SATA Slot: scbus3 target 0 ses0: pass4,ada4 in 'Slot 04', SATA Slot: scbus4 target 0 ses0: pass5,ada5 in 'Slot 05', SATA Slot: scbus5 target 0 regards Michal > On 21 Nov 2019, at 00:58, Alexander Motin wrote: > > Hi Michael, > > I'm sorry, I've forgot to merge it after Warner merged his r351356. > Please try the fresh stable/12 and tell if you still have a problem. > > On 20.11.2019 17:34, Michal Vančo wrote: >> Hi, >> >> I have an issue with SES not working with AHCI. After some digging I found a >> thread on freebsd-current >> (https://lists.freebsd.org/pipermail/freebsd-current/2019-August/074176.html) >> where exactly the same issue was described and finally fixed in r351589. My >> question is, will this fix be merged into 12-STABLE? I tried manually >> patching 12-STABLE src tree and after rebuilding the kernel SES started to >> work as expected. I don’t want to run CURRENT just for this simple fix. > > -- > Alexander Motin > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r351589 ses no longer attaches
Hi, I have an issue with SES not working with AHCI. After some digging I found a thread on freebsd-current (https://lists.freebsd.org/pipermail/freebsd-current/2019-August/074176.html) where exactly the same issue was described and finally fixed in r351589. My question is, will this fix be merged into 12-STABLE? I tried manually patching 12-STABLE src tree and after rebuilding the kernel SES started to work as expected. I don’t want to run CURRENT just for this simple fix. regards Michal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
On 29.12.2018 18:47, Dennis Clarke wrote:
> On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote:
>>
>> On 2018-Dec-28, at 12:12, Mark Millard wrote:
>>
>>> On 2018-Dec-28, at 05:13, Michal Meloun
>>> wrote:
>>>
>>>> Mark,
>>>> this is known problem with qemu-user-static.
>>>> Emulation of every single interruptible syscall is broken by design (it
>>>> have signal related races). Theses races cannot be solved without major
>>>> rewrite of syscall emulation code.
>>>> Unfortunately, nobody actively works on this, I think.
>>>>
>
> Following along here quietly and I had to blink at this a few times.
> Is there a bug report somewhere within the qemu world related to this
> 'broken by design' qemu feature?
Firstly, I apologize for late answer. Writing a technically accurate but
still comprehensible report is extremely difficult for me.
Major design issue with qemu-user is the fact that guest (blocking /
interruptible) syscalls must be emulated atomically, including
delivering of asynchronous signals (including signals originated by
other thread).
This is something that cannot be emulated precisely by user mode
program, without specific kernel support. Let me explain this in a
little more details.
Assume that we have following trivial code:
void sig_alarm_handler(…)
{
if (!done) {
do some work;
alarm(10);
}
}
void foo(void)
{
install_signal_handler(SIGALARM, sig_alarm_handler);
alarm(10);
do some work;
while (true) {
rv = select(…, NULL);
if (rv == 0)
do some work;
else if (rv != EINTR)
Report error end exit;
}
}
In native environment, this code works well. It calls alarm signal
handler every 10s, irrespective if signal is fired in the program code
or in libc implementation of select() or if program is waiting in kernel
part of select() syscall.
In qemu-user environment, things get significantly harder. Qemu can
deliver signals to guest only on instruction boundary, the guest signal
handler should see emulated CPU context in consistent state. But kernel
can deliver signal to qemu in any time. Due to this, qemu must store
delivered signals into queue and emit these later, when emulator steps
over next instruction boundary.
Assume that qemu just emulates 'syscall' instruction from guest select()
call. Also assume that no other signals (but SIGALARM) are generated,
and socket used in select() never received or transmits any data.
The first version of qemu-user code emulating select() was:
abi_long do_freebsd_select(..)
{
convert input guest arguments to host;
rv = select(…);
convert output host arguments to guest;
return(rv);
}
But this is very racy. If alarm signal is fired before select(…) enters
kernel, qemu queues it (but does not deliver it to guest because it
isn't on instruction boundary) and continues in emulation. And because
(in our case) select() waits indefinitely, alarm signal is never
delivered to guest and whole program hangs.
Actual qemu code emulating select() looks like:
abi_long do_freebsd_select(..)
{
convert input guest arguments to host;
sigfillset(&mask);
sigprocmask(SIG_BLOCK, &mask, &omask);
if (ts->signal_pending) {
sigprocmask(SIG_SETMASK, &omask, NULL);
/* We have a signal pending so just poll select() and return. */
tv2.tv_sec = tv2.tv_usec = 0;
ret = select(…, , &tv2));
if (ret == 0)
ret = TARGET_EINTR;
} else {
ret = pselect(…, &omask));
sigprocmask(SIG_SETMASK, &omask, NULL);
}
convert output host arguments to guest;
return(rv);
}
This look a much better. The code blocks all signals first, then checks
if any signal is pending. If yes, then does not-blocking select()
(because timeout is zero) and correctly returns EINTR immediately.
Otherwise, it uses other variant of select(), pselect() which adjusts
right signal mask itself.
That's mean that syscall is called with blocked signal delivery, but
kernel adjusts right sigmask before it waits for event. While this looks
like perfect solution and this code closes all races from first version,
then it doesn't. pselect() uses different semantic that select(), it
doesn't update timeout argument. So this solution is also inappropriate.
Moreover, I think, we don't have p equivalents for all blocking
syscalls.
Mark, I hope that this is also the answer to your question posted to
hackers@ and also the exploitation why you see hang.
Linux uses different approach to overcome this issue, safe_syscall ->
https://gitlab.collabora.com/tomeu/qemu/commit/4d330cee37a21aabfc619a1948953559e66951a4
It looks like workable workaround, but I'm not sure about ERESTART
versus EINTR return values. Imho, this can be problem.
I have list of other qemu-user problems (I mean mainly a bsd-user part
of qemu code here), not counti
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
0 wait 1 0:00 0.00% >>> /bin/sh -e -c (cd >>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! >>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES >>> 41567 root 2 52088M13M0 select 4 0:00 0.00% >>> /usr/local/bin/qemu-arm-static ninja -j28 -v all >>> 41585 root 2 520 100M24M0 kqread 8 0:00 0.00% >>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen >>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >>> 41586 root 2 520 100M24M0 kqread 22 0:00 0.00% >>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen >>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >>> >>> So: waiting in kqread trying to run cmake. >>> >>> Unlike some intermittent hang-ups, attaching-then-detaching via gdb does not >>> resume the hung-up processes. Kills of the processes waiting on kqread stop >>> the build. >>> >>> Given the prior ports have been built already, building just >>> multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same point. >>> >>> Building anything that requires multimedia/gstreamer1-qt@qt5 seems to be >>> solidly blocked in my environment. > > > I built a FreeBSD head -r340288 context and tried cross-buiding an > amd64->armv7 ports head -r484783 of my usual ports and the problem > repeated. I also found evidence that originally in the old time frame > I'd disabled part of my originally-intended port builds because of > other problems so multimedia/gstreamer1-qt 's build was not being > tried. > > So the qemu-user-static vintage or content may be what to vary to > narrow down the problem instead of bisecting FreeBSD kernel or world > vintages. clang7 building qemu-user-static or the kernel/world has > been eliminated. > > > (I used -r340288 to match a artifact.ci.freebsd.org build, incorrectly > expecting to bisect via kernel substitutions.) > Mark, this is known problem with qemu-user-static. Emulation of every single interruptible syscall is broken by design (it have signal related races). Theses races cannot be solved without major rewrite of syscall emulation code. Unfortunately, nobody actively works on this, I think. Michal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
0 wait 1 0:00 0.00% >>> /bin/sh -e -c (cd >>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! >>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES >>> 41567 root 2 52088M13M0 select 4 0:00 0.00% >>> /usr/local/bin/qemu-arm-static ninja -j28 -v all >>> 41585 root 2 520 100M24M0 kqread 8 0:00 0.00% >>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen >>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >>> 41586 root 2 520 100M24M0 kqread 22 0:00 0.00% >>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen >>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >>> >>> So: waiting in kqread trying to run cmake. >>> >>> Unlike some intermittent hang-ups, attaching-then-detaching via gdb does not >>> resume the hung-up processes. Kills of the processes waiting on kqread stop >>> the build. >>> >>> Given the prior ports have been built already, building just >>> multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same point. >>> >>> Building anything that requires multimedia/gstreamer1-qt@qt5 seems to be >>> solidly blocked in my environment. > > > I built a FreeBSD head -r340288 context and tried cross-buiding an > amd64->armv7 ports head -r484783 of my usual ports and the problem > repeated. I also found evidence that originally in the old time frame > I'd disabled part of my originally-intended port builds because of > other problems so multimedia/gstreamer1-qt 's build was not being > tried. > > So the qemu-user-static vintage or content may be what to vary to > narrow down the problem instead of bisecting FreeBSD kernel or world > vintages. clang7 building qemu-user-static or the kernel/world has > been eliminated. > > > (I used -r340288 to match a artifact.ci.freebsd.org build, incorrectly > expecting to bisect via kernel substitutions.) > Mark, this is known problem with qemu-user-static. Emulation of every single interruptible syscall is broken by design (it have signal related races). Theses races cannot be solved without major rewrite of syscall emulation code. Unfortunately, nobody actively works on this, I think. Michal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
On 27.12.2018 14:07, Gary Jennejohn wrote:
> On Thu, 27 Dec 2018 03:58:51 -0800
> Enji Cooper wrote:
>
>>> On Dec 27, 2018, at 2:17 AM, Trev wrote:
>>>
>>> Graham Perrin wrote on 26/12/2018 21:20:
>>>> grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
>>>> Wed Dec 26 10:18:52 GMT 2018
>>>> FreeBSD 13.0-CURRENT r342466 GENERIC-NODEBUG
>>>> grahamperrin@momh167-gjp4-8570p:~ % iridium
>>>> ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
>>>> grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' iridium-browser
>>>> www/iridium 2018.5.67_6 FreeBSD
>>>> grahamperrin@momh167-gjp4-8570p:~ %
>>>> Any ideas?
>>>> TIA
>>>
>>> Same problem with a freshly compiled (after 5 days, finished yesterday)
>>> www/chromium on RPi3.
>>>
>>> $ chrome
>>> ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
>>>
>>> $ uname -a
>>> FreeBSD rpi3.sentry.org 13.0-CURRENT FreeBSD 13.0-CURRENT r342189 RPI3
>>> arm64
>>
>> Hmm___ is something wonky with recent changes to rtld-elf that might be
>> impacting ARM64?
>>
>> CCing mmel@, because they might be interested in these bug reports.
>>
>
> No. I saw this with mplayer and also iridium when I installed them
> with pkg on AMD64.
>
>
> Strangely enough, mpv works, even though it shows a dependency on
> libglib-2.0.so.0 when I run ldd on it.
>
> glib-2 has "extern char **environ;" in one of its C-files.
>
I cannot talk about iridium (its i386/amd64 only and I don't want to
infect my headless build box with tons of X11 libraries).
But for multimedia/mplayer, I can say that this problem is caused by
mplayer itself.
The 'environ' is defined as global symbol in /usr/lib/crt1.o:
>readelf -s /usr/lib/crt1.o | grep environ
46: 0008 8 OBJECT GLOBAL DEFAULT COM environ
These startup objects (/usr/lib/crt*.o) are linked to each single
executable (but not to shared libraries). That means that any
dynamically linked executable exports 'environ' symbol (and many, many
others) with globally visibility.
>readelf -s /bin/ls | grep environ
78: 0024 8 OBJECT GLOBAL DEFAULT 22 environ
Because these symbols are globally visible, glib20 (and/or other
libraries) can use them.
Unfortunately, when mplayer binary gets linked, makefile uses symbol
version script '-Wl,--version-script,binary.ver' as part of link
command. And this script explicitly lowers visibility of *all* symbols
(but _IO_stdin_used) to local.
>more binary.ver
MPLAYER_1 {
# to support glibcs abhorrent backwards-compatibility hack
global: _IO_stdin_used;
local: *;
};
>readelf -s mplayer | grep environ
26: 0050 8 OBJECT LOCAL DEFAULT 24 environ
Of course, local symbols are visible only within originating object,
these are invisible for other objects.
I have no idea why mplayer authors uses this script, mainly why version
script is used for *main executable*.
>From my point of view, it's nothing but pure nonsense. This script hides
symbols provided by startup object files so resulting binary is (and
must be) invalid.
I hope that this short description is enough for maintainer to fix these.
Michal
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rm cannot recursively delete directory on tmpfs on RPi2
On 07.12.2018 10:59, Mateusz Guzik wrote: > On 12/7/18, Michal Meloun wrote: >> >> >> On 07.12.2018 7:25, Mateusz Guzik wrote: >>> On 12/7/18, Jia-Shiun Li wrote: >>>> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >>>> >>>>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li >>>>> wrote: >>>>>> >>>>>> amd64 and RPi3 do not have this issue. >>>>>> >>>>>> jsli@rpi2:/home/jsli 13:04 # uname -a >>>>>> FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG >>>>> arm >>>>>> jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt >>>>>> jsli@rpi2:/home/jsli 13:05 # cd /mnt >>>>>> jsli@rpi2:/mnt 13:05 # tar xf >>>>>> /usr/ports/distfiles/sqlite-autoconf-326.tar.gz >>>>>> jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ >>>>>> rm: sqlite-autoconf-326/tea: Operation not permitted >>>>>> rm: sqlite-autoconf-326/: Directory not empty >>>>>> jsli@rpi2:/mnt 13:05 # >>>>>> >>>>>> -Jia-Shiun >>>>> >>>>> Did you check for file flags? Do "ls -lod >>>>> sqlite-autoconf-326/tea". >>>>> >>>>> >>>> Unlikely caused by flags I think. >>>> >>>> jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt >>>> jsli@rpi2:/home/jsli # cd /mnt >>>> jsli@rpi2:/mnt # ls -R >>>> jsli@rpi2:/mnt # mkdir dir >>>> jsli@rpi2:/mnt # ls -R >>>> dir/ >>>> ls: dir: directory causes a cycle >>>> jsli@rpi2:/mnt # >>>> >>>> >>>> looks inode no for directories are wrong >>>> >>>> jsli@rpi2:/mnt # ll -ia >>>> total 4 >>>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ >>>> 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ >>>> 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ >>>> jsli@rpi2:/mnt # ll -ia dir >>>> total 0 >>>> 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ >>>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ >>>> jsli@rpi2:/mnt # >>>> >>> >>> Ouch. >>> >>> Looks like 64-bit atomic on 32-bit arm don't work as advertised. >>> >>> While they should be fixed, I have been meaning to commit the following >>> which will have a side effect of taking care of the bug you ran into: >>> >> >> Mateusz, >> where you see problem with 64-bit atomic on arm? I'm not aware of any >> problem in this area. > > inode allocation for tmpfs (and other places) was recently changed to use > 64-bit atomics (excluding mips and powerpc). So far atomic_fetchadd_64 > failing to bump the number on 32-bit arm (at least for the variant used > by whatever is put on rpi2) looks like a decent explanation. The code > definitely works on amd64. > Fixed in r341679. Thanks for report. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rm cannot recursively delete directory on tmpfs on RPi2
On 07.12.2018 10:59, Mateusz Guzik wrote: > On 12/7/18, Michal Meloun wrote: >> >> >> On 07.12.2018 7:25, Mateusz Guzik wrote: >>> On 12/7/18, Jia-Shiun Li wrote: >>>> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >>>> >>>>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li >>>>> wrote: >>>>>> >>>>>> amd64 and RPi3 do not have this issue. >>>>>> >>>>>> jsli@rpi2:/home/jsli 13:04 # uname -a >>>>>> FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG >>>>> arm >>>>>> jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt >>>>>> jsli@rpi2:/home/jsli 13:05 # cd /mnt >>>>>> jsli@rpi2:/mnt 13:05 # tar xf >>>>>> /usr/ports/distfiles/sqlite-autoconf-326.tar.gz >>>>>> jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ >>>>>> rm: sqlite-autoconf-326/tea: Operation not permitted >>>>>> rm: sqlite-autoconf-326/: Directory not empty >>>>>> jsli@rpi2:/mnt 13:05 # >>>>>> >>>>>> -Jia-Shiun >>>>> >>>>> Did you check for file flags? Do "ls -lod >>>>> sqlite-autoconf-326/tea". >>>>> >>>>> >>>> Unlikely caused by flags I think. >>>> >>>> jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt >>>> jsli@rpi2:/home/jsli # cd /mnt >>>> jsli@rpi2:/mnt # ls -R >>>> jsli@rpi2:/mnt # mkdir dir >>>> jsli@rpi2:/mnt # ls -R >>>> dir/ >>>> ls: dir: directory causes a cycle >>>> jsli@rpi2:/mnt # >>>> >>>> >>>> looks inode no for directories are wrong >>>> >>>> jsli@rpi2:/mnt # ll -ia >>>> total 4 >>>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ >>>> 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ >>>> 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ >>>> jsli@rpi2:/mnt # ll -ia dir >>>> total 0 >>>> 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ >>>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ >>>> jsli@rpi2:/mnt # >>>> >>> >>> Ouch. >>> >>> Looks like 64-bit atomic on 32-bit arm don't work as advertised. >>> >>> While they should be fixed, I have been meaning to commit the following >>> which will have a side effect of taking care of the bug you ran into: >>> >> >> Mateusz, >> where you see problem with 64-bit atomic on arm? I'm not aware of any >> problem in this area. > > inode allocation for tmpfs (and other places) was recently changed to use > 64-bit atomics (excluding mips and powerpc). So far atomic_fetchadd_64 > failing to bump the number on 32-bit arm (at least for the variant used > by whatever is put on rpi2) looks like a decent explanation. The code > definitely works on amd64. > Ahh, right. atomic_fetchadd_64() is clearly broken. Give me a few minutes for fix and test. -- diff --git a/sys/arm/include/atomic-v6.h b/sys/arm/include/atomic-v6.h index 8f63554c701..40d2b94f4cf 100644 --- a/sys/arm/include/atomic-v6.h +++ b/sys/arm/include/atomic-v6.h @@ -435,7 +435,7 @@ atomic_fetchadd_64(volatile uint64_t *p, uint64_t val) __asm __volatile( "1: \n" - " ldrexd %Q[tmp], %R[tmp], [%[ptr]] \n" + " ldrexd %Q[ret], %R[ret], [%[ptr]] \n" " adds%Q[tmp], %Q[ret], %Q[val] \n" " adc %R[tmp], %R[ret], %R[val] \n" " strexd %[exf], %Q[tmp], %R[tmp], [%[ptr]] \n" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rm cannot recursively delete directory on tmpfs on RPi2
On 07.12.2018 7:25, Mateusz Guzik wrote: > On 12/7/18, Jia-Shiun Li wrote: >> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >> >>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li wrote: amd64 and RPi3 do not have this issue. jsli@rpi2:/home/jsli 13:04 # uname -a FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG >>> arm jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt jsli@rpi2:/home/jsli 13:05 # cd /mnt jsli@rpi2:/mnt 13:05 # tar xf /usr/ports/distfiles/sqlite-autoconf-326.tar.gz jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ rm: sqlite-autoconf-326/tea: Operation not permitted rm: sqlite-autoconf-326/: Directory not empty jsli@rpi2:/mnt 13:05 # -Jia-Shiun >>> >>> Did you check for file flags? Do "ls -lod sqlite-autoconf-326/tea". >>> >>> >> Unlikely caused by flags I think. >> >> jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt >> jsli@rpi2:/home/jsli # cd /mnt >> jsli@rpi2:/mnt # ls -R >> jsli@rpi2:/mnt # mkdir dir >> jsli@rpi2:/mnt # ls -R >> dir/ >> ls: dir: directory causes a cycle >> jsli@rpi2:/mnt # >> >> >> looks inode no for directories are wrong >> >> jsli@rpi2:/mnt # ll -ia >> total 4 >> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ >> 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ >> 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ >> jsli@rpi2:/mnt # ll -ia dir >> total 0 >> 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ >> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ >> jsli@rpi2:/mnt # >> > > Ouch. > > Looks like 64-bit atomic on 32-bit arm don't work as advertised. > > While they should be fixed, I have been meaning to commit the following > which will have a side effect of taking care of the bug you ran into: > Mateusz, where you see problem with 64-bit atomic on arm? I'm not aware of any problem in this area. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
buildkernel ULE related breakage
Hi, Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT ( wrapped long lines ) cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c cc1: warnings being treated as errors /usr/src/sys/kern/sched_ule.c: In function `sched_setup': /usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i' *** Error code 1 Stop in /usr/obj/usr/src/sys/TEST. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Michal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vt(4) sysctl inconsistency question
On Fri, 2015-02-06 at 14:23 +0200, Aleksandr Rybalko wrote: > On Wed, 04 Feb 2015 22:56:57 +0100 > Michal Varga wrote: >> [...] > > Interestingly, two cases in particular (excluding SPSC which isn't > > implemented yet) were left out of this configuration, namely the standby > > and suspend modes (STBY, SUSP), making use of those keys completely > > non-optional. > > > > If anyone could tell me, what was the reason for not including sysctls > > for those two modes? > > > > m. > > > Hi Michal! > > When I was work on vt(4) due to lack of knowledge about kbd(4) > internals I decide to not touch it a lot, so I mostly just copy sc(4) > things :) > > IIRC support of such keys/combinations will require some updates to > kbd(4). > > Think, if somebody will prepare patch for such things, guys and maybe > me, will be happy to review and possibly commit it. > > Thanks! Hello Aleksandr, I think you misunderstood what I meant. The code in question is already there, just that some particular cases are not configurable via sysctl: http://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?r1=271380&r2=271381&; At lines 500-528, all cases got their own sysctls so you can easily turn their behavior on/off: case SPCLKEY | : if (vt_) ... The other three cases (l. 530-540), one of them unfinished though, are missing sysctls, so vt will always execute those actions no matter what. Now that you mentioned copying sc(4) stuff, I cross-checked it with sc sources and you're right, even sc is missing configuration in cases like suspend and standby (which is kinda puzzling, to me). So now the question stands - can we have the rest of this behavior configurable, or is there any opposition to it? Which would mean adding another set of: VT_SYSCTL_INT(kbd_saver, 1, "Enable screen saver keyboard combination." VT_SYSCTL_INT(kbd_standby, 1, "Enable PM standby keyboard combination." VT_SYSCTL_INT(kbd_suspend, 1, "Enable PM suspend keyboard combination." and ading the corresponding 'if (vt_' to those cases that are missing them. If that's ok with you and you're interested, I could submit a patch via PR for review... m. -- Michal Varga, Stonehenge ___ 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"
vt(4) sysctl inconsistency question
I have a quick question regarding the vt driver which hopefully someone involved in its design could answer for me. Roughly 4 months ago, vt gained the ability to listen to a set of keyboard combinations controlling power/debug situations and the ability to control (or more precisely, turn off) their behavior via sysctls: http://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?r1=271380&r2=271381&; Interestingly, two cases in particular (excluding SPSC which isn't implemented yet) were left out of this configuration, namely the standby and suspend modes (STBY, SUSP), making use of those keys completely non-optional. If anyone could tell me, what was the reason for not including sysctls for those two modes? m. -- Michal Varga, Stonehenge ___ 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: no X after installing xorg + xfce
On Tue, 2011-09-20 at 12:02 -0500, Antonio Olivares wrote: > >Newb hacker tip number one: try CTRL-ALT-F1 when you get the > > technicolor screen. If your system isn't hosed then you'll get the > > first tty. > > I do know this, before it was CTRL + ALT + BACKSPACE and now it is > CTRL + ALT + F1 :) I am not exactly a ``newbie'' but I am not an > ``expert'' as I am still learning :) > Those two are very different kinds of beasts. CTRL+ALT+Fx is an xf86/xorg substitute for the regular ALT+Fx (console switching), so that ALT+Fx can be still used within X applications. On the other hand, CTRL+ALT+BACKSPACE is a "zap" command, that will let you instantly kill a currently running X server. Note that in more recent versions of xorg (incl. 7.5), CTRL+ALT+BACKSPACE is disabled by default. To get it working again, you will need to setup xorg.conf with at least: Section "ServerLayout" Identifier"Main Layout" [...] InputDevice "Main Keyboard" "CoreKeyboard" EndSection Section "ServerFlags" [...] Option"DontZap" "False" EndSection Section "InputDevice" Identifier"Main Keyboard" Driver"kbd" Option"XkbOptions""terminate:ctrl_alt_bksp" EndSection > Garrett & all, > > I have X working :) Used nvidia-driver, as specified in FreeBSD howto > (handbook page). changed 'nv' to 'nvidia', added nvidia_enable="YES" > to /etc/rc.conf and now X works. I am loading more software that is That's good to hear. Congratulations. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: no X after installing xorg + xfce
On Tue, 2011-09-20 at 07:01 -0500, Antonio Olivares wrote: > > I've skimmed the thread, (apologies if I've missed it), but I haven't > > yet seen your Xorg log or your config file. Almost every graphics card > > should work with VESA at a minimum. > > I have no Xorg.conf file as it is not needed anymore. I tried to rebuild it, > # Xorg -configure xorg.conf isn't "needed" in case you wish to rely purely on xorg's and HAL's autodetection (this is a perfectly bad idea), and if you do not need to change any single xorg option from defaults (this would be very strange in my book). There are tons of manuals on the Internet detailing how to write a proper xorg configuration file (it even has its own man page - man xorg.conf) and as with any properly configured software - it pays off. > process hangs and returns colors on the screen :( Autodetection blows. You will have to write your configuration manually. > I can't attach Xorg.0.log, I know which driver to use, as I have X > working correctly with Linux(Slackware) on that same machine[another > hard drive]. It is just that I have no way of saving logs or posting > information without taking a picture, I would to put all doubts away. Honestly, I really don't understand the "I can't attach Xorg.log" wording. It's a physical log file, just a regular file. How is it that you cannot copy it from the particular machine/hard drive/filesystem and put it someplace on the Internet, or paste the relevant parts inline in one of the emails? > As of know I will rebuild world, install new kernel remove all ports > and start from scratch. If I can't get it to work with a fresh start. There's really nothing wrong with your ports and you'll be only wasting your time with this generic and pointless "Windows-style reinstall everything" procedure, without actually looking at the issue itself. The other poster(s) already told you. If you need any help, you will have to provide error messages, you will have to provide error logs (and you will have to properly configure your xorg, because as you already noticed, autodetection clearly doesn't work the way you expect it to). > I will wait for BETA 3 or an RC :) I just want to help in testing, > it is that I can't supply the information as I would like to :( I can 100% guarantee that BETA3 nor RC won't change anything in regard to the issue you're experiencing. Your problem lies elsewhere and you didn't even start systematically investigating it. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: How does one install kernel sources and base
On Mon, 2011-09-19 at 19:22 -0500, Antonio Olivares wrote: > Michal, > > Thank you very much for your detailed instruction. I was able to get > all of the sources and built nvidia driver successfully :) > > However, when I run kldload nvidia, I get a mismatch with the running > kernel and an incompatible ?. I cannot post exact error as the > machine gives me no X :(, I checked to see if enabling hald and dbus > at /etc/rc.conf would make a difference and they have not :(, I have > also tried nouveau and it also does not work. No working X on FreeBSD > 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, > ... I will post in the thread I created on this issue. > > Regards, > > Antonio Some details about the "incompatible ?" error would be quite useful as without an actual (and exact) error message it's only guessing... But it is possible that your downloaded (latest -HEAD) sources are no longer compatible with your currently running OS, though there being like about a week difference, I find it somewhat unlikely (but always possible). If that's the case, you have two possible routes to take: You can either bring your system up to date corresponding to the latest sources; that is, rebuilding and installing new FreeBSD kernel and world. That should get rid of any incompatibilities you currently experience. It's a pretty straightforward process which in your case amounts to just about - # cd /usr/src # make buildworld installworld kernel - but note that the above mentioned IS NOT an officially supported procedure and you are first REQUIRED to read FreeBSD Handbook and understand the basics of building and updating FreeBSD. I just mention it to illustrate how simple the procedure generally is. But again, don't run it blindly. When unsure, always use the officially supported, while somewhat lenghtier, procedure described in FreeBSD Handbook. Now the other possible route that doesn't involve building and updating FreeBSD at all, is to download the sources that closely match your currently running system. As far as I know (and I wasn't able to find), there is no CVS tag for BETA2, so you can't pull the exact sources that way, but you should be able to get very close with: $ uname -a - and notice when the kernel was built, which was hopefully very close to the time when the sources were pulled from CVS (this is more or less only a guess, so someone involved in release engineering might be of more help with this issue, if there even is any). To do this, you just need to edit your supfile and include the specific date from when to pull the sources: That is, replacing the line: *default release=cvs tag=. With: *default release=cvs tag=. date=2011.09.??.??.??.?? (Just fill in the missing dd, hh, mm, ss values based on the date you already know from uname.) This modified supfile will let you pull sources that should be a very close - if not perfect - match to your current system. You can then rebuild your drivers (i.e. that non-working nvidia module) the regular way. By my humble estimate, that should be enough to fix your issue. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: How does one install kernel sources and base
On Sun, 2011-09-18 at 09:00 -0500, Antonio Olivares wrote: > Dear folks, > > I have installed 9.0 - BETA 2, and I had no x, when I typed startx, > some folks have suggested to check if I have xorg-server, I will do > that as soon as I get to my machine on Monday. Also I will check if I > put into /etc/rc.conf, hald_enable="YES" and dbus_enable="YES" as > well, otherwise startx will not work. xorg works very well (and actually much better) without HAL and as far as I know, doesn't even use dbus. Try checking xorg port's config in: # cd /usr/ports/x11-servers/xorg-server/ # make config You can then rebuild your xorg-server port if necessary. Note that for using xorg server without HAL, you will need to configure it properly (see manuals/howtos on xorg.conf, if you never done it before), what was the main 'issue' HAL was originally trying to solve. It failed miserably, which is the reason why newer xorg generations moved away from it and nowadays is only to be found as a sad reminder on FreeBSD. Generally, you will be better off without HAL as it only leads to more failures than running without it. > But my question is as follows, > How do I get kernel sources and base installed? You can download them via csup with a config file similar to this: *default host=cvsup5.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=. *default compress delete use-rel-suffix src-all Save your config file (or so called supfile) someplace and run it as: # csup your.supfile csup will download the latest source tree for kernel and base OS. Also, see FreeBSD Handbook for more information on using csup (or the older, but functionally identical cvsup), and for many other questions regarding general FreeBSD installation and maintenance: http://www.freebsd.org/doc/handbook/cvsup.html m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: Well, there goes Windows!
On Thu, 2011-08-18 at 16:24 -0700, Garrett Cooper wrote: > So, I used the bsdinstaller again on the 9.0-BETA1 media with manual > partitioning. The HP desktop ate up 3 partitions, I inconveniently > forgot that geom can't grok secondary PC MBR partitions, was fooling > around and cleared the partitions, etc. I hit abort to exit the > partitioner start and from scratch and now my Windows partitions and > recovery partitions are gone. > Well, there's "gone" and there's really "gone" (but obviously, this is not a pleasant situation in any case). Just as a quick reminder for anyone who might not know (as this happens regularly) - sysutils/testdisk should be able to recover those cleared partitions pretty easily and put them back in place. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: jumbograms (& em) & nfs a no go
On Sat, 1 Nov 2003, Terry Lambert wrote: > I think at this point, you are going to have to look at the > sources; IMO, it's a problem in some code that calls the > ether_output() function directly with too large a packet, and > since NFS doesn't manually implement TCP, that's not it. > > Hmmm. Is this maybe UDP? If so, the easiest fix is "don't > use UDP"; FreeBSD's UDP fragment reassembly code sucks anyway, > and gives an excellent means of implementing a DOS attack on > the target system's available mbufs. > > If it's UDP, and you insist on it working, you might want to > make sure that the packet goes through the UDP fragmentation > and NFS rsize/wsize limitation code. > I noticed in src/sys/dev/em/README that there are problems with jumbograms and UDP so I use TCP. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Flash card reader error
FreeBSD 5.1-CURRENT #0: Thu Oct 30 17:49:13 EST 2003 This problem persists since I tried to use flash reader (~1.5 month) I have SimpleTech flash card reader (FlashLink). Connecting to USB ports causes the following errors: umass0: USB Mass Storage, rev 1.10/1.13 addr3 umass0: Max Lun not supported (STALLED) umass0: BBBreset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOEROR umass0: BBB bulk-out clear stall failed, IOERROR . . . . . GEOM: create disk da2 dp = 0xc7241850 da2: (umass-sim0:0:0:0) got CAM status 0x4 da2: (umass-sim0:0:0:0) fatal error, failed to attach to device da2: (umass-sim0:0:0:0) lost device GEOM: destroy disk da2 dp = 0x7241850 GEOM: removing device entry Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Sticky mouse with SCHED_ULE 10-30-03
FreeBSD 5.1-CURRENT #0: Thu Oct 30 17:49:13 EST 2003 When kernel compiled with SCHED_ULE, USB mouse (MS USB Intellimouse) is almost unusable. Even if CPU is idle, mouse feels sticky. When loading mozilla or compiling comething mouse freezes for several seconds and is nonresponsive in general. Switched back to SCHED_4BSD and mouse is better than ever. No problems at all when loading programs or compiling. To me subjective feeling mouse respomds worse than month ago with SCHED_ULE and much better with SCHED_4BSD than before. Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Digital Camera not working after 10-30-03
FreeBSD 5.1-CURRENT #0: Thu Oct 30 17:49:13 EST 2003 Digital camera (Canon PowerShot S50) is not accessible after latest buildworld. I use gtkam to connect to the camera. /dev shows ugen devices as before. No error at CLI. Errors from gtkam: "An error uccured in tje io-library )"could not find the requested device on the USB port'): Could not find USB device (class 0x28a09032, subclass 0x80dfc00, protocol 0x28a14b60). Make sure that this device is connected to the computer." Previous build (10-14-03) worked well. I was able to access camera as user and as a root. Neither is working now. Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
On Thu, 30 Oct 2003, Barney Wolff wrote: > On Thu, Oct 30, 2003 at 08:04:58AM -0800, Sam Leffler wrote: > > > > I've ran many jumbogram tests of machines connected with a cross-over cable > > and em devices at each end. If you've got a swtch in the middle make sure it > > does the right thing. > > Just a minor note: GigE should not require a crossover cable. It's > supposed to work to connect two GigE adapters with a straight-thru > cable. I verified this with two Intel em NICs, quite a while ago. > As I recall, when I used a crossover cable, I could not get the > adapters to go to 1000, only 100. That might have been the cable, > or not. I can confirm it works equally well with crossover as with straight cable. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
On Thu, 30 Oct 2003, Doug Ambrisko wrote: > Michal Mertl writes: > | On Thu, 30 Oct 2003, Sam Leffler wrote: > | > | > On Thursday 30 October 2003 04:46 am, Michal Mertl wrote: > | > > I wanted to test gigabit network performance and found out that current > | > > (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU > | > > set to 6000), Intel adapters and nfs (both UDP and TCP). > | > > > | > > I checked that the same thing works with 4.9. > | > > > | > > I then left one computer at 4.9 and upgraded the other to 5.0. When I > | > > mount a partition from 5.0 machine I found out, that copying reliably > | > > works only from 5.0 to 4.9. The other way around I see messages 'em0: > | > > discard oversize frame (ether type 800 flags 3 len 67582 > max 6014)' on > | > > 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server > | > > 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can > | > > be revived by changing mtu back to 1500 and down/up sequence. > | > > | > I've ran many jumbogram tests of machines connected with a cross-over cable > | > and em devices at each end. If you've got a swtch in the middle make sure it > | > does the right thing. > | > | I also used exclusively crossover cable. The same configuration worked > | with 4.9. The problem appears only with NFS. > > You might want to try this patch: > > Index: if_em.c > === > RCS file: /cvs/src/sys/dev/em/if_em.c,v > retrieving revision 1.32 > diff -c -r1.32 if_em.c > *** if_em.c 15 Oct 2003 05:34:41 - 1.32 > --- if_em.c 30 Oct 2003 19:39:49 - > *** > *** 2454,2460 > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ > MCLBYTES,/* maxsize */ > !1, /* nsegments */ > MCLBYTES,/* maxsegsize */ > BUS_DMA_ALLOCNOW,/* flags */ > NULL,/* lockfunc */ > --- 2454,2460 > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ > MCLBYTES,/* maxsize */ > !2, /* nsegments */ > MCLBYTES,/* maxsegsize */ > BUS_DMA_ALLOCNOW,/* flags */ > NULL,/* lockfunc */ > > There was a few bugs in the system before in that there was insufficient > error check in the bus_dma stuff. The issue was that HW was writing more > then was the allocated due to (nsegments=1). This isn't the right fix but > might help point to the issue. > > I don't have access to the HW to test it out anymore. > > Doug A. I'm afraid it doesn't help. The problem doesn't occur with FTP. For the last tests I've got two -current machines from Oct 30th. One exports a filesystem (server) and the other mounts it R/W (client). Copying /usr/src from server to client stalls (with 'em0: discard oversized frame...' on the receiver) and from client to server stalls too. NFS doesn't work (cp is uninterruptible and other access to remote fs stalls too). Client shows after some time 'nfs server 10.0.0.1:/usr: not responding'. At the time NFS doesn't work I can ping the other machine, so the interface isn't completely stuck. Copying one large file works from server to client but not the other way around. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
On Thu, 30 Oct 2003, Sam Leffler wrote: > On Thursday 30 October 2003 04:46 am, Michal Mertl wrote: > > I wanted to test gigabit network performance and found out that current > > (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU > > set to 6000), Intel adapters and nfs (both UDP and TCP). > > > > I checked that the same thing works with 4.9. > > > > I then left one computer at 4.9 and upgraded the other to 5.0. When I > > mount a partition from 5.0 machine I found out, that copying reliably > > works only from 5.0 to 4.9. The other way around I see messages 'em0: > > discard oversize frame (ether type 800 flags 3 len 67582 > max 6014)' on > > 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server > > 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can > > be revived by changing mtu back to 1500 and down/up sequence. > > I've ran many jumbogram tests of machines connected with a cross-over cable > and em devices at each end. If you've got a swtch in the middle make sure it > does the right thing. I also used exclusively crossover cable. The same configuration worked with 4.9. The problem appears only with NFS. I can repeat the whole test once again to make sure I didn't overlooked anything. It will take some time because I had to put one of the servers into production. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
jumbograms (& em) & nfs a no go
I wanted to test gigabit network performance and found out that current (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU set to 6000), Intel adapters and nfs (both UDP and TCP). I checked that the same thing works with 4.9. I then left one computer at 4.9 and upgraded the other to 5.0. When I mount a partition from 5.0 machine I found out, that copying reliably works only from 5.0 to 4.9. The other way around I see messages 'em0: discard oversize frame (ether type 800 flags 3 len 67582 > max 6014)' on 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can be revived by changing mtu back to 1500 and down/up sequence. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
I found easy way to ugen problem: in /etc/devfs.rules I added [local_ruleset=10] add path 'ugen*' mode 664 then in /etc/rc.conf devfs_system_ruleset="local_ruleset" And this is it. Now user can acces camera (PowerShots50) with gtkam. The resolution was given by (http://lists.freebsd.org/pipermail/freebsd-current/2003-September/009706.html) Jeff Walters*. *Based on man devfs it is impossible to resolve this issue. * * ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: samba 3 on CURRENT and net.inet.tcp.blackhole
setting net.inet.tcp.log_in_vain=1 did not bring anything informative. What I found is that when setting net.inet.tcp.blackhole=1, then smbclient will work instantly. If next I set it to net.inet.tcp.blackhole=2 then it again works without delay. However if I set net.inet.tcp.blackhole=2 directly I will have to wait 90 secs for the connection. So as Don Levis suggested I should wait a little longer. Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: samba 3 on CURRENT and net.inet.tcp.blackhole
"net.inet.tcp.blackhole changes the behaviour of refused incoming TCP connections and it doesn't seem possible it's the cause this problem. I'd sugest increasing the log level in smb.conf." Thanks for suggestion about logging. I know what net.inet.tcp.blackhole seting is for (and I would like to continue to use it). And this is why I do not understand what is wrong. I have run smbd -D -d10 and checked log.smbd but I could not find anything informative. Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
samba 3 on CURRENT and net.inet.tcp.blackhole
Hello, I have a problem with samba 3.0. I had to reinstall FreeBSD-CURRENT after known problems with ATAng and atapicam (beginning of September(?)), since then I can't set net.inet.tcp.blackhole=2 in /etc/sysctl.conf. If I add the option to sysctl then samba will hung until I press ^C. If I boot without this option then samba starts fine. However running now sysctl net.inet.tcp.blackhole=2 prevent smbclient from running. I still will be able to connect to smb shere from another computer. It seems that this is local problem but it never occurred before FreeBSD re-instal with samba 3.0. I do not see any errors in log files. I also contacted mantainer of samba but he was unable to help. I dont think that it is the issue with samba because samba 3 (devel) worked with previous snaps. So there must be something particular with my configuration of FreeBSD I would appreciate any help Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bktr(4) bufs plus patch
On Wed, 3 Sep 2003, Jens Rehsack wrote:
> Michal Mertl wrote:
> > I found 2 bugs and some potential problems in bktr(4) code.
> >
> > Bug 1:
> > Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
> > that code tries to use iicbus which isn't defined where it looks for
> > it. I added it there and the compilation and detection goes fine. I don't
> > know how to actually test it though.
> >
>
> [...]
>
> Will anyone responsible take notice of this patch and commit it?
>
> >
> >
> > *** dev/bktr/bktr_reg.h.ori Sun Dec 8 10:40:14 2002
> > --- dev/bktr/bktr_reg.h Sun Dec 8 10:40:38 2002
> > ***
> > *** 448,453
> > --- 448,454
> > struct bktr_i2c_softc {
> > int bus_owned;
> >
> > + device_t iicbus;
> > device_t iicbb;
> > device_t smbus;
> > };
> > *** dev/bktr/bktr_os.c.ori Sun Dec 8 10:39:13 2002
> > --- dev/bktr/bktr_os.c Sun Dec 8 10:39:35 2002
> > ***
> > *** 499,513
> > destroy_dev(bktr->tunerdev);
> > destroy_dev(bktr->bktrdev);
> >
> > - /* If this is unit 0, then destroy the alias entries too */
> > - #if (__FreeBSD_version >=50)
> > - if (unit == 0) {
> > - destroy_dev(bktr->vbidev_alias);
> > - destroy_dev(bktr->tunerdev_alias);
> > - destroy_dev(bktr->bktrdev_alias);
> > - }
> > - #endif
> > -
> > /*
> > * Deallocate resources.
> > */
> > --- 499,504
The destroy_dev calls for aliases have been removed in -current on 9th Dec
2002 (one day after I sent the email). See PR kern/36413. The fix hasn't
been MFCed but there's no need - the code is wrapped in '#if
(__FreeBSD_version >= 50)'. The fix for BKTR_USE_FREEBSD_SMBUS hasn't
been commited.
I didn't send-pr but will recheck the status of things over the weekend
and perhaps will do.
To other readers: in my original email
(http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2276+0+archive/2002/freebsd-current/20021215.freebsd-current)
I talked about another problem (limits on the maximum number of devices).
When I reread what I wrote at the time I have to say 'sorry for my
English' :-).
--
Michal Mertl
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
buildkernel ULE related breakage
Hi, Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT ( wrapped long lines ) cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c cc1: warnings being treated as errors /usr/src/sys/kern/sched_ule.c: In function `sched_setup': /usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i' *** Error code 1 Stop in /usr/obj/usr/src/sys/TEST. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Michal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Twin CPU machine running with only one cpu?
On Mon, 9 Jun 2003, Brendon and Wendy wrote: > Dear All, > > Just installed 5.1 RC1 on my Dual Prestonia Xeon box. Works great. In fact > this is the first time i've had much success with the 5.x branch. > > Anyway, heres my question. Despite the fact that I've recompiled my kernel > with SMP and IOAPIC enabled, I seem to have only one CPU running. At boot > time the kernel reports starting CPU#1 at the end of boot time. The machdep.* > systctls claim that I have two cpus, but no matter what I do I cannot get the > CPU load over 48% (for instance running two c programs that loop infinitely > with no delay)! > Do you mean with the subject line that you have only one physical processor installed but you expect to see two in action because of HTT? If that's the case, your behaviour is normal because HTT is by default disabled. You should be able to see an idle kthread with 'top -S' eating 100% of CPU 1. You can toggle HTT on/off at any time with 'sysctl machdep.hlt_logical_cpus=0|1'. I think that when hlt_logical_cpus == 1 system shouldn't account for logical CPUs' idle time because it's confusing to see cpu load always <= 50%. -- Michal Mertl [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: potential for foot-shooting with KLD's
On Tue, 4 Mar 2003, Giorgos Keramidas wrote: > On 2003-03-02 17:34, Michal Mertl <[EMAIL PROTECTED]> wrote: > : Imagine you decided to go with modular kernel. You comment out 'device > : random' in your kernel-config and place 'random_load="YES"' in > : /boot/loader.conf. When you reboot and don't rebuild the kernel first, you > : have your machine unbootable - at least in case you previously had acpi in > : your kernel and acpi doesn't work without OS supplied dsdt (as in my > : case) or you need acpi as a module or any other module. > : > : The way out is to boot from install CDROM, have fixit floppy, mount the > : old root and remove the random.ko module. Which is pretty inconvenient, > : when you don't have the medias handy. > : > : The problem is that I can't ask loader not to load some module. It doesn't > : understand 'unset XX_load'. It doesn't work to say 'set XX_load="NO"' > : either. The only way I found to make it not load the modules is to 'load > : /boot/kernel/kernel;set module_path="";boot'. Unfortunately it doesn't > : help me either because I need to load special acpi_dsdt.aml which isn't > : then loaded either. > > On 2003-03-03 17:19:05, Giorgos Keramidas <[EMAIL PROTECTED]> wrote: > : > : How about `unset XX_load' ? > : > : - Giorgos > > On 2003-03-04 00:41, Michal Mertl <[EMAIL PROTECTED]> wrote: > : > How about `unset XX_load' ? > : > : It works only for acpi. > > I just tried editing my /boot/loader.conf to make sure you haven't hit > upon a bug. I added this line: > > ipfw_load="YES" > > and rebooted. The loader loaded both /boot/kernel/kernel and ipfw.ko > as you'd expect. I then used the `unload' command and loaded only my > kernel afterwards: > > OK unload > OK load /boot/kernel/kernel > OK boot -s > > Voila! Only my kernel and acpi.ko were loaded. Then, without editing > my /boot/loader.conf I rebooted and inteerrupted the loader after > ipfw.ko and the kernel were loaded. I disabled ACPI with: > > OK unset acpi_load > OK boot -s > > Only the kernel and ipfw.ko were loaded. Then, I tried yet another > way of disabling ipfw.ko at load time, and set ipfw_load to "NO" in > my loader.conf. Only the kernel and acpi.ko were loaded. > > What is it that troubles you? I'm not sure I can reproduce it. The problem is that you may need to load some module and disable loading of some other. The problem I hit was that I had 'device acpi' in the static kernel. When the ACPI is active on my notebook I need to supply fixed dsdt otherwise it won't find PCI or something and doesn't boot. It may have been possible to set hint.acpi.0.disable=1 and it will boot, but I didn't think of it. Using hints one may be able to escape from the problem. Other situation could be that you have SCSI adapter from which you boot as a module. Then you add say random_load="YES" to loader.conf. And try to boot the kernel with random compiled in. You either load both modules (and panic on boot with 'random mutex already initialized' or something) or unload them both (and don't find your root fs). -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: potential for foot-shooting with KLD's
> How about `unset XX_load' ? It works only for acpi. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
potential for foot-shooting with KLD's
Imagine you decided to go with modular kernel. You comment out 'device random' in your kernel-config and place 'random_load="YES"' in /boot/loader.conf. When you reboot and don't rebuild the kernel first, you have your machine unbootable - at least in case you previously had acpi in your kernel and acpi doesn't work without OS supplied dsdt (as in my case) or you need acpi as a module or any other module. The way out is to boot from install CDROM, have fixit floppy, mount the old root and remove the random.ko module. Which is pretty inconvenient, when you don't have the medias handy. The problem is that I can't ask loader not to load some module. It doesn't understand 'unset XX_load'. It doesn't work to say 'set XX_load="NO"' either. The only way I found to make it not load the modules is to 'load /boot/kernel/kernel;set module_path="";boot'. Unfortunately it doesn't help me either because I need to load special acpi_dsdt.aml which isn't then loaded either. The fix could be to be able to say 'unset XX_load' or make 'set XX_load="NO"' work. The other fix (probably more difficult to do) would be to make all modules loading/linking fail when they're statically compiled in. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bktr(4) bufs plus patch
I found 2 bugs and some potential problems in bktr(4) code.
Bug 1:
Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
that code tries to use iicbus which isn't defined where it looks for
it. I added it there and the compilation and detection goes fine. I don't
know how to actually test it though.
Bug 2:
On module unload destroy_dev(9) is called on dev_alias which leads to
panic. According to MAKE_DEV(9) it's forbidden. The patch removes the code
to remove aliases. All seems to work fine.
Problem 1:
When using bktr(4) in a module, there's a helper module
bktr_mem, which allocates memory for bktr(4) devices. There is fixed limit
(#define BKTR_MEM_MAX_DEVICES 8 in bktr_mem.h) on number of devices
supported - it should at least be mentioned somewhere and possibly raised
- I have 16 devices and soon will be using more.
Problem 2:
There's another limit on number of bktr(4) devices in device creation
on lines 443-448 in bktr_os.c.
bktr->bktrdev = make_dev(&bktr_cdevsw, unit,
0, 0, 0444, "bktr%d", unit);
bktr->tunerdev= make_dev(&bktr_cdevsw, unit+16,
0, 0, 0444, "tuner%d", unit);
bktr->vbidev = make_dev(&bktr_cdevsw, unit+32,
0, 0, 0444, "vbi%d" , unit);
If I read the code right it seems to limit the maximum number of devices
to 16. I don't see why it can't be much more here - say 256 (so change +16
to +256 and +32 to +512. In DEVFS world users should care about
majors/minors but with normal /dev it could be problem.
Problem 3: (affacting mainly STABLE)
In MAKEDEV there's only one char allowed so one can create only 10
devices. Patch could look like this:
*** MAKEDEV.ori Sun Dec 8 11:02:38 2002
--- MAKEDEV Sun Dec 8 11:07:01 2002
***
*** 1552,1559
chmod 444 meteor$unit
;;
! bktr?)
unit=`expr $i : 'bktr\(.*\)'`
mknod bktr$unit c 92 `unit2minor $unit`
mknod tuner$unit c 92 `unit2minor $((16 + $unit))`
mknod vbi$unit c 92 `unit2minor $((32 + $unit))`
--- 1552,1562
chmod 444 meteor$unit
;;
! bktr*)
unit=`expr $i : 'bktr\(.*\)'`
+ if [ ${unit} -lt 0 -o ${unit} -gt 15 ]; then
+ die 3 "bktr(4) unit limited to 0-15"
+ fi
mknod bktr$unit c 92 `unit2minor $unit`
mknod tuner$unit c 92 `unit2minor $((16 + $unit))`
mknod vbi$unit c 92 `unit2minor $((32 + $unit))`
--
Michal Mertl
[EMAIL PROTECTED]
*** dev/bktr/bktr_reg.h.ori Sun Dec 8 10:40:14 2002
--- dev/bktr/bktr_reg.h Sun Dec 8 10:40:38 2002
***
*** 448,453
--- 448,454
struct bktr_i2c_softc {
int bus_owned;
+ device_t iicbus;
device_t iicbb;
device_t smbus;
};
*** dev/bktr/bktr_os.c.ori Sun Dec 8 10:39:13 2002
--- dev/bktr/bktr_os.c Sun Dec 8 10:39:35 2002
***
*** 499,513
destroy_dev(bktr->tunerdev);
destroy_dev(bktr->bktrdev);
- /* If this is unit 0, then destroy the alias entries too */
- #if (__FreeBSD_version >=50)
- if (unit == 0) {
- destroy_dev(bktr->vbidev_alias);
- destroy_dev(bktr->tunerdev_alias);
- destroy_dev(bktr->bktrdev_alias);
- }
- #endif
-
/*
* Deallocate resources.
*/
--- 499,504
Re: ACPI + Compaq Armada m700
> Hello, Last night I cvsupped from 4.6-STABLE to 5.0-CURRENT. I do know > the risks of using -CURRENT. Unfortunately I am having a problem with > ACPI on boot. > > I have to issue the following to get the machine to boot > boot> unset acpi_load > boot> set boot_verbose=YES > boot> boot -v > > then the usual fsck and mount commands. I have read the acpi manpage > along with acpiconfig. Unfortunately this didn't shed much light on > fixing this problem on a permanent basis. I too have Armada m700 and am seeing the problem. The right solution is to have HP/Compaq fix the BIOS (which isn't likely) or to get someone who has a clue about ACPI look at our acpidump and find what's wrong there and fix the BIOS locally (ACPI configuration can be fetched from disk instead of from BIOS). The reason our computers don't boot is that under newer -current with ACPI it's either full HW configuration via ACPI and m700's ACPI does define our PCI bus (or something) wrong way (or there's a bug in ACPI code in -current). Meanwhile (forever I suppose) you could disable ACPI permanently by adding hint.acpi.0.disabled=1 to /boot/loader.conf[.local]. I also have hint.atkbd.0.flags="0x3" in there which helps with using my m700 with the docking station BTW. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system locks with vnode backed md(4)
Ok, I got another one. DDB output attached. I did all kinds of operations to trigger it - had 3 md mounted from the same dir, in 2 of them doing my ports.tgz torture test and in root file system I had 'find . -inum 1231231' running. One find finished succesfully but then it finally locked-up. > Yeah, vnode locks and other lockmgr locks don't show up in 'show locks', > since only SMPng locking primitives are tracked by WITNESS. I see. > There are a fair number of vnode locking deadlock scenarios that are > unavoidable where we rely on grabbing vnode locks out of the directory > structure lock order. This occurs for vnode-backed md devices, quotas, > and UFS1 extended attributes, and probably some other situations. I > suspect that Terry is correct that operations on the vnode backing file > storage directory are triggering the problem, since that increases the > chances that a vnode lock "race to root" will occur from both the file > system backed into the md device, and for the md backing vnodes during > blocking I/O. If you can avoid directory operations on the md backing > directory, that would probably be one way to avoid triggering the bug. I'm afraid this doesn't sound too good for me. > Seeing it reproduced would probably confirm that this is the case. On the > other hand, there may be other deadlocks in the vnode/ufs/md code that can > be more easily corrected than this general VFS problem, so details there > would be very useful. May be the attached one will allow someone to track something down. PS: Sorry if you have problems with attachment, I myself find them difficult to read (I'm receivind digest of this list - isn't there a possibility to have it in mime form (like Buqtraq and others)? -- Michal Mertl [EMAIL PROTECTED] db> show lockedvnods Locked vnodes 0xc3ef8b90: tag ufs, type VDIR, usecount 1, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1993 ino 6593, on dev ad0s1a (4, 4) 0xc3efea68: tag ufs, type VREG, usecount 2, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 599 ino 6596, on dev ad0s1a (4, 4) 0xc4ac7818: tag devfs, type VCHR, usecount 1297, writecount 0, refcount 30, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by pid 8 0xc574f250: tag ufs, type VREG, usecount 2, writecount 1, refcount 8, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1919 ino 7, on dev ad0s2e (4, 10) 0xc3f3c940: tag ufs, type VREG, usecount 2, writecount 1, refcount 225, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 439 ino 3, on dev ad0s2e (4, 10) 0xc559d940: tag ufs, type VREG, usecount 0, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1965 ino 4, on dev ad0s2e (4, 10) 0xc5c84cb8: tag ufs, type VREG, usecount 2, writecount 1, refcount 426, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 810 ino 5, on dev ad0s2e (4, 10) 0xc4a5a000: tag ufs, type VDIR, usecount 0, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1990 ino 96988, on dev md0 (4, 12) 0xc444f128: tag ufs, type VDIR, usecount 1, writecount 0, refcount 2, lock type ufs: EXCL (count 1) by pid 1964 ino 14330, on dev md0 (4, 12) 0xc4454818: tag ufs, type VNON, usecount 1, writecount 0, refcount 0, lock type ufs: EXCL (count 1) by pid 1964 ino 14336, on dev md0 (4, 12) 0xc5183de0: tag ufs, type VDIR, usecount 0, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1992 ino 5090, on dev md1 (4, 14) db> show locks exclusive sleep mutex Giant r = 0 (0xc0399660) locked @ ../../../kern/kern_intr.c:534 db> ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 1993 c4819938 e17970000 1737 1993 0004002 norm[SLPQ newbuf c03ede10][SLP] find 1992 c481b3b0 e179c0000 547 1992 0004002 norm[SLPQ getblk ce3eabb8][SLP] rm 1990 c4819b10 e17980000 1962 1990 0004002 norm[SLPQ getblk ce2d1ba4][SLP] cp 1965 c4819000 e174e0000 1964 1964 0006002 norm[SLPQ newbuf c03ede10][SLP] gzip 1964 c481b938 e179f0000 436 1964 0004002 norm[SLPQ biord ce2f743c][SLP] tar 1962 c4b57000 e17c30000 1958 1962 2004002 norm[SLPQ pause e17c3000][SLP] csh 1958 c4b571d8 e17c4000 1001 1779 1958 0004102 norm[SLPQwait c4b571d8][SLP] su 1919 c48193b0 e175e0000 0 0 204 norm[SLPQ newbuf c03ede10][SLP] md2 1779 c4819588 e175f000 1001 1778 1779 2004002 norm[SLPQ pause e175f000][SLP] tcsh 1778 c4b59000 e17cb000 1001 1775 360 100 norm[CVQ select c039cbe4][SLP] sshd 1775 c4b59588 e18040000 360 360 100 norm[SLPQ sbwait c3f00e64][SLP] sshd 1737 c4b591d8 e17cc0000 1736 1737 2004002 norm[SLPQ pause e17cc000][SLP] csh 1736 c4
Re: system locks with vnode backed md(4)
On Sat, 30 Nov 2002, Michal Mertl wrote: Including rwatson because of the thread on hackers@. Sorry for follow-up to myself. > Recently there was a discussion about jails on some freebsd list. Someone > recommended vnconfig(8)ed file-backed disk for jail file systems. Terry > wrote there are problems with it. I liked the idea and played with > mdconfig(8)ed devices on current. Terry was right - I can easily make the > system deadlock. I really like the idea of jails in vnode-backed I'm now unable to make it dead-lock again. Yet it happened quite easily. I had more md backing files in the same directory at the beginning (to test Terry's suspicion mentioned in thread 'jail' on hackers@). After the first lock-up I tried 'while(1);tar xzf ports.tgz; rm -rf ports;end' on normal filesystem, let it run for long time (> 1h) and then I found the system almost dead-locked too (the system worked, but anything accessing disk was painfully slow - it might be the same problem or it might be different. It never ended (at least for > ~30 mins when I didn't (weren't able) anything on it). syncer and bufdaemon and others were in wdrain. Disk as seen in systat -v showed maximal usage yet no inodes were resolved. Sometimes during that test I had lock order reversal: ../../../kern/kern_synch.c:152: sleeping with "mntvnode" locked from ../../../kern/vfs_subr.c:3016 lock order reversal 1st 0xc03a0aa0 mntvnode (mntvnode) @ ../../../kern/vfs_subr.c:3016 The 2nd isn't unfortunately saved in logs but it was Giant. I'll try to get more problems and get more info (show lockedvnods, show locks). show locks with first dead-lock showed only Giant AFAIR. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unkillable process - 'mdconfig -t vnode' on small file
Subject says it all.
I wanted to make vnode-backed md(4) and forgot to specify size, thas it
after 'touch mdfile;mdconfig -a -t vnode -f mdfile' mdconfig process can't
be killed. It's wchan ('ps axO wchan|grep mdconf') is mddest.
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
system locks with vnode backed md(4)
new [IWAIT] irq7: bktr1 bktr4++ 21 c120e760 d66430000 0 0 204 new [IWAIT] irq11: bktr0 bktr7* 20 c120e938 d66440000 0 0 204 new [IWAIT] irq13: 19 c120eb10 d66450000 0 0 204 new [IWAIT] swi5: acpitaskq 18 c120ece8 d66460000 0 0 204 new [IWAIT] swi3: cambio 17 c3cc d78180000 0 0 204 new [IWAIT] swi2: camnet 16 c3cc01d8 d78190000 0 0 204 new [IWAIT] swi5: task queue 15 c3cc03b0 d781a0000 0 0 204 norm[SLPQ sleep c03b5040][SLP] random 4 c1207000 d65cb0000 0 0 204 norm[SLPQ g_down c03934b0][SLP] g_down 3 c12071d8 d66380000 0 0 204 norm[SLPQg_up c03934ac][SLP] g_up 2 c12073b0 d66390000 0 0 204 norm[SLPQ g_events c03934a4][SLP] g_event 14 c1207588 d663a0000 0 0 204 new [IWAIT] swi4: vm 13 c1207760 d663b0000 0 0 20c norm[RUNQ] swi6: tty:sio clock 12 c1207938 d663c0000 0 0 204 norm[IWAIT] swi1: net 11 c1207b10 d663d0000 0 0 20c norm[Can run] idle 1 c1207ce8 d663e0000 0 1 0004200 norm[SLPQwait c1207ce8][SLP] init 10 c120e000 d663f0000 0 0 204 norm[CVQ ktrace c03c50c4][SLP] ktrace 0 c0394720 c04ff0000 0 0 0000200 norm[SLPQ sched c0394720][SLP] swapper -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
WITNESS complaints
I keep getting lots of /usr/src/sys/kern/kern_sysctl.c:1002: could sleep with "drm memory" locked from @/dev/drm/drm_memory.h:217 and /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0" locked from /usr/src/sys/dev/sound/pcm/sound.c:134 /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:fake" locked from /usr/src/sys/dev/sound/pcm/channel.c:677 /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:play:0" locked from /usr/src/sys/dev/sound/pcm/channel.c:677 /usr/src/sys/vm/uma_core.c:1330: could sleep with "pcm0:record:0" locked from /usr/src/sys/dev/sound/pcm/channel.c:677 for long time. I don't know, how serious these are and how much work is required to fix it. Otherwise it's proabably just a slight nuisance hidden for most users (once GENERIC is without WITNESS). I use both as modules but I'm pretty sure I had the same problem with both compiled into the kernel. In case it matters sound device is detected as: pcm0: port 0xe400-0xe403,0xe000-0xe003,0xdc00-0xdcff irq 12 at device 7.5 on pci0 pcm0: ac97 codec id 0x49434511 (ICEnsemble ICE1232) pcm0: ac97 codec features headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, Reserved 27 pcm0: ac97 primary codec extended features variable rate PCM, AMAP and video is drm0: <3dfx Voodoo3 3000> port 0xc000-0xc0ff mem 0xd800-0xd9ff,0xd400-0xd5ff irq 10 at device 0.0 on pci1 info: [drm] Initialized tdfx 1.0.0 20010216 on minor 0 The complaints about "drm memory" are shown in groups of about 25 same messages on each invocation of 'sysctl hw.dri' (or -a) but otherwise they seem to be quiet. The complaints about pcm happen only on boot (about 30). I'm ready to send more detail if required but I suppose it's going to be general problem - I've seen it mentioned (at least the pcm one) several times. Thanks. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: crash with network load (in tcp syncache ?)
On Fri, 1 Nov 2002, Terry Lambert wrote: > Bill Fenner wrote: > > >I think this can still crash (just like my patch); the problem is in > > >what happens when it fails to allocate memory. Unless you set one of > > >the flags, it's still going to panic in the same place, I think, when > > >you run out of memory. > > > > No. The flags are only checked when so_head is not NULL. sonewconn() > > was handing sofree() an inconsistent struct so (so_head was set without > > being on either queue), i.e. sonewconn() was creating an invalid data > > structure. > > You're right... I missed that; I was thinking too hard on the other > situations (e.g. soabort()) that could trigger that code, and no > enough on the code itself. > > > The call in sonewconn() used to be to sodealloc(), which didn't care > > about whether or not the data structure was self-consistent. The code > > was refactored to do reference counting, but the fact that the socket > > was inconsistent at that point wasn't noticed until now. > > Yeah; I looked at doing a ref() of the thing as a partial fix, > but the unref() did the sotryfree() anyway. > > > > The problem is not at all based on what happens in the allocation or > > protocol attach failure cases. The SYN cache is not involved, this is > > a bug in sonewconn(), plain and simple. > > I still think there is a potential failure case, but the amount of > code you'd have to read through to follow it is immense. It has to > do with the conection completing at NETISR, instead of in a process > context, in the allocation failure case. I ran into the same issue > when trying to run connections to completion up to the accept() at > interrupt, in the LRP case. The SYN cache case is very similar, in > the case of a cookie that hits when there are no resources remaining. > He might be able to trigger it with his setup, by setting the cache > size way, way don, and thus relying on cookies, and then flooding it > with conection requests until he runs it out of resources. Do I read you correctly that Bill's patch is probably better than yours (I tested both, both fix the problem)? If you still believe there's a problem (bug) I may trigger with some setting please tell me. I don't know how to make syncookies kick in - I set net.inet.tcp.cachelimit to 100 but it doesn't seem to make a difference but I don't know what am I doing :-). I imagine syncache doesn't grow much when I'm connecting from signle IP and connections are quickly eastablished. I'll be able to do some tests on monday - this is a computer at work. FWIW netstat -m during the benchmark run shows (I read it that it doesn't have problem - even just before the crash): mbuf usage: GEN list: 0/0 (in use/in pool) CPU #0 list:71/160 (in use/in pool) CPU #1 list:79/160 (in use/in pool) Total: 150/320 (in use/in pool) Maximum number allowed on each CPU list: 512 Maximum possible: 34560 Allocated mbuf types: 80 mbufs allocated to data 70 mbufs allocated to packet headers 0% of mbuf map consumed mbuf cluster usage: GEN list: 0/0 (in use/in pool) CPU #0 list:38/114 (in use/in pool) CPU #1 list:41/104 (in use/in pool) Total: 79/218 (in use/in pool) Maximum number allowed on each CPU list: 128 Maximum possible: 17280 1% of cluster map consumed 516 KBytes of wired memory reserved (37% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: crash with network load (in tcp syncache ?)
On Fri, 1 Nov 2002, Bill Fenner wrote:
> sonewconn() hands sofree() a self-inconsistent socket -- so->so_head is
> set, so so must be on a queue, but sonewconn() hasn't put it on a queue yet.
> Please try this patch.
>
> Bill
>
> Index: uipc_socket2.c
> ===
> RCS file: /home/ncvs/src/sys/kern/uipc_socket2.c,v
> retrieving revision 1.104
> diff -u -r1.104 uipc_socket2.c
> --- uipc_socket2.c18 Sep 2002 19:44:11 - 1.104
> +++ uipc_socket2.c1 Nov 2002 22:40:52 -
> @@ -192,7 +192,7 @@
> return ((struct socket *)0);
> if ((head->so_options & SO_ACCEPTFILTER) != 0)
> connstatus = 0;
> - so->so_head = head;
> + so->so_head = NULL;
> so->so_type = head->so_type;
> so->so_options = head->so_options &~ SO_ACCEPTCONN;
> so->so_linger = head->so_linger;
> @@ -209,6 +209,7 @@
> return ((struct socket *)0);
> }
>
> + so->so_head = head;
> if (connstatus) {
> TAILQ_INSERT_TAIL(&head->so_comp, so, so_list);
> so->so_state |= SS_COMP;
>
This patch fixes the panics for me. Thanks a lot. I believe it should be
commited.
BTW: I get about 850 fetches pers second on UP an 600 SMP (the same
machine and settings). Don't know if it's expected in this usage pattern.
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
crash with network load (in tcp syncache ?)
a
--- trap 0x1, eip = 0, esp = 0xd6a62d7c, ebp = 0 ---
gdb trace
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc01bd1ca in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:364
#2 0xc01bd487 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc013e5e2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc013e562 in db_command (last_cmdp=0xc0310460, cmd_table=0x0,
aux_cmd_tablep=0xc030996c, aux_cmd_tablep_end=0xc0309970)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc013e676 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc014132a in db_trap (type=3, code=0) at
/usr/src/sys/ddb/db_trap.c:72
#7 0xc02b02e0 in kdb_trap (type=3, code=0, regs=0xd6a629b0)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc02c939a in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = -980418544, tf_edi = -1050436352,
tf_esi = 256, tf_ebp = -693753348, tf_isp = -693753380, tf_ebx = 0, tf_edx
= 0, tf_ecx = 1021, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip =
-1070922283, tf_cs = 8, tf_eflags = 646, tf_esp = -1070583802, tf_ss =
-1070657532})
at /usr/src/sys/i386/i386/trap.c:605
#9 0xc02b1b18 in calltrap () at {standard input}:99
#10 0xc01bd46f in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc01f7e1e in sofree (so=0xc58f05d0) at
/usr/src/sys/kern/uipc_socket.c:312
#12 0xc01fa508 in sonewconn (head=0xc43874d8, connstatus=2)
at /usr/src/sys/kern/uipc_socket2.c:208
#13 0xc023f42f in syncache_socket (sc=0x2, lso=0xc43874d8, m=0xc1662200)
at /usr/src/sys/netinet/tcp_syncache.c:564
#14 0xc023f748 in syncache_expand (inc=0xd6a62b3c, th=0xc1f6c834,
sop=0xd6a62b10, m=0xc1662200) at
/usr/src/sys/netinet/tcp_syncache.c:783
#15 0xc0239978 in tcp_input (m=0xc1f6c834, off0=20)
at /usr/src/sys/netinet/tcp_input.c:713
#16 0xc0235143 in ip_input (m=0xc1662200)
at /usr/src/sys/netinet/ip_input.c:916
#17 0xc0235234 in ipintr () at /usr/src/sys/netinet/ip_input.c:934
#18 0xc02295f3 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:97
#19 0xc01a8dc4 in ithread_loop (arg=0xc162b400)
at /usr/src/sys/kern/kern_intr.c:535
#20 0xc01a7c54 in fork_exit (callout=0xc01a8bf0 , arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:860
Please keep me on cc: list, I'm getting digests so I would be slow in
reponsding.
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: bug in sysv semaphores on -CURRENT
On Fri, 6 Sep 2002, Alfred Perlstein wrote:
Alfred (thanks) found a bug in my code. Sorry for the fuss folks :-(.
> * Michal Mertl <[EMAIL PROTECTED]> [020906 06:10] wrote:
> > There seems to be bug in $SUBJ. When I run attached program on recent
> > -CURRENT, it always (after several seconds) triggers the bug. I first
> > suspected a problem in the program's logic but on stable in runs just
> > fine.
> >
> > Esentially I use piece of shm memory to pass some data between several
> > processes. I implemented simple locking functions with semaphores and
> > noticed it behaves strange on -CURRENT and ok on -STABLE.
> >
> > CCing Alfred because he made some changes into the kernel part of $SUBJ. I
> > don't expect the bug is new though.
> >
> > May I ask someone with older -CURRENT to try running the program for a
> > minute?
>
> I found your bug.
>
> In the function ipc_unlock() you do this:
>
> > int
> > ipc_unlock(void)
> > {
> > struct sembufsem_buf;
> > int err;
> >
> > if (ipc_cfg->sem_owner != getpid()) {
> > fprintf(stderr, "%d: can't unlock (bug), owner: %d\n",
> > getpid(), ipc_cfg->sem_owner);
> > return (-1);
> > }
> > if (semctl(ipc_cfg->sem_id, 0, GETVAL) != 0) {
> > fprintf(stderr, "%d: can't unlock (bug), not locked\n",
> > getpid());
> > return (-1);
> > }
> > printf("%d: ipc_unlock()\n", getpid());
> > sem_buf.sem_num = 0;
> > sem_buf.sem_op = 1;
> > sem_buf.sem_flg = 0;
> > err = semop(ipc_cfg->sem_id, &sem_buf, 1);
> > if (err == -1) {
> > fprintf(stderr, "%d: semop()\n", getpid());
> > return (-1);
> > }
> > ipc_cfg->sem_owner = -1;
> > return (0);
> > }
>
> Problem is that you're messing with lock state after dropping your
> semaphore!
>
> If you move the
> ipc_cfg->sem_owner = -1;
> to before the semop() call it seems to fix things.
>
> -Alfred
>
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
bug in sysv semaphores on -CURRENT
There seems to be bug in $SUBJ. When I run attached program on recent
-CURRENT, it always (after several seconds) triggers the bug. I first
suspected a problem in the program's logic but on stable in runs just
fine.
Esentially I use piece of shm memory to pass some data between several
processes. I implemented simple locking functions with semaphores and
noticed it behaves strange on -CURRENT and ok on -STABLE.
CCing Alfred because he made some changes into the kernel part of $SUBJ. I
don't expect the bug is new though.
May I ask someone with older -CURRENT to try running the program for a
minute?
--
Michal Mertl
[EMAIL PROTECTED]
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define MY_SHM_MAGIC 0x56d9f13b
typedef struct {
struct shmid_ds shm_ds;
struct semid_ds sem_ds;
pid_tsem_owner;
int sem_id;
int shm_id;
int size;
} s_ipc_cfg;
s_ipc_cfg *ipc_cfg = NULL;
int
ipc_setup(int size)
{
int skey;
int ipc_tok;
void *shm_addr;
struct shmid_ds shm_ds;
union semun sem_arg;
ipc_tok = IPC_PRIVATE;
if ((skey = shmget(ipc_tok, size, SHM_R | SHM_W
| IPC_CREAT)) == -1) {
fprintf(stderr, "shmget()\n");
return (-1);
}
if ((shmctl(skey, IPC_STAT, &shm_ds)) == -1) {
fprintf(stderr, "shmctl()\n");
return (-1);
}
if ((shm_addr = shmat(skey, NULL, 0)) == (void *)-1) {
fprintf(stderr, "shmat()\n");
return (-1);
}
ipc_cfg = shm_addr;
ipc_cfg->size = size - sizeof(s_ipc_cfg);
memcpy(ipc_cfg, &shm_ds, sizeof(shm_ds));
ipc_cfg->shm_id = skey;
if (shmctl(ipc_cfg->shm_id, IPC_RMID, NULL) == -1) {
fprintf(stderr, "shmctl() IPC_RMID\n");
return (-1);
}
if ((skey = semget(ipc_tok, 1, SEM_R | SEM_A | IPC_CREAT)) == -1) {
fprintf(stderr, "semget()\n");
return (-1);
}
ipc_cfg->sem_id = skey;
sem_arg.buf = (void *)&ipc_cfg->sem_ds;
if (semctl(ipc_cfg->sem_id, 0, IPC_STAT, sem_arg) == -1) {
fprintf(stderr, "semctl()\n");
return (-1);
}
ipc_cfg->sem_owner = -1;
sem_arg.val = 1;
semctl(ipc_cfg->sem_id, 0, SETVAL, sem_arg);
return (0);
}
void
ipc_shutdown(void)
{
if (ipc_cfg)
semctl(ipc_cfg->sem_id, 0, IPC_RMID);
}
int
ipc_lock(int wait, int undo)
{
struct sembuf sem_buf;
int err;
sem_buf.sem_num = 0;
sem_buf.sem_op = -1;
sem_buf.sem_flg = wait ? 0 : IPC_NOWAIT;
sem_buf.sem_flg |= undo ? SEM_UNDO : 0;
err = semop(ipc_cfg->sem_id, &sem_buf, 1);
if (err == -1) {
if (wait && errno == EAGAIN)
return (-2);
fprintf(stderr, "%d: semop()\n", getpid());
return (-1);
}
printf("%d: ipc_lock()\n", getpid());
ipc_cfg->sem_owner = getpid();
return (0);
}
int
ipc_unlock(void)
{
struct sembufsem_buf;
int err;
if (ipc_cfg->sem_owner != getpid()) {
fprintf(stderr, "%d: can't unlock (bug), owner: %d\n",
getpid(), ipc_cfg->sem_owner);
return (-1);
}
if (semctl(ipc_cfg->sem_id, 0, GETVAL) != 0) {
fprintf(stderr, "%d: can't unlock (bug), not locked\n",
getpid());
return (-1);
}
printf("%d: ipc_unlock()\n", getpid());
sem_buf.sem_num = 0;
sem_buf.sem_op = 1;
sem_buf.sem_flg = 0;
err = semop(ipc_cfg->sem_id, &sem_buf, 1);
if (err == -1) {
fprintf(stderr, "%d: semop()\n", getpid());
return (-1);
}
ipc_cfg->sem_owner = -1;
return (0);
}
int
ipc_locked(void)
{
return (semctl(ipc_cfg->sem_id, 0, GETVAL) ? 0 : 1);
}
int
ipc_owned(void)
{
return (ipc_locked() &&
ipc_cfg->sem_owner == getpid() ? 1 : 0);
}
int
ipc_useit(void)
{
if (!ipc_owned()) {
if (ipc_lock(1, 0) < 0) {
printf("%d: _ipc_getpart() can't lock\n",
getpid());
return (-1);
Re: VLock and 5.0 DP1
> When i try to compile Vlock from ports, i get: > > cc -O -pipe -DUSE_PAM -c vlock.c > cc -O -pipe -DUSE_PAM -c signals.c > cc -O -pipe -DUSE_PAM -c help.c > cc -O -pipe -DUSE_PAM -c terminal.c > cc -O -pipe -DUSE_PAM -c input.c > input.c:64: security/pam_misc.h: No such file or directory > input.c:67: `misc_conv' undeclared here (not in a function) > input.c:67: initializer element is not constant > input.c:67: (near initialization for `PAM_conversation.conv') vlock's PAM handling is written for LinuxPAM. There's some icompatibility issue with OpenPAM which I didn't look much into but it helps to remove USE_PAM. You don't have to tell the vlock you're using shadow passwords because FreeBSD's getpwent(3) returns password to the program run by root automatically. To run the program as root you must make sure it's owned by root and has suid bit set (or always run it as root). This easily may be security hole if there's bug in the program. HTH -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panics with CardBus
kern/kern_fork.c:799
(kgdb) up 12
#12 0xc016603c in pci_print_verbose (dinfo=0xc18c2900) at
/usr/src/sys/dev/pci/pcivar.h:211
211 return PCI_READ_CONFIG(device_get_parent(dev), dev, reg,
width);
(kgdb) print *dinfo
$2 = {pci_links = {stqe_next = 0x0}, resources = {slh_first = 0x0}, cfg =
{dev = 0x0, subvendor = 4445, subdevice = 4481,
vendor = 4445, device = 3, cmdreg = 0, statreg = 528, baseclass = 2
'\002', subclass = 0 '\000', progif = 0 '\000',
revid = 3 '\003', hdrtype = 0 '\000', cachelnsz = 8 '\b', intpin = 1
'\001', intline = 128 '\200', mingnt = 20 '\024',
maxlat = 40 '(', lattimer = 168 '¨', mfdev = 1 '\001', nummaps = 6
'\006', bus = 2 '\002', slot = 0 '\000',
func = 0 '\000', pp_cap = 65041, pp_status = 224 'ŕ', pp_pmcsr = 226
'â', pp_data = 0 '\000'}, conf = {pc_sel = {
pc_bus = 2 '\002', pc_dev = 0 '\000', pc_func = 0 '\000'}, pc_hdr =
0 '\000', pc_subvendor = 4445,
pc_subdevice = 4481, pc_vendor = 4445, pc_device = 3, pc_class = 2
'\002', pc_subclass = 0 '\000',
pc_progif = 0 '\000', pc_revid = 3 '\003', pd_name = '\000' , pd_unit = 0}}
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
latest pccard/cardbus megacommit broke on-boot detection
I have Xircom CBEM-56G (on card printed RBEM-56G-100) which used to be detected on boot without problem on -CURRENT. After todays cvsup and buildworld the card is no longer detected. It works when I unplug it and put it back. Is it expected behaviour? It seems to me it can be and the commit is work in progress to make it behave more like OLDCARD ? -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ntfs and sendfile problem (corrupted data)
On Mon, 31 Dec 2001, Michal Mertl wrote: Sorry to bloat the list but I forgot to mention that the panics occur when I actually try to read from ntfs partition (after appliing pach from previous email). cd works ok but ls panics the kernel. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ntfs and sendfile problem (corrupted data)
On Sun, 30 Dec 2001, Terry Lambert wrote:
> Michal Mertl wrote:
> >
> > I wrote about the issue once before but now I know more about the
> > problem.
> >
> > I have ntfs partition mounted ro on current. I can read from it without
> > problems. But I noticed I get corrupted data (the corrupted file has
> > right size but contains mostly zeros) when using ftpd to read them.
> >
> > I'm pretty sure the problem is thus in sendfile(2) and/or ntfs fs support.
>
> The getpages() doesn't work like you think in NTFS.
>
Thanks for the info, but I wasn't thinking much about how it works. I just
found there's something wrong. Matt suggested a fix to smbfs which I
tweaked a bit to fit into ntfs_vnops.c source but it panics.
my patch (-current&ntfs modified Matt's smbfs_vnops.c patch):
--- ntfs_vnops.c.oriMon Dec 31 11:16:04 2001
+++ ntfs_vnops.cMon Dec 31 11:04:02 2001
@@ -85,6 +85,8 @@
static int ntfs_fsync __P((struct vop_fsync_args *ap));
static int ntfs_pathconf __P((void *));
+static int ntfs_createvobject __P((struct vop_createvobject_args *ap));
+
intntfs_prtactive = 1; /* 1 => print out reclaim of active vnodes */
static int
@@ -741,6 +743,7 @@
{ &vop_access_desc, (vop_t *)ntfs_access },
{ &vop_close_desc, (vop_t *)ntfs_close },
+ { &vop_createvobject_desc, (vop_t *)ntfs_createvobject },
{ &vop_open_desc, (vop_t *)ntfs_open },
{ &vop_readdir_desc, (vop_t *)ntfs_readdir },
{ &vop_fsync_desc, (vop_t *)ntfs_fsync },
@@ -751,6 +754,17 @@
{ NULL, NULL }
};
+
+static int
+ntfs_createvobject(ap)
+ struct vop_createvobject_args /* {
+ struct vnode *vp;
+ struct ucred *cred;
+ struct thread *td;
+ } */ *ap;
+{
+ return(0);
+}
static
struct vnodeopv_desc ntfs_vnodeop_opv_desc =
-
This is backtrace :
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492
#1 0xc01c0800 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:335
#2 0xc01c0c4f in panic (fmt=0xc02a9f2a "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:634
#3 0xc0135af5 in db_panic (addr=-1071094807, have_addr=0, count=-1,
modif=0xcace1a6c "") at /usr/src/sys/ddb/db_command.c:452
#4 0xc0135a95 in db_command (last_cmdp=0xc02f1b18, cmd_table=0xc02f1938,
aux_cmd_tablep=0xc02e9b58, aux_cmd_tablep_end=0xc02e9b5c)
at /usr/src/sys/ddb/db_command.c:348
#5 0xc0135b5f in db_command_loop () at /usr/src/sys/ddb/db_command.c:474
#6 0xc0137f83 in db_trap (type=3, code=0) at
/usr/src/sys/ddb/db_trap.c:72
#7 0xc0286178 in kdb_trap (type=3, code=0, regs=0xcace1b6c)
at /usr/src/sys/i386/i386/db_interface.c:167
#8 0xc0292568 in trap (frame={tf_fs = 24, tf_es = -1070399472, tf_ds =
16,
tf_edi = -89802, tf_esi = 256, tf_ebp = -892462152,
tf_isp = -892462184, tf_ebx = 514, tf_edx = -1070719377, tf_ecx =
32,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071094807, tf_cs
= 8,
tf_eflags = 70, tf_esp = -1070719393, tf_ss = -1070857413})
at /usr/src/sys/i386/i386/trap.c:585
#9 0xc02863e9 in Debugger (msg=0xc02c033b "panic") at
machine/cpufunc.h:66
#10 0xc01c0c38 in panic (
fmt=0xc02c8820 "open: vmio vnode has no backing object after vn_open")
at /usr/src/sys/kern/kern_shutdown.c:621
#11 0xc01fe31c in open (td=0xca793c04, uap=0xcace1d20)
at /usr/src/sys/kern/vfs_syscalls.c:1203
#12 0xc0292e94 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134960050, tf_esi = 135049216, tf_ebp = -1077938904,
tf_isp = -892461708, tf_ebx = 135057664, tf_edx = 135049216,
tf_ecx = 135057664, tf_eax = 5, tf_trapno = 12, tf_err = 2,
tf_eip = 134574035, tf_cs = 31, tf_eflags = 647, tf_esp =
-1077938964,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1150
#13 0xc02870ed in syscall_with_err_pushed ()
--
I think this wasn't the right patch, after all.
> -- Terry
>
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ntfs and sendfile problem (corrupted data)
On Sun, 30 Dec 2001, Sheldon Hearn wrote: > > > On Sun, 30 Dec 2001 01:53:08 +0100, Michal Mertl wrote: > > > I have ntfs partition mounted ro on current. I can read from it without > > problems. But I noticed I get corrupted data (the corrupted file has > > right size but contains mostly zeros) when using ftpd to read them. > > > > I'm pretty sure the problem is thus in sendfile(2) and/or ntfs fs support. > > See also PR bin/31692, which reports simmilar problems using ftpd and > smbfs. See my request for feedback, which ought to help verify that > it's sendfile(2) causing the problem. > I did use the "goto oldway;" and the problem went away. I tried to look at /sys/kern/uipc_syscalls.c sendfile implementation but it is too complex for me :-(. I tried ktrace on ftpd but only saw the call to sendfile(2). If you give me some guidance I can try to look into problem deeper. I don't have any experience in kernel debugging but would like to learn it. > Ciao, > Sheldon. > -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ntfs and sendfile problem (corrupted data)
I wrote about the issue once before but now I know more about the problem. I have ntfs partition mounted ro on current. I can read from it without problems. But I noticed I get corrupted data (the corrupted file has right size but contains mostly zeros) when using ftpd to read them. I'm pretty sure the problem is thus in sendfile(2) and/or ntfs fs support. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
weird NTFS and FTPD performance
I reinstalled my laptop with quite current current (20011126-JPSNAP) because I need to access NTFS partition and have 32bit PCCARD NIC (NTFS was just unbroken on current AFAIK). When I connect with ftp to 4.3-RELEASE using 100Mbps-FDX I can upload from NTFS partition with about 6MB/s (limited by disk - in systat I see lots of 4KB requests, disk usage about 90%). When connecting from 4.3 to FTPD running on current I get 7MB downloading from UFS slice and 1MB for NTFS partition! Systat show lots of 244KB requests (totalling in 22MB/s - nonsense on this disk). I expect the problem is in NTFS but there must be something important in a way ftpd reads files to serve. I can give you all the info you would need. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
