Re: [Patch] [regression] libvgl and r197330 (kbd)
On Fri, Sep 25, 2009 at 8:39 AM, Ed Schouten wrote:
> Hi all,
>
> * Kostik Belousov wrote:
>> > Ah, it seems SDL also calls GIO_KEYMAP. Just rebuilding SDL should fix
>> > this. I promised to add a message to UPDATING as well, so I'll also
>> > mention SDL should be rebuilt as well.
>>
>> I consider this as a very strong argument to keep the existing ioctl
>> as is, and provide new ioctl that takes new table.
>
> I've attached a patch that should restore binary compatibility. I first
> thought this wasn't really needed, because most applications would use
> K_RAW instead of K_XLATE anyway.
>
> Just breaking binary compatibility with kbdcontrol(1) wouldn't have been
> too bad, but it turns out things like SDL use this as well. I've
> attached a patch that should restore binary compatibility. Anyone
> interested in testing this before I commit it to SVN?
Replying to ancient history, it looks like this patch never got
committed? The Debian kFreeBSD folks have run into a similar issue:
http://lists.debian.org/debian-bsd/2011/06/msg00238.html
proposing
===
Upstream could do it properly, without ABI breaking, i.e. by
#define GIO_KEYMAP_OLD _IOR('k', 6, keymap_t)
#define PIO_KEYMAP_OLD _IOW('k', 7, keymap_t)
...
#define GIO_KEYMAP _IO('k', 16)
#define PIO_KEYMAP _IO('k', 17)
===
Something to keep the ABI between 8 and 9 is probably still useful,
even at this juncture.
-Ben Kaduk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Hang During Startup on ZFS Boot (intermittent)
On Friday, June 17, 2011 05:04:44 PM Jung-uk Kim wrote: > I believe the problem was fixed by the following commit: > > http://svn.freebsd.org/changeset/base/222032 Thank you very much. Now for a stupid question, do I just resync my /usr/src with 9-Current and rebuild? Aric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Hang During Startup on ZFS Boot (intermittent)
On Friday 17 June 2011 07:54 pm, Aric Gregson wrote: > Hello, > > I have installed 9-Current from the May 12 2011 iso that was > available and I used a ZFS boot disk and gpt partition as > described. I have a problem on reboot that booting stalls during > listing of the SMP CPU start-up (?) after listing the 15th or 16th > CPU. I must power-down the computer to initiate a new restart once > it stalls. Sometimes I need to power-down two or three times before > it will proceed through the start-up. There does not appear to be > anything written to a log file during failed start-ups. > > How would I go about attempting to find out why this is occurring > (presuming it is not a known problem)? It makes me nervous that > powering down like that will eventually cause a problem preventing > any reboot. I have posted the most recent system log from a boot. > Thanks for any pointers in advance. [SNIP] I believe the problem was fixed by the following commit: http://svn.freebsd.org/changeset/base/222032 Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Hang During Startup on ZFS Boot (intermittent)
Hello, I have installed 9-Current from the May 12 2011 iso that was available and I used a ZFS boot disk and gpt partition as described. I have a problem on reboot that booting stalls during listing of the SMP CPU start-up (?) after listing the 15th or 16th CPU. I must power-down the computer to initiate a new restart once it stalls. Sometimes I need to power-down two or three times before it will proceed through the start-up. There does not appear to be anything written to a log file during failed start-ups. How would I go about attempting to find out why this is occurring (presuming it is not a known problem)? It makes me nervous that powering down like that will eventually cause a problem preventing any reboot. I have posted the most recent system log from a boot. Thanks for any pointers in advance. Aric --- FreeBSD freeenv 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu May 12 15:34:46 UTC 2011 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 --- 2011-06-16 10:40:36 freeenv syslogd kernel boot file is /boot/kernel/kernel 2011-06-16 10:40:36 freeenv kernel Copyright (c) 1992-2011 The FreeBSD Project. 2011-06-16 10:40:36 freeenv kernel Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 2011-06-16 10:40:36 freeenv kernel The Regents of the University of California. All rights reserved. 2011-06-16 10:40:36 freeenv kernel FreeBSD is a registered trademark of The FreeBSD Foundation. 2011-06-16 10:40:36 freeenv kernel FreeBSD 9.0-CURRENT #0: Thu May 12 15:34:46 UTC 2011 2011-06-16 10:40:36 freeenv kernel r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 2011-06-16 10:40:36 freeenv kernel WARNING: WITNESS option enabled, expect reduced performance. 2011-06-16 10:40:36 freeenv kernel CPU: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz (2793.05-MHz K8-class CPU) 2011-06-16 10:40:36 freeenv kernel Origin = "GenuineIntel" Id = 0x206c2 Family = 6 Model = 2c Stepping = 2 2011-06-16 10:40:36 freeenv kernel Features=0xbfebfbff 2011-06-16 10:40:36 freeenv kernel Features2=0x9ee3fd 2011-06-16 10:40:36 freeenv kernel AMD Features=0x2c100800 2011-06-16 10:40:36 freeenv kernel AMD Features2=0x1 2011-06-16 10:40:36 freeenv kernel TSC: P-state invariant, performance statistics 2011-06-16 10:40:36 freeenv kernel real memory = 51539607552 (49152 MB) 2011-06-16 10:40:36 freeenv kernel avail memory = 49642921984 (47343 MB) 2011-06-16 10:40:36 freeenv kernel Event timer "LAPIC" quality 600 2011-06-16 10:40:36 freeenv kernel ACPI APIC Table: <032610 APIC1143> 2011-06-16 10:40:36 freeenv kernel FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs 2011-06-16 10:40:36 freeenv kernel FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 SMT threads 2011-06-16 10:40:36 freeenv kernel cpu0 (BSP): APIC ID: 0 2011-06-16 10:40:36 freeenv kernel cpu1 (AP): APIC ID: 1 2011-06-16 10:40:36 freeenv kernel cpu2 (AP): APIC ID: 2 2011-06-16 10:40:36 freeenv kernel cpu3 (AP): APIC ID: 3 2011-06-16 10:40:36 freeenv kernel cpu4 (AP): APIC ID: 4 2011-06-16 10:40:36 freeenv kernel cpu5 (AP): APIC ID: 5 2011-06-16 10:40:36 freeenv kernel cpu6 (AP): APIC ID: 16 2011-06-16 10:40:36 freeenv kernel cpu7 (AP): APIC ID: 17 2011-06-16 10:40:36 freeenv kernel cpu8 (AP): APIC ID: 18 2011-06-16 10:40:36 freeenv kernel cpu9 (AP): APIC ID: 19 2011-06-16 10:40:36 freeenv kernel cpu10 (AP): APIC ID: 20 2011-06-16 10:40:36 freeenv kernel cpu11 (AP): APIC ID: 21 2011-06-16 10:40:36 freeenv kernel cpu12 (AP): APIC ID: 32 2011-06-16 10:40:36 freeenv kernel cpu13 (AP): APIC ID: 33 2011-06-16 10:40:36 freeenv kernel cpu14 (AP): APIC ID: 34 2011-06-16 10:40:36 freeenv kernel cpu15 (AP): APIC ID: 35 2011-06-16 10:40:36 freeenv kernel cpu16 (AP): APIC ID: 36 2011-06-16 10:40:36 freeenv kernel cpu17 (AP): APIC ID: 37 2011-06-16 10:40:36 freeenv kernel cpu18 (AP): APIC ID: 48 2011-06-16 10:40:36 freeenv kernel cpu19 (AP): APIC ID: 49 2011-06-16 10:40:36 freeenv kernel cpu20 (AP): APIC ID: 50 2011-06-16 10:40:36 freeenv kernel cpu21 (AP): APIC ID: 51 2011-06-16 10:40:36 freeenv kernel cpu22 (AP): APIC ID: 52 2011-06-16 10:40:36 freeenv kernel cpu23 (AP): APIC ID: 53 2011-06-16 10:40:36 freeenv kernel ioapic1: Changing APIC ID to 7 2011-06-16 10:40:36 freeenv kernel ioapic0 irqs 0-23 on motherboard 2011-06-16 10:40:36 freeenv kernel ioapic1 irqs 24-47 on motherboard 2011-06-16 10:40:36 freeenv kernel kbd1 at kbdmux0 2011-06-16 10:40:36 freeenv kernel acpi0: on motherboard 2011-06-16 10:40:36 freeenv kernel acpi0: Power Button (fixed) 2011-06-16 10:40:36 freeenv kernel acpi0: reservation of 0, a (3) failed 2011-06-16 10:40:36 freeenv kernel acpi0: reservation of 10, bff0 (3) failed 2011-06-16
Re: TLS bug?
On Fri, Jun 17, 2011 at 03:31:29PM -0400, Nathaniel W Filardo wrote:
> On Fri, Jun 17, 2011 at 08:07:13PM +0200, Marius Strobl wrote:
> > Using bonnie++ I can't reproduce this (didn't try mysql) but I have
>
> I seem to have good luck reproducing it with "-r 5 -s 10 -x 10" by about the
> third iteration.
Ok, with these parameters I can reproduce it.
>
> > some TLS fixes for libthr I forgot about but could be relevant here
> > (most actually date back to 2008 when the base binutils didn't support
> > GNUTLS for sparc64 so I couldn't test them easily). Could you please
> > give a libthr build with the following patch a try?
> > http://people.freebsd.org/~marius/libthr_sparc64.diff
>
> Concurrent runs both with and without those diffs still asserted.
> Interestingly, libc's .tbss section, even after the assertion, is still full
> of zeros, so it looks like something stranger than a wild-write back to
> .tbss. I'll go diving through the tls allocation code again when I get a
> minute.
>
In combination with the below patch bonnie++ survived 100 iterations
here. I'm not sure what this means though as I don't have much knowledge
about TLS, I merely implemented the necessary relocations. Could be
that malloc() actually requires the initial exec model for variant II.
Unfortunately, it's not documented why it was added for x86.
Jason, can you shed some light on this?
Marius
Index: malloc.c
===
--- malloc.c(revision 219535)
+++ malloc.c(working copy)
@@ -234,7 +234,7 @@
#ifdef __sparc64__
# define LG_QUANTUM 4
# define LG_SIZEOF_PTR3
-# define TLS_MODEL/* default */
+# define TLS_MODEL__attribute__((tls_model("initial-exec")))
#endif
#ifdef __amd64__
# define LG_QUANTUM 4
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: atkbdc broken on current ?
On Friday, May 06, 2011 11:47:33 am John Baldwin wrote: > On Thursday, May 05, 2011 5:04:54 pm Damjan Marion wrote: > > > > On May 5, 2011, at 7:43 PM, John Baldwin wrote: > > > > > On Thursday, May 05, 2011 9:21:04 am Damjan Marion wrote: > > >> > > >> Hi, > > >> > > >> I have issue with old HP DL380G3 server. When I use ILO virtual console > > >> to > > > manage server. Seems that 9-CURRENT fails to detect atkbdc. > > >> When I boot 8.2-RELEASE it works well. > > >> > > >> 8.2 dmesg shows: > > >> > > >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > >> > > >> 9.0: > > >> > > >> atkbdc0: failed to probe at port 0x60 on > > >> isa0 > > >> > > >> Is this a known issue? > > >> > > >> Should I enable some additional outputs, like KBDIO_DEBUG? > > > > > > I suspect this is a resource issue stemming from changes I made to the > > > acpi(4) > > > bus driver quite a while ago to make it use rman_reserve_resource(). Can > > > you > > > capture a full verbose dmesg from 9 along with devinfo -rv and devinfo > > > -ur > > > output from 9? > > > > Here it is: > > > > http://web.me.com/dmarion/atkbdc.txt > > Ohh, hmm. Your BIOS has done "odd" things: > > isab0 pnpinfo vendor=0x1166 device=0x0201 subvendor=0x1166 > subdevice=0x0201 class=0x060100 at slot=15 function=0 handle=\_SB_.PCI0.IBRG > isa0 > I/O ports: > 0x0-0xf > 0x20-0x21 > 0x40-0x43 > 0x60 > 0x61 > 0x64 > 0x80-0x8f > 0xa0-0xa1 > 0xc0-0xdf > 0x4d6 > > Still, I don't know how the ISA bus is actually allocating resources. Can > you add some code to the x86 nexus driver to drop into kdb when it receives > a SYS_RES_IOPORT allocation request from "isa0" and get a stack trace from > DDB and reply with the trace? So I think I just found the explanation for this and I think the change I just committed will fix your system: Author: jhb Date: Fri Jun 17 21:19:01 2011 New Revision: 223207 URL: http://svn.freebsd.org/changeset/base/223207 Log: Don't create a device_t object or parse current resources (via _CRS) for ACPI Device() objects that do not have any device IDs available via the _HID or _CID methods. Without a device ID a device driver cannot attach to the device anyway. Namespace objects that are devices but not of type ACPI_TYPE_DEVICE are not affected. A few BIOSes have also attached a _CRS method to a PCI device to allocate resources that are not managed via a BAR. With the previous code those resources are allocated from acpi0 directly which can interfere with the new PCI-PCI bridge driver (since the PCI device in question may be behind a bridge and its resources should be allocated from that bridge's windows instead). The resources were also orphaned and and would end up associated with some other random device whose device_t reused the pointer of the original ACPI-enumerated device (after it was free'd by the ACPI PCI bus driver) in devinfo output which was confusing. If we want to handle _CRS on PCI devices we can adjust the ACPI PCI bus driver to do that in the future and associate the resources with the proper device object respecting PCI-PCI bridges, etc. Note that with this change the ACPI PCI bus driver no longer has to delete ACPI-enumerated device_t devices that mirror PCI devices since they should in general not exist. There are rare cases when a BIOS will give a PCI device a _HID (e.g. I've seen a PCI-ISA bridge given a _HID for a system resource device). In that case we leave both the ACPI and PCI-enumerated device_t objects around just as in the previous code. Modified: head/sys/dev/acpica/acpi.c head/sys/dev/acpica/acpi_pci.c -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time keeping Issues with the low-resolution TSC timecounter
On Friday 17 June 2011 01:45 pm, Ian FREISLICH wrote: > Jung-uk Kim wrote: > > On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: > > > Jung-uk Kim wrote: > > > > 1481522037 144590601.0098392393 > > > > 1495969404 144473671.0090225853 > > > > > > > > As you can see, HPET increases normally (within errors from > > > > sleep(3) accuracy, syscall overhead, etc.) but TSC-low is > > > > totally erratic (and too low). I don't know how this can > > > > happen, though. > > > > > > > > :-( > > > > > > > > I need some time to figure it out. > > > > > > Even though sleep states have been disabled in the past when on > > > AC power, they seem to have mysteriously been enabled. Perhaps > > > this accounts for the strangeness: > > > > > > /etc/rc.conf > > > performance_cx_lowest="HIGH" > > > performance_cpu_freq="HIGH" > > > economy_cx_lowest="LOW" > > > economy_cpu_freq="HIGH" > > > > > > > > > [mini] /usr/home/ianf $ sysctl dev.cpu > > > dev.cpu.0.%desc: ACPI CPU > > > dev.cpu.0.%driver: cpu > > > dev.cpu.0.%location: handle=\_PR_.CPU0 > > > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > > > dev.cpu.0.%parent: acpi0 > > > dev.cpu.0.freq: 1600 > > > dev.cpu.0.freq_levels: 1600/2000 1400/1750 1333/1533 1166/1341 > > > 1066/1066 932/932 800/600 700/525 600/450 500/375 400/300 > > > 300/225 200/150 100/75 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > > dev.cpu.0.cx_lowest: C3 > > > dev.cpu.0.cx_usage: 0.00% 8.69% 91.30% last 693us > > > dev.cpu.1.%desc: ACPI CPU > > > dev.cpu.1.%driver: cpu > > > dev.cpu.1.%location: handle=\_PR_.CPU1 > > > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > > > dev.cpu.1.%parent: acpi0 > > > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > > > dev.cpu.1.cx_lowest: C3 > > > dev.cpu.1.cx_usage: 0.00% 14.96% 85.03% last 2897us > > > > > > Pulling the power cord and re-inserting it has the cx_lowest > > > correctly trantsition to C1 and then TSC-low behaves properly > > > as the system timecounter. But, time will be wierd when on > > > battery. > > > > > > In light of this, I doubt the patch in your other email will > > > have any effect. Perhaps the thing to do is to have the > > > timecounter code aware of the lowest Cx sleep state and to pick > > > best time counter for that state and to re-evaluate the choice > > > on cx_lowest transitions. > > > > > > ie: TSC-low, HPET or ACPI-fast for C1 and HPET or ACPI-fast for > > > C2 and lower. > > > > Hmm... So, you are saying this CPU model is P-state invariant > > but not C-state invariant (i.e., it stops incrementing in C2 > > state and above). If that's the case, it is really useless for > > timecounter. :-( > > > > What happens if you set it to C2, i.e., > > > > economy_cx_lowest="C2" > > > > In other words, does it really stop in C2-state? > > The folowing is with timecounter=HPET, just to see what the effect > on TSC-low is. It looks like it does stop in C3. > > hw.acpi.cpu.cx_lowest=C3 > [mini] /usr/home/ianf $ sh -c 'count=10; while [ $count -gt 0 ]; do > count=$((count - 1)); sysctl kern.timecounter.tc.TSC-low.counter; > sleep 1; done' kern.timecounter.tc.TSC-low.counter: 722687906 > kern.timecounter.tc.TSC-low.counter: 724328394 > kern.timecounter.tc.TSC-low.counter: 726038743 > kern.timecounter.tc.TSC-low.counter: 727690855 > kern.timecounter.tc.TSC-low.counter: 729245616 > kern.timecounter.tc.TSC-low.counter: 730786569 > kern.timecounter.tc.TSC-low.counter: 732398571 > kern.timecounter.tc.TSC-low.counter: 733910987 > kern.timecounter.tc.TSC-low.counter: 735711469 > kern.timecounter.tc.TSC-low.counter: 737368279 > > hw.acpi.cpu.cx_lowest=C2 > kern.timecounter.tc.TSC-low.counter: 897318486 > kern.timecounter.tc.TSC-low.counter: 909873821 > kern.timecounter.tc.TSC-low.counter: 922416894 > kern.timecounter.tc.TSC-low.counter: 934960462 > kern.timecounter.tc.TSC-low.counter: 947504154 > kern.timecounter.tc.TSC-low.counter: 960050573 > kern.timecounter.tc.TSC-low.counter: 972590754 > kern.timecounter.tc.TSC-low.counter: 985133990 > kern.timecounter.tc.TSC-low.counter: 997677052 > kern.timecounter.tc.TSC-low.counter: 1010220299 > > CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.04-MHz 686-class > CPU) Origin = "GenuineIntel" Id = 0x106c2 Family = 6 Model = 1c > Stepping = 2 > Features=0xbfe9fbffR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x40c39dOVBE> AMD Features2=0x1 > TSC: P-state invariant, performance statistics Thanks for the info, it confirmed my speculation. Somewhere from an Intel manual, I think I read TSC stops when DPSLP# pin is asserted for Core/Core2/Atom processors and I guess that means entering C3 stops TSC. :-( Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SU+J: negative used diskspace (for a while)
On Fri, Jun 17, 2011 at 05:34:15PM +0200, Hans Ottevanger wrote: > Hi, > > I found a possible issue with SU+J on recent versions of -CURRENT. > > After deleting a large file hierarchy (copy of /usr/src, ~1.5 Gbyte), > df reports a negative number of blocks "Used" for a while. > Yes, thank you. This is a known issue and I believe that it is on Jeff's to-do list. - Peter ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS bug?
On Thu, Jun 16, 2011 at 03:53:19AM -0400, Nathaniel W Filardo wrote:
> Atcht; it's late. I forgot to mention that this system is a sparc64 V240
> 2-way SMP machine. It's running a kernel from 9.0-CURRENT r222833+262af52:
> Tue Jun 7 18:47:35 EDT 2011 and a userland from a little later.
>
> Sorry about that.
> --nwf;
>
> On Thu, Jun 16, 2011 at 03:31:38AM -0400, Nathaniel W Filardo wrote:
> > I have a few applications (bonnie++ and mysql, specifically, both from
> > ports) which trip over the assertion in
> > lib/libc/stdlib/malloc.c:/^_malloc_thread_cleanup that
> > > assert(tcache != (void *)(uintptr_t)1);
> >
> > I have patched malloc.c thus:
> >
> > > --- a/lib/libc/stdlib/malloc.c
> > > +++ b/lib/libc/stdlib/malloc.c
> > > @@ -1108,7 +1108,7 @@ static __thread arena_t *arenas_map
> > > TLS_MODEL;
> > >
> > > #ifdef MALLOC_TCACHE
> > > /* Map of thread-specific caches. */
> > > -static __thread tcache_t *tcache_tls TLS_MODEL;
> > > +__thread tcache_t *tcache_tls TLS_MODEL;
> > >
> > > /*
> > > * Number of cache slots for each bin in the thread cache, or 0 if tcache
> > > * is
> > > @@ -6184,10 +6184,17 @@ _malloc_thread_cleanup(void)
> > > #ifdef MALLOC_TCACHE
> > > tcache_t *tcache = tcache_tls;
> > >
> > > +fprintf(stderr, "_m_t_c for %d:%lu with %p\n",
> > > + getpid(),
> > > + (unsigned long) _pthread_self(),
> > > + tcache);
> > > +
> > > if (tcache != NULL) {
> > > - assert(tcache != (void *)(uintptr_t)1);
> > > - tcache_destroy(tcache);
> > > - tcache_tls = (void *)(uintptr_t)1;
> > > + /* assert(tcache != (void *)(uintptr_t)1); */
> > > + if((uintptr_t)tcache != (uintptr_t)1) {
> > > + tcache_destroy(tcache);
> > > + tcache_tls = (void *)(uintptr_t)1;
> > > + }
> >
> > and libthr/thread/thr_create.c thus:
> >
> > > --- a/lib/libthr/thread/thr_create.c
> > > +++ b/lib/libthr/thread/thr_create.c
> > > @@ -243,6 +243,8 @@ create_stack(struct pthread_attr *pattr)
> > > return (ret);
> > > }
> > >
> > > +extern __thread void *tcache_tls;
> > > +
> > > static void
> > > thread_start(struct pthread *curthread)
> > > {
> > > @@ -280,6 +282,11 @@ thread_start(struct pthread *curthread)
> > > curthread->attr.stacksize_attr;
> > > #endif
> > >
> > > +fprintf(stderr, "t_s for %d:%lu with %p\n",
> > > +getpid(),
> > > +(unsigned long) _pthread_self(),
> > > +tcache_tls);
> > > +
> > > /* Run the current thread's start routine with argument: */
> > > _pthread_exit(curthread->start_routine(curthread->arg));
> > >
> >
> > to attempt to debug this issue. With those changes in place, bonnie++'s
> > execution looks like this:
> >
> > >[...]
> > > Writing a byte at a time...done
> > > Writing intelligently...done
> > > Rewriting...done
> > > Reading a byte at a time...done
> > > Reading intelligently...done
> > > t_s for 79654:1086343168 with 0x0
> > > t_s for 79654:1086345216 with 0x0
> > > t_s for 79654:1086346240 with 0x0
> > > t_s for 79654:1086347264 with 0x0
> > > t_s for 79654:1086344192 with 0x0
> > > start 'em...done...done...done...done..._m_t_c for 79654:1086344192 with
> > > 0x41404400
> > > _m_t_c for 79654:1086346240 with 0x40d2c400
> > > _m_t_c for 79654:1086343168 with 0x41404200
> > > _m_t_c for 79654:1086345216 with 0x41804200
> > > done...
> > > _m_t_c for 79654:1086347264 with 0x41004200
> > > Create files in sequential order...done.
> > > Stat files in sequential order...done.
> > > Delete files in sequential order...done.
> > > Create files in random order...done.
> > > Stat files in random order...done.
> > > Delete files in random order...done.
> > > 1.96,1.96,hydra.priv.oc.ietfng.org,1,1308217772,10M,,7,81,2644,7,3577,14,34,93,+,+++,773.7,61,16,,,
> > > ,,2325,74,13016,99,2342,86,3019,91,11888,99,2184,89,16397ms,1237ms,671ms,2009ms,177us,1305ms,489ms,1029
> > > us,270ms,140ms,53730us,250ms
> > > Writing a byte at a time...done
> > > Writing intelligently...done
> > > Rewriting...done
> > > Reading a byte at a time...done
> > > Reading intelligently...done
> > > t_s for 79654:1086343168 with 0x1
> > > t_s for 79654:1086346240 with 0x1
> > > t_s for 79654:1086345216 with 0x1
> > > t_s for 79654:1086347264 with 0x1
> > > t_s for 79654:1086344192 with 0x1
> > > start 'em...done...done...done...done...done...
> > > _m_t_c for 79654:1086347264 with 0x1
> > > _m_t_c for 79654:1086344192 with 0x1
> > > _m_t_c for 79654:1086343168 with 0x1
> > >[...]
> >
> > So what seems to be happening is that the TLS area is being set up
> > incorrectly, eventually: rather than zeroing the tcache_tls value, it is
> > being set to 1, which means no tcache is ever allocated, so when we get
> > around to exiting, the assert trips.
> >
> > Unfortunately, setting a b
Re: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim wrote: > On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: > > Jung-uk Kim wrote: > > > 1481522037144590601.0098392393 > > > 1495969404144473671.0090225853 > > > > > > As you can see, HPET increases normally (within errors from > > > sleep(3) accuracy, syscall overhead, etc.) but TSC-low is totally > > > erratic (and too low). I don't know how this can happen, though. > > > :-( > > > > > > I need some time to figure it out. > > > > Even though sleep states have been disabled in the past when on AC > > power, they seem to have mysteriously been enabled. Perhaps this > > accounts for the strangeness: > > > > /etc/rc.conf > > performance_cx_lowest="HIGH" > > performance_cpu_freq="HIGH" > > economy_cx_lowest="LOW" > > economy_cpu_freq="HIGH" > > > > > > [mini] /usr/home/ianf $ sysctl dev.cpu > > dev.cpu.0.%desc: ACPI CPU > > dev.cpu.0.%driver: cpu > > dev.cpu.0.%location: handle=\_PR_.CPU0 > > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > > dev.cpu.0.%parent: acpi0 > > dev.cpu.0.freq: 1600 > > dev.cpu.0.freq_levels: 1600/2000 1400/1750 1333/1533 1166/1341 > > 1066/1066 932/932 800/600 700/525 600/450 500/375 400/300 300/225 > > 200/150 100/75 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > dev.cpu.0.cx_lowest: C3 > > dev.cpu.0.cx_usage: 0.00% 8.69% 91.30% last 693us > > dev.cpu.1.%desc: ACPI CPU > > dev.cpu.1.%driver: cpu > > dev.cpu.1.%location: handle=\_PR_.CPU1 > > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > > dev.cpu.1.%parent: acpi0 > > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > > dev.cpu.1.cx_lowest: C3 > > dev.cpu.1.cx_usage: 0.00% 14.96% 85.03% last 2897us > > > > Pulling the power cord and re-inserting it has the cx_lowest > > correctly trantsition to C1 and then TSC-low behaves properly as > > the system timecounter. But, time will be wierd when on battery. > > > > In light of this, I doubt the patch in your other email will have > > any effect. Perhaps the thing to do is to have the timecounter > > code aware of the lowest Cx sleep state and to pick best time > > counter for that state and to re-evaluate the choice on cx_lowest > > transitions. > > > > ie: TSC-low, HPET or ACPI-fast for C1 and HPET or ACPI-fast for C2 > > and lower. > > Hmm... So, you are saying this CPU model is P-state invariant but not > C-state invariant (i.e., it stops incrementing in C2 state and > above). If that's the case, it is really useless for > timecounter. :-( > > What happens if you set it to C2, i.e., > > economy_cx_lowest="C2" > > In other words, does it really stop in C2-state? The folowing is with timecounter=HPET, just to see what the effect on TSC-low is. It looks like it does stop in C3. hw.acpi.cpu.cx_lowest=C3 [mini] /usr/home/ianf $ sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1)); sysctl kern.timecounter.tc.TSC-low.counter; sleep 1; done' kern.timecounter.tc.TSC-low.counter: 722687906 kern.timecounter.tc.TSC-low.counter: 724328394 kern.timecounter.tc.TSC-low.counter: 726038743 kern.timecounter.tc.TSC-low.counter: 727690855 kern.timecounter.tc.TSC-low.counter: 729245616 kern.timecounter.tc.TSC-low.counter: 730786569 kern.timecounter.tc.TSC-low.counter: 732398571 kern.timecounter.tc.TSC-low.counter: 733910987 kern.timecounter.tc.TSC-low.counter: 735711469 kern.timecounter.tc.TSC-low.counter: 737368279 hw.acpi.cpu.cx_lowest=C2 kern.timecounter.tc.TSC-low.counter: 897318486 kern.timecounter.tc.TSC-low.counter: 909873821 kern.timecounter.tc.TSC-low.counter: 922416894 kern.timecounter.tc.TSC-low.counter: 934960462 kern.timecounter.tc.TSC-low.counter: 947504154 kern.timecounter.tc.TSC-low.counter: 960050573 kern.timecounter.tc.TSC-low.counter: 972590754 kern.timecounter.tc.TSC-low.counter: 985133990 kern.timecounter.tc.TSC-low.counter: 997677052 kern.timecounter.tc.TSC-low.counter: 1010220299 CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.04-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbff Features2=0x40c39d AMD Features2=0x1 TSC: P-state invariant, performance statistics Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time keeping Issues with the low-resolution TSC timecounter
On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: > Jung-uk Kim wrote: > > 1481522037 144590601.0098392393 > > 1495969404 144473671.0090225853 > > > > As you can see, HPET increases normally (within errors from > > sleep(3) accuracy, syscall overhead, etc.) but TSC-low is totally > > erratic (and too low). I don't know how this can happen, though. > > :-( > > > > I need some time to figure it out. > > Even though sleep states have been disabled in the past when on AC > power, they seem to have mysteriously been enabled. Perhaps this > accounts for the strangeness: > > /etc/rc.conf > performance_cx_lowest="HIGH" > performance_cpu_freq="HIGH" > economy_cx_lowest="LOW" > economy_cpu_freq="HIGH" > > > [mini] /usr/home/ianf $ sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1600 > dev.cpu.0.freq_levels: 1600/2000 1400/1750 1333/1533 1166/1341 > 1066/1066 932/932 800/600 700/525 600/450 500/375 400/300 300/225 > 200/150 100/75 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.0.cx_lowest: C3 > dev.cpu.0.cx_usage: 0.00% 8.69% 91.30% last 693us > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=\_PR_.CPU1 > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.1.cx_lowest: C3 > dev.cpu.1.cx_usage: 0.00% 14.96% 85.03% last 2897us > > Pulling the power cord and re-inserting it has the cx_lowest > correctly trantsition to C1 and then TSC-low behaves properly as > the system timecounter. But, time will be wierd when on battery. > > In light of this, I doubt the patch in your other email will have > any effect. Perhaps the thing to do is to have the timecounter > code aware of the lowest Cx sleep state and to pick best time > counter for that state and to re-evaluate the choice on cx_lowest > transitions. > > ie: TSC-low, HPET or ACPI-fast for C1 and HPET or ACPI-fast for C2 > and lower. Hmm... So, you are saying this CPU model is P-state invariant but not C-state invariant (i.e., it stops incrementing in C2 state and above). If that's the case, it is really useless for timecounter. :-( What happens if you set it to C2, i.e., economy_cx_lowest="C2" In other words, does it really stop in C2-state? Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: graid hit the tree
2011/6/17 Gavin Atkinson : > Is there any chance that mapping from /dev/arX -> /dev/raid/r0 etc could > also be done? so this is lying yet? UPDATING 20110424: ataraid(4) functionality is now supported by the RAID GEOM class. To use it you can load geom_raid kernel module and use graid(8) tool for management. Instead of /dev/arX device names, use /dev/raid/rX. BTW, amr controllers seem not hiding real device, I got somethings like ar0, ad4, ad6 in ATA era. For solving device name issue, usually I use label, but the unhided device make label duplicated, anyway to tune it? Thanks, Buganini ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SU+J: negative used diskspace (for a while)
Hi, I found a possible issue with SU+J on recent versions of -CURRENT. After deleting a large file hierarchy (copy of /usr/src, ~1.5 Gbyte), df reports a negative number of blocks "Used" for a while. I am using a GENERIC kernel (r223184) on an amd64 platform. The hardware is relatively simple: Intel DP965LT mainboard with a Q6600 CPU, 8 Gbyte RAM and two Samsung 501LJ 500 Gbyte SATA disks. The issue can be demonstrated by copying /usr/src to the current directory (cp -R /usr/src .) and running the following script to delete the copy and print the free space at 10 second intervals: #!/bin/sh df . time rm -rf src echo 'src is gone ...' while true do df . | tail -1 sleep 10 done This yields the following output: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ada0s1g 416144900 1612066 381241242 0%/home 51.21 real 1.00 user17.38 sys src is gone ... /dev/ada0s1g 416144900 -164692 383018000-0%/home /dev/ada0s1g 416144900 -165082 383018390-0%/home /dev/ada0s1g 416144900 -246852 383100160-0%/home /dev/ada0s1g 416144900 -246852 383100160-0%/home /dev/ada0s1g 416144900 -246852 383100160-0%/home /dev/ada0s1g 416144900 -64146 382917454-0%/home /dev/ada0s1g 416144900 -64146 382917454-0%/home /dev/ada0s1g 416144900 -64146 382917454-0%/home /dev/ada0s1g 416144900 32910 382820398 0%/home /dev/ada0s1g 416144900 32910 382820398 0%/home So it takes more than a minute before the disk space is back to "normal" values. After disabling journaling (tunefs -j disable) I get the following output: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ada0s1g 416144900 1579284 381274024 0%/home 35.40 real 0.96 user13.32 sys src is gone ... /dev/ada0s1g 416144900 128 382853180 0%/home /dev/ada0s1g 416144900 128 382853180 0%/home /dev/ada0s1g 416144900 128 382853180 0%/home /dev/ada0s1g 416144900 128 382853180 0%/home which is as it should be. The problem also does not occur with journaling enabled when I revert to r222723. Is anybody else seeing these weird phenomena? Could this be related to the recent changes to UFS? Kind regards, Hans Ottevanger ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: udav: vendor 0x0fe6, product: 0x9700
Hi all
I was venturing more on the idea of running this adapter, I decided to
test on OpenBSD 4.9
OpenBSD 4.9 RELEASE is already entry for id 0x8180, equal to FreeBSD
9.0-CURRENT.
What I did (see attached diff file) was to do the same, I tried to do
in freebsd, add the id of the new adapter based on 0x8180
And everything worked as I expected, I managed to get a MAC address
and use the ifconfig output as below:
udav0: flags=8802 mtu 1500
lladdr 00:e0:4c:53:44:58
priority: 0
media: Ethernet none
inet6 fe80::2e0:4cff:fe53:4458%udav0 prefixlen 64 scopeid 0x5
Do I have to specify the id somewhere else, some input to the PHY?
Thanks
2011/6/10 Luiz Gustavo S. Costa :
> Hi Rick,
>
> 2011/6/10 Rick van der Zwet :
>> On 10 June 2011 14:17, Luiz Gustavo S. Costa wrote:
>>> I'm trying to add a new product id [1] to the driver udav and am
>>> having a little trouble.
>>>
>>> At first, this is similar to id 0x8180 and there should be no
>>> problems, but I still can not get a PHY for it.
>>
>> Assuming you mean 0x8181 --looking at your patch-- How do you know
>> they have similar chip-sets? Can you get the full interface
>> description list for both to see if they have the same endpoints:
>> usbconfig dump_all_config_desc
>
> Yes... I will find here the link that describes this:
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commit;h=67158cebde60edb1a11cf4743f1cb9ded847c5fc
>
>>
>>> Can someone help me?
>> ...
>>>About adapter:
>>> [1] http://www.luizgustavo.pro.br/~lgcosta/jp1080/
>>
>> Looking at the picture these kind of USB dongles (various chipsets)
>> tend to die. I suspect the build quality is not that great. Just
>> checking you did check it the device is functioning properly using the
>> official (linux) drivers?
>
> Yes, it's a very cheap adapter, can be found on ebay easily.
>
> And yes, he normally works in linux, I am posting a link to the code
> and it is observed, the only difference are exactly the entries "id"
> of the product.
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=blob;f=drivers/net/usb/dm9601.c;h=5002f5be47be7dcbd95e0fd9cee2a80910046a81;hb=HEAD
>
>>
>> Br. /Rick
>> --
>> http://rickvanderzwet.nl
>>
>
> Thanks
>
>
> --
> /\ Luiz Gustavo S. Costa
> / \ Programmer at BSD Perimeter
> / \ /\/\/\ Visit the pfSense Project
> / \ \ \ http://www.pfsense.org
> -
> BSD da serra carioca, Teresopolis (visite: http://miud.in/Inv)
> Contatos: luizgust...@luizgustavo.pro.br / lgco...@pfsense.org
> Blog: http://www.luizgustavo.pro.br
>
--
/\ Luiz Gustavo S. Costa
/ \ Programmer at BSD Perimeter
/ \ /\/\/\ Visit the pfSense Project
/ \ \ \ http://www.pfsense.org
-
BSD da serra carioca, Teresopolis (visite: http://miud.in/Inv)
Contatos: luizgust...@luizgustavo.pro.br / lgco...@pfsense.org
Blog: http://www.luizgustavo.pro.br
diff -r 18f25adaa9dd dev/usb/if_udav.c
--- a/dev/usb/if_udav.c Fri Jun 17 10:39:30 2011 -0300
+++ b/dev/usb/if_udav.c Fri Jun 17 10:43:51 2011 -0300
@@ -167,7 +167,8 @@
{{ USB_VENDOR_SHANTOU, USB_PRODUCT_SHANTOU_ST268 }, 0 },
{{ USB_VENDOR_SHANTOU, USB_PRODUCT_SHANTOU_ZT6688 }, 0 },
{{ USB_VENDOR_SHANTOU, USB_PRODUCT_SHANTOU_ADM8515 }, 0 },
- {{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_DM9601 }, 0 }
+ {{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_DM9601 }, 0 },
+ {{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_JP1082 }, 0 }
};
#define udav_lookup(v, p) ((struct udav_type *)usb_lookup(udav_devs, v, p))
diff -r 18f25adaa9dd dev/usb/usbdevs
--- a/dev/usb/usbdevs Fri Jun 17 10:39:30 2011 -0300
+++ b/dev/usb/usbdevs Fri Jun 17 10:43:51 2011 -0300
@@ -3744,6 +3744,7 @@
/* Unknown vendor 4 */
product UNKNOWN4 DM96010x8101 DM9601
+product UNKNOWN4 JP1082 0x9700 JP1082
/* Unknown vendor 5 */
product UNKNOWN5 NF_RIC0x0001 NF RIC
diff -r 18f25adaa9dd dev/usb/usbdevs.h
--- a/dev/usb/usbdevs.h Fri Jun 17 10:39:30 2011 -0300
+++ b/dev/usb/usbdevs.h Fri Jun 17 10:43:51 2011 -0300
@@ -3751,6 +3751,7 @@
/* Unknown vendor 4 */
#defineUSB_PRODUCT_UNKNOWN4_DM9601 0x8101 /* DM9601 */
+#define USB_PRODUCT_UNKNOWN4_JP1082 0x9700 /* DM9601 */
/* Unknown vendor 5 */
#defineUSB_PRODUCT_UNKNOWN5_NF_RIC 0x0001 /* NF RIC */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: graid hit the tree
On Fri, Jun 17, 2011 at 6:09 AM, Gavin Atkinson wrote: > On Thu, 2011-03-24 at 23:48 +0200, Alexander Motin wrote: >> Hi. >> >> I've just committed the new GEOM-based software RAID driver (graid) into >> the HEAD [1]. Brave testers are welcome. :) >> >> 1. http://svn.freebsd.org/viewvc/base?view=revision&revision=219974 > > One question. > > I'm very happy with the performance of the ahci subsystem, it is > measurably faster against the old ATA subsystem on modern hardware. I > also really appreciate the compatibility shims to aid migration from the > adX style numbering to adaX. On every system I've migrated so far, this > mapping has worked flawlessly. > > Is there any chance that mapping from /dev/arX -> /dev/raid/r0 etc could > also be done? > > One thing that I have found is that it can be hard to determine from the > dmesg exactly where raid partitions will appear. It would be wonderful > if devices similar to the "adX" devices could be made, for any graid > devices found. For this case, would it make more sense to advise folks to use devfs.conf ? Otherwise one would need to tell geom to talk ataraid a bit, which may or may not confuse some consumers. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: graid hit the tree
On Thu, 2011-03-24 at 23:48 +0200, Alexander Motin wrote: > Hi. > > I've just committed the new GEOM-based software RAID driver (graid) into > the HEAD [1]. Brave testers are welcome. :) > > 1. http://svn.freebsd.org/viewvc/base?view=revision&revision=219974 One question. I'm very happy with the performance of the ahci subsystem, it is measurably faster against the old ATA subsystem on modern hardware. I also really appreciate the compatibility shims to aid migration from the adX style numbering to adaX. On every system I've migrated so far, this mapping has worked flawlessly. Is there any chance that mapping from /dev/arX -> /dev/raid/r0 etc could also be done? One thing that I have found is that it can be hard to determine from the dmesg exactly where raid partitions will appear. It would be wonderful if devices similar to the "adX" devices could be made, for any graid devices found. Thanks, Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwn does not associates
On Fri, 17 Jun 2011 10:25:46 +0200 Bernhard Schmidt wrote: On Friday, June 17, 2011 09:36:46 rm...@free.fr wrote: >> >> hi all, >> >> since a month the wireless card of the E6400 Dell does not associate >> with the access point. >> it used to work fine, before. >> the config is exactly the same: >> iwn5150fw + iwn + wpa_supplicant => tkip. >> >> starting wpa_supplicant associates a few seconds and reverts to no carrier. >> >> here is what i get: >> sysctl dev.iwn.0.debug=1 >> >> iwn_notif_intr: scanning channel 7 status 1 >> >> ifconfig wlan0 >> ... >> status: no carrier >> ssid MyDomain channel 7 (2442 MHz 11g) >> regdomain ETSI country FR authmode OPEN privacy OFF txpower 30 >> bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 >> roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 >> >> >> thanks in advance for your help. > >Are you running the latest current? >This is a 5350? yes, head r223138 >Can you post your configuration (rc.conf)? sure but nothing is configured in rc.conf except em0 when needed. i join it anyway. > >If you have a 'ifconfig wlan0 channel 7' somewhere, drop it, I'm aware >of an issue regarding fixed channels, but found no clean solution yet. > >You might also want to try 'ifconfig wlan0 -ht', it might be related >to the recent introduction of 11n support for iwn(4). changing the channel does nothing else, nor 'ht' too. setting channel 11 or any channel gives the same result, association for about 30 sec, and lost of carrier. Best Regards Raoul rm...@free.fr ># Enable network daemons for user convenience. ># Please make all changes to this file, not to /etc/defaults/rc.conf. ># pour cacher les commandes exécutées ajouter dans rc: set -x >rc_debug="NO" >#rc_info="YES" >dumpdev="/dev/ada0s3b" >dumpdir="/var/crash" >savecore_flags="-vz" >#apmd_enable="YES" >firewall_enable="NO" # Set to YES to enable firewall functionality >allscreens_flags="-m on" >#amd_enable="NO" # Run amd service with $amd_flags (or >NO). >defaultrouter="192.168.0.255" >entropy_file="YES" >#firewall_enable="YES" # Set to YES to enable firewall functionality >firewall_flags="" # Flags passed to ipfw when type is a file >firewall_logging="YES" # Set to YES to enable events logging >firewall_quiet="NO"# Set to YES to suppress rule display >firewall_script="/etc/rc.firewall" # Which script to run to set up the firewall >firewall_type="SIMPLE" # Firewall type (see /etc/rc.firewall) >font8x14="iso-8x14" >font8x16="iso-8x16" >font8x8="iso-8x8" >gateway_enable="YES" >hostname="MyHost" >#ifconfig_em0="DHCP" >#ifconfig_em0="inet 192.168.1.2 192.168.1.255 netmask 255.255.255.0" # media >100baseTX >inetd_enable="YES" >ipv6_enable="YES" >#gif_interfaces="gif0" >#gifconfig_gif0="192.168.0.2 11.22.33.44" >#ifconfig_gif0_ipv6="inet6 2001:::::2 ># 2001:::::1 prefixlen 128" ># ipv6_defaultrouter="2001:::::1" >keymap="fr.iso.acc" >ldconfig_insecure="YES" >ldconfig_paths="/usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib >/usr/compat/linux/lib" >ldconfig_paths_aout="/usr/lib/compat/aout /usr/X11R6/lib/aout >/usr/local/lib/aout" >linux_enable="YES" >lpd_enable="YES" # Run the line printer daemon. >lpd_program="/usr/sbin/lpd"# path to lpd, if you want a different one. >moused_enable="YES" >#moused_enable="NO" >moused_type="ps/2" >natd_enable="YES" >#nfs_client_enable="YES" >#nfs_reserved_port_only="YES" >#nfs_server_enable="YES" >portmap_enable="YES" >#sendmail_enable="YES" >sshd_enable="YES" >usbd_enable="YES" >ntpdate_enable="YES" >ntp_hosts="195.145.119.188" >#ntpdate_flags="ntp1.t-online.de" >#kern_securelevel="1" >#kern_securelevel_enable="YES" >mixer_enable="YES" # preserve your behaviour through reboot >fusefs_enable="YES" >#powerd_enable="YES" >#powerd_flags="-a hiadaptive" ># wlans_ath0="wlan0" ># vap_create_wlan0="wlanmode sta country US indoor" ># ifconfig_wlan0="WPA DHCP" ># ifconfig_bge0_alias0="inet6 2001:418:1::40/64" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwn does not associates
On Friday, June 17, 2011 09:36:46 rm...@free.fr wrote: > > hi all, > > since a month the wireless card of the E6400 Dell does not associate > with the access point. > it used to work fine, before. > the config is exactly the same: > iwn5150fw + iwn + wpa_supplicant => tkip. > > starting wpa_supplicant associates a few seconds and reverts to no carrier. > >here is what i get: > sysctl dev.iwn.0.debug=1 > > iwn_notif_intr: scanning channel 7 status 1 > > ifconfig wlan0 > ... > status: no carrier > ssid MyDomain channel 7 (2442 MHz 11g) > regdomain ETSI country FR authmode OPEN privacy OFF txpower 30 > bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 > roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 > > > thanks in advance for your help. Are you running the latest current? This is a 5350? Can you post your configuration (rc.conf)? If you have a 'ifconfig wlan0 channel 7' somewhere, drop it, I'm aware of an issue regarding fixed channels, but found no clean solution yet. You might also want to try 'ifconfig wlan0 -ht', it might be related to the recent introduction of 11n support for iwn(4). -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: two issues after upgrading to a more up-to-date HEAD
On Thu Jun 16 11, Alexander Best wrote: > hi there, i reverted my kernel back to r222890. everything works fine now and both issues i mentioned below dissapeared. i also discovered another issue with the more recent kernel: i was getting errno -128 with a lot of apps. but only the first time i ran them. e.g. with git: 1) -128 2) OK 3) -128 4) OK 5) ... the same with stuff like ./configure or ee(1). first time failures while running or saving; second time it works. this as well was fixed by reverting back to r222890. cheers. alex > > i'm running HEAD on amd64. yesterday i updated my kernel to r223109. i'm now > seeing two issues, which weren't there beforehand: > > 1) > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-7 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-8 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) > xpt_action_default: CCB type 0xe not supported > xpt_action_default: CCB type 0xe not supported > xpt_action_default: CCB type 0xe not supported > cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > SMP: AP CPU #1 Launched! > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: cd present [2291664 x 2048 byte records] > > ^^ i suspect the xpt_action_default messages have been introduced by the > recent > CAM changes. they appear to be harmless though. > > 2) > dumpon: ioctl(DIOCSKERNELDUMP): Device not configured > /etc/rc: WARNING: unable to specify /dev/label/swapfs as a dump device > > /dev/label/swapfs is a perfect swap partition and worked without any problems > beforehand. specifying the device node instead of the label makes no > difference: > > taku% dumpon /dev/ada1p1 > dumpon: ioctl(DIOCSKERNELDUMP): Device not configured > otaku% gpart show > => 34 488394988 ada0 GPT (232G) > 34128 1 freebsd-boot (64k) > 162 16777216- free - (8.0G) >16777378 471617644 3 freebsd-ufs (224G) > > =>34 1953525101 ada1 GPT (931G) > 3420971520 1 freebsd-swap (10G) > 20971554 4194304 2 freebsd-ufs (2.0G) > 25165858 1928359277 3 freebsd-ufs (919G) > > otaku% glabel status > Name Status Components > label/boot N/A ada0p1 > gptid/e52df583-e446-11de-bb92-000fb58207c8 N/A ada0p1 > ufs/rootfs N/A ada0p3 > label/swapfs N/A ada1p1 > ufs/varfs N/A ada1p2 > ufs/usrfs N/A ada1p3 > iso9660/Futurama Season 6 Ep 1-8 720p N/A cd0 > > cheers. > alex > > -- > a13x -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
iwn does not associates
hi all, since a month the wireless card of the E6400 Dell does not associate with the access point. it used to work fine, before. the config is exactly the same: iwn5150fw + iwn + wpa_supplicant => tkip. starting wpa_supplicant associates a few seconds and reverts to no carrier. here is what i get: sysctl dev.iwn.0.debug=1 iwn_notif_intr: scanning channel 7 status 1 ifconfig wlan0 ... status: no carrier ssid MyDomain channel 7 (2442 MHz 11g) regdomain ETSI country FR authmode OPEN privacy OFF txpower 30 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 thanks in advance for your help. Best regards raoul rm...@free.fr ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
