Re: serial/ulscom: response timeout using pySerial/esptool.py
ox (old Z77 based > IvyBridge ASRock crap), a > couple of Lenovo T560 running 14-STABLE and several Fujitsu Esprimo > Q5XX boxes there is always > this weird error message, but in very rare cases I get connection. > > Only exception: the Fujsitus Celsius 7XX workstation (14-STABLE, last > complied today noon). No > matter what ESP32, no matter what vendor, no matter what cablin used: > connection is established > at any BAUD rate issued at any time. Not one single failure as shown > above in any session (I > checked several tenth times)! > > Now I'm out of ideas and I suspect the CP210X ulscom serial driver to > have trouble with most > onboard serial chipsets. > > Can anyone help me track down this issue? Is there anything I could have > missed? > > I drives me nuts ... > > Thanks in advance, > > Oliver > > > -- > O. Hartmann -- - Tom
Re: diff(1) goes into cpu-hogging endless loop
On Sat, Mar 25, 2023 at 09:55:14PM +, Jamie Landeg-Jones wrote: > Hi, A "diff" of 2 files: > > 1 77,933,904 bytes > 2 63,013,818 bytes > > , goes into an endless loop, whilst "gdiff" completes the operation in > about 5 seconds. > > I tested using the latest "diff" from current, and get the same result. > > Splitting both files into 10Mb chunks, and diffing these was successful. > > A ktrace of the "diff" actually stops producing any output after about > 5 seconds, whilst the cpu looping continues. > > Any ideas on what to do next? Does anyone else get the same result? > > The files are just utf-8 freebsd git logs, and are available here if > anyone would like to test: > > http://www.catflap.org/jamie/1.xz (13,282,864 bytes) > http://www.catflap.org/jamie/2.xz (12,221,164 bytes) > > Cheers, Jamie My guess is that you are hitting a worst case in the stone algorithm. I have a WIP review to integrate the Myers algorithm from libdiff here: https://reviews.freebsd.org/D36860 - Tom
Re: [HEADSUP] making /bin/sh the default shell for root
On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote: > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > > Hello, > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > For years now, csh is the default root shell for FreeBSD, csh can be > > confusing > > as a default shell for many as all other unix like settled on a bourne shell > > compatible interactive shell: zsh, bash, or variant of ksh. > > > > Recently our sh(1) has receive update to make it more user friendly in > > interactive mode: > > * command completion (thanks pstef@) > > * improvement in the emacs mode, to make it behave by default like other > > shells > > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > > * support for history as described by POSIX. > > > > This makes it a usable shell by default, which is why I would like to > > propose to > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > > > If no strong arguments has been raised until October 15th, I will make this > > proposal happen. > > > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > I think this is fine. I would also be fine with either removing 'toor' from > the > default password file or just leaving it as-is for POLA. (I would probably > prefer removing it outright.) I support both of these suggestions, when I first installed FreeBSD ~2006 toor already felt like a strange an anachronism. - Tom
[no subject]
r...@freebsd.org Bcc: Subject: Re: How to enable tcp bbr in FreeBSD??? Reply-To: In-Reply-To: <6042155a-297b-d85e-1d64-24d93da32...@gmail.com> ... snip ... > > Maybe it is not ready for prime time, i do not know why it is not in the > default build. > Maybe ask the committer. > I have added rrs@ in cc and the freebsd-transport list. Does anyone know if there are plans to enable alternate TCP stacks in generic? Is there a stability point we need to hit first? - Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ThinkPad: reboots after successful shutdown -p
On Mon, Nov 18, 2019 at 11:47:18AM -0800, Oleksandr Tymoshenko wrote: > Bjoern A. Zeeb (bzeeb-li...@lists.zabbadoz.net) wrote: > > On 18 Nov 2019, at 7:14, Xin Li wrote: > > > > > Hi, > > > > > > I recently noticed that if I do a 'shutdown -p' from -CURRENT, the > > > system would shut down and seemingly powered off, then it would > > > restart > > > after about 5-10 seconds. > > > > Interesting. I have the opposite problem that a reboot does a shutdown > > but never resets (also no reset from ddb>). I’ve seen this on the > > X270 and the T480. > > I had this issue on my Thinkpad too. The "solution" was to disable > bluetooth chip in BIOS. I didn't try to find the root cause of this > behavior. There was a related bluetooth update in September after which my x270 was able to reboot. You might want to reenable and try again - [tj] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: hang up with r352239 and r352386 with i5-7500
On Mon, Sep 16, 2019 at 01:24:12PM +0200, Niclas Zeising wrote: > On 2019-09-16 13:09, Masachika ISHIZUKA wrote: > >Hi. > > > >My machine (with core i5-7500) is hangup when loading i915kms.ko > > on r352239 and r352386 (1300047). > >This machine was working good with r351728 (1300044). > > > >/etc/rc.conf has the following line. > > kld_list="i915kms.ko" > > > >It is good wowking with core i7-4500U on r352239 (1300047). > > > > Hi! > Which version of drm-current are you using? Have you recompiled it > after updating the kernel? What happens if you change to > kld_list="/boot/modules/i915kms.ko"? > > There is a patch here: > https://github.com/FreeBSDDesktop/kms-drm/pull/175/commits/7b8fab2461262b22f64425146b60608bb0e0240d > > that might solve the issue, can you apply that and recompile > drm-current-kmod and see if it works? Hi Niclas, I can report that the above patch fixes lock ups when loading i915kms on my x270 - [tj] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: wlan can't discover known networks after relocating
On Tue, Sep 17, 2019 at 04:36:28PM +, Poul-Henning Kamp wrote: > > In message <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org>, Johannes > Lundber > g writes: > > >For a long time now I have had this problem with iwm and wlan0. Whenever > >I move between work and home it won't reconnect automatically and I have > >to do wlan0 scan manually for it to pick up the different network. > > I suffer from the dreaded "reason=0" when I move inside my house: > > > scan > OK > <3>CTRL-EVENT-SCAN-RESULTS > <3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' > freq=2452 MHz) > <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:3d:a2:e9 reason=0 > <3>CTRL-EVENT-SCAN-RESULTS > <3>Trying to associate with 6c:3b:6b:ab:ce:d4 (SSID='Palombia' > freq=2412 MHz) > <3>Associated with 6c:3b:6b:ab:ce:d4 > > a2:e9 is the loudest AP here in my office, but my I have been in the > other end of the house iwn consistently fails to associate with it and > and keeps picking the weaker AP in the far end. > > Eventually (hours!) it disconnects from the weaker ap, also with > "reason=0" and gets it right: > > <3>WPA: Group rekeying completed with 6c:3b:6b:ab:ce:d4 [GTK=CCMP] > <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:ab:ce:d4 reason=0 > <3>CTRL-EVENT-SCAN-RESULTS > <3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' > freq=2452 MHz) > <3>Associated with 6c:3b:6b:3d:a2:e9 > <3>WPA: Key negotiation completed with 6c:3b:6b:3d:a2:e9 [PTK=CCMP > GTK=CCMP] > <3>CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:3d:a2:e9 completed > [id=3 id_str=] > <3>WPA: Group rekeying completed with 6c:3b:6b:3d:a2:e9 [GTK=CCMP] > > And yes, working roaming would be nice too... I have the problem that when roaming networks become disabled $ wpa_cli Selected interface 'wlan0' Interactive mode > list_networks network id / ssid / bssid / flags 0 network1any [CURRENT] 1 network2 any[DISABLED] 2 network3 any[DISABLED] 3 network4 any[DISABLED] 4 network5 any[DISABLED] Selected interface 'wlan0' I address this by doing network_enable x in wpa_cli and it all comes back. I asked Adrian about this in the past, but it needs some debugging to pin down. - [tj] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Rotating (efi) framebuffer
On Thu, May 02, 2019 at 09:06:28AM -0700, Johannes Lundberg wrote: > Hi > > I have a Lenovo Ideapad where the screen is rotated 90 degrees and I > can't rotate it to landscape mode until I'm in X. How many of you are in > the same situation and would like a fix? Seeing how development is going > with small (tiny) computers it will probably be more and more common > with ultra portables having a "phone screen" which most likely is in > portrait mode by default. This also applies to embedded and home brew / > prototype devices. > > It would certainly be nice if we could have a boot time parameter that > could rotate the framebuffer (just as a data point, I'm pretty sure > Linux can do this). How many would be interested in this? Is there > anyone working on this atm? Not sure I will have the time to develop > this all of my own but thought I'd check the interest at least. Perhaps > a GSoC project? > This is an issue on the GPD Pocket and many other devices that use a tablet screen. A boot parameter for this would be fine, Linux does it with a parameter. A quick search shows it is probably: 'fbcon=rotate:1' I think you could probably detect that the dimensions are swapped, i.e. taller than you are wide, but there should still be a parameter to allow manual config. - [tj] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: axp288 on Intel HW
On Thu, Nov 22, 2018 at 06:17:45AM +0100, Emmanuel Vadot wrote: > > Hi, > > Allwinner PMIC on X86, interesting :) > > On Fri, 16 Nov 2018 08:51:31 + > Johannes Lundberg wrote: > > > Hi > > > > I have a Lenovo Ideapad Miix 310 that has a Intel CherryTrail CPU and it > > runs FreeBSD quite nicely (with accelerated graphics). What I'm missing is > > battery life status.. > > > > I can get this information using smb (for some reason i2c just returns > > error sending start condition) > > smbmsg -f /dev/smb6 -s 0x68 -c 0xB9 -i 1 -F %d > > > > In emergency this works but it would be nice to have a kernel driver for > > it. > > > > I found the axp2xx driver for Allwinner in the tree. Would it be possible > > to share this with amd64 with not too much effort? > > The first step would be to add acpi attach functions (no idea how this > works), then compare the registers with the pmics supported by the > axp2xx driver to check what regulators are present and controllable (if > any) and also checking the registers for talking to the battery > controller part. > I don't see why it wouldn't work but I haven't checked details on how > supported chips differs with this one. > > > > > If not, all I'm really interested in is battery status so I might just hack > > together a simple driver for that report values to hw.acpi.battery (because > > I don't think there is a sysctl for battery info that aggregates different > > sources?) > > We don't have a generic battery/power supply framework yes. On an ACPI there is an IOCTL that will collate battery information from anything in the battery devclass. There is an acpi_battery_register function, but what it actually does is set up sysctls. I have a patch to land (hopefully this week) that you would need first. I have a driver for a maxim fuel gauge on a unreasonably complicated laptop that includes an example of what you have to do to be a battery: https://github.com/adventureloop/gpdpocket/blob/master/chvpower/chvpower.c#L148 To support battery on arm (say for the pinebook) we need a more general system. I plan to extract out the current battery code from acpi as a first attempt at this. - [tj] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Panic on RPI boot with revision 335282
I get an: panic: Assertion zone->uz_flags & UMA_ZONE_PCPU failed at /media/swan/src.svn/sys/vm/uma_core.c:2239 A one month old kernel runs fine, uma_core.c was edited at that location 9 days ago ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange ARC/Swap/CPU on yesterday's -CURRENT
Hi All, On 11/03/2018 13:43, Jeff Roberson wrote: [snip] > > Hi Folks, > > This could be my fault from recent NUMA and concurrency related work. I > did touch some of the arc back-pressure mechanisms. First, I would like > to identify whether the wired memory is in the buffer cache. Can those > of you that have a repro look at sysctl vfs.bufspace and tell me if that > accounts for the bulk of your wired memory usage? I'm wondering if a > job ran that pulled in all of the bufs from your root disk and filled up > the buffer cache which doesn't have a back-pressure mechanism. Then arc > didn't respond appropriately to lower its usage. > > Also, if you could try going back to r328953 or r326346 and let me know > if the problem exists in either. That would be very helpful. If anyone > is willing to debug this with me contact me directly and I will send > some test patches or debugging info after you have done the above steps. > > Thank you for the reports. > > Jeff [snip] I'm seeing this on 11.1 stable r330126 with 32G of memory. I have two physical storage devices (one SSD, one HD) each a separate ZFS pool and I can reproduce this fairly easily and quickly with: cp -r The directory being copied has about 25G (from du -sg), I end up with 16G wired after starting with less than 1G. After the copy: sysctl vfs.bufspace --> 0 Out of curiosity I copied it back the other way and drove the wired memory to 26G during the copy falling back to 24G once the copy finished, with vfs.bufspace at 0. I'm not really in a good position to roll back to r328953 (or anything much earlier), my graphics HW (i915) needs something pretty recent. I am running a custom kernel (I dropped a lot of the newtwork interfaces), so if you need more info I'm willing to help, as long as you explain what you need in short words :). (I'm not very familiar with FreeBSD kernel work or sysadmin.) Regards, -- Tom Rushworth ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panics in network stack in 12-current
Hamza Sheikh wrote: I may have encountered something similar on an EdgeRouter Lite running r317256. It's serving as network gateway at home. After some time the WAN connection goes dead. It starts working with either (a) reconnecting the network cable or (b) pinging any IP on the internet from that box. On rare occasions I had to reboot to get it to work. it doesn't sound much like my problem. i had no network issues until the system would suddenly panic and reboot. removing FLOWTABLE from my kernel might have fixed it, but it is too early to tell as I have yet to discover a reproducible way to trigger the bug. I'm still new to FreeBSD and don't know how to collect relevant information or whether to even determine if my issue is related to Andrey's. Any help is really appreciated. My setup is documented in detail in a blog post[0] if it helps. You probably don't want to hear this, but if you are new to FreeBSD, maybe you shouldn't be running current. I probably shouldn't running current and I have 35 years of BSD experience. I do it as a way of contributing to the project by alpha-testing new code when I have time. Brendan Gregg has some very good material on his site that might help you learn to collect useful info about what is going on inside your systems. http://www.brendangregg.com/Perf/freebsd_observability_tools.png http://www.brendangregg.com/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panics in network stack in 12-current
Andrey V. Elsukov wrote: On 27.04.2017 08:42, Tom Uffner wrote: Tom Uffner wrote: Andrey V. Elsukov wrote: I think the most of these panics should be fixed in r315956. thanks. I'll give it a try and report back as soon as I have a result. r315956 panicked about 22 min after boot. failed to dump a core. Why not update to the latest revision? Probably this is flowtable related, don't think it is usable. Anyway we need the trace to determine the cause. Also it seems you have VIMAGE enabled. This also have some known panics. attached is a text dump from this version core.txt.6.bz2 Description: Binary data ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panics in network stack in 12-current
Andrey V. Elsukov wrote: On 27.04.2017 08:42, Tom Uffner wrote: r315956 panicked about 22 min after boot. failed to dump a core. Why not update to the latest revision? I did several times a while ago, but didn't get a panic free system. I was hoping to bisect the point the point where the problem actually occurred and maybe send a patch instead of just begging for help. trouble was, I got down to a small number of revisions and none of them had any changes that looked even remotely related to my problem. I'll give today's HEAD a try. Probably this is flowtable related, don't think it is usable. Anyway we need the trace to determine the cause. Also it seems you have VIMAGE enabled. This also have some known panics. OK, I will also try disabling flowtable. Not sure about VIMAGE. I don't have it specifically enabled, but I don't have it specifically disabled either if it defaults to on. I don't know much about it. I have also tried using the GENERIC kernel instead of my custom one, but it was even less stable on my hardware and bricked the system instead of panicking and producing a core dump. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panics in network stack in 12-current
Tom Uffner wrote: Andrey V. Elsukov wrote: I think the most of these panics should be fixed in r315956. thanks. I'll give it a try and report back as soon as I have a result. r315956 panicked about 22 min after boot. failed to dump a core. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panics in network stack in 12-current
Andrey V. Elsukov wrote: On 26.04.2017 04:03, Tom Uffner wrote: I think the most of these panics should be fixed in r315956. thanks. I'll give it a try and report back as soon as I have a result. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panics in network stack in 12-current
Since updating my -current box to 12 several months ago, I have been trying to pin down several elusive and probably related panics. they always manifest a a trap out of rw_wlock_hard() i am fairly certain that r302409 was stable, revs up through r306792 may be stable, or perhaps I just didn't wait long enough for my system to panic. I don't know of anything that I can reproducably poke at to trigger this. r306807 is definitely bad, as is everything up through r309124. I haven't seen anything on the mailing lists or in the SVN logs that looks like it is related to my problem. my hardware is an Asus M4A77TD MB, AMD Phenom 2 X6 1100T CPU (for some of this time I had an Athlon 2 X2, but upgraded recently), and RealTek 8168 PCIe Gigabit NIC. FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #33 r306807M: Tue Apr 18 17:09:55 EDT 2017 t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 in revs between 306807-307125, the panics have been in flowcleaner, in more recent ones, they happen in arbitrary userspace processes that make heavy use of the network. I know I should try the latest rev to see if it went away. aside from that, any thoughts on how I should proceed? Mon Apr 17 02:52:10 EDT 2017 FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #32 r306821M: Fri Apr 7 02:11:44 EDT 2017 t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 panic: page fault Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3b8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8057820d stack pointer = 0x28:0xfe046a422650 frame pointer = 0x28:0xfe046a422690 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 697 (ntpd) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe046a4222b0 vpanic() at vpanic+0x186/frame 0xfe046a422330 panic() at panic+0x43/frame 0xfe046a422390 trap_fatal() at trap_fatal+0x331/frame 0xfe046a4223f0 trap_pfault() at trap_pfault+0x14f/frame 0xfe046a422430 trap() at trap+0x21e/frame 0xfe046a422580 calltrap() at calltrap+0x8/frame 0xfe046a422580 --- trap 0xc, rip = 0x8057820d, rsp = 0xfe046a422650, rbp = 0xfe046a422690 --- __rw_wlock_hard() at __rw_wlock_hard+0xad/frame 0xfe046a422690 ip_output() at ip_output+0x483/frame 0xfe046a4227c0 udp_send() at udp_send+0xb8f/frame 0xfe046a422890 sosend_dgram() at sosend_dgram+0x431/frame 0xfe046a422910 kern_sendit() at kern_sendit+0x178/frame 0xfe046a4229c0 sendit() at sendit+0x179/frame 0xfe046a422a10 sys_sendto() at sys_sendto+0x4d/frame 0xfe046a422a60 amd64_syscall() at amd64_syscall+0x391/frame 0xfe046a422bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe046a422bf0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x8013c9cba, rsp = 0x7fffdfffc7e8, rbp = 0x7fffdfffc830 --- Mon Apr 17 03:19:00 EDT 2017 FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #32 r306821M: Fri Apr 7 02:11:44 EDT 2017 t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 panic: page fault Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3b8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8057820d stack pointer = 0x28:0xfe0469a0eab0 frame pointer = 0x28:0xfe0469a0eaf0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 21 (flowcleaner) trap number = 12 Timeout initializing vt_vga panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0469a0e710 vpanic() at vpanic+0x186/frame 0xfe0469a0e790 panic() at panic+0x43/frame 0xfe0469a0e7f0 trap_fatal() at trap_fatal+0x331/frame 0xfe0469a0e850 trap_pfault() at trap_pfault+0x14f/frame 0xfe0469a0e890 trap() at trap+0x21e/frame 0xfe0469a0e9e0 calltrap() at calltrap+0x8/frame 0xfe0469a0e9e0 --- trap 0xc, rip = 0x8057820d, rsp = 0xfe0469a0eab0, rbp = 0xfe0469a0eaf0 --- __rw_wlock_hard() at __rw_wlock_hard+0xad/frame 0xfe0469a0eaf0 flowtable_clean_vnet() at flowtable_clean_vnet+0x496/frame 0xfe0469a0eb80 flowtable_cleaner() at flowtable_cleaner+0x90/frame 0xfe0469a0ebb0 fork_exit() at fork_exit+0x75/frame 0xfe0469a0ebf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0469a0ebf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Mon Apr 17 02:25:20 EDT 2017 FreeBSD
Re: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]
Op wo 19 apr. 2017 09:11 schreef Tom Vijlbrief <tvijlbr...@gmail.com>:
> I'm currently rebuilding world and kernel on a just completed SVN checkout.
>
> Note that the normal sendmail daemon which listens for incoming traffic
> does NOT loop.
>
> The sendmail instance which tries local delivery (echo Hi | mail root) or
> the msp_queue instance is looping.
>
> It might be an arm64 specific issue, but a few weeks ago this was not an
> issue.
>
I just completed a full rebuild on the Pine64 and I cannot reproduce the
problem, so there is probably no issue anymore...
(Except the spurious interrupts issue)
> Op di 18 apr. 2017 om 21:15 schreef Mark Millard <mar...@dsl-only.net>:
>
>> Ronald Klop ronald-lists at klop.ws wrote on Tue Apr 18 09:59:50 UTC
>> 2017:
>>
>> > there is a thread ono this list about a problem in syslogd which made
>> > syslog-clients (like sendmail busy-looping on logging.
>> > That might be related to this. (it is fixed in the source already, so
>> > upgrading again might help)
>> > See the thread with subject like 'Re: r316958: booting a server takes
>> >10
>> > minutes!'
>> >
>> > Regards,
>> >
>> > Ronald.
>>
>>
>> Yes. But Tom V.'s report is for -r317039, which is after the reported
>> fixes as far as I can tell. Something besides syslogd might also cause
>> problems?
>>
>> In my nearly-default -r317015 ardm64 context [as a VirtualBox guest]
>> I've not seen the problem, where I did before. (The only reason sendmail
>> runs in my context is for the messages FreeBSD sends to it own local
>> accounts. I do not otherwise use mail in this context.)
>>
>> Tom V.'s report vs. others finding lack of a problem suggests that the
>> coverage of the fixes is incomplete somehow but useful. I happen to not
>> be doing whatever causes the problem to appear. I've no clue what might
>> be different or unusual in Tom V.'s context.
>>
>> There is also the possibility that Tom V.'s report is a fully independent
>> issue. But such does not seem all that likely on the initial information.
>>
>>
>> > On 2017-Apr-17, at 7:57 AM, Mark Millard
>> wrote:
>> >
>> >> Just an FYI of a more recent report of runaway sendmail on a
>> >> more recent system version ( -r317039 ):
>> >>
>> >> Begin forwarded message:
>> >>
>> >>> From: Tom Vijlbrief
>> >>> Subject: Sendmail eats CPU on r317039
>> >>> Date: April 17, 2017 at 3:39:37 AM PDT
>> >>> To: "freebsd-current at freebsd.org" ,
>> freebsd-arm
>> >>>
>> >>> On a recent kernel sendmail is constantly consuming CPU.
>> >>>
>> >>> truss -p PID
>> >>>
>> >>> shows:
>> >>>
>> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
>> 'No
>> >>> buffer space available'
>> >>> nanosleep({ 0.01000 }) = 0 (0x0)
>> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
>> 'No
>> >>> buffer space available'
>> >>> nanosleep({ 0.01000 })
>> >>> ...
>> >>>
>> >>> This is on an arm64 system
>> >>
>> >> Analysis of Tom V.'s context for this may be required.
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>>
>> ___
>> freebsd-...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]
I'm currently rebuilding world and kernel on a just completed SVN checkout.
Note that the normal sendmail daemon which listens for incoming traffic
does NOT loop.
The sendmail instance which tries local delivery (echo Hi | mail root) or
the msp_queue instance is looping.
It might be an arm64 specific issue, but a few weeks ago this was not an
issue.
Op di 18 apr. 2017 om 21:15 schreef Mark Millard <mar...@dsl-only.net>:
> Ronald Klop ronald-lists at klop.ws wrote on Tue Apr 18 09:59:50 UTC 2017:
>
> > there is a thread ono this list about a problem in syslogd which made
> > syslog-clients (like sendmail busy-looping on logging.
> > That might be related to this. (it is fixed in the source already, so
> > upgrading again might help)
> > See the thread with subject like 'Re: r316958: booting a server takes >10
> > minutes!'
> >
> > Regards,
> >
> > Ronald.
>
>
> Yes. But Tom V.'s report is for -r317039, which is after the reported
> fixes as far as I can tell. Something besides syslogd might also cause
> problems?
>
> In my nearly-default -r317015 ardm64 context [as a VirtualBox guest]
> I've not seen the problem, where I did before. (The only reason sendmail
> runs in my context is for the messages FreeBSD sends to it own local
> accounts. I do not otherwise use mail in this context.)
>
> Tom V.'s report vs. others finding lack of a problem suggests that the
> coverage of the fixes is incomplete somehow but useful. I happen to not
> be doing whatever causes the problem to appear. I've no clue what might
> be different or unusual in Tom V.'s context.
>
> There is also the possibility that Tom V.'s report is a fully independent
> issue. But such does not seem all that likely on the initial information.
>
>
> > On 2017-Apr-17, at 7:57 AM, Mark Millard wrote:
> >
> >> Just an FYI of a more recent report of runaway sendmail on a
> >> more recent system version ( -r317039 ):
> >>
> >> Begin forwarded message:
> >>
> >>> From: Tom Vijlbrief
> >>> Subject: Sendmail eats CPU on r317039
> >>> Date: April 17, 2017 at 3:39:37 AM PDT
> >>> To: "freebsd-current at freebsd.org" ,
> freebsd-arm
> >>>
> >>> On a recent kernel sendmail is constantly consuming CPU.
> >>>
> >>> truss -p PID
> >>>
> >>> shows:
> >>>
> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
> 'No
> >>> buffer space available'
> >>> nanosleep({ 0.01000 }) = 0 (0x0)
> >>> sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55
> 'No
> >>> buffer space available'
> >>> nanosleep({ 0.01000 })
> >>> ...
> >>>
> >>> This is on an arm64 system
> >>
> >> Analysis of Tom V.'s context for this may be required.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Sendmail eats CPU on r317039
On a recent kernel sendmail is constantly consuming CPU.
truss -p PID
shows:
sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55 'No
buffer space available'
nanosleep({ 0.01000 }) = 0 (0x0)
sendto(3,"<22>Apr 17 10:30:33 sendmail[362"...,163,0x0,NULL,0) ERR#55 'No
buffer space available'
nanosleep({ 0.01000 })
...
This is on an arm64 system
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Installworld fails with TMPDIR pointing to NFS mounted directory
Op di 12 jan. 2016 om 18:08 schreef NGie Cooper <yaneurab...@gmail.com>: > > > On Jan 12, 2016, at 08:42, Tom Vijlbrief <tvijlbr...@gmail.com> wrote: > > > > If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not > > think it is raspberry related or even 11-CURRENT related. > > > > export TMPDIR=/media/usbdisk/tmp > > > > make installword MAKEOBJDIRPREFIX=/media/swan/obj > > Hi Tom, > MAKEOBJDIRPREFIX should always be set via the environment, not the > command line, e.g. > > export MAKEOBJDIRPREFIX=/media/swan/obj > make installworld > > Cheers, > -NGie I think I actually did the export and not as I typed in my mail, the export is in my shell history :-) I also added: rpc_lockd_enable="YES" to my /etc/rc.conf and rebooted (rpc.lockd is now running) as Bryan suggested, but I don't think that it is needed if the only client accessing the NFS tmp dir is the local client? [root@rpibsd /media/swan/src]# env | grep swan TMPDIR=/media/swan/tmp PWD=/media/swan/src MAKEOBJDIRPREFIX=/media/swan/obj make installworld DESTDIR=/d/root11 Same result: ===> etc/sendmail (install) cd /media/swan/src/etc/../share/man; make makedb makewhatis /d/root11/usr/share/man makewhatis /d/root11/usr/share/openssl/man rm: /media/swan/tmp/install.sy3BjziY/locale/en_US.UTF-8: Directory not empty rm: /media/swan/tmp/install.sy3BjziY/locale: Directory not empty rm: /media/swan/tmp/install.sy3BjziY: Directory not empty *** Error code 1 Stop. make[1]: stopped in /media/swan/src *** Error code 1 Stop. make: stopped in /media/swan/src [root@rpibsd /media/swan/src]# ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Installworld fails with TMPDIR pointing to NFS mounted directory
https://lists.freebsd.org/pipermail/freebsd-current/2010-September/019820.html Op 12 jan. 2016 20:39 schreef "Garrett Cooper" <yaneurab...@gmail.com>: > > On Jan 12, 2016, at 11:21, Tom Vijlbrief <tvijlbr...@gmail.com> wrote: > > > Op di 12 jan. 2016 om 18:08 schreef NGie Cooper <yaneurab...@gmail.com>: > >> >> > On Jan 12, 2016, at 08:42, Tom Vijlbrief <tvijlbr...@gmail.com> wrote: >> > >> > If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not >> > think it is raspberry related or even 11-CURRENT related. >> > >> > export TMPDIR=/media/usbdisk/tmp >> > >> > make installword MAKEOBJDIRPREFIX=/media/swan/obj >> >> Hi Tom, >> MAKEOBJDIRPREFIX should always be set via the environment, not >> the command line, e.g. >> >> export MAKEOBJDIRPREFIX=/media/swan/obj >> make installworld >> >> Cheers, >> -NGie > > > I think I actually did the export and not as I typed in my mail, > the export is in my shell history :-) > > I also added: > > rpc_lockd_enable="YES" > > to my /etc/rc.conf and rebooted (rpc.lockd is now running) as Bryan > suggested, but I don't think that it is needed if the only client accessing > the NFS tmp dir is the local client? > > [root@rpibsd /media/swan/src]# env | grep swan > TMPDIR=/media/swan/tmp > PWD=/media/swan/src > MAKEOBJDIRPREFIX=/media/swan/obj > > make installworld DESTDIR=/d/root11 > > Same result: > > ===> etc/sendmail (install) > cd /media/swan/src/etc/../share/man; make makedb > makewhatis /d/root11/usr/share/man > makewhatis /d/root11/usr/share/openssl/man > rm: /media/swan/tmp/install.sy3BjziY/locale/en_US.UTF-8: Directory not > empty > rm: /media/swan/tmp/install.sy3BjziY/locale: Directory not empty > rm: /media/swan/tmp/install.sy3BjziY: Directory not empty > *** Error code 1 > > Stop. > make[1]: stopped in /media/swan/src > *** Error code 1 > > Stop. > make: stopped in /media/swan/src > [root@rpibsd /media/swan/src]# > > > The NFS "directory not empty" issue has been a common annoyance for me for > several years. It's not just you... It deserves a bug though. > Thanks! > -NGie > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Installworld fails with TMPDIR pointing to NFS mounted directory
If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not think it is raspberry related or even 11-CURRENT related. export TMPDIR=/media/usbdisk/tmp make installword MAKEOBJDIRPREFIX=/media/swan/obj Works as expected but fails cleaning up when TMPDIR points to an NFS mounted directory: export TMPDIR=/media/swan/tmp The NFS server exports /media/swan which has a src/ obj/ and tmp/ subdirectory. src/ has the sources, obj/ is filled correctly by makeworld. The tmp dir has the correct permissions. The installworld runs till the end, except for the last cleanup action which fails: ===> etc/sendmail (install) cd /media/swan/src/etc/../share/man; make makedb makewhatis /d/root11/usr/share/man makewhatis /d/root11/usr/share/openssl/man rm: /media/swan/tmp/install.xrgbPMy8/locale/en_US.UTF-8: Directory not empty rm: /media/swan/tmp/install.xrgbPMy8/locale: Directory not empty rm: /media/swan/tmp/install.xrgbPMy8: Directory not empty *** Error code 1 Stop. make[1]: stopped in /media/swan/src *** Error code 1 Stop. make: stopped in /media/swan/src On some runs just a single error message that complains about: /media/swan/tmp/install.xyz not being empty, but an "ls" shows no files and an "rmdir /media/swan/tmp/ install.xyz" succeeds! In the example above "/media/swan/tmp/install.xrgbPMy8/locale/en_US.UTF-8" IS empty! It is as if a removed file remains visible for the client for a while. The NFS server is running Ubuntu 15.10, NFSv3 is used, no other clients access the NFS tmp directory, no error messages on the client or server dmesg. /etc/exports on the server: /export/all/bsd 192.168.0.0/24(rw,no_root_squash,nohide,insecure,no_subtree_check,async) The systems have completed many build/install world/kernel cycles using this NFS mount and are rock solid. Any hints would be appreciated. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r289932 causes pf reversion - breaks rules with broadcast destination
Kristof Provost wrote:
Can you give this a quick test:
diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c
index 1dfc37d..762b82e 100644
--- a/sys/netpfil/pf/pf.c
+++ b/sys/netpfil/pf/pf.c
@@ -1973,9 +1973,9 @@ pf_addr_wrap_neq(struct pf_addr_wrap *aw1, struct
pf_addr_wrap *aw2)
switch (aw1->type) {
case PF_ADDR_ADDRMASK:
case PF_ADDR_RANGE:
- if (PF_ANEQ(>v.a.addr, >v.a.addr, 0))
+ if (PF_ANEQ(>v.a.addr, >v.a.addr, AF_INET6))
return (1);
- if (PF_ANEQ(>v.a.mask, >v.a.mask, 0))
+ if (PF_ANEQ(>v.a.mask, >v.a.mask, AF_INET6))
return (1);
return (0);
case PF_ADDR_DYNIFTL:
Your patch appears to solve the problem. Thanks!
Also thank you for your quick response.
Sorry I took so long to reply, but I was getting bizarre results from
the "quick" test, and needed to fall back to a full kernel rebuild w/
a consistent set of sources to do a fair apples to apples comparison.
tom
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r289932 causes pf reversion - breaks rules with broadcast destination
Tom Uffner wrote: Commit r289932 causes pf rules with broadcast destinations (and some but not all rules after them in pf.conf) to be silently ignored. This is bad. I do not understand the pf code well enough to see why this change caused the breakage, but I suspect that it might expose some deeper problem and should not simply be reverted. OK, so here is why I don't want to simply back this out and have a "working" firewall again: Apparently PF_ANEQ was prone to false positives when comparing IPv4 addrs. This is what r289932 and r289940 fixed. For IPv4 it does not matter where in bits 32-127 the address mismatch occurs or what order the garbage data is tested. That is all the paren fix in r289940 changes. It might be relevant for v6, but doesn't matter here. So, if my rule was "working" due to false positive in a comparison that has now been fixed, how many other address comparisons were affected by this error? There are 36 occurrences of PF_ANEQ in pf.c and 2 in if_pfsync.c About half of them appear to be testing IPv4 addresses. How many of them may have been influenced by uninitialized data returning a false positive result? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r289932 causes pf reversion - breaks rules with broadcast destination
Kristof Provost wrote: On 2015-11-04 20:31:35 (-0500), Tom Uffner <t...@uffner.com> wrote: Commit r289932 causes pf rules with broadcast destinations (and some but not all rules after them in pf.conf) to be silently ignored. This is bad. What version did you test exactly? There was an issue with r289932 that was fixed in r289940, so if you're in between those two can you test with something after r289940? thanks for your response. r289940 does not fix the problem that I am seeing. I first discovered it when I updated a -current system (from Jun 30, don't know the exact rev) to r290174 on Oct 30. After finding that many of my net services no longer worked, I isolated rules w/ broadcast addresses as the specific cause of the problem. Then I looked up every commit that touched sys/netpfil/pf from 6/30 to 10/30 and tested a kernel from before & after each one. when r290160 unexpectedly failed, I looked a little deeper and came up with sys/net/pfvars.h and r289932 As I said, I don't know why this change causes a problem (and don't really have time to figure it out at the moment). I just know that <=r289931 works, and that r289932 and greater do not. thanks, tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r289932 causes pf reversion - breaks rules with broadcast destination
Commit r289932 causes pf rules with broadcast destinations (and some but not
all rules after them in pf.conf) to be silently ignored. This is bad.
this broke access to my samba shares, and every "pass in ..." rule occurring
after the samba rule in my pf.conf.
for example, the host in question is a file server that allows SMB access on
my DMZ network. prior to r289932 the I could allow clients to browse shares
with pf rules such as:
pass in log on $dmz_if proto tcp from $ext_if:network to $dmz_if:0 \
port { 137 139 445 }
pass in log on $dmz_if proto udp from $ext_if:network to $dmz_if:0 port 137
pass in log on $dmz_if proto udp from $ext_if:network to $dmz_if:broadcast \
port { 137 138 }
after r289932 the 3rd of these was silently ignored -- pf parsed it w/o
complaint and listed it w/ "pfctl -s rules" but packets that should have
been allowed were instead matched by my default rule 0 ("block log all")
as were packets that should have matched later pass in rules.
it did not matter if the rule used an explicit address (... to 10.10.61.255)
or interface (... to re0:broadcast) or a macro (to $dmz_if:broadcast).
I do not understand the pf code well enough to see why this change caused
the breakage, but I suspect that it might expose some deeper problem and
should not simply be reverted.
tom
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SOEKRIS kernel config
That's a great idea. I'll give it a try and get back to the list. On Sun, Sep 28, 2014 at 12:33 AM, Scot Hetzel swhet...@gmail.com wrote: On Sat, Sep 27, 2014 at 9:47 PM, Tom Everett t...@khubla.com wrote: I see there is no SOEKRIS config on the tree, here https://svnweb.freebsd.org/base/head/sys/i386/conf/ I have attached one for addition to the tree. Since you only appended a few configuration options to the end of the GENERIC configuration, it would be better to use the include directive in the SOEKRIS config file. This allows changes to be made to the GENERIC configuration, and the SOEKRIS kernel would automatically get those changes. Here's a shorter version of that configuration file: # # SOEKRIS -- Generic Kernel configuration file for FreeBSD/i386 on SOEKRIS # # $FREEBSD include GENERIC ident SOEKRIS # To Make a SOEKRIS Kernel, the next options are needed options CPU_SOEKRIS options CPU_ELAN #options CPU_ELAN_PPS #options CPU_ELAN_XTAL=32768000 options CPU_GEODE # Include TMPFS options TMPFS -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. -- A better world shall emerge based on faith and understanding - Douglas MacArthur ___ 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: SOEKRIS kernel config
Bugzilla ID is *194003 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194003* On Sun, Sep 28, 2014 at 8:59 AM, Tom Everett t...@khubla.com wrote: That's a great idea. I'll give it a try and get back to the list. On Sun, Sep 28, 2014 at 12:33 AM, Scot Hetzel swhet...@gmail.com wrote: On Sat, Sep 27, 2014 at 9:47 PM, Tom Everett t...@khubla.com wrote: I see there is no SOEKRIS config on the tree, here https://svnweb.freebsd.org/base/head/sys/i386/conf/ I have attached one for addition to the tree. Since you only appended a few configuration options to the end of the GENERIC configuration, it would be better to use the include directive in the SOEKRIS config file. This allows changes to be made to the GENERIC configuration, and the SOEKRIS kernel would automatically get those changes. Here's a shorter version of that configuration file: # # SOEKRIS -- Generic Kernel configuration file for FreeBSD/i386 on SOEKRIS # # $FREEBSD include GENERIC ident SOEKRIS # To Make a SOEKRIS Kernel, the next options are needed options CPU_SOEKRIS options CPU_ELAN #options CPU_ELAN_PPS #options CPU_ELAN_XTAL=32768000 options CPU_GEODE # Include TMPFS options TMPFS -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. -- A better world shall emerge based on faith and understanding - Douglas MacArthur -- A better world shall emerge based on faith and understanding - Douglas MacArthur ___ 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
SOEKRIS kernel config
I see there is no SOEKRIS config on the tree, here https://svnweb.freebsd.org/base/head/sys/i386/conf/ I have attached one for addition to the tree. -- A better world shall emerge based on faith and understanding - Douglas MacArthur # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: head/sys/i386/conf/GENERIC 271137 2014-09-04 21:06:33Z markj $ cpu I486_CPU cpu I586_CPU cpu I686_CPU ident SOEKRIS makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options TCP_OFFLOAD # TCP offload options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options QUOTA # Enable disk quotas for UFS options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD# New Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options KBD_INSTALL_CDEV# install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options CAPABILITY_MODE # Capsicum capability mode options CAPABILITIES# Capsicum capabilities options MAC # TrustedBSD MAC Framework options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF # Kernel ELF linker loads CTF data options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging support. Always need this: options KDB # Enable kernel debugger support. options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use (turn off in stable branch): options DDB # Support DDB. options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT
Crash in GEOM, booting on Soekris
I am seeing this crash on r271882, booting a Soekris 4501. POST: 012345689bcefghipsajklnopqr,,,tvwxy comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 Soekris Engineering. net45xx 0064 Mbyte MemoryCPU Elan SC520 133 Mhz Pri Mas SanDisk SDCFX-016G LBA Xlt 1024--63 15625 Mbyte Slot Vend Dev ClassRev Cmd Stat CL LT HT Base1Base2 Int --- 0:00:0 1022 3000 0600 0006 2280 00 00 00 0:18:0 100B 0020 0200 0107 0290 00 3F 00 E001 A000 10 0:19:0 100B 0020 0200 0107 0290 00 3F 00 E101 A0001000 11 0:20:0 100B 0020 0200 0107 0290 00 3F 00 E201 A0002000 05 1 Seconds to automatic boot. Press Ctrl-P for entering Monitor. /boot/config: -h Consoles: serial port BIOS drive C: is disk0 BIOS 639kB/64512kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (tom@bernice, Fri Sep 19 19:39:16 MDT 2014) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x790cd5 data=0x5e2a0+0x2f0eb8 syms=[0x4+0x89480+0x4+0xebe59] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r271882M: Fri Sep 19 20:21:03 MDT 2014 tom@bernice:/storage/home/tom/crochet-kientzle/crochet-freebsd/work/obj/i386.i386/storage/home/tom/crochet/src/FreeBSDHead/head/sys/SOEKRIS i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Origin=AuthenticAMD Id=0x494 Family=0x4 Model=0x9 Stepping=4 Features=0x1FPU real memory = 67108864 (64 MB) avail memory = 47398912 (45 MB) random device not loaded; using insecure entropy random: Software, Yarrow initialized module_register_init: MOD_LOAD (vesa, 0xc0a447c0, 0) error 19 kbd1 at kbdmux0 ACPI BIOS Error (bug): A valid RSDP was not found (20130823/tbxfroot-223) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. sysctl machdep.i8254_freq=1189161 returns 0 Timecounter ELAN frequency 833 Hz quality 1000 pcib0 pcibus 0 on motherboard pci0: PCI bus on pcib0 sis0: NatSemi DP8381[56] 10/100BaseTX port 0xe000-0xe0ff mem 0xa000-0xafff irq 10 at device 18.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: MII bus on sis0 nsphyter0: DP83815 10/100 media interface PHY 0 on miibus0 nsphyter0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c8:d4:d4 sis1: NatSemi DP8381[56] 10/100BaseTX port 0xe100-0xe1ff mem 0xa0001000-0xa0001fff irq 11 at device 19.0 on pci0 sis1: Silicon Revision: DP83816A miibus1: MII bus on sis1 nsphyter1: DP83815 10/100 media interface PHY 0 on miibus1 nsphyter1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c8:d4:d5 sis2: NatSemi DP8381[56] 10/100BaseTX port 0xe200-0xe2ff mem 0xa0002000-0xa0002fff irq 5 at device 20.0 on pci0 sis2: Silicon Revision: DP83816A miibus2: MII bus on sis2 nsphyter2: DP83815 10/100 media interface PHY 0 on miibus2 nsphyter2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c8:d4:d6 cpu0 on motherboard isa0: ISA bus on motherboard pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xc8000-0xd0fff pnpid ORM on isa0 ata0: ATA channel at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: ATA channel at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atrtc0: AT realtime clock at port 0x70 irq 8 on isa0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer at port 0x40 on isa0 Timecounter i8254 frequency 1189161 Hz quality 0 Event timer i8254 frequency 1189161 Hz quality 100 uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: 16550 or compatible at port 0x2f8-0x2ff irq 3 on isa0 Timecounters tick every 1.000 msec interrupt storm detected on irq5:; throttling interrupt source Elan-mmcr driver: MMCR at 0xc37ff000. Elan-mmcr Soekris net45xx comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 random: unblocking device. ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: SanDisk SDCFX-016G HDX 7.03 CFA-0 device ada0: Serial Number AJZ061813191928 ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) ada0: 15259MB (31250432 512 byte sectors: 16H 63S/T 31002C) ada0: Previously was known as ad0 panic: Bio not on queue bp=0xc2aaa4c0 target 0xc0c0f8bc KDB: stack backtrace: db_trace_self_wrapper
SOEKRIS kernel crash
I've compiled a SOEKRIS kernel which I'm booting with Crochet-BSD. It's reliably crashing on boot, with the below message. The kernel revision is 271600, and the kernel config is here: https://github.com/kientzle/crochet-freebsd/blob/master/board/Soekris/conf/SOEKRIS11 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer at port 0x40 on isa0 Timecounter i8254 frequency 1189161 Hz quality 0 Event timer i8254 frequency 1189161 Hz quality 100 uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: 16550 or compatible at port 0x2f8-0x2ff irq 3 on isa0 Timecounters tick every 1.000 msec interrupt storm detected on irq5:; throttling interrupt source Elan-mmcr driver: MMCR at 0xc37ff000. Elan-mmcr Soekris net45xx comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 random: unblocking device. ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: SanDisk SDCFX-016G HDX 7.03 CFA-0 device ada0: Serial Number AJZ061813191928 ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) ada0: 15259MB (31250432 512 byte sectors: 16H 63S/T 31002C) ada0: Previously was known as ad0 panic: Bio not on queue bp=0xc2ab74c0 target 0xc0c0f43c KDB: stack backtrace: db_trace_self_wrapper(c0b3e6fa,c2a01800,c2689be4,c061fdf1,c2a01830,...) at db_trace_self_wrapper+0x2d/frame 0xc2689bb8 kdb_backtrace(c0b39cc6,c0c11408,c0b26e7a,c2689c70,c0b26e7a,...) at kdb_backtrace+0x30/frame 0xc2689c1c vpanic(c0c112a8,100,c0b26e7a,c2689c70,c2689c70,...) at vpanic+0x80/frame 0xc2689c40 kassert_panic(c0b26e7a,c2ab74c0,c0c0f43c,0,c28d9c40,...) at kassert_panic+0xe9/frame 0xc2689c64 g_bioq_first(c0c0f454,0,c0b26c3c,5c,0,...) at g_bioq_first+0x63/frame 0xc2689c80 g_io_schedule_up(c28d9c40,0,c0b27089,60,c2689cf4,...) at g_io_schedule_up+0x94/frame 0xc2689cb4 g_up_procbody(0,c2689d08,c0b3335e,3c9,0,...) at g_up_procbody+0x9d/frame 0xc2689ccc fork_exit(c0703210,0,c2689d08) at fork_exit+0x7f/frame 0xc2689cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xc2689cf4 --- trap 0, eip = 0, esp = 0xc2689d40, ebp = 0 --- KDB: enter: panic [ thread pid 13 tid 19 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db bt Tracing pid 13 tid 19 td 0xc28d9c40 kdb_enter(c0b39f64,c0b39f64,c0b26e7a,c2689c70,c0b26e7a,...) at kdb_enter+0x3d/frame 0xc2689c1c vpanic(c0c112a8,100,c0b26e7a,c2689c70,c2689c70,...) at vpanic+0xcb/frame 0xc2689c40 kassert_panic(c0b26e7a,c2ab74c0,c0c0f43c,0,c28d9c40,...) at kassert_panic+0xe9/frame 0xc2689c64 g_bioq_first(c0c0f454,0,c0b26c3c,5c,0,...) at g_bioq_first+0x63/frame 0xc2689c80 g_io_schedule_up(c28d9c40,0,c0b27089,60,c2689cf4,...) at g_io_schedule_up+0x94/frame 0xc2689cb4 g_up_procbody(0,c2689d08,c0b3335e,3c9,0,...) at g_up_procbody+0x9d/frame 0xc2689ccc fork_exit(c0703210,0,c2689d08) at fork_exit+0x7f/frame 0xc2689cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xc2689cf4 --- trap 0, eip = 0, esp = 0xc2689d40, ebp = 0 --- db -- A better world shall emerge based on faith and understanding - Douglas MacArthur ___ 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: timezone for 100.chksetuid
On Fri, May 16, 2014 at 2:53 PM, J.R. Oldroyd f...@opal.com wrote: I would like to propose that a timezone setting be possible for the src/etc/periodic/security/100.chksetuid script. Either fix it at something like UTC, or add an rc.conf setting that specifies what timezone to use. Or both, default to UTC but allow a timezone setting in rc.conf. Reason for this is that for folk who travel, the 100.chksetuid script generates and diffs find -ls output and this output changes if you change timezones and update the system timezone setting while you are away. It then changes back again when you return. If you travel a lot, the two timezone changes cause this script to flag every setuid file as having changed (twice), when all that changed is the time display. This means that real changes during the same period will likely be overlooked and the frequent non-real diffs tend to make one likely to ignore this section. Do you mean you are changing /etc/localtime whenever you move to another timezone? I would suggest stopping doing that! Instead just set TZ in your user environment to whatever TZ you want. That way, your programs will all be localised correctly, and scripts which run as root will remain consistent. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS bug or feature
On Tue, Apr 22, 2014 at 5:18 PM, Andrey Fesenko f0and...@gmail.com wrote: After detach ada0 and attach him (reboot between that) boot only one disk Apr 17 13:33:52 x220 kernel: ada0 at ahcich2 bus 0 scbus0 target 0 lun 0 Apr 17 13:33:52 x220 kernel: ada0: OCZ-NOCTI 2.15 ATA-8 SATA 2.x device Apr 17 13:33:52 x220 kernel: ada0: Serial Number OCZ-J8928HU1G10KR9XM Apr 17 13:33:52 x220 kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Apr 17 13:33:52 x220 kernel: ada0: Command Queueing enabled Apr 17 13:33:52 x220 kernel: ada0: 114473MB (234441648 512 byte sectors: 1H 63S/T 65535C) Apr 17 13:33:52 x220 kernel: ada0: Previously was known as ad4 After attach ada0 im see this # camcontrol devlist Corsair Neutron SSD M206 at scbus0 target 0 lun 0 (ada0,pass0) OCZ-NOCTI 2.15 at scbus1 target 0 lun 0 (ada1,pass1) # zpool status pool: x220pool state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(7) for details. scan: resilvered 42.4M in 0h0m with 0 errors on Thu Apr 17 13:48:42 2014 config: NAME STATE READ WRITE CKSUM x220pool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 diskid/DISK-OCZ-J8928HU1G10KR9XMs1a ONLINE 0 0 0 ada0s1a ONLINE 0 0 0 errors: No known data errors # gpart show = 63 468862065 ada0 MBR (224G) 63 234441585 1 freebsd (112G) 234441648 234420480 2 freebsd (112G) =0 234441585 ada0s1 BSD (112G) 0 234441585 1 freebsd-zfs (112G) = 63 234441585 diskid/DISK-OCZ-J8928HU1G10KR9XM MBR (112G) 63 234441585 1 freebsd [active] (112G) =0 234441585 diskid/DISK-OCZ-J8928HU1G10KR9XMs1 BSD (112G) 0 234441585 1 freebsd-zfs (112G) Apr 17 13:48:43 x220 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Apr 17 13:48:43 x220 kernel: ada0: Corsair Neutron SSD M206 ATA-8 SATA 3.x device Apr 17 13:48:43 x220 kernel: ada0: Serial Number 124079271802000A Apr 17 13:48:43 x220 kernel: ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) Apr 17 13:48:43 x220 kernel: ada0: Command Queueing enabled Apr 17 13:48:43 x220 kernel: ada0: 228936MB (468862128 512 byte sectors: 16H 63S/T 16383C) Apr 17 13:48:43 x220 kernel: ada0: Previously was known as ad4 Apr 17 13:48:43 x220 kernel: ada1 at ahcich2 bus 0 scbus1 target 0 lun 0 Apr 17 13:48:43 x220 kernel: ada1: OCZ-NOCTI 2.15 ATA-8 SATA 2.x device Apr 17 13:48:43 x220 kernel: ada1: Serial Number OCZ-J8928HU1G10KR9XM Apr 17 13:48:43 x220 kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Apr 17 13:48:43 x220 kernel: ada1: Command Queueing enabled Apr 17 13:48:43 x220 kernel: ada1: 114473MB (234441648 512 byte sectors: 1H 63S/T 65535C) Apr 17 13:48:43 x220 kernel: ada1: Previously was known as ad6 # zpool history -il | tail -6 2014-04-17.13:33:51 [txg:8004153] open pool version 5000; software version 5000/5; uts 11.0-CURRENT 115 amd64 [on x220.local] 2014-04-17.13:48:36 [txg:8004321] open pool version 5000; software version 5000/5; uts 11.0-CURRENT 115 amd64 [on x220.local] 2014-04-17.13:48:41 [txg:8004324] scan setup func=2 mintxg=8004151 maxtxg=8004320 [on x220.local] 2014-04-17.13:48:42 [txg:8004325] scan done complete=1 [on x220.local] 2014-04-17.13:53:53 zpool clear x220pool [user 0 (root) on x220.local] I'm confused, what is the bug or feature? Has it added the disk with the wrong label? You can correct that with an zpool export x220pool / zpool import -d /dev/diskid x220pool Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) in -HEAD supporting Centrino Wireless-N 135
Hi, I'm just wondering if you had any time to look at this? I'm happy to test any patches or diffs. Regards, Tom On Tue, Mar 11, 2014 at 11:03:20AM -0700, Adrian Chadd wrote: I still don't have any ideas here. I do however want to try hacking the driver to transmit EAPOL frames at the management rate, and then ensure the management rate is non-MCS. -a On 28 February 2014 15:14, Adrian Chadd adr...@freebsd.org wrote: Hi, the interesting bits: Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 3 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 4 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 3 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 4 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 5 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 6 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 5 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 6 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 7 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 8 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 7 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 8 retries 16 nkill 0 rate 80006902 duration 2815 status 83 .. so it's failing to transmit the management frames after association - they're being transmitted at MCS0 and the AP is just plain not ACKing them. Now, I don't know why this is. It's trying to transmit the initial frame at non-MCS rates, but I have a feeling the multi-rate retry table thing is confusing it and it's trying to send it as MCS. So maybe the AP doesn't like management frames at MCS rates. I'll have to think about this a little. -a On 28 February 2014 15:07, Tom Murphy free...@pertho.net wrote: I've attached my iwn debug messages to this email starting with the point I tried to associate to the Wifi. Thanks again for looking at this! Kind regards, Tom On Thu, Feb 27, 2014 at 12:13:51PM -0800, Adrian Chadd wrote: On 26 February 2014 23:52, Alexandr shur...@shurik.kiev.ua wrote: Tom, could you: 1. compile kernel WITH_IWNDEBUG 2. sysctl dev.iwn.0.debug=0x1 3. wlandebug -i wlan0 auth+assoc 4. Associate with AP in 11n mode 5. Send us appropriate /var/log/messages Then I try to compare it with my log. Please do. I've been trying to track down the source of this ht just doesn't work! but it works fine with all of the Intel NICs I have here. Can someone see if they can find a mtaching NIC online (amazon,ebay?) Owning one that I can whack in a laptop is likely going ot help things a lot. Thanks, -a ___ 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: Error when adding user with multiple groups with bsdconfig
On Fri, Jan 10, 2014 at 12:37 AM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: Hi I'm on 11-CURRENT amd64. I wanted to add a user using bsdconfig but got an error when adding to several groups. Error message: ERROR!: pw pw: group `wheel daemon operator dialer network` does not exist. Creating a user who is only added to one group (for example wheel) works fine. I have submitted a PR. What command line did you use? A user can only have one primary group (-g), but can be in multiple groups (-G). -g group Set the account's primary group to the given group. group may be defined by either its name or group number. -G grouplist Set additional group memberships for an account. grouplist is a comma, space or tab-separated list of group names or group numbers. The user's name is added to the group lists in /etc/group, and removed from any groups not specified in grouplist. Note: a user should not be added to their pri‐ mary group with grouplist. Also, group membership changes do not take effect for current user login sessions, requir‐ ing the user to reconnect to be affected by the changes. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin j...@freebsd.org wrote: On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: Password expiry is an orthogonal issue and should be up to administrator policy. Yes, but if you are moving to a different algorithm to improve security, not coupling it with an eventual expiration of non-migrated accounts gives a false sense of security. Any admin worth his/her salt is going to want the option of enforcing that sort of policy along with the transparent update. They should really be implemented together is all. Account expiration and password expiration are already present. There is absolutely no reason that password algorithm upgrade should be tied in any way to expiration. A transparent algorithm upgrade as proposed is *far* better than the forced password change method that is commonly employed. If the administrator wants to force all accounts to migrate by a set deadline, we already have the expiration facilities in place to accomplish that. Expiring accounts that have not been used in a long time, regardless of algorithm changes, should be part of general housekeeping and may be covered by existing policy. Password expiration serves no purpose, EVER. Password expiration encourages users to choose bad passwords because they are throwaway items. Bruce states it well enough I need not elaborate further https://www.schneier.com/blog/archives/2010/11/changing_passwo.html Anyone who fails to understand the above should NOT be an administrator. I think you failed to understand my point. I am assuming that an administrator wants the transparent upgrade (which I think is useful) because they are assuming that the hash algorithm is compromised or inferior. To that end, they may wish to limit the time window for which they accept hashes generated using the suspect algorithm. This is separate (I believe) from the issue Bruce raises above. For example, in this case, the administrator is perfectly happy for the actual plaintext to remain the same, the administrator simply wants to enforce the new hash. As far as I can tell, there is nothing in /etc/login.conf to allow for automatic account expiration if an account is idle for more than N days. OTOH, even that is probably not sufficient for the original case since a user might login with a different authentication method (e.g. ssh key) that would reset the idle timer without updating the hash. I suppose if you really were paranoid about the hash what you would want is an ability to set an expiration time on the hash algo itself where authentication using that hash always fails after the expiration time. This doesn't necessarily expire the entire account (e.g. ssh key auth would still work), though it might be a bit surprising to the user to find that the next time they attempt to use password authentication it doesn't work. (You would at least want a warning about the hash being expired on login via another mechanism.) All of this is orthogonal to adding a way to upgrade hashes. Yes, all of the points you mentioned are relevant to general password security, but doesn't explain why a feature that provides transparent hash upgrades cannot be added without first adding the features you are asking for. It's like trying to prevent people from shooting themselves in the foot by only giving them rocks to throw. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) in -HEAD supporting Centrino Wireless-N 135
I've attached my iwn debug messages to this email starting with the point I tried to associate to the Wifi. Thanks again for looking at this! Kind regards, Tom On Thu, Feb 27, 2014 at 12:13:51PM -0800, Adrian Chadd wrote: On 26 February 2014 23:52, Alexandr shur...@shurik.kiev.ua wrote: Tom, could you: 1. compile kernel WITH_IWNDEBUG 2. sysctl dev.iwn.0.debug=0x1 3. wlandebug -i wlan0 auth+assoc 4. Associate with AP in 11n mode 5. Send us appropriate /var/log/messages Then I try to compare it with my log. Please do. I've been trying to track down the source of this ht just doesn't work! but it works fine with all of the Intel NICs I have here. Can someone see if they can find a mtaching NIC online (amazon,ebay?) Owning one that I can whack in a laptop is likely going ot help things a lot. Thanks, -a Feb 28 22:55:20 kernel: wlan0: Ethernet address: 0c:d2:92:0e:aa:e2 Feb 28 22:55:20 wpa_supplicant[2424]: Successfully initialized wpa_supplicant Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 1 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 6 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 11 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 7 status 1 Feb 28 22:55:20 wpa_supplicant[2423]: Successfully initialized wpa_supplicant Feb 28 22:55:20 wpa_supplicant[2426]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Device not configured Feb 28 22:55:20 wpa_supplicant[2426]: wlan0: Failed to initiate AP scan Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 1 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 6 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 11 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 7 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 13 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 2 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 3 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 4 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 5 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 8 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 9 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 10 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 12 status 1 Feb 28 22:55:20 wpa_supplicant[2426]: wlan0: Trying to associate with a0:f3:c1:35:a3:6c (SSID='pertho' freq=2462 MHz) Feb 28 22:55:20 wpa_supplicant[2425]: wlan0: Trying to associate with a0:f3:c1:35:a3:6c (SSID='pertho' freq=2462 MHz) Feb 28 22:55:21 kernel: iwn_tx_data_raw: qid 3 idx 0 len 6 nsegs 1 Feb 28 22:55:21 kernel: iwn_tx_data_raw: qid 3 idx 1 len 6 nsegs 1 Feb 28 22:55:21 kernel: iwn5000_tx_done: qid 3 idx 0 retries 0 nkill 0 rate 420a duration 778 status 201 Feb 28 22:55:21 kernel: iwn5000_tx_done: qid 3 idx 1 retries 0 nkill 0 rate 420a duration 778 status 201 Feb 28 22:55:21 kernel: iwn_tx_data_raw: qid 3 idx 2 len 87 nsegs 1 Feb 28 22:55:21 kernel: iwn5000_tx_done: qid 3 idx 2 retries 0 nkill 0 rate 420a duration 1426 status 201 Feb 28 22:55:21 kernel: iwn_set_link_quality: 1stream antenna=0x01, 2stream antenna=0x03, ntxstreams=1 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=0, txrate=7, rate=0x87 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=1, txrate=6, rate=0x86 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=2, txrate=5, rate=0x85 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=3, txrate=4, rate=0x84 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=4, txrate=3, rate=0x83 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=5, txrate=2, rate=0x82 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=6, txrate=1, rate=0x81 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=7, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=8, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=9, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=10, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=11, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=12, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=13, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=14, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=15, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: wlan0: link state changed to UP Feb 28 22:55:21 wpa_supplicant[2425]: wlan0: Associated with a0:f3:c1:35:a3:6c Feb 28 22:55:21 wpa_supplicant[2426]: wlan0: Associated with a0:f3:c1:35:a3:6c Feb 28 22:55:21 dhclient[2746]: send_packet: No buffer space available Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 3 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 4 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 3 retries 16 nkill 0 rate 80006902 duration 2815 status
Re: iwn(4) in -HEAD supporting Centrino Wireless-N 135
Hi Adrian, If I set -ht on wlan0 it works. I have to put it in rc.conf for it to work, though. ifconfig_wlan0=DHCP WPA -country GB -ht So it does look like 11n isn't right. Kind regards, Tom On Wed, Feb 26, 2014 at 11:32:17PM -0800, Adrian Chadd wrote: Yeah, try to verify if it's this or not. It's quite possible that there's some NIC setup for 11n that isn't completely correct. -a On 26 February 2014 23:23, Alexandr shur...@shurik.kiev.ua wrote: May be it is similar to my problem. It connects to AP for a few seconds and then drop a connection. It situation 100% reproducible in 11n mode, but in 11g works fine. http://docs.freebsd.org/cgi/mid.cgi?5304B48E.8070404 26.02.2014 17:09, Adrian Chadd пишет: Hi, Yeah, there's likely something missing. But I just at the moment have no time to debug this. -a On 26 February 2014 04:37, Tom Murphy free...@pertho.net wrote: Hi all, I compiled a fresh kernel from -HEAD and rebooted in the hope that my laptop's wifi would now be supported (I saw the commit messages in January about it possibly supporting Centrino Wireless-N 135). However, while it does attempt to bring the wifi up, the link just goes up and down and does not work properly. Knowing that the BSDs are fairly close and share some code, I did try the OpenBSD driver and it works. Is there some code that could be missing from the FreeBSD iwn(4) to stabilize it? I'd be happy to test any patches. Kind regards, Tom wlan0: no link ..wlan0: link state changed to UP wlan0 link stage up - down DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 wlan0: link state changed to UP wlan0: link state down - up (more DHCPDISCOVER) wlan0 link stage up - down Rise and repeat. iwn0: Intel Centrino Wireless-N 135 mem 0xf790-0xf7901fff irq 18 at device 0.0 on pci3 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
iwn(4) in -HEAD supporting Centrino Wireless-N 135
Hi all, I compiled a fresh kernel from -HEAD and rebooted in the hope that my laptop's wifi would now be supported (I saw the commit messages in January about it possibly supporting Centrino Wireless-N 135). However, while it does attempt to bring the wifi up, the link just goes up and down and does not work properly. Knowing that the BSDs are fairly close and share some code, I did try the OpenBSD driver and it works. Is there some code that could be missing from the FreeBSD iwn(4) to stabilize it? I'd be happy to test any patches. Kind regards, Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
iwn(4) in -HEAD supporting Centrino Wireless-N 135
Hi all, I compiled a fresh kernel from -HEAD and rebooted in the hope that my laptop's wifi would now be supported (I saw the commit messages in January about it possibly supporting Centrino Wireless-N 135). However, while it does attempt to bring the wifi up, the link just goes up and down and does not work properly. Knowing that the BSDs are fairly close and share some code, I did try the OpenBSD driver and it works. Is there some code that could be missing from the FreeBSD iwn(4) to stabilize it? I'd be happy to test any patches. Kind regards, Tom wlan0: no link ..wlan0: link state changed to UP wlan0 link stage up - down DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 wlan0: link state changed to UP wlan0: link state down - up (more DHCPDISCOVER) wlan0 link stage up - down Rise and repeat. iwn0: Intel Centrino Wireless-N 135 mem 0xf790-0xf7901fff irq 18 at device 0.0 on pci3 ___ 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: fonts and characters
On Fri, Feb 7, 2014 at 3:57 PM, Sean Bruno sean_br...@yahoo.com wrote: 1 question though, I see that LANG isn't set by default. Should I know where to modify my system to set en_US.UTF-8 or is it supposed to have that turned on by default? /etc/profile is where I set it on mine. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
On Thu, Feb 6, 2014 at 6:34 PM, Julian H. Stacey j...@berklix.com wrote: Best avoid the obscure word `Deprecated' in manuals: It's not common/ plain English. Maybe a geek import, or USA dialect ? It's not easily internationaly understood English. Best make manuals easier for non native English speakers ( native English too ;-). I am British born bred, whether in English speaking circles in UK or Germany I never hear or read 'deprecated' unless its in BSD context. Few native English speakers I know will be immediately sure of the meaning, it's too obscure. As another Briton this surprises me: The word deprecate has a clear and specific meaning in all computing, especially in standards, release notes and documentation. It is from latin and is the same base word in all romance languages. It is definitely in common usage in the UK, I would not hesitate to use it any conversation with anyone and expect them to understand its meaning. To my ear there is no clearer word to use for this purpose. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
On Thu, Dec 19, 2013 at 12:33 PM, Thomas Mueller mueller6...@bellsouth.net wrote: Better would be if manufacturers' and online vendors' websites would say what chipset their Ethernet, Bluetooth adapter, USB wi-fi adapter, etc use. I think manufacturers don't consider this relevant info, they sell features, not the underlying spec. This allows them to chop and change what chip is actually in a device depending on the vagaries of their supply chain. Eg, Rev A, Rev B might be precisely the same packaging but different chips underneath. Suck for non Windows users, I agree. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [request] ntp upgrade
On Wed, Nov 27, 2013 at 3:29 PM, Cristiano Deana cristiano.de...@gmail.com wrote: Hi, is it possible to include in base system of the upcoming 10.0 the new version of ntp (4.2.7 instead of 4.2.4)? There is a bug in older versions ( 4.2.7) who allows attacker use an ntp server to DDoS. This has been corrected in new version: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks This attack seems to be increasing in the last few weeks. net/ntp-devel is Ok. Thank you, sorry for my basic english. ntp 4.2.4p8 isn't vulnerable. http://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html The reflection attack is the first in the list, 4.2.4p7 and below are affected. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [request] ntp upgrade
On Wed, Nov 27, 2013 at 4:10 PM, Cristiano Deana cristiano.de...@gmail.com wrote: On Wed, Nov 27, 2013 at 5:06 PM, Tom Evans tevans...@googlemail.com wrote: There is a bug in older versions ( 4.2.7) who allows attacker use an ntp server to DDoS. This has been corrected in new version: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks This attack seems to be increasing in the last few weeks. net/ntp-devel is Ok. ntp 4.2.4p8 isn't vulnerable. http://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html The reflection attack is the first in the list, 4.2.4p7 and below are affected. Thank you, Tom for your quick reply. That is not the same bug. I had two ntpd with 4.2.4p8 used the last days to DDoS. I found the link below, used net/ntp-devel and the abuse was gone. Does it have a CVE? The article is low on content :( Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [heads up] axing AppleTalk and IPX/SPX
On Oct 28, 2013, at 11:54 AM, Stefan Bethke s...@lassitu.de wrote: Am 28.10.2013 um 13:42 schrieb Gleb Smirnoff gleb...@freebsd.org: The plan is two axe two old networking protocols from FreeBSD head/, meaning that FreeBSD 11.0-RELEASE, available in couple of years would be shipped without them. 1) AppleTalk Last time claimed to be supported by vendor in 2007[1]. In practice had very little use since 90th. Discontinued by major routing equipment vendors since 2009[2]. Since Apple has now even deprecated AFP (the file sharing protocol implemented by netatalk, among others), it’s time to let go. Do you have a reference for that? Various pundits have claimed that Apple is deprecating AFP because when you enable Personal File Sharing, that enables SMB now, not AFP, but so far I have not seen any official announcement from Apple either way. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mplayer
On Thu, Sep 19, 2013 at 10:06 PM, Ajtim lum...@gmail.com wrote: I try to built Mplayer but I have a problems (they were so many warnings) and finally error: libmpdemux/demux_rtp.cpp:101:20: error: no member named 'describeWithPassword' in 'RTSPClient' return client-describeWithPassword(url, network_username, password); ~~ ^ libmpdemux/demux_rtp.cpp:103:20: error: no member named 'describeURL' in 'RTSPClient' return client-describeURL(url); Live555 (net/liveMedia) changed their API, you either have too new a version of that library with too old an mplayer snapshot, or too old version of that library with too new of an mplayer snapshot. Either way, update all ports that mplayer depends on and try again. If it still doesn't work, update your ports tree, update all ports that mplayer depends on and try again. You could also disable Live555 support if you don't need RTSP. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots
On Sun, Mar 17, 2013 at 8:26 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: Dear All , Previously , in the following message , I have mentioned effect of memory chip placement on execution speed : http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html Effect of Processor and Memory on KDE4 execution speedhttp://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html These seems to be more than different memory slot allocation between those two boxes. Can you reproduce this on the one labelled 'FAST' by assigning memory in the same manner as it is assigned in the one labelled 'SLOW'? The above thread did not produce any usable result . The problem is persisting over 9.1 and 10.0 current . My opinion is that , it is NOT related to KDE only . After X is started , any desktop is behaving very slowly . This is also visible in PC-BSD and GhostBSD . This is very nebulous. What is 'very slowly'? Is there a test you can run that is independent of X, KDE, etc that demonstrates this? One thing that KDE does require (iirc - from about 5 years ago, probably wrong now) is that since KDE is C++, it spends a lot of time loading executables/libraries into memory and prelinking them. If you have dramatically lowered your RAM bandwidth, then this stage could take a lot longer. One thing that could cause memory bandwidth to lower is by installing mismatched modules. The BIOS will set all RAM up at the same speed, the lowest that all of the installed RAM supports. If you fill the RAM slots with mismatched modules of different sizes, it may also not enable dual channel memory, further reducing the RAM bandwidth. Because of this, I think it is a jump to go from My computer runs slow when I put these bits of RAM in to FreeBSD always runs slow when there is mismatched RAM. If you find out what is slow on FreeBSD - eg RAM bandwidth - you can then test the same thing in Linux. If Linux shows the same slowdown from fast to slow, then I'm sorry, that's a hardware defect. If, on the other hand, Linux is just as fast in both configurations, then I'm sure a lot of people would be interested as to why. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots
On Mon, Mar 18, 2013 at 10:30 AM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Mon, Mar 18, 2013 at 3:01 AM, Tom Evans tevans...@googlemail.com wrote: On Sun, Mar 17, 2013 at 8:26 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: Dear All , Previously , in the following message , I have mentioned effect of memory chip placement on execution speed : http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html Effect of Processor and Memory on KDE4 execution speedhttp://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html These seems to be more than different memory slot allocation between those two boxes. Can you reproduce this on the one labelled 'FAST' by assigning memory in the same manner as it is assigned in the one labelled 'SLOW'? The above thread did not produce any usable result . The problem is persisting over 9.1 and 10.0 current . My opinion is that , it is NOT related to KDE only . After X is started , any desktop is behaving very slowly . This is also visible in PC-BSD and GhostBSD . This is very nebulous. What is 'very slowly'? Is there a test you can run that is independent of X, KDE, etc that demonstrates this? One thing that KDE does require (iirc - from about 5 years ago, probably wrong now) is that since KDE is C++, it spends a lot of time loading executables/libraries into memory and prelinking them. If you have dramatically lowered your RAM bandwidth, then this stage could take a lot longer. One thing that could cause memory bandwidth to lower is by installing mismatched modules. The BIOS will set all RAM up at the same speed, the lowest that all of the installed RAM supports. If you fill the RAM slots with mismatched modules of different sizes, it may also not enable dual channel memory, further reducing the RAM bandwidth. Because of this, I think it is a jump to go from My computer runs slow when I put these bits of RAM in to FreeBSD always runs slow when there is mismatched RAM. If you find out what is slow on FreeBSD - eg RAM bandwidth - you can then test the same thing in Linux. If Linux shows the same slowdown from fast to slow, then I'm sorry, that's a hardware defect. If, on the other hand, Linux is just as fast in both configurations, then I'm sure a lot of people would be interested as to why. Cheers Tom I think , all of the answers to your questions may be found in the above referenced thread messages : Nope, you tested 'running KDE' and on different computers found out that one runs at a different speed than another. You've not done anything else to determine why or because of what. You're the one seeing this problem. If you want it fixed, you will need to do some work to determine what is causing it. All you are saying now is When I build this complex combination of hardware and software, it's slow. Fix my special case. Every possible combination has been tried , and identified that the problem is different memory chip sizes for FreeBSD ( v9.0 , v9.1 , v10.0 ) ( GhostBSD , PC-BSD , v9.0 , v9.1 ) : Channel A : Slot 1 : 2 GB Slot 2 : 1 GB Channel B : Slot 1 : 2 GB Slot 2 : 1 GB All of the memory chips : Kingston HyperX , same clock frequency . Memory placement kind is correct . You say this, have you actually measured/checked. sysutils/dmidecode will interrogate your BIOS and tell us what it thinks is installed in each RAM socket. It is not uncommon for RAM to say one thing on the outside, and report something completely different to the BIOS. There is NO any hardware defect . Linux is insensitive to such different memory chip sizes ( I am using Fedora , CentOS , Mandriva , Mageia , OpenSUSE , Arch Linux , Puppy Linux , and some others ... ) And you've run the tests which clearly demonstrate this? Or you've installed KDE, and it's not been 'too slow'? I'm trying to get you to approach a more scientific approach to this. Hopefully, this would lead to some actual conclusions and things that can be improved, rather than FreeBSD is slow. You've got a problem when you have mismatched memory, your computer runs slower. Is the memory running slower? Test memory bandwidth in both 'fast' and 'slow' configurations. Is there a difference? Apparently linux is unaffected. Test memory bandwidth in both fast and slow configurations on linux. Is there a difference? Doing those 4 steps should tell us more about your actual problem, and might spur an idea in someone. You can use ramspeed to test ram speed in both linux and freebsd: http://alasir.com/software/ramspeed/ Problems with your memory modules should produce testable scenarios that don't involve X and KDE. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr
Re: using multiple interfaces for same Network Card
On Tue, Mar 12, 2013 at 7:43 AM, Yasir hussan kolya...@gmail.com wrote: Hi guys, Is there any way that i can have multiple interfaces which i can able to access from any other machine for same single network card, I am able to create new interfaces like # ifconfig arge0.1 create but i am unable to access it frm any other machine. I want it be able to oing from any other machine Thanks I see you asked about this yesterday: https://groups.google.com/forum/?fromgroups=#!topic/mailing.freebsd.current/uP9BC7_dSrA ifconfig iface create is how aliases are created on linux. You need to use ifconfig iface addr alias on FreeBSD. As was pointed out to you yesterday when you asked. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: ports include /etc/src.conf? i.e. graphics/libfpx
On Thu, Feb 14, 2013 at 12:27 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: 13.02.2013 11:22, O. Hartmann написав(ла): If this is taken literally then could it be said that ports that use bsd.lib.mk are broken because they are using makefile includes from the source tree? -Kimmo For one, the particular port (its Makefile.bsd) was created in 2001, five years before src.conf appeared. The intent of creating a separate src.conf, I believe, was to shield a world-build from crazy options someone could've put into their make.conf for the benefit of building a port or two... But I may be mistaken. I think src.conf is meant only to be included when building src. For example, bsd.port.mk sets _WITHOUT_SRCCONF before including bsd.own.mk (which is the makefile that includes src.conf). It's done this since src.conf was added in 2006, so evidently ports are, by design, not supposed to include src.conf. I would consider them broken! On the contrary. I wish, more ports were using the system's bsd.*.mk collection -- instead of the godawful autoconf, for example. Er? What port uses autoconf for driving the building the port? A lot of ports have build systems that use autoconf, but determining how to build is always driven by *.mk. I don't think part of porting to FreeBSD should be rewriting how the package builds itself. The intent in bsd.port.mk is clearly to not include src.conf in port builds. What does the port's Makefile.bsd say? It says: These are the sources, this is the name of the library I want. Please, create it. That's all... It is how things are supposed to be, in my opinion. If the bsd.*.mk collection was not meant to be used outside of /usr/src, then it wouldn't be installed (under /usr/share/mk) for the decades, that BSD exists. Maybe, the bsd.*.mk collection should be smarter -- and not include src.conf -- when .CURDIR is outside of /usr/src. I'm not sure... This is the intent of bsd.port.mk, which is not applied when building this port. How could I track down problems if they are results of intermixed config files when the manpage explicitely tells me, that the /etc/src.conf is only for the build of the operating system? If the manual says that, it is incorrect -- if only because it does not reflect (as you've experienced) the practice, that existed long before the manual was written. As for your tracking down problems, I'd say, it should be very easy for you to recognize the flags you've added by hand -- even if you've added them to where you believed, they would not affect a port. Either the documentation is wrong, and should be changed, or this singular port is not behaving as it should. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports include /etc/src.conf? i.e. graphics/libfpx
On Thu, Feb 14, 2013 at 1:12 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: I may sound defensive here, but I'll still repeat, that this singular port (and I do, in fact, have other ones like it) started using bsd.lib.mk 5 years before src.conf (and its man-page) was added to the tree. -mi This is true. But what is the bug, that the port's Makefile.bsd was not updated on the introduction of src.conf to DTRT (and no-one noticed for 7 years), or that the purpose of src.conf has been mistakenly documented for 7 years? Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports include /etc/src.conf? i.e. graphics/libfpx
On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote: On 2013/02/13 19:08, O. Hartmann wrote: Setting only base system source compiler optins in /etc/src.conf, for instance # CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 which do NOT appear in /etc/make.conf, make building port grahpics/libfpx complaining about unrecognized compiler options. As far a sI know, /etc/src.conf is ONLY for building the source tree of the operating system and make.conf is supposed to contain all stuff necessary for compiling both world and ports, but /etc/src.conf is world only. Am I wrong? Oliver Yes. Because files/Makefile.bsd includes bsd.lib.mk, /etc/src.conf is included. src.conf(5) says: The only purpose of src.conf is to control the compilation of the FreeBSD source code, which is usually located in /usr/src. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Expanding ZFS RAIDZ on the fly?
On Fri, Jan 11, 2013 at 7:10 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: My question may sound naiv, sorry. I have already set up a RAIDZ (on FreeBSD 10.0-CUR), comprised with three 3 TB disks. I'd like to expand the array with an additional disk - on the fly. oh It's not possible to expand by just 1 disk. Expanding with another 3 disks is possible though, or backup, destroy, create, restore. Expanding or reducing the number of disks in a raidz is the mythical block pointer rewrite functionality, google will tell more. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Removing firewire support from GENERIC
On Fri, Oct 19, 2012 at 3:25 PM, Dag-Erling Smørgrav d...@des.no wrote: Firewire is - a significant security risk - an obstacle to functining suspend / resume on many systems - rapidly becoming obsolete - available as a module The attached patch removes it from GENERIC across the board. Any serious objections before I commit it to head? DES Hi DES Would dcons over firewire still work in GENERIC, with firewire as a module? Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Buying recommendation for silent router/fileserver
On Fri, Oct 12, 2012 at 10:58 AM, Ulrich Spörlein u...@freebsd.org wrote: Btw, eSATA is supposed to simply show up as another SATA port in FreeBSD, right? No special driver supported needed for that one? Yep, I have an eSATA hard drive dock, drop the drive in and it is instantly recognised. The eSATA port in my case comes from Intel ICH10, and uses ahci(4). Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Buying recommendation for silent router/fileserver
On Thu, Oct 11, 2012 at 3:54 PM, Ulrich Spörlein u...@freebsd.org wrote: Hey guys, I need to replace an aging Pentium IV system that has been serving as my router, access point, file- and mediaserver for quite some time now. The replacement should have: - amd64 CPU (for ZFS, obviously) - 2x GigE (igress, egress interfaces) - some form of wlan interface (I currently use an Atheros based PCI card) … For Wifi I can always fall back to sticking in a supported USB stick, although that's kinda hacky. Are you planning to have the wifi act as an access point? Very few USB wlan devices support hostap mode; and those that do, don't support it very well. I've used a ural(4) stick in hostap before; any client that supports client power save, and that you can't disable power save on, will fall lose link as soon as it tries to enable power save. I don't know of any other wifi sticks that support hostap. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nice-ing a service?
On Wed, Sep 12, 2012 at 11:31 AM, Ivan Voras ivo...@freebsd.org wrote:
Hi,
For whatever reason, I'd like to start services, from a properly formed
rc.d script, configured via /etc/rc.conf, etc. with a custom nice
value. Is there already support for this?
rc.subr indicates you can use ${name}_nice for this purpose.
Cheers
Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: geom mirror now rebuilding on every reboot?
Alexander Motin wrote: I think the right answer would be to remove stale Promise format RAID metadata from the disk. You should be able to do it by booting from any source and doing `graid list -a` to see all RAID GEOMs (even broken) and then remove them with `graid remove Promise ad4`. thanks, that fixed it. tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: geom mirror now rebuilding on every reboot?
not quite the same issue, but i tried to update a system with gmirror from FreeBSD eris.uffner.com 10.0-CURRENT FreeBSD 10.0-CURRENT #210: Thu Mar 15 16:41:18 EDT 2012 t...@eris.uffner.com:/usr/obj/usr/src/sys/ERIS i386 to -current from Aug 4th, and booting now fails into mountroot with GEOM_RAID: Promise: Array Promise Created GEOM_RAID: Promise: Disk ad4 state changed from NONE to SPARE GEOM_MIRROR: Cannot open consumer ad4 (error=1) GEOM_MIRROR: Cannot add disk ad4 to gm0 (error=1) GEOM_MIRROR: Device gm0 destroyed GEOM_RAID: Promise: Array Promise Created GEOM_RAID: Promise: Disk ad6 state changed from NONE to SPARE GEOM_MIRROR: Cannot open consumer ad6 (error=1) GEOM_MIRROR: Cannot add disk ad6 to gm0 (error=1) GEOM_MIRROR: Device gm0 destroyed nor will it boot from the underlying partitions (ad4s1a, ad6s1a), even if i unplug one of the drives. the partitions metadata are not corrupt and work just fine if i revert to the previous kernel. i haven't had time yet to track down the commit where this breaks. i was just wondering if anyone knew offhand what is going on how to fix it. tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Migrating from FreeBSD 9.0-STABLE/amd to 10.0-CURRENT/amd64?
On Tue, Mar 6, 2012 at 4:09 PM, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Hello. […] Well, I tried to switch by doing a svn switch in /usr/src, building a kernel, restarting the kernel in single user mode and then trying to build the world. At some point in /usr/src/share (I forgot were exactly, it was somewhere with lots of locale stuff), the buildworld process fails so I couldn't build a world. /usr/src/UPDATING says this: To upgrade in-place from 8.x-stable to current -- make sure you have good level 0 dumps make buildworld [9] make kernel KERNCONF=YOUR_KERNEL_HERE [8] [1] reboot in single user [3] mergemaster -p [5] make installworld mergemaster -i [4] make delete-old [6] reboot Even though it says 8.x, I would start from these instructions. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with ACPI / reboot: Black Screen? Part No 2
On Tue, Jan 10, 2012 at 7:12 PM, Fischer Markus mfisc...@reitzner.de wrote: Hello, I habe a BIG Problem with the ACPI Interface. The problem is the reboot command. The Shutdown command works. I don't think ``reboot`` is the command you want. If you want the computer to shut down, and then restart, you should use ``shutdown -r now``, which will invoke ``reboot`` at the appropriate point. Easy enough to check... Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstall kbdmap
On Thu, Jan 5, 2012 at 12:58 AM, Edwin L. Culp W. edwinlc...@gmail.com wrote: I really appreciate your help but I am having a hard time understanding because this has been working perfectly on FreeBSD 9.0 since new. ( 4 months ago ) Just incase it is important. # uname -a FreeBSD home.encontacto.net 9.0-STABLE FreeBSD 9.0-STABLE #44: Wed Jan 4 05:03:08 CST 2012 r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO amd64 My rc.conf has keymap=spanish.iso.acc.kbd Are you sure this is right? My rc.conf has: keymap=uk.iso ie, no '.kbd' file ending, which is implied. I have no /etc/X11 configuration file and haven't ever needed one. The mouse has never had a problem until I reset the server this morning. Mouse? I thought you were talking about keyboard! To get the correct keymap in X from hal, you need to add a policy file, exactly as described in the handbook. Possibly you didn't have hal enabled in earlier X builds, but if you want it to work with hal, you need the policy file. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Dog Food tm
On Thu, Dec 8, 2011 at 3:55 PM, Sean Bruno sean...@yahoo-inc.com wrote: On Thu, 2011-12-08 at 02:08 -0800, Peter Maloney wrote: And what problems did you run into? More or less, trying to do gmirror(4) style mirroring on GPT partitions doesn't work. See http://www.freebsd.org/doc/handbook/geom-mirror.html for the BIG RED WARNING that says why. Er, gmirroring GPT _partitions_ works just fine. It is when you try to gmirror an entire disk that is partitioned with GPT that you have issues, as gmirror trashes the secondary GPT table at the end of the disk. You do not have that issue with individual GPT partitions. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CVS removal from the base
On Sat, Dec 3, 2011 at 3:24 PM, Max Khon f...@samodelkin.net wrote: CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. In my mind, a first step would be to move ports to subversion, initially using svn-cvs bridge. Once done, the next step would be to change all infrastructure scripts so that they can build from/be driven by subversion. After that, nothing in base would use cvs for any purpose, and at that point I would be happy for it to be dropped from base - but only if it was replaced by subversion. I think it is important that with a base install of FreeBSD you can check out and update the source and rebuild itself. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CVS removal from the base
On Mon, Dec 5, 2011 at 3:12 PM, Lowell Gilbert freebsd-current-lo...@be-well.ilk.org wrote: Tom Evans tevans...@googlemail.com writes: On Sat, Dec 3, 2011 at 3:24 PM, Max Khon f...@samodelkin.net wrote: CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. Max Khon was the one who posted the original message in the thread. That message explicitly stated that moving ports and doc away from CVS was a prerequisite for removing CVS from base. As far as I've noticed, no one has challenged that. I'm trying to think of a way to fit the previous paragraph into the bikeshed metaphor, but I'm coming up with nothing. The bikeshed is discussing about how cvs will eventually be removed from base when there are known, unsolved, issues that block that happening. Removing CVS will be an emotive issue, there is no need to discuss it until appropriate, as every one (like me) will wade in saying that x is good and must stay and x is bad and must die, and every colour of bike shed in between. Just look at the number of replies to this topic. It would be much better to concentrate on the other issues rather than animated discussion of something that cannot realistically happen for quite some time yet. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Fri, Oct 28, 2011 at 11:05 AM, Thomas Mueller mueller6...@bellsouth.net wrote: Update: the fix didn't work, even though I have the necessary things in master.passwd and /etc/rc.conf . Did you re-run pwd_mkdb? How does one run mergemaster without running roughshod over existing configuration? So when mergemaster runs, it will ask you if you want to (i)nstall (d)elete or (m)erge the changes. If there are no additions to the file - eg new users or groups from the source - then you can just delete the update. If there are new users/groups, you need to merge them in. If you choose merge for /etc/group and /etc/master.passwd, it will show you the differences, and ask you to choose from the option on the left (your original file) or the right (the updated file) to merge them in. Cheers Tom PS Here is a log of me updating my /etc/group, as a new group 'hast' has been added that is not in my /etc/group *** Displaying differences between ./etc/group and installed version: --- /etc/group 2011-05-05 10:54:43.0 +0100 +++ ./etc/group 2011-10-28 11:39:54.0 +0100 @@ -1,11 +1,11 @@ -# $FreeBSD: src/etc/group,v 1.35.10.1.6.1 2010/12/21 17:09:25 kensmith Exp $ +# $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ # -wheel:*:0:root,tom +wheel:*:0:root daemon:*:1: kmem:*:2: sys:*:3: tty:*:4: -operator:*:5:root,tom +operator:*:5:root mail:*:6: bin:*:7: news:*:8: @@ -26,21 +26,7 @@ dialer:*:68: network:*:69: audit:*:77: -www:*:80:tom +www:*:80: +hast:*:845: nogroup:*:65533: nobody:*:65534: -tom:*:1001: -cyrus:*:60: -messagebus:*:556: -avahi:*:558: -polkit:*:562: -haldaemon:*:560: -pulse:*:563: -pulse-access:*:564: -pulse-rt:*:557: -gdm:*:92: -pgsql:*:70: -rabbitmq:*:135: -_sabnzbd:*:350: -squid:*:100: -webcamd:*:145:tom Use 'd' to delete the temporary ./etc/group Use 'i' to install the temporary ./etc/group Use 'm' to merge the temporary and installed versions Use 'v' to view the diff results again Default is to leave the temporary file to deal with by hand How should I deal with this? [Leave it for later] m # $FreeBSD: src/etc/group,v 1.35.10.1.6.1 2010/12/21 17:09:25 kensmith Exp $ |# $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ %r wheel:*:0:root,tom| wheel:*:0:root %l operator:*:5:root,tom | operator:*:5:root %l www:*:80:tom | www:*:80: hast:*:845: %r tom:*:1001: cyrus:*:60: messagebus:*:556: avahi:*:558: polkit:*:562: haldaemon:*:560: pulse:*:563: pulse-access:*:564: pulse-rt:*:557: gdm:*:92: pgsql:*:70: rabbitmq:*:135: _sabnzbd:*:350: squid:*:100: webcamd:*:145:tom %l Use 'i' to install merged file Use 'r' to re-do the merge Use 'v' to view the merged file Default is to leave the temporary file to deal with by hand *** How should I deal with the merged file? [Leave it for later] v # $FreeBSD: stable/8/etc/group 220104 2011-03-28 17:41:10Z trociny $ # wheel:*:0:root,tom daemon:*:1: kmem:*:2: sys:*:3: tty:*:4: operator:*:5:root,tom mail:*:6: bin:*:7: news:*:8: man:*:9: games:*:13: ftp:*:14: staff:*:20: sshd:*:22: smmsp:*:25: mailnull:*:26: guest:*:31: bind:*:53: proxy:*:62: authpf:*:63: _pflogd:*:64: _dhcp:*:65: uucp:*:66: dialer:*:68: network:*:69: audit:*:77: www:*:80: hast:*:845: nogroup:*:65533: nobody:*:65534: tom:*:1001: cyrus:*:60: messagebus:*:556: avahi:*:558: polkit:*:562: haldaemon:*:560: pulse:*:563: pulse-access:*:564: pulse-rt:*:557: gdm:*:92: pgsql:*:70: rabbitmq:*:135: _sabnzbd:*:350: squid:*:100: webcamd:*:145:tom Use 'i' to install merged file Use 'r' to re-do the merge Use 'v' to view the merged file Default is to leave the temporary file to deal with by hand *** How should I deal with the merged file? [Leave it for later] As you can see, the new file contains
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On Thu, Oct 27, 2011 at 11:22 AM, Thomas Mueller mueller6...@bellsouth.net wrote: I just finished the upgrade from source from 9.0-BETA2 to RC1, and I find two problems. First, I lost my users; nonroot user names are not recognized, if for instance I type passwd arlene I already tried to login as arlene with old password, no good. I copied the /etc directory to a backup on another disk cp -Rp /etc /media/etcbackup-BETA2 and then copied back /media/etcbackup-BETA2/passwd (and group) to /etc but that didn't help. Do I have to recreate nonroot users from scratch? Also, I got a warning about DBUS not starting. When I tried to startx as root, I got into X, but mouse and keyboard were nonfunctional; I did type Ctrl-Alt-F1 and Ctrl-C to get out of X. I think it was the second mergemaster part. Should I, as root and X not running, do mv /etc /etcbackup-RC1 and cp -Rp /media/etcbackup-BETA2 /etc where /media would be mount point for backup partition on USB 3.0 hard drive? The second invocation of mergemaster (after booting single-user) can wreak havoc on /etc . As I type this, I am in my older installation of FreeBSD 9.0-BETA1 but have access to RC1 partition. By the way, /etc/rc.conf remained intact, showing that hald_enable and dbus_enable are still there: hostname=amelia2 keymap=us.iso.kbd ifconfig_re0=DHCP ifconfig_re0_ipv6=inet6 accept_rtadv sshd_enable=YES moused_enable=YES ntpd_enable=YES hald_enable=YES dbus_enable=YES Tom I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. If you still have a backup, you are probably missing just master.passwd. hald, dbus would fail to start since their users are no longer there. Once you've done this to your system once, you never want to do it again! Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: '/bin/ls' broken by SVN r226509
On Wed, Oct 19, 2011 at 7:47 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: Thanks. Can you also please remind how to reinstall just /bin/ls, without the make buildworld? cp /rescue/ls /bin/ls Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: no X after installing xorg + xfce
On Tue, Sep 20, 2011 at 12:41 PM, Antonio Olivares olivares14...@gmail.com wrote: The first thing to try is reading the handbook section on configuring X at http://www.freebsd.org/doc/handbook/x-config.html - specifically try running Xorg -configure as root to get a basic xorg.conf file that you can then tweak Once you have this working, you may like to try the binary nvidia driver available from http://www.nvidia.co.uk/Download/index.aspx?lang=en-uk which should provide the all the features of the graphics card Anthony Been there! Done that! Makes no difference. X hangs and returns screen with many lines in colors but X does not work correctly. So thanks for advice, but no that does not help. Maybe what do I have to lose, I should try to rebuild system or reinstall to see if it makes a difference? Regards, Antonio 'Does not work correctly' covers everything from the background the wrong colour to the mouse being inverted and everything inbetween. I've skimmed the thread, (apologies if I've missed it), but I haven't yet seen your Xorg log or your config file. Almost every graphics card should work with VESA at a minimum. With an ancient graphics 'card' like a 6050, x11/nvidia-driver is the wrong driver, you want x11/nvidia-driver-173. However, the 173 series drivers do not support amd64 IIRC. With logs someone may be able to help you, without logs its just shouting out ideas why your X11 installation isn't working. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9.0
On Thu, Sep 15, 2011 at 3:42 PM, Alisson alisson...@gmail.com wrote: Somebody know when FreeBSD 9.0 Releng will be available? http://www.freebsd.org/releases/9.0R/schedule.html Remember that just because a date is in the schedule, doesn't make it a hard date. So I don't know, but sometime soon, when it is ready. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: http://www.freebsd.org/marketing/os-comparison.html
On Wed, Aug 31, 2011 at 7:51 PM, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: On 08/31/11 20:13, Garrett Cooper wrote: The list would be way too long. I know other Linux-based groups that have integrated drivers from FreeBSD as well for proprietary work. Thanks, -Garrett And claimed then it's GPLv3? Not that anything is (legally) wrong with that. All code re-use is good - if so many OSes hadn't reused BSD sockets, we probably wouldn't be having this discussion now. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA1 IPv6 crash
2011/8/22 Sergey Kandaurov pluk...@gmail.com: On 8 August 2011 22:06, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote: 2011/8/7 Sergey Kandaurov pluk...@gmail.com: On 7 August 2011 17:11, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote: I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the new installer. Major issue I noticed was the missing /home. It took me quite some time to get IPv6 working in the guest (a Linux configuration issue), but now that it works BETA1 panics in about 50% of the boot attempts: testbsd dumped core - see /var/crash/vmcore.0 Sun Aug 7 08:25:28 CEST 2011 FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 UTC 2011 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... [..] panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 cpuid = 0 KDB: enter: panic Uptime: 28s Physical memory: 491 MB Dumping 45 MB: 30 14 #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc0a04965 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:430 #2 0xc0a04291 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc09f4a4a in _mtx_lock_sleep (m=0xc35f3a28, tid=3278693824, opts=0, file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676) at /usr/src/sys/kern/kern_mutex.c:341 #4 0xc09f4c67 in _mtx_lock_flags (m=0xc35f3a28, opts=0, file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676) at /usr/src/sys/kern/kern_mutex.c:203 #5 0xc0bbf007 in mld_set_version (mli=0xc3589a00, version=Variable version is not available. ) at /usr/src/sys/netinet6/mld6.c:1676 #6 0xc0bc0c00 in mld_input (m=0xc3951e00, off=48, icmp6len=24) at /usr/src/sys/netinet6/mld6.c:690 #7 0xc0ba5696 in icmp6_input (mp=0xc3313a54, offp=0xc3313a68, proto=58) at /usr/src/sys/netinet6/icmp6.c:654 #8 0xc0bba23a in ip6_input (m=0xc3951e00) at /usr/src/sys/netinet6/ip6_input.c:964 #9 0xc0ac9b1c in netisr_dispatch_src (proto=10, source=0, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1013 #10 0xc0ac9da0 in netisr_dispatch (proto=10, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1104 #11 0xc0abecf1 in ether_demux (ifp=0xc35f3800, m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:936 #12 0xc0abf1b3 in ether_nh_input (m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:755 #13 0xc0ac9b1c in netisr_dispatch_src (proto=9, source=0, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1013 #14 0xc0ac9da0 in netisr_dispatch (proto=9, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1104 #15 0xc0abe7f5 in ether_input (ifp=0xc35f3800, m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:796 #16 0xc0672bc9 in lem_handle_rxtx (context=0xc3732000, pending=1) at /usr/src/sys/dev/e1000/if_lem.c:3554 #17 0xc0a468ab in taskqueue_run_locked (queue=0xc359ca80) at /usr/src/sys/kern/subr_taskqueue.c:306 #18 0xc0a47307 in taskqueue_thread_loop (arg=0xc37365ec) at /usr/src/sys/kern/subr_taskqueue.c:495 #19 0xc09d7af8 in fork_exit (callout=0xc0a472a0 taskqueue_thread_loop, arg=0xc37365ec, frame=0xc3313d28) at /usr/src/sys/kern/kern_fork.c:941 #20 0xc0d1d714 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) This is the same as in PR kern/158426. Can you try the patch from PR followup and report us whether it helps? Full link to PR with patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/158426 I applied the patch and tried about 15 reboots and all went fine Hi, Tom. A better fix for this problem has been developed since then. Would you please try it as well? For doing that, you need to revert a previous patch and apply this one. Please report if this change also fixes the panic for you, so it has better chances to get into 9.0 release. Index: sys/netinet6/mld6.c === --- sys/netinet6/mld6.c (revision 224471) +++ sys/netinet6/mld6.c (working copy) @@ -680,7 +680,6 @@ mld_v1_input_query(struct ifnet *ifp, const struct IN6_MULTI_LOCK(); MLD_LOCK(); - IF_ADDR_LOCK(ifp); /* * Switch to MLDv1 host compatibility mode. @@ -693,6 +692,7 @@ mld_v1_input_query(struct ifnet *ifp, const struct if (timer == 0) timer = 1; + IF_ADDR_LOCK(ifp
Re: Can't map a Spanish keyboard on Current but in FreeBSD 7.4-STABLE it works fin.
On Sat, Aug 6, 2011 at 12:07 AM, eculp ec...@encontacto.net wrote: I'm running kde on both and 7.4 works equally well with ttys and with kde4-4.6.5. My FreeBSD 9.0-BETA1 works with ttys but not even close with kde4-4.6.5. Is this me or could it be kde or Current? There doesn't seem to be any changes in the language files spanish.iso.acc.kbd, for example. I've been tolerating this for the last week since setting it up with Beta1. Thanks, ed Have you told hald that the keyboard has a different layout? IE, do you have this: $ cat /usr/local/etc/hal/fdi/policy/x11-input.fdi ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input.keyboard merge key=input.x11_options.XkbLayout type=stringes/merge /match /device /deviceinfo Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA1 IPv6 crash
2011/8/7 Sergey Kandaurov pluk...@gmail.com: On 7 August 2011 17:11, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote: I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the new installer. Major issue I noticed was the missing /home. It took me quite some time to get IPv6 working in the guest (a Linux configuration issue), but now that it works BETA1 panics in about 50% of the boot attempts: testbsd dumped core - see /var/crash/vmcore.0 Sun Aug 7 08:25:28 CEST 2011 FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 UTC 2011 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... [..] panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 cpuid = 0 KDB: enter: panic Uptime: 28s Physical memory: 491 MB Dumping 45 MB: 30 14 #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc0a04965 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:430 #2 0xc0a04291 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc09f4a4a in _mtx_lock_sleep (m=0xc35f3a28, tid=3278693824, opts=0, file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676) at /usr/src/sys/kern/kern_mutex.c:341 #4 0xc09f4c67 in _mtx_lock_flags (m=0xc35f3a28, opts=0, file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676) at /usr/src/sys/kern/kern_mutex.c:203 #5 0xc0bbf007 in mld_set_version (mli=0xc3589a00, version=Variable version is not available. ) at /usr/src/sys/netinet6/mld6.c:1676 #6 0xc0bc0c00 in mld_input (m=0xc3951e00, off=48, icmp6len=24) at /usr/src/sys/netinet6/mld6.c:690 #7 0xc0ba5696 in icmp6_input (mp=0xc3313a54, offp=0xc3313a68, proto=58) at /usr/src/sys/netinet6/icmp6.c:654 #8 0xc0bba23a in ip6_input (m=0xc3951e00) at /usr/src/sys/netinet6/ip6_input.c:964 #9 0xc0ac9b1c in netisr_dispatch_src (proto=10, source=0, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1013 #10 0xc0ac9da0 in netisr_dispatch (proto=10, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1104 #11 0xc0abecf1 in ether_demux (ifp=0xc35f3800, m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:936 #12 0xc0abf1b3 in ether_nh_input (m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:755 #13 0xc0ac9b1c in netisr_dispatch_src (proto=9, source=0, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1013 #14 0xc0ac9da0 in netisr_dispatch (proto=9, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1104 #15 0xc0abe7f5 in ether_input (ifp=0xc35f3800, m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:796 #16 0xc0672bc9 in lem_handle_rxtx (context=0xc3732000, pending=1) at /usr/src/sys/dev/e1000/if_lem.c:3554 #17 0xc0a468ab in taskqueue_run_locked (queue=0xc359ca80) at /usr/src/sys/kern/subr_taskqueue.c:306 #18 0xc0a47307 in taskqueue_thread_loop (arg=0xc37365ec) at /usr/src/sys/kern/subr_taskqueue.c:495 #19 0xc09d7af8 in fork_exit (callout=0xc0a472a0 taskqueue_thread_loop, arg=0xc37365ec, frame=0xc3313d28) at /usr/src/sys/kern/kern_fork.c:941 #20 0xc0d1d714 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) This is the same as in PR kern/158426. Can you try the patch from PR followup and report us whether it helps? Full link to PR with patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/158426 -- wbr, pluknet I applied the patch and tried about 15 reboots and all went fine ___ 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
BETA1 IPv6 crash
I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the new installer. Major issue I noticed was the missing /home. It took me quite some time to get IPv6 working in the guest (a Linux configuration issue), but now that it works BETA1 panics in about 50% of the boot attempts: testbsd dumped core - see /var/crash/vmcore.0 Sun Aug 7 08:25:28 CEST 2011 FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 UTC 2011 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 UTC 2011 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. CPU: QEMU Virtual CPU version 0.14.0 (3013.63-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x623 Family = 6 Model = 2 Stepping = 3 Features=0x783fbfdFPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2 Features2=0x80802001SSE3,CX16,POPCNT,HV AMD Features=0x100800SYSCALL,NX AMD Features2=0x61LAHF,ABM,SSE4A real memory = 536870912 (512 MB) avail memory = 501788672 (478 MB) Event timer LAPIC quality 400 ACPI APIC Table: BOCHS BXPCAPIC ioapic0: Changing APIC ID to 1 ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: BOCHS BXPCRSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0xb008-0xb00b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci_link4: Unable to route IRQs: AE_NOT_FOUND isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc580-0xc58f at device 1.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 uhci0: Intel 82371SB (PIIX3) USB controller port 0xc540-0xc55f irq 11 at device 1.2 on pci0 usbus0: controller did not stop usbus0: Intel 82371SB (PIIX3) USB controller on uhci0 pci0: bridge at device 1.3 (no driver attached) vgapci0: VGA-compatible display mem 0xfc00-0xfdff,0xfebf-0xfebf0fff at device 2.0 on pci0 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.3 port 0xc500-0xc53f mem 0xfebc-0xfebd irq 11 at device 3.0 on pci0 em0: Memory Access and/or Bus Master bits were not set! em0: Ethernet address: 52:54:00:d6:ff:9e pcm0: Intel ICH (82801AA) port 0xc000-0xc3ff,0xc400-0xc4ff irq 11 at device 4.0 on pci0 pcm0: SigmaTel STAC9700/83/84 AC97 Codec pci0: memory, RAM at device 5.0 (no driver attached) hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 1 Hz quality 950 atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: floppy drive controller port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 attimer0: AT timer at port 0x40 on isa0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 ppc0: parallel port not found. uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Timecounters tick every 10.000 msec pcm0: measured ac97 link rate at 64028 Hz usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: Intel at usbus0 uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: QEMU HARDDISK 0.14.0 ATA-7 device ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada0: 12288MB (25165824 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: QEMU QEMU DVD-ROM 0.14 Removable CD-ROM SCSI-0 device cd0: 16.700MB/s transfers (WDMA2, ATAPI
Re: freebsd-current Digest, Vol 398, Issue 3
On Jun 1, 2011, at 8:03, freebsd-current-requ...@freebsd.org wrote: Send freebsd-current mailing list submissions to freebsd-current@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-current or, via email, send a message with subject or body 'help' to freebsd-current-requ...@freebsd.org You can reach the person managing the list at freebsd-current-ow...@freebsd.org When replying, please edit your Subject line so it is more specific than Re: Contents of freebsd-current digest... Today's Topics: 1. Re: Testing new nfs and VIMAGE (Goran Lowkrantz) 2. Re: [rfc] remove hlt_cpus et al sysctls and related code (Attilio Rao) 3. Re: [rfc] remove hlt_cpus et al sysctls and related code (Andriy Gapon) 4. Re: ZFS install from -CURRENT snapshot (Alexander Leidinger) 5. Re: pcib allocation failure (John Baldwin) 6. Re: message buffer scrambling fix (Kenneth D. Merry) 7. Re: mount root from zfs fails under current with error 6 (Michael Reifenberger) 8. Re: mount root from zfs fails under current with error 6 (Andriy Gapon) 9. lazy mmap for a device driver ? (Luigi Rizzo) 10. Re: lazy mmap for a device driver ? (Kostik Belousov) 11. Re: Boot halts on Thinkpad X220 (Sandy Bridge) (Jung-uk Kim) 12. Re: Boot halts on Thinkpad X220 (Sandy Bridge) (Jung-uk Kim) 13. Re: Boot halts on Thinkpad X220 (Sandy Bridge) (Jung-uk Kim) -- Message: 1 Date: Tue, 31 May 2011 14:34:22 +0200 From: Goran Lowkrantz g...@hidden-powers.com Subject: Re: Testing new nfs and VIMAGE To: freebsd-current@freebsd.org Cc: Rick Macklem rmack...@uoguelph.ca Message-ID: 1DE98FADA8318788A5DD5505@[172.16.2.57] Content-Type: text/plain; charset=us-ascii For the list: Attached patch works. /glz --On May 28, 2011 19:28:43 -0400 Rick Macklem rmack...@uoguelph.ca wrote: It worked when I added CURVNET_SET/CURVNET_RESTORE around the RTFREE_LOCKED macro too. Attached a complete patch. Thank you. and thanks for finding/reporting/testing it. I've attached another variant of the patch that maybe you could try? (I don't think it's necessary to do twice, so I just moved the CURVNET_RESTORE() to after the RTFREE_LOCKED() macro instead.) I don't know if you are a committer for this stuff or not? If you are feel free to commit whichever variant of the patch you find works and prefer. If not, maybe bz@ could either commit it or review it? (or whoever is doing the VIMAGE stuff these days?) rick -- next part -- A non-text attachment was scrubbed... Name: curvnet.patch Type: text/x-patch Size: 1144 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20110531/2c83e02d/curvnet-0001.bin -- Message: 2 Date: Tue, 31 May 2011 09:34:44 -0400 From: Attilio Rao atti...@freebsd.org Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code To: Andriy Gapon a...@freebsd.org Cc: freebsd-current@freebsd.org freebsd-current@freebsd.org, freebsd-a...@freebsd.org freebsd-a...@freebsd.org Message-ID: BANLkTinLwVZqQ3C0E4Ey=twnv5blz+u...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 2011/5/31 Andriy Gapon a...@freebsd.org: on 29/05/2011 06:06 Attilio Rao said the following: 2011/5/28 Attilio Rao atti...@freebsd.org: 2011/5/25 Andriy Gapon a...@freebsd.org: The patch is here: http://people.freebsd.org/~avg/cpu-offline-sysctl.diff It should implement the strategy described above. I don't see the point in keeping alive mp_grab_cpu_hlt() and supporting, actually. On the top of your patch I made some modifies that use directly ap_watchdog() in cpu_idle() which I think is better for the time being: http://www.freebsd.org/~attilio/avg_rem_cpuhlt.diff Yes, I agree, thank you. If you are happy with it, just commit as long as Garrett tests that. OK. Waiting for test feedback. On a second round of changes we can discuss mp_watchdog and eventual removal / improvements to it. I almost forgot: this change would also require an UPDATE entry, where you explicitly mention the new way to deal with CPUs. Use your prefer wording. Sure. Thank you! BTW, I guess there would be no reason to MFC this change? You mean no reason to not MFC it? In general, I think that users may expect those sysctls to be alive (IMHO we should consider sysctls to be part of the userland API) so that we can add some more, but we should not axe them. So probabilly MFC is not the best option here. Attilio -- Peace can only be achieved by understanding - A. Einstein -- Message: 3 Date: Tue, 31 May 2011 16:40:45 +0300 From: Andriy Gapon a...@freebsd.org Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code To:
Freezing PC with start of X with ATI Rage
On Sunday 19 December 2010 09:49:21 Vladislav Movchan wrote: On Sat, Dec 18, 2010 at 10:34 PM, Vladislav Movchan vladislav.movc...@gmail.com wrote: On Sat, Dec 18, 2010 at 11:14 AM, Christian Gusenbauer c...@gmx.at wrote: Hi! With commit r216333 to pmap.c my PC (i386 32 bit) freezes within a few seconds when X (with nvidia-driver 256.53) starts. I already recompiled and reinstalled the nvidia driver, but this didn't change anything. I also tried the latest nvidia-driver 260.19.29 but without luck, too :-(. By chance I saw a panic message vm_page_unwire: page 0x... wire count is zero, but no crash dump was generated. Any clues? Thanks, Christian. ___ 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 I can only add me too - I am experiencing the same problem with two i386 machines. Both PCs work fine on revision 216332 and hanging on revision 216333 or later. I've tried to use different nvidia-driver versions (195.36.24, 256.53 and 260.19.29), tried disabling glx/dri xorg extensions but nothing changed. Freeze happening before the moment when nvidia logo appears. Unfortunately I was never able to see panic message or obtain crash dump. If anybody have ideas I can help with testing. First machine: pciconf: vgap...@pci0:1:0:0: class=0x03 card=0x04421028 chip=0x0a2910de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = display subclass = VGA Xorg log: (--) PCI:*(0:1:0:0) 10de:0a29:1028:0442 nVidia Corporation GT216 [GeForce GT 330M] rev 162, Mem @ 0xfa00/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 0xe000/128, BIOS @ 0x/65536 Second one: pciconf: vgap...@pci0:1:0:0: class=0x03 card=0x34681458 chip=0x061110de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA GeForce 8800 GT (G92)' class = display subclass = VGA Xorg log: (--) PCI:*(0:1:0:0) 10de:0611:1458:3468 nVidia Corporation G92 [GeForce 8800 GT] rev 162, Mem @ 0xf600/16777216, 0xe000/268435456, 0xf400/33554432, I/O @ 0xb000/128, BIOS @ 0x/65536 -- Have a nice(1) day, Vladislav Movchan Update to r216555 fixed this problem for me. I have similar problems on my old Pentium-II with an ATI Rage, but the actual current still freezes. Stable is fine. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB 1.1 devs not working on ASUS K8VSE (x86) MB
according to kldstat -v, both uhci/usbus pci/uhci were present in my kernel but one or both of them was silently failing. apparently something in my sources was corrupt because deleting all of the USB related code from my CVS root, re-csuping it, and building a fresh kernel solved the problem. thanks for the help. tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB 1.1 devs not working on ASUS K8VSE (x86) MB
John Baldwin wrote: On Friday, December 10, 2010 8:13:01 pm Tom Uffner wrote: no...@pci0:0:16:0: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB Ok, can you show the output of 'pciconf -rb pci0:0:16:0 0x9'? [xiombarg#:~:1] pciconf -rb pci0:0:16:0 0x9 00 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB 1.1 devs not working on ASUS K8VSE (x86) MB
John Baldwin wrote: pci0:serial bus, USB at device 16.0 (no driver attached) pci0:serial bus, USB at device 16.1 (no driver attached) pci0:serial bus, USB at device 16.2 (no driver attached) pci0:serial bus, USB at device 16.3 (no driver attached) Can you get pciconf -lv output for these four devices? no...@pci0:0:16:0: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB no...@pci0:0:16:1: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB no...@pci0:0:16:2: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB no...@pci0:0:16:3: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB ___ 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
USB 1.1 devs not working on ASUS K8VSE (x86) MB
I have a fairly recent Current system running on an ASUS K8V SE Deluxe MB. It was a dual boot amd64/x86 system (until a few days ago when the drive w/ the amd64 partitions unexpectedly failed after only a week of use) When running it as x86, USB 1.1 devices are not recognized by FreeBSD. They worked fine on the amd64 kernel built from the same code. both ohci and uhci are in the kernel even though they don't show up in dmesg. the devices in question (currently a 1.1 hub and a mouse) are both seen and activated by the BIOS but turned off once FreeBSD takes over. I had the same problem with GENERIC kernels from the 9.0-current-201011 snapshot, so it is not my kernel config. the mouse also works fine on either x86 or amd64 when plugged into a USB 2.0 hub or a PS2 adapter. and both these devices worked w/ the x86 kernel on the previous incarnation of this system with an ASUS A7N8X MB (NVIDIA chipset) so i suspect that the problem may be in the initialization code for the Via chipset. thanks in advance for any help, tom FreeBSD xiombarg.uffner.com 9.0-CURRENT FreeBSD 9.0-CURRENT #292: Wed Dec 8 13:10:15 EST 2010 root@:/usr/obj/usr/src/sys/XIOMBARG i386 Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #292: Wed Dec 8 13:10:15 EST 2010 root@:/usr/obj/usr/src/sys/XIOMBARG i386 CPU: AMD Athlon(tm) 64 Processor 3200+ (2202.87-MHz 686-class CPU) Origin = AuthenticAMD Id = 0xfc0 Family = f Model = c Stepping = 0 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe0500800SYSCALL,NX,MMX+,LM,3DNow!+,3DNow! real memory = 2147483648 (2048 MB) avail memory = 2094309376 (1997 MB) Event timer LAPIC quality 400 ACPI APIC Table: A M I OEMAPIC ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 0.3 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7fef (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 8385 host to PCI bridge on hostb0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xa000-0xa0ff mem 0xe000-0xefff,0xfce0-0xfce0 irq 16 at device 0.0 on pci1 vgapci1: VGA-compatible display mem 0xd000-0xdfff,0xfcc0-0xfcc0 at device 0.1 on pci1 atapci0: Promise PDC20771 SATA300 controller port 0xe800-0xe87f,0xe400-0xe4ff mem 0xfda0-0xfda00fff,0xfd90-0xfd91 irq 16 at device 9.0 on pci0 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 ata4: ATA channel 2 on atapci0 skc0: Marvell Gigabit Ethernet port 0xe000-0xe0ff mem 0xfdc0-0xfdc03fff irq 17 at device 10.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:11:2f:38:7b:87 miibus0: MII bus on sk0 e1000phy0: Marvell 88E1011 Gigabit PHY PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto re0: RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet port 0xd800-0xd8ff mem 0xfd70-0xfd7000ff irq 17 at device 12.0 on pci0 re0: Chip rev. 0x1000 re0: MAC rev. 0x miibus1: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus1 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:14:d1:14:33:e6 pcm0: CMedia CMI8738 port 0xd400-0xd4ff irq 19 at device 14.0 on pci0 atapci1: VIA 6420 SATA150 controller port 0xd000-0xd007,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xb800-0xb80f,0xb400-0xb4ff irq 20 at device 15.0 on pci0 ata5: ATA channel 0 on atapci1 ata6: ATA channel 1 on atapci1 atapci2: VIA 8237 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: ATA channel 0 on atapci2 ata1: ATA channel 1 on atapci2 pci0: serial bus, USB at device 16.0 (no driver attached) pci0: serial bus, USB at device 16.1 (no driver attached) pci0: serial bus, USB at device 16.2 (no driver attached) pci0: serial bus, USB at device 16.3 (no driver attached) ehci0: VIA VT6202 USB 2.0 controller mem 0xfd50-0xfd5000ff irq 21 at device 16.4 on pci0 usbus0: EHCI version 1.0 usbus0: VIA VT6202 USB 2.0
Re: buildworld + ccache trouble
On 09/15/2010 09:53 AM, Maxim Khitrov wrote: On Wed, Sep 15, 2010 at 8:44 AM, Dmitry Krivenok krivenok.dmi...@gmail.com wrote: Hello All! I recently updated to r212634 and tried to build CURRENT tree with ccache. However, I got build error: snip Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Is it a know issue? Any solutions? If I remember correctly, this happens when you try to build 32-bit library set on amd64 (you do not have WITHOUT_LIB32 set in /etc/src.conf). My solution was to disable 32-bit support by setting that option. If you're still using ccache version 2.4, try upgrading to 3.0.1, though I'm not sure if this problem has been fix. The only other alternative that I know of is to not use ccache to buildworld on amd64. In the past I have used the solution outlined here: http://www.tomjudge.com/index.php/FreeBSD/Creating_a_%28i386/ia32%29_build_cluster_using_amd64_and_i386_hosts This used to (in the 6.2 days) allow us to build i386 objects on amd64 hosts. It may work for you. Tom -- TJU13-ARIN ___ 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: AR9132 CPU and AR9100 wireless support
On 09/14/2010 04:08 PM, Outback Dingo wrote: Ive got some Ubiquiti mips devices id love to get FreeBSD on permanently and a Netgear WNDR370, if only we could boot FreeBSD out of redboot and flash it to them it would seriously ROCK, Booting FreeBSD out of redboot should be no problem. I have used the redboot loader on a Intel NAS to load a FreeBSD kernel and boot successfully, this was an arm core rather than mips however. If you have a working redboot you can also use the redboot shell to flash your kernel (with embedded MFS image) into the SPI part and then rewrite the load script to boot that. The debian-installer armel handbook had some useful docs in it for the platform I was working on, as well as the official redboot site. Tom On Tue, Sep 14, 2010 at 4:24 PM, Stefan Bethkes...@lassitu.de wrote: Am 14.09.2010 um 11:35 schrieb Adrian Chadd: Hi everyone, I've just pushed the initial support for the AR9100 wireless MAC into my git repository. This is for the WMAC on the AR9132 SoC. I've tested it in 11bg hostap mode on an AP83 derived box - the TP-Link TL-WR1043ND. The source tree has support for the CPU, ethernet (but not the switch PHY; it's enough to get data across it!); flash and the AR9100 WMAC. I've only tested open hostap mode on 11bg on a fixed channel. The GIT repo is at: http://www.gitorious.org/~adrianchadd/freebsd/adrianchadd-freebsd ; it's the work/atheros branch. You'll need to open the unit up, solder on some pins to get to the serial port and acquire a TTL - RS232 level converter. There's pictures and howto on the OpenWRT wiki: http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd That sounds really nice! Is there some guide on how to prepare an image? I'm quite familiar with OpenWrt (patching and building) and have a number of routers (WRT-160N, WR941NL, 500gP) with serial adapters attached, but from the messages on the mips list, it felt the bootstrapping process might be a bit dauting... Stefan -- Stefan Bethkes...@lassitu.deFon +49 151 14070811 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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: Ports doesnt respect fetch environment settings
2010/6/30 Dag-Erling Smørgrav d...@des.no: Tom Evans tevans...@googlemail.com writes: Sorry to bump this again. I've diluted this issue down to the core points and raised as a pr - can someone take a look, see if my solution is correct and commit if appropriate? Sorry, fell through the cracks. Your analysis is correct, but I'm not 100% sure about the patch. Can you verify that your change does not introduce the possibility of an infinite loop in edge cases? I don't *think* it does, but like I said, I'm not 100% sure and I don't have time to reacquaint myself with the code right now, especially not that particularly nasty part of it :) DES -- Dag-Erling Smørgrav - d...@des.no Like you said, it's quite a large chunk of code to understand. I think you might be right, there could be a situation where a misbehaving proxy server could make it loop. The process is like this: http_auth_challenges_t proxy_challenges struct initialized (line 1497). The flag 'valid' on the struct is initialized to 0 (line 656) We enter the loop for the first time. We dont add proxy auth the first time through the loop, as 'valid' flag not set (line 1586) We receive the reply and switch on the response code (line 1676) If we receive HTTP_NEED_PROXY_AUTH, and the 'valid' flag is not set (implying we didn't send creds), we simply continue to execute the loop (lines 1703 - 1716). This is where the patch I supplied increments the maximum loop counter. The loop now processes the received headers, and when it receives the 'Proxy-Authenticate' header, it calls http_parse_authenticate with proxy_challenges (line 1795) This then populates the proxy_challenges struct, setting the valid flag. Having processed the headers, the loop then checks that receiving a HTTP_NEED_PROXY_AUTH response has resulted in us now having valid flag set in proxy_challenges, otherwise we goto ouch (out of the loop) (line 1806). The loop ends, and we go through again. I thought for a moment while tracing it through that if a misbehaving proxy server sent a 407 response, but did not add a Proxy-Authenticate header, then we could increase the loop counter but without adding any proxy auth, which would mean an infinite loop. However, there is already that sanity check at the end of the loop to check that if we received a proxy authentication error, and still dont have credentials to supply, then we quickly jump out of the loop. I guess that is a little strange, that we could supply proxy auth credentials, but because the server didnt ask for them correctly, we didnt give them - although that would be quite broken behaviour on the part of the proxy server. I think this does show that the patch could be made a little better. We only want to go through the loop one more time if we have credentials to send, and we have credentials to send if the rv of http_parse_authenticate is good. I also think the same bug would affect fetching from servers requiring authentication, so I've made the same fix there as well. New patch attached Cheers Tom Index: http.c === RCS file: /home/ncvs/src/lib/libfetch/http.c,v retrieving revision 1.78.2.5 diff -u -r1.78.2.5 http.c --- http.c 27 Jan 2010 14:54:48 - 1.78.2.5 +++ http.c 1 Jul 2010 13:45:06 - @@ -1786,12 +1786,14 @@ case hdr_www_authenticate: if (conn-err != HTTP_NEED_AUTH) break; - http_parse_authenticate(p, server_challenges); + if (http_parse_authenticate(p, server_challenges)) + ++n; break; case hdr_proxy_authenticate: if (conn-err != HTTP_NEED_PROXY_AUTH) break; - http_parse_authenticate(p, proxy_challenges); + if (http_parse_authenticate(p, proxy_challenges) == 0); + ++n; break; case hdr_end: /* fall through */ ___ 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: Ports doesnt respect fetch environment settings
Sorry to bump this again. I've diluted this issue down to the core points and raised as a pr - can someone take a look, see if my solution is correct and commit if appropriate? http://www.freebsd.org/cgi/query-pr.cgi?pr=148087 Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
2010/6/29 Anton Shterenlikht me...@bristol.ac.uk: On Tue, Jun 29, 2010 at 12:03:39PM +0200, Dag-Erling Smørgrav wrote: Anton Shterenlikht me...@bristol.ac.uk writes: # make buildenv Entering world for ia64:ia64 # env LIBRARY_PATH=/usr/local/lib where does this come from? Your .bashrc or something? I've this set in $HOME/.tcsh. I don't remember why now. I probably fucked up.. However, I've got this set on 3 ia64 boxes. On two of them I don't have this lzma problem. Didn't you mention (about 70 emails previously) that you only had /usr/local/lib/libzma.a on one of your ia64 boxes, and the other two built world just fine? Does that explain why you dont have this problem on those boxes, with the same setting? Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 8:23 AM, Gary Jennejohn gljennj...@googlemail.com wrote: On Wed, 23 Jun 2010 18:15:09 -0700 Ted Faber fa...@isi.edu wrote: (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) [trimmed Cc] I use cupsd and have these settings to get around using the base system lp stuff: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. --- Gary Jennejohn I also have this in make.conf: CUPS_OVERWRITE_BASE=yes WITHOUT_LPR=yes which print/cups-base uses to do make any lpr related binaries in /usr/bin non-executable, so they are skipped over and the cups specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just stops LPR being built by buildworld. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: zfs panic
On Wed, Jun 23, 2010 at 10:01 PM, ben wilber b...@desync.com wrote: On Wed, Jun 23, 2010 at 01:47:33PM -0700, Xin LI wrote: panic: _sx_xlock_hard: recursed on non-recursive sx buf_hash_table.ht_locks[i].ht_lock @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/c ommon/fs/zfs/arc.c:1626 Any chance to obtain a backtrace for the panic? From r209229: db:0:kdb.enter.default bt Tracing pid 3233 tid 100396 td 0xff013600f000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x1c8 _sx_xlock_hard() at _sx_xlock_hard+0x93 _sx_xlock() at _sx_xlock+0xaa arc_buf_remove_ref() at arc_buf_remove_ref+0x7b dbuf_rele() at dbuf_rele+0x15d zfs_freebsd_reclaim() at zfs_freebsd_reclaim+0xe1 VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xe8 vgonel() at vgonel+0x186 vnlru_free() at vnlru_free+0x2f4 vfs_lowmem() at vfs_lowmem+0x31 kmem_malloc() at kmem_malloc+0x12c page_alloc() at page_alloc+0x18 keg_alloc_slab() at keg_alloc_slab+0xe6 keg_fetch_slab() at keg_fetch_slab+0x18e zone_fetch_slab() at zone_fetch_slab+0x4f uma_zalloc_arg() at uma_zalloc_arg+0x56b arc_get_data_buf() at arc_get_data_buf+0xaa arc_read_nolock() at arc_read_nolock+0x1cb arc_read() at arc_read+0x71 dbuf_read() at dbuf_read+0x4ea dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x119 dmu_buf_hold_array() at dmu_buf_hold_array+0x57 dmu_read_uio() at dmu_read_uio+0x3f zfs_freebsd_read() at zfs_freebsd_read+0x558 VOP_READ_APV() at VOP_READ_APV+0xe2 vn_read() at vn_read+0x1d0 dofileread() at dofileread+0x97 kern_preadv() at kern_preadv+0x6a pread() at pread+0x52 syscallenter() at syscallenter+0x217 syscall() at syscall+0x39 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (475, FreeBSD ELF64, pread), rip = 0x80100c14c, rsp = 0x7fbfeb48, rbp = 0x2 --- Thanks. I notice the traceback is in the UMA zone allocaor. Did it used to be stable? ZFS recently changed to using the UMA allocator, and I found this made my system less reliable. Does disabling this help? Add this to /boot/loader.conf: vfs.zfs.zio.use_uma=0 Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with buildworld with CLANG
On Wed, Jun 23, 2010 at 4:52 PM, Cristiano Deana cristiano.de...@gmail.com wrote: On Wed, Jun 23, 2010 at 3:15 PM, Tom Evans tevans...@googlemail.com wrote: Top of the '[TESTING] Clang..' email: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial import to be as painless as possible and therefore we ask you to test ClangBSD to assure that the revision we are importing does not have some really embarassing bugs. How to do it (on i386 and amd64): 1) svn co http://svn.freebsd.org/base/projects/clangbsd src i already did it and it worked, two weeks ago. now i wanted to try with clan in system 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf So uncomment your src.conf lines that are incompatible. forgot to tell before. i tried with and without those lines. The error in your first email was clearly a warning being promoted to an error, so either you had a different error on your build with NO_WERROR/WERROR, or your NO_WERROR/WERROR settings were not being respected. Please retry with NO_WERROR/WERROR set in /etc/src.conf, and show the resulting error. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 10:21 AM, Andrew Reilly arei...@bigpond.net.au wrote: On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. Since you have /usr/local/bin in your path, why bother with the symlinks at all? Your shell will find them in their new locations just fine. You'll want to remove the old ones from /usr/bin, but make delete-old will probably do that nicely anyway. Cheers, -- Andrew make delete-old removes old deprecated files, not files that weren't built because of src.conf options. It definitely will not remove the lpr binaries from /usr/bin if they exist there. There already is a proper solution for this: if you want to have LPR from CUPS, and don't want to use LPR from base, then you set these settings in make.conf: CUPS_OVERWRITE_BASE=yes WITHOUT_LPR=yes With these, lpr in base will not be built, and print/cups-base will deactivate any base system lpr binaries that are installed. It's documented in the FreeBSD CUPS article here: http://www.freebsd.org/doc/en/articles/cups/article.html#PRINTING-CUPS-PORTS-KNOBS Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 10:45 AM, Alex Dupre a...@freebsd.org wrote: Tom Evans ha scritto: make delete-old removes old deprecated files, not files that weren't built because of src.conf options. I think you are wrong: http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/build/mk/OptionalObsoleteFiles.inc?rev=1.66 -- Alex Dupre Meh, OK. It didn't used to, there was a discussion about this about 6 months ago, and yes, check the history of that file. This support was added in February, nothing in /usr/src/UPDATING about it.. Still, besides the point. There is one supported way to get cups-base lpr used instead of base lpr, and it's got not much to do with 'make delete-old'. http://www.freebsd.org/doc/en/articles/cups/article.html#PRINTING-CUPS-PORTS-KNOBS Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with buildworld with CLANG
On Thu, Jun 24, 2010 at 2:33 PM, Cristiano Deana cristiano.de...@gmail.com wrote: On Thu, Jun 24, 2010 at 11:24 AM, Tom Evans tevans...@googlemail.com wrote: The error in your first email was clearly a warning being promoted to an error, so either you had a different error on your build with NO_WERROR/WERROR, or your NO_WERROR/WERROR settings were not being respected. Please retry with NO_WERROR/WERROR set in /etc/src.conf, and show the resulting error. Last lines: /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:135:2: error: unsupported inline asm: input with type 'unsigned long' matching output with type 'unsigned int' R1(D,A,B,C,X( 4), 5,0x5A827999L); ^~~~ In file included from /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:60: /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_locl.h:108:4: note: instantiated from: a=ROTATE(a,s); };\ ^ /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:135:2: note: instantiated from: R1(D,A,B,C,X( 4), 5,0x5A827999L); ^ ~ /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:135:5: note: instantiated from: R1(D,A,B,C,X( 4), 5,0x5A827999L); ^ /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:136:2: error: unsupported inline asm: input with type 'unsigned long' matching output with type 'unsigned int' R1(C,D,A,B,X( 8), 9,0x5A827999L); ^~~~ In file included from /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:60: /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_locl.h:108:4: note: instantiated from: a=ROTATE(a,s); };\ ^ /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:136:2: note: instantiated from: R1(C,D,A,B,X( 8), 9,0x5A827999L); ^ ~ /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/md4/md4_dgst.c:136:5: note: instantiated from: R1(C,D,A,B,X( 8), 9,0x5A827999L); ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 4 warnings and 20 errors generated. *** Error code 1 Stop in /usr/src/secure/lib/libcrypto. *** Error code 1 So thats a completely different error than you had been reporting. I'm afraid I don't know enough about clang to help with that one. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with buildworld with CLANG
On Wed, Jun 23, 2010 at 1:38 PM, Cristiano Deana cristiano.de...@gmail.com wrote: # uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #3: Tue Jun 22 16:04:38 CEST 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 # cat /etc/src.conf #NO_WERROR= #WERROR= CC= clang CXX= clang++ sources from this morning, i got this error: clang -O2 -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/stack_protector.c /usr/src/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 error generated. *** Error code 1 Top of the '[TESTING] Clang..' email: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial import to be as painless as possible and therefore we ask you to test ClangBSD to assure that the revision we are importing does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf 3) cd src make buildworld So uncomment your src.conf lines that are incompatible. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Ports doesnt respect fetch environment settings
My company recently enabled proxy authentication for outgoing connections, and this has stopped ports from working. From fetch(5), I understand that I can place my proxy authentication in plain text in the environment*, and this will allow fetch to work correctly, and this does work: # env | grep -i proxy ftp_proxy=http://proxy:3128/ HTTP_PROXY_AUTH=basic:*:tev...@domain.com:password HTTP_PROXY=http://proxy:3128/ # fetch http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz googlecl-0.9.5.tar.gz 100% of 36 kB 77 MBps However, the ports makefiles seem to do something funky to my environment which hides these environment variables, and so the ports infrastructure stops working: # make fetch === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE = googlecl-0.9.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch from http://googlecl.googlecode.com/files/. fetch: http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz: Proxy Authentication Required = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz: Not Found = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/ and try again. *** Error code 1 Stop in /usr/FreeBSD/CURRENT/ports/net/googlecl. This is on i386 7-STABLE, last updated in mid May, with current ports, last updated yesterday. Cheers Tom * Which, incidently, is completely rubbish. Why is there no option for HTTP like ~/.netrc for FTP? Exposing my passwords in plain text in my environment feels stupid. ___ 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: Ports doesnt respect fetch environment settings
On Mon, Jun 21, 2010 at 11:10 AM, Erwin Lansing er...@freebsd.org wrote:
On Mon, Jun 21, 2010 at 11:04:16AM +0100, Tom Evans wrote:
My company recently enabled proxy authentication for outgoing
connections, and this has stopped ports from working.
From fetch(5), I understand that I can place my proxy authentication
in plain text in the environment*, and this will allow fetch to work
correctly, and this does work:
# env | grep -i proxy
ftp_proxy=http://proxy:3128/
HTTP_PROXY_AUTH=basic:*:tev...@domain.com:password
HTTP_PROXY=http://proxy:3128/
# fetch http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz
googlecl-0.9.5.tar.gz 100% of 36 kB 77 MBps
However, the ports makefiles seem to do something funky to my
environment which hides these environment variables, and so the ports
infrastructure stops working:
You should use FETCH_ENV or FETCH_ARGS to pass information to fetch(1) from
the
ports infrastructure. It is documented in /usr/ports/Mk/bsd.port.mk,
search for FETCH_BINARY. Hope that helps.
-erwin
Er, ok that makes slight sense. In /usr/ports/Mk/bsd.port.mk it says:
# FETCH_ENV - Environment to pass to ${FETCH_CMD}.
# Default: none
So how is it picking up that it needs to go thru a proxy at all, given
that this is also only specified in the environment?
Also, am I supposed to literally repeat my same environment variables
in FETCH_ENV? Meaning I have to place my password in plain text again
in my environment? This is horrific...
Also, even after doing that, it still doesn't look at the environment
variables. I prepended -v to FETCH_ENV to show that it is setting
the right environment variables, but fetch in ports is still not
looking at them:
# export FETCH_ENV=-v HTTP_PROXY=$HTTP_PROXY
HTTP_PROXY_AUTH=$HTTP_PROXY_AUTH ftp_proxy=$ftp_proxy
r...@strangepork '11:26:21' '/usr/ports/net/googlecl'
# make fetch
=== Vulnerability check disabled, database not found
=== License check disabled, port has not defined LICENSE
= googlecl-0.9.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
= Attempting to fetch from http://googlecl.googlecode.com/files/.
#env setenv:HTTP_PROXY=http://proxy:3128/
#env setenv:HTTP_PROXY_AUTH=basic:*:tev...@domain:pass
#env setenv:ftp_proxy=http://proxy:3128/
#env executing: /usr/bin/fetch
#envarg[0]= '/usr/bin/fetch'
#envarg[1]= '-ApRr'
#envarg[2]= '-S 37867'
#envarg[3]= 'http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz'
fetch: http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz:
Proxy Authentication Required
= Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/.
#env setenv:HTTP_PROXY=http://proxy:3128/
#env setenv:HTTP_PROXY_AUTH=basic:*:tev...@domain:pass
#env setenv:ftp_proxy=http://proxy:3128/
#env executing: /usr/bin/fetch
#envarg[0]= '/usr/bin/fetch'
#envarg[1]= '-ApRr'
#envarg[2]= '-S 37867'
#envarg[3]=
'ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz'
fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz:
Not Found
= Couldn't fetch it - please try to retrieve this
= port manually into /usr/ports/distfiles/ and try again.
*** Error code 1
*.freebsd.org is whitelisted through the proxies, which is why the
second fetch gets a 404 and not a 407
Any thoughts?
Cheers
___
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: Ports doesnt respect fetch environment settings
On Mon, Jun 21, 2010 at 12:07 PM, Gary Jennejohn gljennj...@googlemail.com wrote: Yes. When you ran fetch by hand you didn't have the -ApRr on the CL. Could it be that the 'p' flag is causing problems? Try running fetch by hand again with those flags and see what happens. If it fails, try removing the 'p' flag. -- Gary Jennejohn Yes, I went through the same logic - its not the 'p' flag, its the 'A' flag, which is supposed to prevent it following 302 redirects. In this case, it refuses to retry the request when it receives a 407. # /usr/bin/fetch -ApRr -v -S 37867 http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz looking up proxy connecting to proxy:3128 requesting http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz proxy requires authorization fetch: http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz: Proxy Authentication Required r...@strangepork '12:13:28' '/usr/ports/net/googlecl' # /usr/bin/fetch -pRr -v -S 37867 http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz looking up proxy connecting to proxy:3128 requesting http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz proxy requires authorization looking up proxy connecting to proxy:3128 requesting http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz local size / mtime: 37867 / 1276839258 remote size / mtime: 37867 / 1276839258 That doesn't seem right! Looking in lib/libfetch/http.c it tries to fetch the file in a loop. libfetch first tries without proxy authentication, even if you specify it in your environment. If the request fails due to proxy authentication being required, it sets a flag to add proxy auth details next time through the loop, and continues. If the '-A' flag is set however, it will only go through this loop one time, and so does not attempt to use the supplied proxy authentication. Comments in the source code imply that this is a change in behaviour introduced at the start of the year to support digest authentication; prior to that it would have attempted proxy auth on the first request. The flag for '-A' is documented as: -A Do not automatically follow ‘‘temporary’’ (302) redirects. Some broken Web sites will return a redirect instead of a not‐found error when the requested object does not exist. where as the behaviour is: Do not attempt to download this file more than once, for any reason. Having seen this, the bug is that we wish to go thru the loop one more time to retry with proxy authentication added, but the loop may exit on the next iteration. This diff allows it to go through the loop one more time, and now fetches the file correctly. Incidentally, having fixed fetch to work with '-A' thru a proxy that requires proxy auth, I now dont require anything in FETCH_ENV or FETCH_*_ARGS, it works correctly with the PROXY_* environment variables. Patch attached. Cheers Tom Index: /usr/src/lib/libfetch/http.c === RCS file: /home/ncvs/src/lib/libfetch/http.c,v retrieving revision 1.78.2.5 diff -u -r1.78.2.5 http.c --- /usr/src/lib/libfetch/http.c27 Jan 2010 14:54:48 - 1.78.2.5 +++ /usr/src/lib/libfetch/http.c21 Jun 2010 11:30:32 - @@ -1710,6 +1710,7 @@ goto ouch; } /* try again, but send the password this time */ + ++n; if (verbose) fetch_info(proxy requires authorization); break; ___ 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
patch submission for multiple branches
I have updated the twa driver (src/sys/dev/twa) and generated patches against RELENG_7 and RELENG_8. I submitted the patches separately in PR 147694 (RELENG_7) and PR 147695 (RELENG_8). PR 147694 has been closed as a duplicate of PR 147695. What happens to the patch for RELENG_7 (PR 147694)? What is the proper way to submit patches for multiple branches? Tom Couch ___ 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: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
Weongyo Jeong wrote: OK. The patch is ready to test. Could you please test it with attached patch? your patch got rid of the bwn0: unsupported rate 0 messages on my Dell Inspiron 1150. But it still gives me repeated: bwn0: RX decryption attempted (old 0 keyidx 0x1) and a few of the following: bwn0: need multicast update callback ts_to_ct(1274664456.824638117) = [2010-05-24 01:27:36] please let me know if there is anything you want me to test. Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #0: Sun May 16 00:05:17 EDT 2010 t...@zoe.uffner.com:/usr/obj/usr/src/sys/ZOE i386 Preloaded elf kernel /boot/kernel/kernel at 0xc0ab6000. Preloaded elf module /boot/kernel/if_bwn.ko at 0xc0ab6174. Preloaded elf module /boot/kernel/siba_bwn.ko at 0xc0ab6220. Preloaded elf module /boot/modules/bwn_v4_ucode.ko at 0xc0ab62d0. Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2597803596 Hz CPU: Intel(R) Celeron(R) CPU 2.60GHz (2597.80-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Family = f Model = 2 Stepping = 9 Features=0xbfebf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4400CNXT-ID,xTPR Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 128 KB, 2-way set associative, sectored cache, 64 byte line size real memory = 1073741824 (1024 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c26000 - 0x3ec82fff, 1040568320 bytes (254045 pages) avail memory = 1040355328 (992 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xcfae pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: x86bios: IVT 0x00-0x0004ff at 0xc000 x86bios: SSEG 0x01-0x01 at 0xc3b74000 x86bios: EBDA 0x09f000-0x09 at 0xc009f000 x86bios: ROM 0x0a-0x0e at 0xc00a ULE: setup cpu 0 wlan: 802.11 Link Layer snd_unit_init() u=0x00ff8000 [512] d=0x7c00 [32] c=0x03ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 firmware: 'bwn_v4_ucode' version 0: 0 bytes loaded at 0xc0a8b808 firmware: 'bwn_v4_ucode5' version 0: 22384 bytes loaded at 0xc0a8b808 firmware: 'bwn_v4_ucode11' version 0: 29864 bytes loaded at 0xc0a90f78 firmware: 'bwn_v4_ucode13' version 0: 32232 bytes loaded at 0xc0a98420 firmware: 'bwn_v4_ucode14' version 0: 31384 bytes loaded at 0xc0aa0208 firmware: 'bwn_v4_ucode15' version 0: 30488 bytes loaded at 0xc0aa7ca0 firmware: 'bwn_v4_pcm5' version 0: 1320 bytes loaded at 0xc0aaf3b8 firmware: 'bwn_v4_a0g1initvals5' version 0: 1840 bytes loaded at 0xc0aaf8e0 firmware: 'bwn_v4_a0g0initvals5' version 0: 1840 bytes loaded at 0xc0ab0010 firmware: 'bwn_v4_b0g0initvals5' version 0: 1840 bytes loaded at 0xc0ab0740 firmware: 'bwn_v4_b0g0initvals13' version 0: 2080 bytes loaded at 0xc0ab0e70 firmware: 'bwn_v4_a0g1bsinitvals5' version 0: 158 bytes loaded at 0xc0ab1690 firmware: 'bwn_v4_a0g0bsinitvals5' version 0: 158 bytes loaded at 0xc0ab172e firmware: 'bwn_v4_b0g0bsinitvals5' version 0: 158 bytes loaded at 0xc0ab17cc firmware: 'bwn_v4_lp0initvals13' version 0: 3618 bytes loaded at 0xc0ab186a firmware: 'bwn_v4_lp0initvals14' version 0: 2064 bytes loaded at 0xc0ab268c firmware: 'bwn_v4_lp0initvals15' version 0: 2052 bytes loaded at 0xc0ab2e9c firmware: 'bwn_v4_lp0bsinitvals13' version 0: 158 bytes loaded at 0xc0ab36a0 firmware: 'bwn_v4_lp0bsinitvals14' version 0: 158 bytes loaded at 0xc0ab373e firmware: 'bwn_v4_lp0bsinitvals15' version 0: 158 bytes loaded at 0xc0ab37dc firmware: 'bwn_v4_n0bsinitvals11' version 0: 158 bytes loaded at 0xc0ab387a kbd: new array size 4 kbd1 at kbdmux0 nfslock: pseudo-device mem: memory Pentium Pro MTRR support enabled null: null device, zero device io: I/O random: entropy source, Software, Yarrow ACPI: RSDP 0xfdf00 00014 (v0 DELL ) ACPI: RSDT 0x3fef 00028 (v1 DELLCPi R 27D50605 ASL 0061) ACPI: FACP 0x3fef0400 00074 (v1 DELLCPi R 27D50605 ASL 0061) ACPI: DSDT 0x3fef0c00 02594 (v1 INT430 SYSFexxx 1001 MSFT 010E) ACPI: FACS 0x3feff800 00040 npx0: INT 16 interface acpi0: DELL CPi R on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: wakeup code va 0xc3b73000 pa 0x1000
