Re: libkvm: consumers of kvm_getprocs for non-live kernels?
on 12/11/2010 01:08 Stanislav Sedov said the following: > On Thu, 11 Nov 2010 15:55:45 +0100 > Ulrich Spörlein mentioned: >> >>> Stas has ongoing work on a libprocstat, you might want to give him a ping. >>> I'm not sure if he plans to refactor some of those existing tools to use >>> that >>> library or not, but crashdump support is a key goal of it. >> >> Thanks for the hint, stas CC'ed and reply-to set. >> > > Yes, the idea was to refactor all base tools > to use libprocstat as well. So far only > procstat(8), fuser and fstat have been converted to use new functionality, so > they are able to operate both on coredumps and on the live system. > We still need to commit the libprocstat itself, > though. > Just to let you know that I am eagerly awaiting for that to happen. Perhaps even could help with something if you'd need that. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: libkvm: consumers of kvm_getprocs for non-live kernels?
on 12/11/2010 15:58 Stanislav Sedov said the following: > On Fri, 12 Nov 2010 14:14:47 +0200 > Andriy Gapon mentioned: > >> Just to let you know that I am eagerly awaiting for that to happen. >> Perhaps even could help with something if you'd need that. >> > > Review can certainly help.:-) > > Can I send you the patch? Definitely! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
new cpuid bits
Guys, I would like to add definitions for couple more useful CPUID bits, but I am greatly confused about how to name them. I failed to deduce the naming convention from the existing definitions and I am not sure how to make the names proper and descriptive. The bits in question are returned by CPUID.6 in EAX and ECX. CPUID.6 block is described by both AMD and Intel as "Thermal and Power Management (Leaf)". Bits in EAX are defined only for Intel at present, the bit in ECX is defined for both. Description/naming of the bits from the specifications: EAX[0]: Digital temperature sensor is supported if set EAX[1]: Intel Turbo Boost Technology Available EAX[2]: ARAT. APIC-Timer-always-running feature is supported if set. ECX[0]: Intel: Hardware Coordination Feedback Capability (Presence of Bits MCNT and ACNT MSRs). AMD: EffFreq: effective frequency interface. How does the following look to you? I will appreciate suggestions/comments. Thanks! Index: sys/amd64/include/specialreg.h === --- sys/amd64/include/specialreg.h (revision 215524) +++ sys/amd64/include/specialreg.h (working copy) @@ -136,6 +136,15 @@ #defineCPUID2_AESNI0x0200 /* + * Important bits in the Thermal and Power Management flags + * CPUID.6 EAX and ECX. + */ +#defineCPUTPM1_SENSOR 0x0001 +#defineCPUTPM1_TURBO 0x0002 +#defineCPUTPM1_ARAT0x0004 +#defineCPUTPM2_EFFREQ 0x0001 + +/* * Important bits in the AMD extended cpuid flags */ #defineAMDID_SYSCALL 0x0800 -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
statclock(n)
Alexander, I wonder if instead of calling statclock() multiple times (after an idle period) we couldn't call it just with an appropriate N parameter. So some stats like e.g. cp_time[] could do +=N instead of ++. Other stats ru_ixrss need to be updated only once. Similarly, N could be passed further down to sched_clock() and handled there too. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Remove printf in acpi_tz_sanity()
on 21/11/2010 13:07 Paul B Mahol said the following:
> This patch removes printf which spams console whenever thermal state
> is changed in laptop. Source of problem is in buggy BIOS.
>
> diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c
> index 515a742..00866b2 100644
> --- a/sys/dev/acpica/acpi_thermal.c
> +++ b/sys/dev/acpica/acpi_thermal.c
> @@ -697,11 +697,8 @@ acpi_tz_getparam(struct acpi_tz_softc *sc, char
> *node, int *data)
> static void
> acpi_tz_sanity(struct acpi_tz_softc *sc, int *val, char *what)
> {
> -if (*val != -1 && (*val < TZ_ZEROC || *val > TZ_ZEROC + 2000)) {
> - device_printf(sc->tz_dev, "%s value is absurd, ignored (%d.%dC)\n",
> - what, TZ_KELVTOC(*val));
> +if (*val != -1 && (*val < TZ_ZEROC || *val > TZ_ZEROC + 2000))
> *val = -1;
> -}
> }
As is - this is a perfect candidate for a "local only" patch.
To be included into the tree - this, most probably, has to be controlled by a
tunable/sysctl.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Building my own release ISOs
on 22/11/2010 03:31 Sean Bruno said the following: > Does this look about right to build from a test branch? > > sudo make release SVNROOT=ssh+svn://svn.freebsd.org/base > SVNBRANCH=projects/sbruno_64cpus MAKE_ISOS=y MAKE_DVD=y NO_FLOPPIES=y > NODOC=y NOPORTSATALL=y WORLD_FLAGS=-j32 KERNEL_FLAGS=-j32 > BUILDNAME=sbruno CHROOTDIR=/new_release BTW, just in case, I think that EXTSRCDIR could be used to make a release out of an existing src directory as opposed to code in a repository. -- Andriy Gapon -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Remove printf in acpi_tz_sanity()
on 22/11/2010 01:18 Paul B Mahol said the following: > On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon wrote: >> As is - this is a perfect candidate for a "local only" patch. >> To be included into the tree - this, most probably, has to be controlled by a >> tunable/sysctl. > > So solution for useless console spamming is to add useless sysctl. Are you absolutely sure that they both are/would be useless? For all uses of acpi_tz_sanity()? E.g. if some system has never produced those messages in years and then suddenly starts spewing them out, would that be useless information? > For -1 values, sane default values should be picked up. For current temperature too? > Anyway only _CRT is showing on console, and _PSV & _HOT are both -1 for tz0. On your system. > I'm not first one mentioning this and issue is old several years. OK. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
smp_rendezvous_cpus() vs sched_bind()
If I need to call a function func on a specific CPU which one of the following I should use? 1. smp_rendezvous_cpus(1 << cpuid, ..., func, ...); 2. sched_bind(cpuid); func(); sched_unbind(); Or does it depend on some additional factors? What are the main differences here? And also by extension. If I need to execute func() on all CPUs - which one is better again - smp_rendezvous_cpus() or CPU_FOREACH+sched_bind? Thanks a lot! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
dtrace/cyclic deadlock
I think that I've run into the known issue of dtrace/cyclic deadlock. Just would like to run my understanding and ideas by you. The problem is that the cyclic_fire() callback is executed in the interrupt filter context (and thus with interrupts disabled) and it tries to obtain a spin mutex lock in the cyclic code. At the same time other CPU may execute a thread that holds that spin mutex and uses smp_rendezvous_cpus() to perform a synchronous function invocation on the first CPU. So, CPU #1 can not make forward progress because it is spinning on the spin-lock and CPU #2 can not make forward progress because it can not interrupt CPU #1. I think that the problem was introduced during the porting of the code. On (Open)Solaris there are no spin-locks in this code, all data structures are per-CPU and data coherency is ensured by (1) accessing the data only from the CPU to which it belongs; and (2) using some modern-day spl*() equivalent[?] to block interrupts. I think that this is quite similar to what we do for per-CPU caches in UMA and so the same approach should work here. That is, as in (Open)Solaris, the data should be accessed only from the owning CPU and spinlock_enter()/spinlock_exit() should be used to prevent races between non-interrupt code and nested interrupt code. What do you think? Thanks! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtrace/cyclic deadlock
on 23/11/2010 08:33 Andriy Gapon said the following: > I think that this is quite similar to what we do for per-CPU caches in UMA and > so the same approach should work here. > That is, as in (Open)Solaris, the data should be accessed only from the owning > CPU and spinlock_enter()/spinlock_exit() should be used to prevent races > between > non-interrupt code and nested interrupt code. Here's a patch that makes our version of cyclic.c a little bit closer to the upstream version whilst implementing the above idea: http://people.freebsd.org/~avg/cyclic-deadlock.diff All accesses to per-CPU cyclics data are performed strictly from the corresponding CPUs in an interrupt or interrupt-like context. "Upcalls" occur in event timer's interrupt filter and all down calls are performed via smp_rendezvous_cpus(). I will appreciate reviews and testing. Thanks! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Best way to determine if an IRQ is present
on 22/11/2010 16:24 John Baldwin said the following: > Well, the real solution is actually larger than described in the PR. What > you > really want to do is take the logical CPUs offline when they are "halted". > Taking a CPU offline should trigger an EVENTHANDLER that various bits of code > could invoke. In the case of platforms that support binding interrupts to > CPUs (x86 and sparc64 at least), they would install an event handler that > searches the MD interrupt tables (e.g. the interrupt_sources[] array on x86) > and move bound interrupts to other CPUs. However, I think all the interrupt > bits will be MD, not MI. That's a good idea and a comprehensive approach. One minor technical detail - should an offlined CPU be removed from all_cpus mask/set? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Best way to determine if an IRQ is present
on 25/11/2010 17:28 John Baldwin said the following: > Andriy Gapon wrote: >> on 22/11/2010 16:24 John Baldwin said the following: >>> Well, the real solution is actually larger than described in the PR. What >>> you >>> really want to do is take the logical CPUs offline when they are "halted". >>> Taking a CPU offline should trigger an EVENTHANDLER that various bits of >>> code >>> could invoke. In the case of platforms that support binding interrupts to >>> CPUs >>> (x86 and sparc64 at least), they would install an event handler that >>> searches >>> the MD interrupt tables (e.g. the interrupt_sources[] array on x86) and move >>> bound interrupts to other CPUs. However, I think all the interrupt >>> bits will be MD, not MI. >> >> That's a good idea and a comprehensive approach. >> One minor technical detail - should an offlined CPU be removed from all_cpus >> mask/set? > > That's tricky. In other e-mails I've had on this topic, the idea has been to > have > a new online_cpus mask and maybe a CPU_ONLINE() test macro similar to > CPU_ABSENT(). In that case, an offline CPU should still be in all_cpus, but > many > places that use all_cpus would need to use online_cpus instead. > This sounds like a plan. CPU_FOREACH_ONLINE() could also come handy, Thanks! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtrace/cyclic deadlock
on 23/11/2010 15:26 Andriy Gapon said the following: > on 23/11/2010 08:33 Andriy Gapon said the following: >> I think that this is quite similar to what we do for per-CPU caches in UMA >> and >> so the same approach should work here. >> That is, as in (Open)Solaris, the data should be accessed only from the >> owning >> CPU and spinlock_enter()/spinlock_exit() should be used to prevent races >> between >> non-interrupt code and nested interrupt code. > > Here's a patch that makes our version of cyclic.c a little bit closer to the > upstream version whilst implementing the above idea: > http://people.freebsd.org/~avg/cyclic-deadlock.diff > > All accesses to per-CPU cyclics data are performed strictly from the > corresponding > CPUs in an interrupt or interrupt-like context. "Upcalls" occur in event > timer's > interrupt filter and all down calls are performed via smp_rendezvous_cpus(). > > I will appreciate reviews and testing. Should I wait for any pending comments? Otherwise I am confident enough in the patch to commit it. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtrace/cyclic deadlock
on 26/11/2010 21:10 Artem Belevich said the following: > On Fri, Nov 26, 2010 at 5:54 AM, Andriy Gapon wrote: >>> I will appreciate reviews and testing. >> >> Should I wait for any pending comments? >> Otherwise I am confident enough in the patch to commit it. > > Some time back I used to have reproducible crash related to dtrace/cyclic: > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2008-10/msg00449.html > > If you can wait until Tuesday, I'll try to check if the problem is > still reproducible and whether your patch fixes it. Artem, thanks a lot! I am sure in no hurry and I will appreciate your testing! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
small dtrace patch for review
The patch is not about DTrace functionality, but about infrastructure use in one particular place. http://people.freebsd.org/~avg/dtrace_gethrtime_init.diff I believe that sched_pin() is need there to make sure that "host"/base CPU stays the same for all calls to smp_rendezvous_cpus(). The pc_cpumask should just be a cosmetic change. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: DTrace: Sending ^C while running script produces no output
on 03/12/2010 07:20 Brandon Gooch said the following:
> I've been tinkering with DTrace a bit, and I've notice something
> peculiar on each system I've tried it on.
>
> Sending ^C from the keyboard in the terminal (console, XTerm, Konsole)
> produces no output [1].
Can you ktrace the dtrace process?
I wonder, could it be that SIGINT from ^C is somehow delivered twice?..
> For example, while trying out a one-liner (from
> http://www.brendangregg.com/DTrace/dtrace_oneliners.txt):
>
> bran...@d820:~$ sudo dtrace -n 'syscall:::entry { @num[execname] = count(); }'
> dtrace: description 'syscall:::entry ' matched 514 probes
> ^C
BTW, sudo might play a role here... Just a thought.
> bran...@d820:~$ (12-02
> 23:11)
>
>
> If I instead, from another terminal, use pkill to quit or terminate
> the process, I get output:
>
> bran...@d820:~$ sudo dtrace -n 'syscall:::entry { @num[execname] = count();
> }';
> dtrace: description 'syscall:::entry ' matched 514 probes
>
>
> akonadi_control 4
> akonadiserver 5
> syslogd 6
> sendmail 8
> akonadi_ical_resour 12
> akonadi_maildir_res 12
> akonadi_nepomuk_con 12
> akonadi_vcard_resou 12
> kuiserver12
> akonadi_maildispatc 14
> korgac 14
> virtuoso-t 15
> dbus-daemon 17
> mysqld 18
> hald 24
> knotify4 27
> akonadi_contacts_re 36
> nepomukservicestub 70
> pkill70
> powerd 72
> dtrace 101
> zsh 111
> sudo495
> kwin 2812
> firefox-bin3175
> kdeinit4 11044
> Xorg 39588
> bran...@d820:~$ (12-02
> 23:14)
>
>
> I also want to add that I've tried this with a variety of shells on
> both 8.2-PRERELEASE and HEAD systems, i386 and amd64, built with GCC
> and nearly GENERIC kernels in order to try to eliminate the cause.
>
> I feel as though this has something to do with file descriptors being
> closed too soon when handling the signal or something of that nature.
> It's also been suggested that this could be a bug in libdtrace, but I
> haven't the knowledge (or skill) to try and pinpoint the cause myself.
>
> Is there anyone here that may be able to provide feedback or debugging
> suggestions?
>
> Thanks!
>
> -Brandon
>
> [1] This isn't always the case, only like 99.99% of the time.
> Sometimes I do get output, but usually it's just snippets, and
> sometimes random characters!
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
atomic_set_xxx(&x, 0)
$ glimpse atomic_set_ | fgrep -w 0 /usr/src/sys/dev/arcmsr/arcmsr.c: atomic_set_int(&acb->srboutstandingcount, 0); /usr/src/sys/dev/arcmsr/arcmsr.c: atomic_set_int(&acb->srboutstandingcount, 0); /usr/src/sys/dev/jme/if_jme.c: atomic_set_int(&sc->jme_morework, 0); /usr/src/sys/dev/jme/if_jme.c: atomic_set_int(&sc->jme_morework, 0); /usr/src/sys/dev/ale/if_ale.c: atomic_set_int(&sc->ale_morework, 0); /usr/src/sys/mips/rmi/dev/xlr/rge.c: atomic_set_int(&(priv->frin_to_be_sent[i]), 0); /usr/src/sys/dev/drm/drm_irq.c: atomic_set_rel_32(&dev->vblank[i].count, 0); /usr/src/sys/dev/cxgb/ulp/tom/cxgb_tom.c: atomic_set_int(&t->tids_in_use, 0); I wonder if these are all bugs and atomic_store_xxx() was actually intended? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: getting a list of open files versus PID nos.?
on 09/12/2010 01:47 Matthew Fleming said the following: > On Wed, Dec 8, 2010 at 3:01 PM, Bruce Cran wrote: >> On Wed, 8 Dec 2010 14:54:57 -0800 >> Matthew Fleming wrote: >> >>> This is what lsof is for. I believe there's one in ports, but I have >>> never tried it. >> >> Is there any advantage to using lsof instead of fstat(1) (fstat -p pid)? > > I believe that lsof reports on all open files by all processes, > whereas fstat will only report on a specific provided pid. Just try running fstat without any options. Or procstat -a -f. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: getting a list of open files versus PID nos.?
on 09/12/2010 13:49 krad said the following: > > not sure if dtrace is ready for it on freebsd yet, but it certainly can do it > on > solaris Greatly depends on what you meant by 'it'. Personally I don;t see how DTrace capabilities in needed for this task. Can you please enlighten me? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Where userland read/write requests, whcih is larger than MAXPHYS, are splitted?
on 10/12/2010 15:22 Lev Serebryakov said the following: > Hello, Freebsd-geom. > >I'm digging thought GEOM/IO code and can not find place, where > requests from userland to read more than MAXPHYS bytes, is splitted > into several "struct bio"? Check out g_disk_start(). The split is done based on disk-specific d_maxsize, not hardcoded MAXPHYS, of course. > It seems, that these children request are issued one-by-one, not in > parallel, am I right? Why? It breaks down parallelism, when > underlying GEOM can process several requests simoltaneously? How do you *issue* the child requests in parallel? Of course, they can *run* in parallel if system configuration permits that and request run time is sufficient for an overlap to happen. Besides, there are no geoms under disk geom, it works on peripheral drivers. But maybe I misunderstood your question and you talked about a different I/O layer or different I/O path. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Where userland read/write requests, whcih is larger than MAXPHYS, are splitted?
on 10/12/2010 16:48 Andriy Gapon said the following: > But maybe I misunderstood your question and you talked about a different I/O > layer > or different I/O path. > Oh, probably you talk about physread/physwrite == physio. Indeed, it issues bio-s with max size of si_iosize_max and runs them sequentially. Besides, if uio is really "vectored", then each uio sub-buffer is processed sequentially too. This is probably less fast than running the requests in parallel; plus side could be that less KVA is required for mapping user space buffer (UIO_USERSPACE case) into kernel. Not sure if the latter is much of concern though. The sequential code is simpler too :-) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Where userland read/write requests, whcih is larger than MAXPHYS, are splitted?
on 10/12/2010 16:45 Alexander Motin said the following: > by default. Many SCSI drivers still limited by DFLTPHYS - 64K. Including the cases where MAXBSIZE is abused because it historically has the same value. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: syscall provider naming convention. Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32
on 13/12/2010 11:35 Alexander Leidinger said the following: > On Sat, 11 Dec 2010 23:38:32 -0800 Artem Belevich > wrote: > >> Functionally both approaches are about the same functionally. Each has >> pluses and minuses. Using module, though, looks somewhat cleaner. > > I agree. +1, just in case. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[dtrace] syscall provider naming convention.
on 14/12/2010 05:10 Artem Belevich said the following: > I've posted updated version of the patch here: > https://sites.google.com/site/abc678site/files/dt-systrace.patch.gz > > This patch uses DTrace module field to specify syscall's compat > variant in the syscall probe name. If there are no objections and no pending reviews and comments, then I would like to commit this shortly. > The patch also adds syscall probe for linux32 binaries on amd64. I'll > try to add i386 support soon, too, but I have no i386 box I could > compile and test the changes on. I'll try to get one set up under > VirtualBox later, but for now the patch is for 8-STABLE/amd64 only. It would be nice to get the i386 counterpart too when this goes into the tree. Thanks! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [dtrace] syscall provider naming convention.
on 21/12/2010 11:27 Artem Belevich said the following: > On Tue, Dec 21, 2010 at 1:26 AM, Artem Belevich wrote: >> On Mon, Dec 20, 2010 at 3:15 AM, Andriy Gapon wrote: >>> It would be nice to get the i386 counterpart too when this goes into the >>> tree. >> >> Here's updated version that has syscall:linux32 working on i386, too. >> >> https://sites.google.com/site/abc678site/files/dt-systrace-20101221.patch.gz > > Forgot to mention. The patch is against stable/8 r216436 The previous version applied fine to head, I think that that should be the case with this version too. I have one comment though. I am not sure about renaming syscall.ko to syscall_freebsd.ko. Perhaps we could keep the old name? Or add a new module under that name that would load native syscall module and all emulation syscall modules (if any)? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [dtrace] syscall provider naming convention.
on 24/12/2010 04:02 Artem Belevich said the following: >> I have one comment though. I am not sure about renaming syscall.ko to >> syscall_freebsd.ko. > > You mean systrace_freebsd.ko. Yes, thanks. > I've renamed it for consistency with other systrace provider variants. > I can change it back. I think that I would prefer this. If only for POLA reasons. >> Perhaps we could keep the old name? Or add a new module >> under that name that would load native syscall module and all emulation >> syscall >> modules (if any)? > > I'm not sure that creating an umbrella 'systrace' module is worth it. > "kldload /boot/kernel/systrace*" should do that just fine. The reason > dtrace exists is that there are number of modules with dtrace > providers that are not easily distinguishable by their name. I agree. I am going on vacation and I don't want to risk, so it looks like I will be able to commit your patch after the holidays. Unless someone else beats me to it. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: machdep.hlt_cpus not safe with ULE?
on 19/02/2011 14:36 Steven Hartland said the following: > I'm trying to debug a possibly failing CPU, so I thought it would > be easy just disable the cores using machdep.hlt_cpus and see if > we see the panic's we've been seeing. > > The problem is it seems ULE doesnt properly support machdep.hlt_cpus > and still schedules processes onto the halted cpus which obviously > causes problems. > > Can anyone confirm this behaviour? Yes, your observations are correct. Please also see: http://www.freebsd.org/cgi/query-pr.cgi?pr=145385 > Should machdep.hlt_cpus and I assume > the logical counterpart never be used with ULE? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
/dev/dsp mmap question
Guys, if we the following on FreeBSD (pseudo-code): fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); This won't work entirely correctly, right? I base my question on some observations of how a particular program behaves on FreeBSD and on the following comment in sys/dev/sound/pcm/dsp.c: /* * XXX The linux api uses the nprot to select read/write buffer * our vm system doesn't allow this, so force write buffer. * * This is just a quack to fool full-duplex mmap, so that at * least playback _or_ recording works. If you really got the * urge to make _both_ work at the same time, avoid O_RDWR. * Just open each direction separately and mmap() it. * * Failure is not an option due to INVARIANTS check within * device_pager.c, which means, we have to give up one over * another. */ P.S. is this something that can easily fixed or not? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: hw.physmem (loader.conf and sysctl)
on 04/03/2011 16:36 Dmitry Krivenok said the following: > Hello Hackers, > I've limited the amount of physical memory visible for my FreeBSD-8.2 by > adding > the following in loader.conf: > > $ cat /boot/loader.conf | grep hw.physmem > hw.physmem="500M" > $ > > However, according to sysctl, the system sees > > $ sysctl hw.physmem > hw.physmem: 507445248 > $ > > The difference is (500 * 2**20 - 507445248) / 2**20 == 16.0625 Mb. > How does the system use this "hidden" memory? Some memory is taken by structures that describe usable pages. There is one vm_page_t structure per each 4KB page. I believe that that memory is excluded from physmem. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heci: a new driver for review and testing
on 27/01/2011 07:43 Lawrence Stewart said the following: > Hi Andriy, > > On 10/15/09 04:12, Andriy Gapon wrote: >> >> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: >> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 >> >> I actually got around to implementing it (in initial/basic form): >> http://people.freebsd.org/~avg/heci.tgz > > An old thread I know, but I just noticed my desktop has AMT support and > was investigating if I could get access to the Serial Over Lan feature. > I stumbled across your HECI driver and thought I'd give it a spin. It > loads and attaches fine and unloads without issue as well. I tested with > device "HECI_DEV_ID_ICH9_82Q35" on a HP DC7800 minitower machine. I get > no output when I run your "heci-qst" program though. > > Few more details: > > heci0@pci0:0:3:0: class=0x078000 card=0x2819103c chip=0x29b48086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel(R) Management Engine Interface (HECI) (Q35-Chipset)' > class = simple comms > > lstewart@lstewart> uname -a > FreeBSD lstewart 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0 r217387M: Fri > Jan 14 15:52:16 EST 2011 > lstewart@lstewart:/usr/obj/usr/src/sys/DESKTOP amd64 It's quite possible that your AMT firmware doesn't have a QST module. Upon loading of heci driver it prints a list of discovered module guids. QST guid is 6B5205B9-8185-4519-B889-D98724B58607. But I have mostly gave up on development of this driver (although I keep using it). I think that it's better to port either OpenSolaris or Linux heci driver to FreeBSD. BTW, Intel has released QST SDK source code: http://software.intel.com/en-us/articles/Intel_Quiet_System_Technology_Software_Development_Kit/ -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: get_cyclecount(9) deprecation
on 18/03/2011 15:56 Kostik Belousov said the following: > On Fri, Mar 18, 2011 at 05:26:53PM +1100, Bruce Evans wrote: > ... >> - set cputicker() has some design bugs. It assumes that the tick frequency >> is the same across all CPUs, but the TSC is per-CPU. I have an old SMP >> system with CPUs of different frequency that can demonstrate bugs from >> this. > We definitely do not support configurations with different models of > CPUs in SMP, this is what Simmetric is about. Different as in frequency > or stepping. Are there any fundamental reasons for us to not support that configuration in situations where hardware and BIOS (in x86 case) happen to support it? I am personally more interested in non-uniform topologies like one package having two cores and another having four. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)?
on 25/03/2011 11:52 Alexander Leidinger said the following: > As I read it, it looks a little bit like the SYSINIT of the SDT probes didn't > work as expected for my new probes (does this work in modules? fxr.watson.org > AFAICS only lists SDT probes in kernel-code, not in module-code), a hit with > the > clue-bat is welcome. My reading of the code is that all modules with SDT proivders/probes should be loaded before sdt module itself. SYSINIT in your module(s) works as expect, but dtrace_register() is not called on your SDT provider. See sys/cddl/dev/sdt/sdt.c for details: sdt_modevent -> sdt_load -> sdt_provider_listall(sdt_provider_reg_callback) -> dtrace_register. I am not saying that this behavior is correct/desired, just that this is what we have now. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
on 25/03/2011 17:35 Pietro Cerutti said the following: > No need to look for strange scenarios, I'm surely going to sudo rm -f the file > more sooner than later, so... maybe just save a copy? I even can rm -rf / by accident. What's your solution to this? :) P.S. one solution would be a subcase of the other -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: New Boot-Loader
on 28/03/2011 14:08 Alexander Best said the following: > sorry if we have different opinions on this matter, but i don't quite see > the "fresh" look. > > imo a "modern" boot loader looks like this > > http://www.dailycupoftech.com/wp-content/uploads/2006/08/ubuntu01.png > > or this > > http://images.linuxscreenshots.com/distro/opensuse/11.3/h400/01_boot_menu.png > > ... and not something made out of ascii chars like it's 1981. ;) There is/was a different project for that too: http://wiki.freebsd.org/OliverFromme/BootLoader Please note that graphical loaders are not very serial console friendly ;-) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: New Boot-Loader
Would also be cool to have an option to boot "something else" (like e.g. memtest86). Maybe a special directory with loadable binaries and a special menu entry to select one of them. Probably even better to have a mechanism for pluggable menu entries like a special directory that would have .4th files each of which would represent one extra menu option. So instead of hacking system .4th files, one could easily extend main menu with custom entries. Just a dream... -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
on 25/03/2011 12:11 Baptiste Daroussin said the following: > Hi all, > > miwi@ launched the new thing called Experimental Call For Testing, > it's our turn :) > > Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge > contributor) have been working since the end of the last GSoC on a > rewrite of pkg_install. > > pkgng is a binary package manager written from scratch for FreeBSD. > > After a long period of technology testing, (json, tinycdb, bdb, etc) > and we now have achieved to implement the basic functionnality. We > would greatly approciate to have some feedback, wider testing, > patching, documenting etc, before implementing the higher level > features. > > pkgng is built on top of a new libpkg, which allow to deal with the database > of > installed packages, to deal with remote repositories, manage packages: > creation, installation gathering informations, registering new ports. > > features supported are or will be : > > - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486) > which allow to have a bsd.port.mk which deal with both pkg_install > and pkgng. (done in alpha) > > - the register command can analyse elf files when registering a new port to > discover forgotten dependencies if necessary. (done in alpha using libelf) > > - the register command has two mode available : when dealing with old > fashion ports it just registers the package, in new mode it does > everything that would > have been done by pkg add when installing the package : should display > messages, execute post-install, execute @exec etc. (old fashion done > in the alpha) > > - pkg add supports two mode : the old fashion one (no real upgrade > support) and new one: upgrade scripts supported. (old fashion in the > alpha) > > - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL, > +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion > scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't > supported in the alpha) > > - new +MANIFEST (plist-like format) with new metadatas : options, arch, os > version, etc. (done in the alpha) > > - pkgng supports checking arch of the package which means that users > won't be able to install sparc64 binary package into amd64 machines. > (not done yet) > > - a special architecture "all" allows to specify when a package can be used > on every architecture. (not done yet) > > - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself > which directory has to be removed. (done in the alpha but needs love > :)) > > - new repository (apt-like feature) (only the repository generation is done) > > - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the > alpha) > > - test unit (libcheck) on libpkg. (done in the alpha needs some more love) > > - many more Perhaps I am too impatient :) but I would like to inquire about the following features: I. A provides/requires interface for packages. Each package specified a list of files (and perhaps other entities) that it provides and requires. At the initial stage, without ports modifications, these could be: (1) a list of all files installed by package for provides; (2) for requires - an auto-generated list of dependencies based on required shared libraries plus dependency specifications in ports. I think that this kind of interface should help with using alternatives that provide the same interface (e.g. like gamin vs fam). II. Package signing. III. Package naming that includes architecture, major OS version (for API/ABI), maybe more. IV. "Convenient" support for i386 packages on amd64. Distinct installation directories, proper installation conflict detection/avoidance between i386 and amd64 packages, proper library paths, etc. And finally some exotic ideas - support for multiple package sources (when different people build packages in different ways (e.g. with different options, or different optimizations) from the same ports tree; support for multiple ports sources.(when people maintain different ports tree (e.g. kde or gnome development ports tree)). Perhaps, with some compatibility/hierarchy support for packages and ports sources. But that's almost a pipe dream, so don't take it seriously :) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
on 28/03/2011 21:22 Julien Laffaye said the following: > On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper wrote: >>> III. Package naming that includes architecture, major OS version (for >>> API/ABI), >>> maybe more. >> >> This could be provided in the manifest. Doing it in the filename sort >> of turns into a mess, as I've discovered working at Cisco :). >> > > Actually, it *is* in the +MANIFEST of pkgng packages archives :-) Well, by the package name I meant not only a package file name. Let's imagine that we do support installing i386 packages on amd64 in parallel to amd64 packages. And for some reason I want to have both 32-bit and 64-bit versions of, say, firefox; e.g. for benchmarking. If the packages would have the same name, then that would be impossible. I think that having some thing in package name in addition to package metadata could have certain benefits. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
on 29/03/2011 23:29 Baptiste Daroussin said the following: > ok let's try to say it simpler :) the main goal is to keep it simple > for now, simple and rock solid, so that we can replace pkg_install and > do some cleanup in the ports tree, add the "must have" features while > doing that. And only when we will be ready for that and that portmgr > have decided that it is mature enough to replace pkg_install, only > after that we will start improving with new features and new changes. > > I thinks changing the package name scheme is not a "must have" > feature, it for sure is and intresting feature, but what about pushing > to after the first stable release? managing architecture as we plan to > do it is enough imho. Oh, yes, I realize all this and totally agree with it. Given how huge and how visible our ports and packages systems are, it's better to be slow and cautious. All the ideas that I suggested were more for the "next step" than for now. Thank you for the work! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
looking for error codes
I am looking for error codes that would unambiguously signal that a disk drive has readonly or write-protected media and that disk drive has no media at the moment. I foresee these error codes being used mostly between disk peripheral drivers and filesystem drivers. I will appreciate your suggestions. P.S. I see that Linux uses EROFS and ENOMEDIUM for these purposes. I am not sure about EROFS in this role. And we don't have ENOMEDIUM (nor EMEDIUMTYPE). -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: looking for error codes
on 01/04/2011 18:04 Andrew Duane said the following: > AFAIK, FreeBSD does not really detect read-only media. This was something I > had to add as a small project here at work, and was considering cleaning up > to try to get into CURRENT. If there's a real need for it, I could speed that > up. > Yes, that's exactly the problem that I am looking at. So if you have anything to share it will be greatly appreciated at least by me. But I think many more people could benefit from it (e.g. those having SD/SDHC/etc cards). Thanks! > > From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] > On Behalf Of Warner Losh [i...@bsdimp.com] > Sent: Friday, April 01, 2011 10:51 AM > To: Andriy Gapon > Cc: FreeBSD Hackers; FreeBSD Arch > Subject: Re: looking for error codes > > On Apr 1, 2011, at 8:29 AM, Andriy Gapon wrote: > >> >> I am looking for error codes that would unambiguously signal that a disk >> drive has >> readonly or write-protected media and that disk drive has no media at the >> moment. >> I foresee these error codes being used mostly between disk peripheral >> drivers and >> filesystem drivers. >> >> I will appreciate your suggestions. >> >> P.S. >> I see that Linux uses EROFS and ENOMEDIUM for these purposes. >> I am not sure about EROFS in this role. >> And we don't have ENOMEDIUM (nor EMEDIUMTYPE). > > Maybe we could add ENOMEDIA for that (spelled however Linux spells it) after > EDAVE. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Updating PCI vendors database
on 04/04/2011 17:10 Philip Paeps said the following: > It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as > far as I can tell) has become rather stale. We also appear to be tracking > sources which no longer exist. > > Would anyone object if I updated this list to source the same database used by > Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids? > > It helps that our pciconf looks to be compatible with that format. We just > ignore subvendor and subdevice, but it doesn't appear to matter that the file > contains this information. > > I could cull the subvendor/subdevice from the list though. > > Any views? > > Reason I'm looking into this is because one of my customers would like their > name to be correct when I import the driver I've been working on for them. :) This is just for your information: http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577 Maybe you'll find something useful there. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: looking for error codes
on 01/04/2011 17:29 Andriy Gapon said the following: > > I am looking for error codes that would unambiguously signal that a disk > drive has > readonly or write-protected media and that disk drive has no media at the > moment. > I foresee these error codes being used mostly between disk peripheral drivers > and > filesystem drivers. > > I will appreciate your suggestions. > > P.S. > I see that Linux uses EROFS and ENOMEDIUM for these purposes. > I am not sure about EROFS in this role. > And we don't have ENOMEDIUM (nor EMEDIUMTYPE). Thanks for all the error code suggestions so far :-) It seems that ENODEV could be a good choice for signaling readonly or write-protected media on write access: 19 ENODEV Operation not supported by device. An attempt was made to apply an inappropriate function to a device, for example, trying to read a write-only device such as a printer. BTW, SCSI code currently maps that condition to EACCES, but I don't think that that is the best choice - the error could be also produced by "permissions-related" checks. E.g. from intro(2): 13 EACCES Permission denied. An attempt was made to access a file in a way forbidden by its file access permissions. As for the ENOMEDIUM, I don't think that adding a distinct error code here would provide any new useful abilities. So, ENXIO should still be a good option. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
retry mounting with ro when rw fails
[sorry for double post, it should have been "hackers" not "hardware"] Guys, could you please review and comment on the following patch? http://people.freebsd.org/~avg/mount-retry-ro.diff Thank you! The patch consists of two parts. The first part is in CAM/SCSI to make sure that ENODEV is consistently returned to signal that an operation is not supported by a device (in accordance to intro(2)) and specifically to return ENODEV on write attempt to a read-only or write-protected media. Making this change in SCSI should cover real SCSI devices, as well as ATAPI through ahci/siis/atapicam or similar, plus majority (all?) of USB Mass Storage devices. The second part is in vfs_mount code. The idea is to re-try a mount call if we get the ENODEV error, and mounting was not already in read-only mode, and there was no explicit rw or noro option; the second try is changed to ro. I did only basic testing with an SD card in write-protected mode and a USB card-reader. Since I am not very familiar with vfs_mount code I might have missed some important details. A sample test log, just in case: ugen2.2: at usbus2 umass0: on usbus2 da0 at umass-sim0 bus 0 scbus7 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 488MB (1000448 512 byte sectors: 64H 32S/T 488C) da1 at umass-sim0 bus 0 scbus7 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 scbus7 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 scbus7 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present GEOM: da0s1: EBR has non empty bootcode. (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 0 ea 0 0 8 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: DATA PROTECT csi:0,aa,55,61 asc:27,0 (Write protected) field replaceable unit: 1 g_vfs_done():da0s1[WRITE(offset=512, length=4096)]error = 19 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 0 ea 0 0 8 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: DATA PROTECT csi:0,aa,55,61 asc:27,0 (Write protected) field replaceable unit: 1 g_vfs_done():da0s1[WRITE(offset=512, length=4096)]error = 19 vfs_donmount: R/W mount failed, possibly R/O media, falling back to R/O mount -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: retry mounting with ro when rw fails
on 08/04/2011 03:00 Jeremy Chadwick said the following: > On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: >> On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon wrote: >>> >>> [sorry for double post, it should have been "hackers" not "hardware"] >>> >>> Guys, >>> could you please review and comment on the following patch? >>> http://people.freebsd.org/~avg/mount-retry-ro.diff >>> Thank you! >>> >>> The patch consists of two parts. >>> >>> The first part is in CAM/SCSI to make sure that ENODEV is consistently >>> returned to >>> signal that an operation is not supported by a device (in accordance to >>> intro(2)) >>> and specifically to return ENODEV on write attempt to a read-only or >>> write-protected media. ?Making this change in SCSI should cover real SCSI >>> devices, >>> as well as ATAPI through ahci/siis/atapicam or similar, plus majority >>> (all?) of >>> USB Mass Storage devices. >>> >>> The second part is in vfs_mount code. ?The idea is to re-try a mount call >>> if we >>> get the ENODEV error, and mounting was not already in read-only mode, and >>> there >>> was no explicit rw or noro option; the second try is changed to ro. >>> >>> I did only basic testing with an SD card in write-protected mode and a USB >>> card-reader. ?Since I am not very familiar with vfs_mount code I might have >>> missed >>> some important details. >> >> As a generic question / observation, maybe we should just >> implement 'errors=remount-ro' (or a reasonable facsimile) like Linux >> has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or >> [Open]Solaris sported similar functionality. > > I was going to recommend exactly this. :-) > > I like the idea of Andriy's patch, but would feel more comfortable if it > were only used if a mount option was specified (-o errors=remount-ro"). Having the option is appealing, but my main motivation was the simplicity that comes from having that enabled by default. That is, you absolutely want an R/W mount then use -o rw, you need R/O then explicitly -o ro, you "just want" to get that media mounted then the default behavior tries its best. > Why: > > Are there any conditions where ENODEV is returned to the underlying vfs > layer for things like unexpected hardware issues? I would imagine the > latter would be ENXIO, but I'm not certain. An example situation: > > 1. User inserts USB flash drive/etc. > 2. User tries to mount disk R/W manually > 3. Weird/bizarre hardware issue happens mid-mount (drive falling off >the bus, or maybe even the user yanking the drive right in the >middle) -- could this ever return ENODEV? It shouldn't. If that happens then the underlying layers should be fixed. > 4. Kernel attempts re-mount, which also fails, or possibly panics > due to some underlying condition which nobody predicted > 5. User mails mailing list > > If I'm worrying over nothing, then perfect. :-) My other concern is > whether or not this mechanism change could caused some sort of "infinite > loop" within devd(8)/devctl(4) where the daemon gets very confused as to > what's going on or some automated commands get run when they shouldn't. I can't see how that can happen. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: retry mounting with ro when rw fails
on 08/04/2011 05:16 Garrett Cooper said the following: > Yeah. It seems like something else like EINVAL (just an example -- > probably a bad one) would be better. Also, please be careful as > returning ENODEV seems to be UFS-specific: I wonder how you arrived at that conclusion. See intro(2) or grep the sources. > > The following errors can occur for a ufs file system mount: > > [ENODEV] A component of ufs_args fspec does not exist. That documented specific use of ENODEV in UFS doesn't make ENODEV UFS-specific. Besides I don't ENODEV anywhere under sys/ufs. > Also, Tom Rhodes has a similar change to what I suggested on the > backburner, but it hasn't been 100% fleshed out yet. I like that approach too. It has its advantages. But I don't give up yet on my suggestion. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: retry mounting with ro when rw fails
on 07/04/2011 23:20 Garrett Cooper said the following: > > As a generic question / observation, maybe we should just > implement 'errors=remount-ro' (or a reasonable facsimile) like Linux > has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or > [Open]Solaris sported similar functionality. No problem, I am OK with being first. Then, I only want to deal with media that is "semi-permanently" or permanetly read-only. That's why I handle only failure to mount media as R/W. But from what I read 'errors=remount-ro' in Linux has to do with errors that happen after filesystem is mounted. That is, you mounted a filesystem, you work with it, you get some error (e.g. because of bad blocks), you auto-downgrade the filesystem to readonly. This may be a nice feature, but this is something different from what I proposed. And, AFAIK, Linux does what I propose by default, without any additional options. Google for "block device ... is write-protected, mounting read-only". But yes, it seems that they handle this situation entirely in userland. And I am not against it. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: retry mounting with ro when rw fails
on 08/04/2011 15:20 Bruce Evans said the following: > But the default behaviour is backwards, especially for read-mostly > removable media. The default should be ro, possibly with an automagic > upgrade to rw iff the media really needs to be written too. Writing > timestamps for file system and inode access times doesn't count as > "really needs to be written to". > > I think I prefer requiring an explicit upgrade to rw. rw implies > writing access times unless you also use noatime, and I wouldn't want > noatime to be set automagically depending on whether rw is set explicitly, > so I would want noatime to be set explicitly, and once you do that > then you can easily set rw or ro at the same time. A new rm (read mostly) > or "rwa" (read or write automagically) flag could give automatic upgrade > from ro to rw. I'd also like automatic downgrade to ro after a file > system has not been written to for some time (this would avoid fscks > in most cases for read-mostly file systems. The ro flag should be > per-cylinder-group in ffs so that on big disks, most parts are read-only > most of the time and don't need to be checked). This is a very good idea, I would like to get that too, but it's a bit more work than the "auto"-mounting. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: retry mounting with ro when rw fails
on 08/04/2011 15:36 Andrew Duane said the following: > What I was hoping to do was design a better mechanism for passing that R/O > detection from the device to the filesystem code. Our implementation uses a > platform sysctl that checks the incoming device name against some hardware or > software settings. Ick. I don't know enough about device/GEOM calls to do it > better though. I am actually not aware of any way to inquiry write-protection status from hardware. There are distinct SCSI sense codes for that, but you get them only after a failed write attempt. But there are many things that I don't know about... -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Kernel Tracking Question.. regarding kernel and boot files
on 10/04/2011 00:51 Chris Richardson said the following: > Yeah. this file provides me with the stages in theoretical way. How about > implementing it using qemu to emulate livecd to see what is going on boot0. > Do you have an idea about that ? Yes, that's perfectly possible. You have to be familiar with assembly and know basic behavior of BIOS booting (supposing we talk about x86) and FreeBSD boot blocks, e.g. what is loaded at what address. Here's an example of something related: http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008580.html -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
couple more vim gems for C/FreeBSD hackers
This is for your .vimrc.
Picked from some google search results.
" highlight too long lines
autocmd BufWinEnter *.c let w:m2=matchadd('ErrorMsg', '\%>80v.\+', -1)
autocmd BufWinLeave *.c call matchdelete(w:m2)
" permanently highlight 80th column
" set colorcolumn=80
" highlight trailing whitespace and tabs after spaces in leading whitespace
highlight ExtraWhitespace ctermbg=red guibg=red
autocmd BufWinEnter *.c match ExtraWhitespace /^\s* \|\s\+$/
autocmd InsertEnter *.c match ExtraWhitespace /^\s* \|\s\+\%#\@http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
puzzled: fork +libthr
Guys, I am trying to debug this chromium issue: http://trillian.chruetertee.ch/chromium/ticket/13 Not sure SOCK_SEQPACKET mentioned in the ticket is an actual culprit, the problem that interests me is that pthread_cond_wait() returns EPERM where it shouldn't. That happens on stable/8. I compared ktrace of chromium on stable/8 and head. Startup traces are very similar until execution gets to one particular place. At that place stable/8 chromium executes pthread_cond_wait - I see _umtx_op(UMTX_OP_CV_WAIT) and that's where EPERM is returned. On the other hand it seems that head chromium executes something different at exactly the same place, perhaps sem_wait - I see _umtx_op(UMTX_OP_WAIT_UINT_PRIVATE). So this is puzzle #1 for me why chromimum build or run-time chooses a different thing to call/use at that place. The second puzzle is the EPERM return value itself, on stable/8. >From what I seem chromium does a bunch of forks before it gets to the place of interest. My debugging shows that those forks are "single-threaded" (i.e. code in thr_fork.c is not called). And then in a process/thread that makes that pthread_cond_wait call I see that libthr and kernel have different opinions about what current TID is. Userland part uses what is actually a kernel TID of its parent thread (the one that called fork). And given how the work is divided between userland and kernel in libthr, that mismatch leads to serious consequences. So my question is why libthr doesn't see its actual TID. Maybe some initialization code is not invoked. BTW, chromium is linked to both libc and libthr (per ldd). But it seems that there are no pthread calls up the fork chain until that pthread_cond_wait call. Maybe this could ring a bell for someone knowledgeable in the area. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
on 16/04/2011 14:46 Andriy Gapon said the following: > > Guys, > > I am trying to debug this chromium issue: > http://trillian.chruetertee.ch/chromium/ticket/13 > Not sure SOCK_SEQPACKET mentioned in the ticket is an actual culprit, the > problem that interests me is that pthread_cond_wait() returns EPERM where it > shouldn't. That happens on stable/8. > > I compared ktrace of chromium on stable/8 and head. Startup traces are very > similar until execution gets to one particular place. At that place stable/8 > chromium executes pthread_cond_wait - I see _umtx_op(UMTX_OP_CV_WAIT) and > that's > where EPERM is returned. On the other hand it seems that head chromium > executes > something different at exactly the same place, perhaps sem_wait - I see > _umtx_op(UMTX_OP_WAIT_UINT_PRIVATE). So this is puzzle #1 for me why > chromimum > build or run-time chooses a different thing to call/use at that place. OK, this was simple. This is because of the new userland condvar implementation in head. The call is the same pthread_cond_wait, just the different implementation in libthr. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
on 16/04/2011 14:46 Andriy Gapon said the following: > The second puzzle is the EPERM return value itself, on stable/8. > From what I seem chromium does a bunch of forks before it gets to the place of > interest. My debugging shows that those forks are "single-threaded" (i.e. > code > in thr_fork.c is not called). And then in a process/thread that makes that > pthread_cond_wait call I see that libthr and kernel have different opinions > about what current TID is. Userland part uses what is actually a kernel TID > of > its parent thread (the one that called fork). And given how the work is > divided > between userland and kernel in libthr, that mismatch leads to serious > consequences. > > So my question is why libthr doesn't see its actual TID. Maybe some > initialization code is not invoked. BTW, chromium is linked to both libc and > libthr (per ldd). But it seems that there are no pthread calls up the fork > chain until that pthread_cond_wait call. The second problem seems to be caused by chrome binary being linked to libc and libthr in "incorrect order", libc comes before libthr in ldd output. My debugging shows that fork is resolved from libc, not from libthr. Not sure what to blame here: - build toolchain for putting libc before libthr - rtld for not preferring libthr over libc - libc/libthr for being split into two pieces in the current way -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
on 17/04/2011 18:21 Daniel Eischen said the following: > On Sun, 17 Apr 2011, Andriy Gapon wrote: > >> on 16/04/2011 14:46 Andriy Gapon said the following: >>> The second puzzle is the EPERM return value itself, on stable/8. >>> From what I seem chromium does a bunch of forks before it gets to the place >>> of >>> interest. My debugging shows that those forks are "single-threaded" (i.e. >>> code >>> in thr_fork.c is not called). And then in a process/thread that makes that >>> pthread_cond_wait call I see that libthr and kernel have different opinions >>> about what current TID is. Userland part uses what is actually a kernel >>> TID of >>> its parent thread (the one that called fork). And given how the work is >>> divided >>> between userland and kernel in libthr, that mismatch leads to serious >>> consequences. >>> >>> So my question is why libthr doesn't see its actual TID. Maybe some >>> initialization code is not invoked. BTW, chromium is linked to both libc >>> and >>> libthr (per ldd). But it seems that there are no pthread calls up the fork >>> chain until that pthread_cond_wait call. >> >> The second problem seems to be caused by chrome binary being linked to libc >> and >> libthr in "incorrect order", libc comes before libthr in ldd output. My >> debugging shows that fork is resolved from libc, not from libthr. >> Not sure what to blame here: >> - build toolchain for putting libc before libthr >> - rtld for not preferring libthr over libc >> - libc/libthr for being split into two pieces in the current way > > - The build procedure for chromium. > > libc/[libc_r, libpthread, libthr] have always behaved that > way since the libc/libc_r split. Well, I wouldn't blame it so expressly: -pthread is the first option on the linkage command line, there is -lc there also. I would expect that that would do the right thing, but it doesn't. And that's a PITA for porting. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: puzzled: fork +libthr
on 18/04/2011 03:54 Alexander Kabaev said the following:
>
> I would blame it, and expressly at that. -pthread is a shortcut for
> {-lpthread -lc} instead of just {-lc} in the place where implied libc
> is provided by the compiler driver and has no magic properties you want
> it it to have. If chromium build infrastructure circumvents that, it is
> only said build infrastructure to blame.
OK, I see, thank you.
Still inconvenient.
As in: if we know for a fact that "gcc ... -pthread -lc" results in a broken
binary, then IMO we should do something about that.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: no KLD symbols in dtrace?
on 22/04/2011 18:24 Alexander Kabaev said the following: > Do ctfdump -tf on your kld and verify that what it outputs actually > makes sense. Do kldload and see if fbt provider knows about your module > and functions. There is nothing else special that I can think off. > > Maybe make sure that you compile your sources with -g in the first > place? DWARF debug info is what CTF generation utils use to figure out > types and function prototypes. Also, dtrace process needs to access the module file for address-to-name translation. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: no KLD symbols in dtrace?
on 22/04/2011 18:56 Chuck Tuffli said the following: > On Fri, Apr 22, 2011 at 8:44 AM, Andriy Gapon wrote: >> Also, dtrace process needs to access the module file for address-to-name >> translation. > > Hmm ... I'm building this module out of tree. Where does dtrace look > for modules? I think that exactly at the place from which a module is loaded. You can double-check with kldstat -v, e.g.: 21 0x80c6c000 217f20 zfs.ko (/boot/kernel/zfs.ko) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
thread_lock vs panic/trap
Can a current thread panic or receive a trap while some other thread holds its thread_lock (the same lock as pointed to by the td_lock)? And a related question, can there be a reason for a thread in panic or kdb context to try to get the thread_lock? Thank you! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RELEASE] New Boot-Loader Menu -- version 1.5
on 16/05/2011 14:34 Tom Evans said the following: > I disagree entirely, the boot loader knows nothing of kernels Eh? Maybe I misunderstand what you are saying, but: set kernel=kernel.old boot IMHO, it shows that you can tell the loader about kernels. Having a kernel-choice sub-menu would be convenient. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: upgrade to version 8 - can not mount root
on 20/05/2011 20:36 Eduardo said the following: > da0 at ahc0 bus0 scbus0 target 5 lun 0 > da0 messages ... > da0 at ahc0 bus0 scbus0 target 6 lun 0 > da1 messages ... > Trying to mount root from ufs:/dev/da0s1a > ROOT MOUNT ERROR: > If you have invalid mount options, reboot, and first try the following > from the loader prompt: > set vfs.root.mountfrom.options=rw > and then remove invalid mount options from /etc/fstab > Loader variables: > vfs.root.mountfrom=ufs:/dev/da0s1a > vfs.root.mountfrom.options=rw > > Manual root filesystem specification: ...etc.. > > mountroot> > > pani: Root mount failed, startup aborted. > cpuid=0 > KBD: stack backtrace: > #0 0xc08ebe67 at kdb_backtrace+0x47 > #1 0xc08bc627 at panic+0x117 > #2 0xc0943fc7 at vfs_mountroot+0x4f7 > #3 0xc08737c0 at start_init+0x60 > #4 0xc0890f51 at fork_exit+0x91 > #5 0xc0bd5b84 at fork_trampoline+0x8 > > I can boot the old kernel at 7.2 and recompile again with debug flags as > needed. > > One thing I did try just now was to install 8.2 from the CD ... after > I choose install options and he goes to create the filesystems I get > these error messages: > > > Unable to find device node for /dev/da0s1b in /dev! > The creation of filesystems will be aborted. First, this is not really a question for hackers@. Perhaps stable@, geom@ or fs@ would be better choices. To the subject matter, it seems like you could have an MBR that is reject by code in in 8. Have you tried to get a lit of devices that kernel sees at the mountroot prompt? What are those? It could also be useful to boot from 8 or 9 live disk and examine how the system sees your disks. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Problem with running simple pthreads program under gdb-7.2 (Invalid selected thread)
on 26/05/2011 03:35 Raphael Kubo da Costa said the following: > If I compile the port myself, I can't run any binary (PR ports/152896, > which has been unanswered despite my efforts): > > Reading symbols from /usr/local/bin/gdb72...I'm sorry, Dave, I can't > do that. Symbol format `elf64-x86-64-freebsd' unknown. > This is a somewhat known issue that John was going to fix a while ago. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Problem with running simple pthreads program under gdb-7.2 (Invalid selected thread)
on 26/05/2011 16:33 John Baldwin said the following: > On Thursday, May 26, 2011 3:37:13 am Andriy Gapon wrote: >> on 26/05/2011 03:35 Raphael Kubo da Costa said the following: >>> If I compile the port myself, I can't run any binary (PR ports/152896, >>> which has been unanswered despite my efforts): >>> >>> Reading symbols from /usr/local/bin/gdb72...I'm sorry, Dave, I can't >>> do that. Symbol format `elf64-x86-64-freebsd' unknown. >>> >> >> This is a somewhat known issue that John was going to fix a while ago. > > Actually, it's not really fixable if you have libreadline installed from > ports > and binutils installed from ports. I'd like to just remove the hack to use > libreadline from ports if possible. I referred to this option as a fix. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] Enabling invariant TSC timecounter on SMP
on 24/05/2011 20:56 Jung-uk Kim said the following: > I think it's about time to enable invariant TSC timecounter on SMP by > default. Please see the attached patch. It is also available from > here: > > http://people.freebsd.org/~jkim/tsc_smp_test4.diff > > avg convinced me enough that it should be an opt-out feature going > forward. :-) Not sure if I really did that. My position is this: - if we think that TSC is SMP-safe then it should have the best priority - we should do our best to auto-guess if TSC is SMP-safe unless a user explicitly overrides that property (either via explicit testing or by making guesses based on CPU model or etc) > Comments? Perhaps I missed it, but I don't remember the "lowres" part of the patch being discussed. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] Enabling invariant TSC timecounter on SMP
on 31/05/2011 23:16 Jung-uk Kim said the following: > On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote: >> on 24/05/2011 20:56 Jung-uk Kim said the following: >>> I think it's about time to enable invariant TSC timecounter on >>> SMP by default. Please see the attached patch. It is also >>> available from here: >>> >>> http://people.freebsd.org/~jkim/tsc_smp_test4.diff >>> >>> avg convinced me enough that it should be an opt-out feature >>> going forward. :-) >> >> Not sure if I really did that. >> My position is this: >> - if we think that TSC is SMP-safe then it should have the best >> priority >> - we should do our best to auto-guess if TSC is SMP-safe >> unless a user explicitly overrides that property (either via >> explicit testing or by making guesses based on CPU model or etc) > > I am sorry if I misunderstood your intention. However, I added > explicit boot-time TSC sanity check (to do our best to auto-guess) > and I think TSC is fairly SMP-safe. Hence, I thought that it is > about time for the change. In this case - yes. But I remember that you were thinking about either improving or simplifying that check or both. >>> Comments? >> >> Perhaps I missed it, but I don't remember the "lowres" part of the >> patch being discussed. > > No, it wasn't discussed with you. Do you see any problem with that > code? I don't see any obvious problem, but I also don't understand rationale of using smaller max_freq for the ncpus > 1 case. Maybe these two logical changes should be done as two separate commits. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] Enabling invariant TSC timecounter on SMP
on 01/06/2011 23:55 Jung-uk Kim said the following: > Yes, it's still a work-in-progress. However, I thought it is good > enough for 9.0 inclusion. BTW, the latest patch is here: > > http://people.freebsd.org/~jkim/tsc_smp_test5.diff > > FYI, the only meaningful change from the previous version is that it's > limited to AMD single-socket Bulldozer platforms and Intel Core and > later platforms. We may add more quirks if needed, of course. Looks good, but I think that the check is a little bit unfair to AMD Family 10h+ CPUs. Although TSCs in those CPUs are per core I've never seen them drift out of sync if they started with the same value. [snip] > Consecutive RDTSCs used on a same CPU is always incremental but we > cannot 100% guarantee that on two cores, even if TSC is derived from > the same clock. I am hoping at least latency difference (I believe > it's about few tens of cycles max) is "eaten up" by lowering > resolution. It's not perfect but it's better than serialization > (Linux) or heuristics (OpenSolaris), just because there are few rare > conditions to consider. Thoughts? I am still not sure which case this code should solve. Thread T1: x1 = rdtsc() on CPU1; Thread T1: x2 = rdtsc() on CPU2; x2 < x1 ? Or? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] Enabling invariant TSC timecounter on SMP
on 03/06/2011 14:50 John Baldwin said the following: > On Friday, June 03, 2011 2:03:55 am Andriy Gapon wrote: >>> Consecutive RDTSCs used on a same CPU is always incremental but we >>> cannot 100% guarantee that on two cores, even if TSC is derived from >>> the same clock. I am hoping at least latency difference (I believe >>> it's about few tens of cycles max) is "eaten up" by lowering >>> resolution. It's not perfect but it's better than serialization >>> (Linux) or heuristics (OpenSolaris), just because there are few rare >>> conditions to consider. Thoughts? >> >> I am still not sure which case this code should solve. >> >> Thread T1: x1 = rdtsc() on CPU1; >> Thread T1: x2 = rdtsc() on CPU2; >> x2 < x1 ? >> Or? > > Yes, that can happen. Well, I think that the test based on smp_rendezvous should ensure that difference in TSC values is "small enough"; that is, I expect that cost (in TSC ticks) of migrating a thread from CPU to CPU should be larger than that difference if the test was passed. Is this an unreasonable expectation? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] Enabling invariant TSC timecounter on SMP
on 03/06/2011 19:28 Jung-uk Kim said the following: > Unlike Intel, AMD did not guarantee "all TSCs reset to zero with RESET > IPI" before Bulldozer[1]. In fact, I tried to measure deltas between > cores when I started hacking on it using some crude heuristics, > somewhat like the OpenSolaris hack[2]. Basically, a dual-core AMD > Family 10h processor showed noticeably larger deltas than *two* > dual-core Intel Woodcrest Xeons'. You are right. I haven't had any problems with my Athlon II system with forced smp_tsc, but testing shows that it has a measurable difference in TSC between cores. E.g. with the "tsc_check" code: cpus 0-1, min_write_time = 186, tdelta = 316 cpus 0-1, TSCs are considered to be OUT of sync > [1] I couldn't find any clues from their publicly available documents > whether they will implement (or need) additional mechanism for > multi-socket Bulldozer platforms. It only says something like "all > TSCs are synchronized with a clock source in north bridge". We will > see when AMD Valencia & Interlagos are available. :-) > [2] Unfortunately, there is no way to accurately measure it with > current generation hardware. Yeah, quite unfortunate. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Issue with 'Unknown Error: -512'
on 18/07/2011 17:53 Brandon Falk said the following: > Hello, > > In recent branches (confirmed with 224119) builds compiled with clang happen > to > throw 'Unknown error: -512' in a lot of places, making the system unusable. > (Untested on gcc compiled systems). Originally I thought the problem was with > specific programs, then I narrowed it down to file I/O, and now I've narrowed > it > down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues > whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' > every > other time you run the program. Common issues, portsnap is affected, making it > impossible to fetch/extract ports. As well as redirecting output in shells eg > `echo 'hi' > test` fails every other try. You have the same issue with text > editors like `edit` where it fails every other save. There are no issues with > `echo 'hi' >> test` as there is no O_TRUNC, it only seems to be an O_TRUNC > error. > > Any tips? Otherwise I'll be looking into this today myself. Just a hint that you could try using DTrace syscall and fbt providers to see where in kernel (if in kernel) that -512 return value originates. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Issue with 'Unknown Error: -512'
on 19/07/2011 03:19 Brandon Falk said the following: > On 7/18/2011 10:18 AM, Andriy Gapon wrote: >> on 18/07/2011 17:53 Brandon Falk said the following: >>> Hello, >>> >>> In recent branches (confirmed with 224119) builds compiled with clang >>> happen to >>> throw 'Unknown error: -512' in a lot of places, making the system unusable. >>> (Untested on gcc compiled systems). Originally I thought the problem was >>> with >>> specific programs, then I narrowed it down to file I/O, and now I've >>> narrowed it >>> down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues >>> whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' >>> every >>> other time you run the program. Common issues, portsnap is affected, making >>> it >>> impossible to fetch/extract ports. As well as redirecting output in shells >>> eg >>> `echo 'hi'> test` fails every other try. You have the same issue with text >>> editors like `edit` where it fails every other save. There are no issues >>> with >>> `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an O_TRUNC >>> error. >>> >>> Any tips? Otherwise I'll be looking into this today myself. >> >> Just a hint that you could try using DTrace syscall and fbt providers to see >> where >> in kernel (if in kernel) that -512 return value originates. >> > > Update: > > I've traced more and more into the kernel, and currently I have found the > following trace: > >>>> ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) > (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) >>>> vn_truncate() (in sys/kern/vfs_vnops.c:636) >>>> kern_openat() (in sys/kern/vfs_syscalls.c:1043) >>>> kern_open() (in sys/kern/vfs_syscalls.c:1035) >>>> open() (in sys/kern/vfs_syscalls.c:1006) > > ufs_setattr() returns with -1 (EPERM) But not -512, though. > I'll continue to try to find the exact problem. A quick workaround currently > would > probably be to use a different filesystem other than ufs, but then again, I > have > no clue if other filesystems have the same issue. > > Hopefully that trace will help anyone who wants to help out. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
on 20/07/2011 15:34 Julian H. Stacey said the following: > Even if we're too lazy to do anything more, we should at least > document it as a patch to man gcc. Talk to GCC people now? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
HTT vs SMT in x86 SMP topology reporting
Can anybody explain to me why our _x86_ SMP topology discovery and reporting code sometimes reports "HTT" and sometimes "SMT"? As in FreeBSD/SMP: %d package(s) x %d core(s) x %d HTT threads vs FreeBSD/SMP: %d package(s) x %d core(s) x %d SMT threads As I understand, and quoting Wikipedia (I know, I know), SMT stands for simultaneous multithreading and is a generic term for a particular kind of hardware multithreading: http://en.wikipedia.org/wiki/Simultaneous_multithreading The only known (to me) implementation of SMT for x86 is Intel's Hyper-Threading Technology aka HTT aka HT Technology aka hyperthreading: http://en.wikipedia.org/wiki/Hyper-threading http://software.intel.com/en-us/articles/intel-hyper-threading-technology-your-questions-answered/?wapkw=%28Intel+Hyper-Threading+Technology%29 I understand that HTT implementation has evolved over time and there could be some reasons to distinguish HTT as implemented in e.g. Pentium 4 from HTT as implemented in the recent architectures like Nehalem and Sandy Bridge. But I still do not understand why we have to call the latter SMT when Intel calls it HTT. Also, right now things like machdep.hyperthreading_allowed act only on old hyperthreads (what we report as "HTT") but completely ignore the new ones (what we report as "SMT"). I am not sure that this is correct either... Perhaps there are no good reasons to disable HTT on modern CPUs, but the current behavior can definitely be confusing. In the end I would like to propose that we always report Intel HTT as HTT. Or even drop HTT/SMT from "x %d threads" altogether. Whether we should internally distinguish old HTT from new HTT is not clear to me. E.g. I see that for old HTT we bind interrupts only to one processing unit (aka logical processor aka hardware thread) from each hyperthreading pair. Not sure if new HTT is so much better that we shouldn't be doing the same for it. P.S. Also currently distinction between old/new HTT technologies is made based on availability of CPUID leaf 0xB. Not sure if this is entirely accurate for e.g. Atom processors, which we seem to detect as old HTT. A lengthy quote from volume 3A as an illustration: 8.7.7 Performance Monitoring Counters Performance counters and their companion control MSRs are shared between the logical processors within a processor core for processors based on Intel NetBurst microarchitecture. As a result, software must manage the use of these resources. The performance counter interrupts, events, and precise event monitoring support can be set up and allocated on a per thread (per logical processor) basis. See Section 19.19, “Performance Monitoring and Intel Hyper-Threading Technology in Processors Based on Intel NetBurst Microarchitecture,” for a discussion of performance monitoring in the Intel Xeon processor MP. In Intel Atom processor family that support Intel Hyper-Threading Technology, the performance counters (general-purpose and fixed-function counters) and their companion control MSRs are duplicated for each logical processor. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Phenom II 975 BE shows 0 celsius
on 01/08/2011 03:28 Mario Lobo said the following: > Hi to all > > In my desktop machine, I had an AM2+ ASROCK mobo with Phenom II 955 BE that > showed each core temperature perfectly under FBSD 8-STABLE, via > dev.cpu.x.temp. amdtemp.ko loaded. > > Unfortunately this Mobo died and only found AM3 boards for which my phenom > 955 > doesn't fit. So I got an ASUS M4A88T-V EVO with a Phenom II 975 BE. > > Funny thing. An AM3 phenom II fits on an AM2 board but an AM3 board doesn't > accept an AM2/AM2+ phenom II :(. > > Anyway, now, under the very same system, it shows 0 degrees on dev.cpu.x.temp > for all cores. Sorry, I've got lost in all the config changes. So what system do you have now? Can please also provide CPU-related information from dmesg? > I've been looking through k8temp and amdtemp src code. I am definitely not > sure of this but I believe something might have happened to those: > > From k8temp.h > > K10_THERM_REG 0xa4 > K10_THERMTRIP_REG 0xe4 > K10_CURTMP(val)(((val) >> 21) & 0xfff) > K10_THERMTRIP(val) ((val >> 1) & 1) > > From amdtemp.c > > /* > * Register control (K8 family) > */ > #define AMDTEMP_REG0F 0xe4 > #define AMDTEMP_REG_SELSENSOR 0x40 > #define AMDTEMP_REG_SELCORE 0x04 > > /* > * Register control (K10 & K11) family > */ > #define AMDTEMP_REG 0xa4 > > > Output of k8temp -dn: > > CPUID: Vendor: AuthenticAMD, 0x100f43: Model=04 Family=f+1 Stepping=3 > Advanced Power Management=0x1f9 >Temperature sensor: Yes > Frequency ID control: No >Voltage ID control: No > THERMTRIP support: Yes >HW Thermal control: Yes >SW Thermal control: Yes >100MHz multipliers: Yes >HW P-State control: Yes > TSC Invariant: Yes > Temp=c0fef > ThermTrip=1fc00c30 > 0 > > I keep a small win7 partition to test little things like this and see if the > same thing happens there, and it doesn't, so I concluded that the sensors are > there and are working. > > One thing is worth noting though. I have used a free gadget that shows > activity/temp for each core. It worked fine with the previous MB/CPU.That > ALSO > stopped working with this new MB. Like FBSD, it shows 0 degrees for any core > too, although it correctly displays each core load. Most likely that gadget just re-uses OS-provided information. > The only windows tool that correctly shows the temperature are the ASUS tools > that came with the mobo. > > Other than that, everything is working fine! The only thing I had to fix was > the fstab ada location. > > I know this is not a big thing but I got accustomed to keeping an eye on > those > temperatures. > > I have googled for a few days now searching for Thermal register address or > offsets for the Phenom II 975 BE, or anything related to this problem and > found nothing. Every search on AMD site was fruitless. I could not find a > single bit of tech info on this processor there, or any other tech info for > that matter. http://support.amd.com/us/Processor_TechDocs/31116.pdf > Would any one have any pointers/clues/suggestions on this? I would try to add some printfs (or used dtrace - whichever is easier for you) to see what's going on. Or you can even use pciconf to directly sneak a peek at what's reported by the hardware, e.g.: # pciconf -r pci0:0:24:3 0xa4 1c881880 You can read the BKDG to see how to interpret the value - search for F3xA4. See F3xE4 for offset calculation. Hopefully you should be able to see if hardware reports sane value and how the amdtemp ends up reporting 0°C. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Phenom II 975 BE shows 0 celsius
[cc list trimmed] on 01/08/2011 19:23 Jung-uk Kim said the following: > I gave up the DiodeOffset recently because a lot of BIOSes do not set > any meaningful values. Instead, I added a tunable for that. Please > see the attached patch, which is also available from here: > > http://people.freebsd.org/~jkim/amdtemp.diff I haven't tried your patch yet, but already have a few comments :-) - at least on head pci_cfgregread() is public via x86/include/pci_cfgreg.h - I am not sure if you really need it; shouldn't pci_read_config() just work since amdtemp attaches under pci bus? - about erratum 319 - I feel like objecting to amdtemp_force_enable approach; given the wide spread of AM2+ and AM3 in consumer boards, and the very important fact that I have AM2+ and I have never observed (with my own eyes) incorrect reading from amdtemp, and the less important fact that the output of amdtemp is not used for anything critical (for anything at all, in fact) in the base system, and that that would be a kind of POLA violation (which is PITA) - I propose to just print some warning message on the affected systems; at most, export that warning as a sysctl node Finally, I promise to test this patch soon-ish. Thank you for digging into this! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Phenom II 975 BE shows 0 celsius
on 01/08/2011 22:48 Jung-uk Kim said the following: > amdtemp(4) attaches under PCI bus but its sibling on function 2 isn't > easy to address, i.e., hostbN. pci_find_bsf() should help with that. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Phenom II 975 BE shows 0 celsius
on 01/08/2011 22:48 Jung-uk Kim said the following: > I have mixed feeling about this because I own a system with such > CPU/motherboard combo, too. I also believe it works well but errata > is errata. If vendor says we shouldn't use it, then we shouldn't. > In fact, I am just following Linux as an example here but I have no > problem with turning this into a warning message, either. Let's cut a deal :-) If we start using amdtemp for fan control, emergency system shutdown or similar, then we follow the strict path. Until then, while we use amdtemp to amuse users with numbers, let's just print a warning :-) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Phenom II 975 BE shows 0 celsius
on 02/08/2011 00:08 Jung-uk Kim said the following: > On Monday 01 August 2011 04:07 pm, Andriy Gapon wrote: >> on 01/08/2011 22:48 Jung-uk Kim said the following: >>> amdtemp(4) attaches under PCI bus but its sibling on function 2 >>> isn't easy to address, i.e., hostbN. >> >> pci_find_bsf() should help with that. > > I thought about that but it seemed like an overkill because this > driver is strictly MD anyway. :-) It's just that pci_cfgregread() has very low level feel to it, nothing else... -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: DTrace script asserts and kills the other process
on 28/07/2011 07:10 ambrosehuang ambrose said the following:
>> Yuri wrote:
>>
>>> I am trying to run this dtrace script:
>>>
>>> #!/usr/sbin/dtrace -s
>>> pid123:libc::entry
>>> {
>>> self->timestmp[probefunc] = timestmp;
>>> }
>>> pid123:libc::return
>>> /self->timestmp[probefunc] != 0/
>>> {
>>> @function_duration[probefunc] = sum(timestmp -
>>> self->timestmp[probefunc]); timestmp[probefunc] = 0;
>>> }
>>>
>>> which I got from here:
>>> http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html
>>> replacing 123 with the pid of some running process.
>>>
>>> Result: dtrace utility asserts:
>>> Assertion failed: (dpr != NULL), file
>>>
>> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c,
>>> line 751.
>>> Abort trap: 6
>>>
>>> Also the target process is killed too:
>>> Killed: 9
>>>
>>> 8.2-STABLE amd64
>>
>> This is a known issue. You may be able to work around it by
>> letting dtrace start the traced process.
>>
>> There's already a PR about it:
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/158431
>> but the limitation isn't mentioned in the wiki:
>> http://wiki.freebsd.org/DTrace/userland
FYI and benefit: I've committed what should be a fix for this issue, r224632.
>> It's not clear to me if this has worked in the past or if it
>> works for other architectures (the reporter and I are both using
>> amd64, too).
>>
>> Fabian
>>
> I came across the same problem in 8.2-stable , it seemed the problem had
> been there since 8.2-release with userland dtrace integrated. I followed the
> PR185431 and found when dtrace started, it indeed attached to the traced
> process( dpr != NULL), but the traced process died soon, and
> according to the PR, this is "error in error" since the dtrace came accross
> error in dfatal
>
> #3 0x000808d8af2d in dt_proc_lookup (dtp=0x80b841000, P=0x80d7ffb40,
> remove=0)
> at
> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:751
> #4 0x000808d8af92 in dt_proc_destroy (dtp=0x80b841000, P=0x80d7ffb40)
> at
> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:763
> #5 0x000808d8bc6e in dt_proc_hash_destroy (dtp=0x80b841000)
> at
> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:1162
> #6 0x000808daa4b5 in dtrace_close (dtp=0x80b841000)
> at
> /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c:1554
> #7 0x00402775 in dfatal (fmt=0x408572 "no probes %s\n")
> at
> /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:236
> #8 0x00406b2c in main (argc=3, argv=0x7ffed9c0)
> at
> /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1825
> .
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: module_register_init fails, but driver is still loaded?
on 05/08/2011 18:21 Sergey Kandaurov said the following:
> On 4 August 2011 20:23, Garrett Cooper wrote:
>> Hi hackers,
>>I noticed that if anything fails while initializing a driver, the
>> driver stays attached to the kernel as a module instead of being
>> kicked when all references to the driver go to 0. Is this desired
>> behavior (it doesn't seem like it, but I can see potential pros and
>> cons of kicking the driver out of the kernel immediately when a
>> failure state occurs)? I've seen this on 7.2 ~ 9-CURRENT. Example
>> sourcecode and invocation attached below.
>
> Hi.
> I have cooked something that might work, though I don't know how much
> is it correct from locking & cleanup side. Can you try it? Anyway, in its
> current form we cannot return error from module_register_init() because
> it's usually called from SYSINIT, so kldload(8) will say nonsense:
> can't load ./bad_module.ko: No error: 0.
Have you also accounted for a situation where multiple logical modules shared
the
same kernel loadable file? Especially when some modules load successfully while
others fail.
> Index: sys/kern/kern_module.c
> ===
> --- sys/kern/kern_module.c (revision 224471)
> +++ sys/kern/kern_module.c (working copy)
> @@ -112,6 +117,7 @@ module_register_init(const void *arg)
> const moduledata_t *data = (const moduledata_t *)arg;
> int error;
> module_t mod;
> + linker_file_t lf;
>
> mtx_lock(&Giant);
> MOD_SLOCK;
> @@ -123,12 +129,14 @@ module_register_init(const void *arg)
> error = MOD_EVENT(mod, MOD_LOAD);
> if (error) {
> MOD_EVENT(mod, MOD_UNLOAD);
> + lf = mod->file;
> MOD_XLOCK;
> module_release(mod);
> MOD_XUNLOCK;
> printf("module_register_init: MOD_LOAD (%s, %p, %p) error"
> " %d\n", data->name, (void *)data->evhand, data->priv,
> error);
> + linker_release_module(NULL, NULL, lf);
> } else {
> MOD_XLOCK;
> if (mod->file) {
>
>
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: root on zfs almot working for me but ...
on 08/08/2011 09:56 Daniel Braniss said the following: > Hi, > I managed to get boot to load the kernel, but the kernel can't find > the root: > ... > Trying to mount root from zfs:z/root > ROOT MOUNT ERROR: > If you have invalid mount options, reboot, and first try the following from > the loader prompt: > > set vfs.root.mountfrom.options=rw > > and then remove invalid mount options from /etc/fstab. > > Loader variables: > vfs.root.mountfrom=zfs:z/root > vfs.root.mountfrom.options=rw > > and > mountroot> ? > > List of GEOM managed disk devices: > gptid/81e19453-94ff-11e0-afed-6cf049b01360 gpt/disk3 > gptid/81d516e2-94ff-11e0-afed-6cf049b01360 gpt/swap3 > gptid/81cbc503-94ff-11e0-afed-6cf049b01360 > gptid/81b4a09a-94ff-11e0-afed-6cf049 > b01360 gpt/disk2 gptid/81a8c76e-94ff-11e0-afed-6cf049b01360 gpt/swap2 > gptid/81a13b80-94ff-11e0-afed-6cf049b01360 > gptid/818c5da7-94ff-11e0-afed-6cf049 > b01360 gpt/disk1 gptid/818199a3-94ff-11e0-afed-6cf049b01360 gpt/swap1 > gptid/817a78d3-94ff-11e0-afed-6cf049b01360 ada3p3 ada3p2 ada3p1 ada2p3 ada2p2 > ada2p1 ada1p3 ada1p2 ada1p1 gptid/81652d6f-94ff-11e0-afed-6cf049b01360 > gpt/disk0 gptid/815afb70-94ff-11e0-afed-6cf049b01360 gpt/swap0 > gptid/81543d17-94ff-11e0-afed-6cf049b01360 ada3 ada2 ada1 ada0p3 ada0p2 > ada0p1 > ada0 cd0 > > but I don't see any zfs, > > any help/ideas? Is /boot/zfs/zpool.cache present and up-to-date? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Clock stalls on Sabertooth 990FX
on 13/08/2011 20:16 Joe Schaefer said the following: > Brand new machine with a Phenom II X6 1100T and under chronic load > the clock will stop running periodically until the machine eventually > completely > freezes. Note: during these stalls the kernel is still running, the > machine is still > mostly responsive, it's just that the clock is frozen in time. > > I've disabled Turbo mode in the bios and toyed with just about every > other setting but nothing seems to resolve this problem. Based on the > behavior > of the machine (just making buildworld will eventually kill it, upping > the -j flag > just kills it faster), I'm guessing it has something to do with the > Digi+ VRM features > but again nothing I've tried modifying in the bios seems to help. > > I've tried both 8.2-RELEASE and FreeBSD 9 (head). Running head now with > a dtrace enabled kernel. > > Suggestions? On head, start with checking what source is used for driving clocks: sysctl kern.eventtimer When the problem starts using vmstat -i to check interrupt rates and see if any relevant counter gets stuck. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: debugging frequent kernel panics on 8.2-RELEASE
Thanks to the debug that Steven provided and to the help that I received from Kostik, I think that now I understand the basic mechanics of this panic, but, unfortunately, not the details of its root cause. It seems like everything starts with some kind of a race between terminating processes in a jail and termination of the jail itself. This is where the details are very thin so far. What we see is that a process (http) is in exit(2) syscall, in exit1() function actually, and past the place where P_WEXIT flag is set and even past the place where p_limit is freed and reset to NULL. At that place the thread calls prison_proc_free(), which calls prison_deref(). Then, we see that in prison_deref() the thread gets a page fault because of what seems like a NULL pointer dereference. That's just the start of the problem and its root cause. Then, trap_pfault() gets invoked and, because addresses close to NULL look like userspace addresses, vm_fault/vm_fault_hold gets called, which in its turn goes on to call vm_map_growstack. First thing that vm_map_growstack does is a call to lim_cur(), but because p_limit is already NULL, that call results in a NULL pointer dereference and a page fault. Goto the beginning of this paragraph. So we get this recursion of sorts, which only ends when a stack is exhausted and a CPU generates a double-fault. So, of course, Steven is interested in finding and fixing the root cause. I hope we will get to that with some help from the "prison guards" :-) But I also would like to use this opportunity to discuss how we can make it easier to debug such issue as this. I think that this problem demonstrates that when we treat certain junk in kernel address value as a userland address value, we throw additional heaps of irrelevant stuff on top of an actual problem. One solution could be to use a special flag that would mark all actual attempts to access userland address (e.g. setting the flag on entrance to copyin and clearing it upon return), so that in the page fault handler we could distinguish actual faults on userland addresses from faults on garbage kernel addresses. I am sure that there could be other clever techniques to catch such garbage addresses early. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: debugging frequent kernel panics on 8.2-RELEASE
on 18/08/2011 02:15 Steven Hartland said the following: > - Original Message - From: "Andriy Gapon" > >> Thanks to the debug that Steven provided and to the help that I received from >> Kostik, I think that now I understand the basic mechanics of this panic, but, >> unfortunately, not the details of its root cause. >> >> It seems like everything starts with some kind of a race between terminating >> processes in a jail and termination of the jail itself. This is where the >> details are very thin so far. What we see is that a process (http) is in >> exit(2) syscall, in exit1() function actually, and past the place where >> P_WEXIT >> flag is set and even past the place where p_limit is freed and reset to NULL. >> At that place the thread calls prison_proc_free(), which calls >> prison_deref(). >> Then, we see that in prison_deref() the thread gets a page fault because of >> what >> seems like a NULL pointer dereference. That's just the start of the problem >> and >> its root cause. > > Thats interesting, are you using http as an example or is that something thats > been gleaned from the debugging of our output? I ask as there's only one > process > running in each of our jails and thats a single java process. It's from the debug data: p_comm = "httpd" I also would like to ask you to revert the last patch that I sent you (with tf_rip comparisons) and try the patch from Kostik instead. Given what we suspect about the problem, can please also try to provoke the problem by e.g. doing frequent jail restarts or something else that supposedly should hit the bug. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: debugging frequent kernel panics on 8.2-RELEASE
on 18/08/2011 13:35 Steven Hartland said the following: > - Original Message - From: "Andriy Gapon" >>> Thats interesting, are you using http as an example or is that something >>> thats >>> been gleaned from the debugging of our output? I ask as there's only one >>> process >>> running in each of our jails and thats a single java process. >> >> >> It's from the debug data: p_comm = "httpd" > > Hmm, there's only one httpd thats ever run on the machine and thats not in > the jail > its on the raw machine. Probably I have mistakenly assumed that the 'prison' in prison_derefer() has something to do with an actual jail, while it could have been just prison0 where all non-jailed processes belong. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: debugging frequent kernel panics on 8.2-RELEASE
on 18/08/2011 14:11 Andriy Gapon said the following:
> Probably I have mistakenly assumed that the 'prison' in prison_derefer() has
> something to do with an actual jail, while it could have been just prison0
> where
> all non-jailed processes belong.
So, indeed:
(kgdb) p $2->p_ucred->cr_prison
$10 = (struct prison *) 0x807d5080
(kgdb) p &prison0
$11 = (struct prison *) 0x807d5080
(kgdb) p *$2->p_ucred->cr_prison
$12 = {pr_list = {tqe_next = 0x0, tqe_prev = 0x0}, pr_id = 0, pr_ref = 398,
pr_uref = 0, pr_flags = 386, pr_children = {lh_first = 0x0}, pr_sibling =
{le_next
= 0x0, le_prev = 0x0}, pr_parent = 0x0,
pr_mtx = {lock_object = {lo_name = 0x8063007c "jail mutex", lo_flags =
16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, pr_task = {ta_link =
{stqe_next = 0x0}, ta_pending = 0,
ta_priority = 0, ta_func = 0, ta_context = 0x0}, pr_osd = {osd_nslots = 0,
osd_slots = 0x0, osd_next = {le_next = 0x0, le_prev = 0x0}}, pr_cpuset =
0xff0012d65dc8, pr_vnet = 0x0,
pr_root = 0xff00166ebce8, pr_ip4s = 0, pr_ip6s = 0, pr_ip4 = 0x0, pr_ip6 =
0x0, pr_sparep = {0x0, 0x0, 0x0, 0x0}, pr_childcount = 0, pr_childmax = 99,
pr_allow = 127, pr_securelevel = -1,
pr_enforce_statfs = 0, pr_spare = {0, 0, 0, 0, 0}, pr_hostid = 3251597242,
pr_name = "0", '\0' , pr_path = "/", '\0' ,
pr_hostname = "censored", '\0' , pr_domainname = '\0'
, pr_hostuuid = "54443842-0054-2500-902c-0025902c3cb0", '\0'
}
Also, let's consider this code:
if (flags & PD_DEUREF) {
for (tpr = pr;; tpr = tpr->pr_parent) {
if (tpr != pr)
mtx_lock(&tpr->pr_mtx);
if (--tpr->pr_uref > 0)
break;
KASSERT(tpr != &prison0, ("prison0 pr_uref=0"));
mtx_unlock(&tpr->pr_mtx);
}
/* Done if there were only user references to remove. */
if (!(flags & PD_DEREF)) {
mtx_unlock(&tpr->pr_mtx);
if (flags & PD_LIST_SLOCKED)
sx_sunlock(&allprison_lock);
else if (flags & PD_LIST_XLOCKED)
sx_xunlock(&allprison_lock);
return;
}
if (tpr != pr) {
mtx_unlock(&tpr->pr_mtx);
mtx_lock(&pr->pr_mtx);
}
}
The most suspicious thing is that pr_uref is zero in the debug data.
With INVARIANTS we would hit the "prison0 pr_uref=0" KASSERT.
Then, because this is prison0 and because pr_uref reached zero, tpr gets
assigned
to NULL. And then because tpr != pr we try to execute mtx_unlock(&tpr->pr_mtx).
That's where the NULL pointer deref happens.
So, now the big question is how/why we reached pr_uref == 0.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: debugging frequent kernel panics on 8.2-RELEASE
on 17/08/2011 23:21 Andriy Gapon said the following: It seems like everything starts with some kind of a race between terminating processes in a jail and termination of the jail itself. This is where the details are very thin so far. What we see is that a process (http) is in exit(2) syscall, in exit1() function actually, and past the place where P_WEXIT flag is set and even past the place where p_limit is freed and reset to NULL. At that place the thread calls prison_proc_free(), which calls prison_deref(). Then, we see that in prison_deref() the thread gets a page fault because of what seems like a NULL pointer dereference. That's just the start of the problem and its root cause. Then, trap_pfault() gets invoked and, because addresses close to NULL look like userspace addresses, vm_fault/vm_fault_hold gets called, which in its turn goes on to call vm_map_growstack. First thing that vm_map_growstack does is a call to lim_cur(), but because p_limit is already NULL, that call results in a NULL pointer dereference and a page fault. Goto the beginning of this paragraph. So we get this recursion of sorts, which only ends when a stack is exhausted and a CPU generates a double-fault. BTW, does anyone has an idea why the thread in question would "disappear" from the kgdb's point of view? (kgdb) p cpuid_to_pcpu[2]->pc_curthread->td_tid $3 = 102057 (kgdb) tid 102057 invalid tid info threads also doesn't list the thread. Is it because the panic happened while the thread was somewhere in exit1()? is there an easy way to examine its stack in this case? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: debugging frequent kernel panics on 8.2-RELEASE
re to search for the tricks next time I need them :-) Thank you again! > For amd64: > > # Do a backtrace given %rip and %rbp as args > define bt > set $_rip = $arg0 > set $_rbp = $arg1 > set $i = 0 > while ($_rbp != 0 || $_rip != 0) > printf "%2d: pc ", $i > if ($_rip != 0) > x/1i $_rip > else > printf "\n" > end > if ($_rbp == 0) > set $_rip = 0 > else > set $fr = (struct amd64_frame *)$_rbp > set $_rbp = $fr->f_frame > set $_rip = $fr->f_retaddr > set $i = $i + 1 > end > end > end > > document bt > Given values for %rip and %rbp, perform a manual backtrace. > end > > define btf > bt $arg0.tf_rip $arg0.tf_rbp > end > > document btf > Do a manual backtrace from a specified trapframe. > end > > For i386: > > # Do a backtrace given %eip and %ebp as args > define bt > set $_eip = $arg0 > set $_ebp = $arg1 > set $i = 0 > while ($_ebp != 0 || $_eip != 0) > printf "%2d: pc ", $i > if ($_eip != 0) > x/1i $_eip > else > printf "\n" > end > if ($_ebp == 0) > set $_eip = 0 > else > set $fr = (struct i386_frame *)$_ebp > set $_ebp = $fr->f_frame > set $_eip = $fr->f_retaddr > set $i = $i + 1 > end > end > end > > document bt > Given values for %eip and %ebp, perform a manual backtrace. > end > > define btf > bt $arg0.tf_eip $arg0.tf_ebp > end > > document btf > Do a manual backtrace from a specified trapframe. > end > -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Phenom II 975 BE shows 0 celsius
on 02/08/2011 00:06 Jung-uk Kim said the following: > On Monday 01 August 2011 04:10 pm, Andriy Gapon wrote: >> on 01/08/2011 22:48 Jung-uk Kim said the following: >>> I have mixed feeling about this because I own a system with such >>> CPU/motherboard combo, too. I also believe it works well but >>> errata is errata. If vendor says we shouldn't use it, then we >>> shouldn't. In fact, I am just following Linux as an example here >>> but I have no problem with turning this into a warning message, >>> either. >> >> Let's cut a deal :-) >> If we start using amdtemp for fan control, emergency system >> shutdown or similar, then we follow the strict path. Until then, >> while we use amdtemp to amuse users with numbers, let's just print >> a warning :-) > > Okay, here is the new patch (not tested on the affected system yet): > > http://people.freebsd.org/~jkim/amdtemp2.diff Tested the patch - looks good! One comment though: it seems that sensor_offset defaults to zero now. Would it be a good idea to default it to what it previously used to be? On my system the hardware reports the offset correctly (as verified by using independent hardware monitoring logic in Super I/O), so defaulting it to zero is kind of a regression. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
skipping locks, mutex_owned, usb
Yes, the subject sounds quite hairy, so please let me try to explain it.
First, let's consider one concrete function:
static int
ukbd_poll(keyboard_t *kbd, int on)
{
struct ukbd_softc *sc = kbd->kb_data;
if (!mtx_owned(&Giant)) {
/* XXX cludge */
int retval;
mtx_lock(&Giant);
retval = ukbd_poll(kbd, on);
mtx_unlock(&Giant);
return (retval);
}
if (on) {
sc->sc_flags |= UKBD_FLAG_POLLING;
sc->sc_poll_thread = curthread;
} else {
sc->sc_flags &= ~UKBD_FLAG_POLLING;
ukbd_start_timer(sc); /* start timer */
}
return (0);
}
This "XXX cludge" [sic] pattern is scattered around a few functions in the ukbd
code and perhaps other usb code:
func()
{
if (!mtx_owned(&Giant)) {
mtx_lock(&Giant);
func();
mtx_unlock(&Giant);
return;
}
// etc ...
}
I have a few question directly and indirectly related to this pattern.
I. [Why] do we need this pattern?
Can the code be re-written in a smarter (if not to say proper) way?
II. ukbd_poll() in particular can be called from the kdb context (kdb_trap ->
db_trap -> db_command_loop -> etc). What would happen if the Giant is held by a
thread on some other CPU (which would be hard-stopped by kdp_trap)? Won't we
get
a lockup here?
So shouldn't this code actually check for kdb_active?
III. With my stop_scheduler_on_panic patch ukbd_poll() produces infinite chains
of 'infinite' recursion because mtx_owned() always returns false. This is
because
I skip all lock/unlock/etc operations in the post-panic context. I think that
it's a good philosophical question: what operations like mtx_owned(),
mtx_recursed(), mtx_trylock() 'should' return when we actually act as if no
locks
exist at all?
My first knee-jerk reaction was to change mtx_owned() to return true in this
"lock-less" context, but _hypothetically_ there could exist some symmetric code
that does something like:
func()
{
if (mtx_owned(&Giant)) {
mtx_unlock(&Giant);
func();
mtx_lock(&Giant);
return;
}
// etc ...
What do you think about this problem?
Should we re-write ukbd_poll() (and possibly usb code) or should mutex_owned()
be
adjusted?
That question III actually brings another thought: perhaps the whole of idea of
skipping locks in a certain context is not a correct direction?
Perhaps, instead we should identify all the code that could be legitimately
executed in the after-panic and/or kdb contexts and make that could explicitly
aware of its execution context. That is, instead of trying to make _lock,
_unlock, _owned, _trylock, etc do the right thing auto-magically, we should try
to
make the calling code check panicstr and kdb_active and do the right thing on
that
level (which would include not invoking those lock-related operations or other
inappropriate operations).
Thank you very much in advance for your insights and help!
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Large machine test ideas
on 29/08/2011 17:46 Ivan Voras said the following: > On 26/08/2011 19:44, Garrett Cooper wrote: >> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote: >> >> ... >> >>> I think that I'll need a 9-CURRENT snapshot on it to run all 128 CPUs, >>> right? >> >> A 9.0-BETA1 snapshot, yes. > > Well, I'll leave it another half an hour but the 9.9-beta1 shapshot > froze on boot after showing a "SRAT: No CPU found for memory domain 4". > > (all this after the traditional "do-nothing" pause of 10-or so minutes > before displaying the copyright banner). Not sure if hw.memtest.tests tunable has made it into 9.0-BETA1. Setting it to zero should result in skipping the checks. You may also try to capture and share a verbose dmesg, if possible. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Large machine test ideas
on 29/08/2011 18:18 Ivan Voras said the following: > On 29 August 2011 17:15, Andriy Gapon wrote: >> on 29/08/2011 17:46 Ivan Voras said the following: >>> On 26/08/2011 19:44, Garrett Cooper wrote: >>>> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote: >>>> >>>> ... >>>> >>>>> I think that I'll need a 9-CURRENT snapshot on it to run all 128 CPUs, >>>>> right? >>>> >>>> A 9.0-BETA1 snapshot, yes. >>> >>> Well, I'll leave it another half an hour but the 9.9-beta1 shapshot >>> froze on boot after showing a "SRAT: No CPU found for memory domain 4". >>> >>> (all this after the traditional "do-nothing" pause of 10-or so minutes >>> before displaying the copyright banner). >> >> Not sure if hw.memtest.tests tunable has made it into 9.0-BETA1. >> Setting it to zero should result in skipping the checks. > > If it did, to what should I set it? See one line above your question :-) >> You may also try to capture and share a verbose dmesg, if possible. > > I'll take some photos of the screen. No serial console? :( -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kldload dtraceall exec format error
on 02/09/2011 19:55 Charlie Martin said the following: > Yeah, and the same overall Makefile is successfully building in dtrace on the > other part of the product, which is actually using FreeBSD 7-something. I'm > sure there's some tiny difference, but it would sure help to have some idea of > what those dmesg messages are telling me. > > It's not that the .ko's are missing, I checked that first thing. The message was expressly telling you that your cyclic.ko and your kernel are out of sync - built from different sources. > On 2011-09-01 19:04, Brandon Gooch wrote: >> I'm guessing you've read this: >> >> http://wiki.freebsd.org/DTrace >> >> Make certain you've configure your kernel correctly, and that you've >> rebuilt your kernel and modules... >> >> -Brandon > -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
topgit
Anybody uses topgit for FreeBSD or FreeBSD related development? What's your impressions of it? Any peculiarities in the workflow? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Fwd: my git development snapshot(s)
Just decided to follow the global trends and trying to throw all of my local/private changes at you in hope that the "crowd-sourcing magic" might somehow happen :-) This seems definitely easier than carefully producing the patch files and keeping them up-to-date. So, my newly cloned gitorious repository: https://gitorious.org/~avg/freebsd/avgbsd And the first branch of interest: https://gitorious.org/~avg/freebsd/avgbsd/commits/devel-20110915 This is a snapshot of almost all of my local changes to the FreeBSD src tree. Please note that the branch is not intended to be public in the git sense. That is, there will be no linear history - I periodically rebase my changes on top of the svn head and also frequently reshuffle/merge/split commits. The snapshot is not tidied up, there are quite a few commits that should be merged into other commits, some commit messages are not accurate/pretty, etc. The older the commits, the more mature they are supposed to be. Based on the above, no new commits are expected to this snapshot branch. I will produce new snapshot branches from time to time. I am posting this information to this list initially, later I plan to share the code with the wider audience e.g. via hackers@. P.S. This code sharing is made easier for me by git, Gitorious and "git rebase --onto" in particular. Thanks to Fabien Thomas for the initial FreeBSD clone repository at Gitorious! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Fwd: my git development snapshot(s)
on 19/09/2011 01:25 Gleb Kurtsou said the following: > Let me share my experience as well. > > My repo: https://github.com/glk/freebsd-head/ > > I used rebase to keep local branches as well, but no longer do so. Such > setup worked for me at least for two years, I had local changes and > worked on a larger patchset for 7,8-STABLE and CURRENT branches > simultaneously (no longer do it either). But (imho) this approach his > serious drawbacks. The biggest one is that it's hard to check if > regression comes from your code or recently merged upstream code. The > second one: once you screw rebase (merge) you are in big trouble. Both > issues can be worked around by keeping previous master branches, but it > hardly helps: once there are conflicts with upstream or your local > changes get commited upstream it becomes only harder and harder. (I used > to have master-prev-DATE similar to devel-DATE Andriy uses.) I have used both approaches and for now I prefer my current one (obviously). But I am really thinking more and more about topgit. Actually, not necessarily that tool and its implementation, but that kind of concept. With that approach one has an explicitly defined upstream (or upstreams) and explicitly defined local changes plus dependency graph for those changes, plus full history of each change. It's like another dimension to version control, now you have not only versions of a tree, but also versions of changes to the tree. topgit implements that idea by having a separate branch for each (developer defined) change and by stacking those branches on top of each other to get the tree that has all the dependent changes. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Fwd: my git development snapshot(s)
on 19/09/2011 10:41 Andriy Gapon said the following: > on 19/09/2011 01:25 Gleb Kurtsou said the following: >> Let me share my experience as well. >> >> My repo: https://github.com/glk/freebsd-head/ >> >> I used rebase to keep local branches as well, but no longer do so. Such >> setup worked for me at least for two years, I had local changes and >> worked on a larger patchset for 7,8-STABLE and CURRENT branches >> simultaneously (no longer do it either). But (imho) this approach his >> serious drawbacks. The biggest one is that it's hard to check if >> regression comes from your code or recently merged upstream code. The >> second one: once you screw rebase (merge) you are in big trouble. Both >> issues can be worked around by keeping previous master branches, but it >> hardly helps: once there are conflicts with upstream or your local >> changes get commited upstream it becomes only harder and harder. (I used >> to have master-prev-DATE similar to devel-DATE Andriy uses.) > > I have used both approaches and for now I prefer my current one (obviously). > But I am really thinking more and more about topgit. Actually, not > necessarily > that tool and its implementation, but that kind of concept. > With that approach one has an explicitly defined upstream (or upstreams) and > explicitly defined local changes plus dependency graph for those changes, plus > full history of each change. It's like another dimension to version control, > now you have not only versions of a tree, but also versions of changes to the > tree. topgit implements that idea by having a separate branch for each > (developer defined) change and by stacking those branches on top of each other > to get the tree that has all the dependent changes. > Forgot to add: I think that this is quite close to what you do, but with another layer on top of git to make change management easier. Or harder - if it has bugs or limitations ;-) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
SW_WATCHDOG vs new eventtimer code
Alexander, just want to check with you first if the following makes sense. I use SW_WATCHDOG on one of the test machines, which was recently updated to from stable/8 to head. Now it seems to get seemingly random watchdog events. My theory is that this is because of the eventtimer logic. If during idle period we accumulate enough timer ticks and then run all those ticks very rapidly, then the SW_WATCHDOG code may get an impression that it was not patted for many real ticks. Not sure what would be the best way to make SW_WATCHDOG happier/smarter. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: SW_WATCHDOG vs new eventtimer code
on 20/09/2011 23:04 Alexander Motin said the following:
> Hi.
>
> On 20.09.2011 22:19, Andriy Gapon wrote:
>> just want to check with you first if the following makes sense.
>> I use SW_WATCHDOG on one of the test machines, which was recently updated to
>> from stable/8 to head. Now it seems to get seemingly random watchdog events.
>> My theory is that this is because of the eventtimer logic.
>> If during idle period we accumulate enough timer ticks and then run all those
>> ticks very rapidly, then the SW_WATCHDOG code may get an impression that it
>> was
>> not patted for many real ticks.
>> Not sure what would be the best way to make SW_WATCHDOG happier/smarter.
>
> Eventtimer code now set to generate interrupts at least 4 times per
> second for each CPU. As soon as SW_WATCHDOG only handles periods more
> then one second, I would say it should not be hurt. I would try to add
> some debug there to see what's going on (how big the tick busts are).
> I'll try it to do it tomorrow.
Just in case, here is a debugging snippet from a panic that I've got:
...
#12 0x80425d80 in watchdog_fire () at /usr/src/sys/kern/kern_clock.c:858
#13 0x8042603e in hardclock_anycpu (cnt=15761, usermode=Variable
"usermode" is not available.
) at atomic.h:183
#14 0x80660ae5 in handleevents (now=0xff80e3e0b8b0, fake=0) at
/usr/src/sys/kern/kern_clocksource.c:209
#15 0x80661b48 in timercb (et=Variable "et" is not available.
) at /usr/src/sys/kern/kern_clocksource.c:379
#16 0x802cc068 in hpet_intr_single (arg=Variable "arg" is not available.
) at /usr/src/sys/dev/acpica/acpi_hpet.c:258
#17 0x802cc71e in hpet_intr (arg=0xff80e3e0b5b0) at
/usr/src/sys/dev/acpica/acpi_hpet.c:276
#18 0x80444b02 in intr_event_handle (ie=0xfe0002751500,
frame=0xff80e3e0ba30) at /usr/src/sys/kern/kern_intr.c:1428
#19 0x8062f920 in intr_remove_handler (cookie=0xff80e3e0b5b0) at
/usr/src/sys/amd64/amd64/intr_machdep.c:197
#20 0x8069cca9 in lapic_enable_pmc () at
/usr/src/sys/x86/x86/local_apic.c:431
#21 0x8062cc70 in Xapic_isr2 () at apic_vector.S:87
#22 0x80443118 in intr_event_execute_handlers (p=0xfe0002758000,
ie=0xfe0002a5eb00) at /usr/src/sys/kern/kern_intr.c:1244
#23 0x80444164 in ithread_loop (arg=0xfe0002758000) at
/usr/src/sys/kern/kern_intr.c:1269
#24 0x8044053a in fork_exit (callout=0x80444024
, arg=0xfe0002b4f700, frame=0xff80e3e0bc50)
at /usr/src/sys/kern/kern_fork.c:1024
#25 0x8062cb0e in Xint0x80_syscall () at ia32_exception.S:62
#26 0x in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) fr 14
#14 0x80660ae5 in handleevents (now=0xff80e3e0b8b0, fake=0) at
/usr/src/sys/kern/kern_clocksource.c:209
209 while (bintime_cmp(now, &state->nextstat, >=)) {
(kgdb) list
204 }
205 if (runs && fake < 2) {
206 hardclock_anycpu(runs, usermode);
207 done = 1;
208 }
209 while (bintime_cmp(now, &state->nextstat, >=)) {
210 if (fake < 2)
211 statclock(usermode);
212 bintime_add(&state->nextstat, &statperiod);
213 done = 1;
(kgdb) p state->nextstat
$1 = {sec = 90, frac = 15986939599958264124}
(kgdb) p *now
$3 = {sec = 106, frac = 11494276814354478452}
(kgdb) p statperiod
$4 = {sec = 0, frac = 145249953336295682}
(kgdb) fr 13
#13 0x8042603e in hardclock_anycpu (cnt=15761, usermode=Variable
"usermode" is not available.
) at atomic.h:183
183 atomic.h: No such file or directory.
in atomic.h
(kgdb) p cnt
$5 = 15761
(kgdb) p newticks
$6 = 15000
(kgdb) p watchdog_ticks
$7 = 16000
Watchdog timeout was set to ~16 seconds.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: SW_WATCHDOG vs new eventtimer code
on 21/09/2011 11:40 Alexander Motin said the following: > It looks like your system was out for about 15 seconds or for some > reason system uptime jumped 15 seconds forward. Have you done anything > special at the moment or have you seen anything strange in system > behavior? Nope. I just looked away for a second :-) > What timecounter are you using? I see you are using HPET > eventtimer, but on what hardware (is it per-CPU or global)? The timecounter is the new TSC-low. The HPET eventtimer was global, I think. It is an ICH9-based system. > Building kernel with KTR_SPARE2 ktrace enabled should help to collect > valuable info about timers behavior before the crash. I will try to debug this further using your suggestion. Thank you! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Installation of kernel symbols file in a separate directory [Was: Re: Experiences with FreeBSD 9.0-BETA2]
on 28/09/2011 07:23 Arnaud Lacombe said the following:
> available here:
>
> https://github.com/lacombar/freebsd/commit/c1d5c4857361028dc40941273dd2ab9576c687fd
>
> This patch adds a KODIR_SYMBOLS variables which is to the kernel and
> modules .symbols files what the KODIR variable is to the kernel and
> modules files. By default ${KODIR_SYMBOLS} = ${KODIR}.
I think that this patch doesn't cover the case of doing make install in a module
directory (i.e. module built/installed independently from a kernel).
KMODDIR_SYMBOLS should have a default value like KMODDIR does (in bsd.own.mk).
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: how to debug RB_TREE for memory corruption?
on 06/10/2011 19:51 Lev Serebryakov said the following: > Hello, Hackers. > > I'm writing some code, which uses RB_TREE from . At some > momoent, it crashes within REMOVE method with "elm" 0xa5a5a5a5 (I have > malloc() debug options turned on). > So, it seems, that free()ed element presents somewhere in the tree, > am I right? > Ok, I add printing of whole tree BEFORE removal call with simple > recursive function. It doesn't crash and doesn't print any invalid pointers! > > How could it happen!? Tree is perfectly valid at line BEFORE > RB_DELETE() call and crashes with bad pointer in this method! > > I could (theoretically!) belive, that my code forget to delete node > from tree in some situations. But in such case tree printing function > will crash (or print "0xa5a5a5a5" pointer) before RB_DELETE crash! > > Any hints how to debug such strange situation? A trivial check first - does the element on which you call RB_DELETE actually belong to the tree in question? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
