Re: So I whip out a FTDI-based multiport Serial USB Adapter....
On Mon, 2013-02-04 at 22:05 +0100, CeDeROM wrote: > On Mon, Feb 4, 2013 at 9:06 PM, Ian Lepore wrote: > > FTDI's vendor ID is 0x0403, and FTDI stuff works fine in FreeBSD 9 and > > 10; I use it all the time. Sometimes aftermarket vendors who use FTDI's > > parts program different vendor/product info and IDs have to be added to > > code to recognize them, that's the only trouble one usually encounters. > > I also want to use my KT-LINK multipurpose low-level embedded access > multitool based on FT2232H with RS232 port and I was worried there is > no driver - right now I will add the PID and recompile sources to see > if it works - happy to catch this thread :-) > > Some questions as you Ian seem to already have experience with this devices: > 1. Is it possible to compile only uftdi driver and load it into > existing kernel that have this driver compiled-in so I don't have to > recompile whole kernel and all of the modules? > 2. Is it possible to pass VID/PID and/or RS232 channel as kernel > loadable option? This would again spare some build/runtime time for me > :-) > 3. Do you know a good method on kernel module testing other than > rebuilding/rebooting all the time? VirtualBox + USB Attach? > > Any hints appreciated! :-) > Tomek > If you don't already have the right devices compiled in, just build the usb/ucom and usb/uftdi modules and kldload uftdi and you should be good to go. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: So I whip out a FTDI-based multiport Serial USB Adapter....
On Mon, 2013-02-04 at 14:58 -0600, Karl Denninger wrote: > On 2/4/2013 2:06 PM, Ian Lepore wrote: > > On Mon, 2013-02-04 at 12:57 -0600, Karl Denninger wrote: > >> ... and plug it into FreeBSD 9.1-Stable with the rev ID FreeBSD > >> 9.1-STABLE #16 r244942 > >> > >> and it returns > >> > >> ugen4.4: at usbus4 > >> uhub6: > >> on usbus4 > >> uhub_attach: port 1 power on failed, USB_ERR_STALLED > >> uhub_attach: port 2 power on failed, USB_ERR_STALLED > >> uhub_attach: port 3 power on failed, USB_ERR_STALLED > >> uhub_attach: port 4 power on failed, USB_ERR_STALLED > >> uhub_attach: port 5 power on failed, USB_ERR_STALLED > >> uhub_attach: port 6 power on failed, USB_ERR_STALLED > >> uhub_attach: port 7 power on failed, USB_ERR_STALLED > >> uhub6: 7 ports with 7 removable, self powered > >> > >> Yuck. > >> > >> The last time it was working was on a FreeBSD 7 box (yeah, I know, > >> rather old) but I never had problems there. And it appears that all of > >> the device declarations that I used to have to put in the kernel as > >> non-standard stuff are now in GENERIC, so I would expect it to work. > >> > >> Ideas as to what may have gotten hosed up here? > >> > > Those messages all seem to be related to a hub. Vendor ID 0x0409 is NEC. > > > > FTDI's vendor ID is 0x0403, and FTDI stuff works fine in FreeBSD 9 and > > 10; I use it all the time. Sometimes aftermarket vendors who use FTDI's > > parts program different vendor/product info and IDs have to be added to > > code to recognize them, that's the only trouble one usually encounters. > > > > -- Ian > Well, that sorta kinda worked. > > Except that it still is identifying it as a hub too, and the two collide > and crash the stack. > > But I can't find anything that is looking at the PID (0x0050) or the > definition (HUB_0050) anywhere in the code. > > I'll go pull the NEC defs and set up something else instead of simply > adding it to the FTDI probe list. > It seems to me you have a problem with a hub (perhaps the root hub or a motherboard hub if you don't have an external one) and this has nothing to do with the ftdi device at all. Or the usb serial device is damaged somehow so that the vendor and product ID are reading as garbage and being mistaken for a hub. Have you tried the ftdi adapter on another port/hub/computer? Have you tried plugging something else into the port you're trying to use for the ftdi adapter, like a thumb drive or something? -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: So I whip out a FTDI-based multiport Serial USB Adapter....
On Mon, 2013-02-04 at 12:57 -0600, Karl Denninger wrote: > ... and plug it into FreeBSD 9.1-Stable with the rev ID FreeBSD > 9.1-STABLE #16 r244942 > > and it returns > > ugen4.4: at usbus4 > uhub6: > on usbus4 > uhub_attach: port 1 power on failed, USB_ERR_STALLED > uhub_attach: port 2 power on failed, USB_ERR_STALLED > uhub_attach: port 3 power on failed, USB_ERR_STALLED > uhub_attach: port 4 power on failed, USB_ERR_STALLED > uhub_attach: port 5 power on failed, USB_ERR_STALLED > uhub_attach: port 6 power on failed, USB_ERR_STALLED > uhub_attach: port 7 power on failed, USB_ERR_STALLED > uhub6: 7 ports with 7 removable, self powered > > Yuck. > > The last time it was working was on a FreeBSD 7 box (yeah, I know, > rather old) but I never had problems there. And it appears that all of > the device declarations that I used to have to put in the kernel as > non-standard stuff are now in GENERIC, so I would expect it to work. > > Ideas as to what may have gotten hosed up here? > Those messages all seem to be related to a hub. Vendor ID 0x0409 is NEC. FTDI's vendor ID is 0x0403, and FTDI stuff works fine in FreeBSD 9 and 10; I use it all the time. Sometimes aftermarket vendors who use FTDI's parts program different vendor/product info and IDs have to be added to code to recognize them, that's the only trouble one usually encounters. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: stable/9: Force ada1 to UDMA-33
On Fri, 2013-02-01 at 19:52 +0100, Oliver Fromme wrote: > Hello, > > I've got a (P)ATA disk in a special frame. The disk itself > supports UDMA-100 (and has an 80-ribbon cable), but the > frame isn't compatible with that. By default, FreeBSD > negotiates UDMA-100, and the console starts to fill with > ICRC errors. > > In the past, I used a patch to ata-all.c that enabled the > following entry in loader.conf to force the disk to UDMA-33, > so it worked fine: > > hw.ata.ata_dma_limit="2" > > But with the "new world", that doesn't work anymore. > What is the proper way with ATA_CAM and ada(4) to force a > P-ATA disk to a lower UDMA mode? You probably want one of these... hint.ata.X.devX.mode limits initial ATA mode for specified device on specified channel. hint.ata.X.mode limits initial ATA mode for every device on specified channel. These are from ata(4) manpage, there are some others there as well. One thing the manpage doesn't say is what sort of values to assign to these hints. From the source code it looks like this is the list: if (!strcasecmp(str, "PIO0")) return (ATA_PIO0); if (!strcasecmp(str, "PIO1")) return (ATA_PIO1); if (!strcasecmp(str, "PIO2")) return (ATA_PIO2); if (!strcasecmp(str, "PIO3")) return (ATA_PIO3); if (!strcasecmp(str, "PIO4")) return (ATA_PIO4); if (!strcasecmp(str, "WDMA0")) return (ATA_WDMA0); if (!strcasecmp(str, "WDMA1")) return (ATA_WDMA1); if (!strcasecmp(str, "WDMA2")) return (ATA_WDMA2); if (!strcasecmp(str, "UDMA0")) return (ATA_UDMA0); if (!strcasecmp(str, "UDMA16")) return (ATA_UDMA0); if (!strcasecmp(str, "UDMA1")) return (ATA_UDMA1); if (!strcasecmp(str, "UDMA25")) return (ATA_UDMA1); if (!strcasecmp(str, "UDMA2")) return (ATA_UDMA2); if (!strcasecmp(str, "UDMA33")) return (ATA_UDMA2); if (!strcasecmp(str, "UDMA3")) return (ATA_UDMA3); if (!strcasecmp(str, "UDMA44")) return (ATA_UDMA3); if (!strcasecmp(str, "UDMA4")) return (ATA_UDMA4); if (!strcasecmp(str, "UDMA66")) return (ATA_UDMA4); if (!strcasecmp(str, "UDMA5")) return (ATA_UDMA5); if (!strcasecmp(str, "UDMA100")) return (ATA_UDMA5); if (!strcasecmp(str, "UDMA6")) return (ATA_UDMA6); if (!strcasecmp(str, "UDMA133")) return (ATA_UDMA6); -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: time issues and ZFS
On Mon, 2013-01-21 at 17:35 +0200, Daniel Braniss wrote: > ... > > > > What's the output of sysctl kern.eventtimer? > > kern.eventtimer.periodic is 0 > > > Does the bad behavior > > change if you set kern.eventimer.periodic=1? > > > > setting kern.eventtimer.timer=LAPIC > instead of the default HPET made the missing cpu timers to appear: > # vmstat -i > interrupt total rate > irq3: uart1 1695 0 > irq4: uart05 0 > irq19: ehci03875 0 > irq20: hpet0 uhci3 5495755 1135 > irq21: uhci2 ehci129 0 > irq23: atapci048 0 > cpu0:timer 7063 1 > irq256: bce0 117073 24 > irq260: mfi0 51083 10 > irq261: mfi13088 0 > cpu1:timer 484 0 > cpu14:timer 36 0 > cpu6:timer 486 0 > cpu8:timer38 0 > cpu5:timer38 0 > cpu15:timer 38 0 > cpu7:timer32 0 > cpu12:timer 38 0 > cpu3:timer40 0 > cpu9:timer36 0 > cpu10:timer 34 0 > cpu11:timer 37 0 > cpu2:timer33 0 > cpu13:timer 40 0 > cpu4:timer36 0 > Total5681160 1173 > > is this relevant? I'll have to let someone who knows modern x86 hardware better comment on the relative merits of hpet vs. lapic timers. If it was using hpet in one-shot mode, and changing it to hpet in periodic mode makes the problem go away, that might be a clue that there's something wrong in the hpet eventtimer start or interrupt routines. I wonder if a single missed interrupt in one-shot mode would bring an eventtimer to a halt like that? And if so, then what is it about manually asking for the date that kicks it into running again? -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: time issues and ZFS
On Mon, 2013-01-21 at 13:33 +0200, Daniel Braniss wrote: > After many trials (and errors), here are some facts: > > host: DELL PowerEdge R710, 16GB, > mfi0: > mfid0: 14305280MB (29297213440 sectors) RAID volume 'r5' is optimal > mfi1: > mfid1: 12393472MB (25381830656 sectors) RAID volume 'Virtual Disk 0' is > optimal > > we have NO problems with FreeBSD-8.3-STABLE, but with 9.1-STABLE, the > real-time > clock slows down when doing some zfs stuff like send|receive, typing 'date' > when less that 1000s went by seems to crorrect the problem, > ntpd kicks in and on track again. > > I have a cron job just logging date every 5 minutes, and the loghost sees: > > |-- local time on loghost | time on problematic host > Jan 20 19:56:19 store-02.cs.huji.ac.il Jan 20 19:56:19 danny: Sun Jan 20 > 19:56:19 IST 2013 -- ok > Jan 20 20:15:00 store-02.cs.huji.ac.il Jan 20 20:15:00 danny: Sun Jan 20 > 20:15:00 IST 2013 -- ok > Jan 20 21:30:00 store-02.cs.huji.ac.il Jan 20 20:21:06 danny: Sun Jan 20 > 20:21:06 IST 2013 -- off by 1:09 > Jan 20 21:33:53 store-02.cs.huji.ac.il Jan 20 20:25:00 danny: Sun Jan 20 > 20:25:00 IST 2013 -- off by 1:08 > Jan 20 21:38:54 store-02.cs.huji.ac.il Jan 20 20:30:00 danny: Sun Jan 20 > 20:30:00 IST 2013 -- off by 1:09 > ... > Jan 20 22:03:54 store-02.cs.huji.ac.il Jan 20 20:55:00 danny: Sun Jan 20 > 20:55:00 IST 2013 -- diff is now constant > .. > Jan 20 22:04:13 store-02.cs.huji.ac.il Jan 20 20:55:19 ntpd[1848]: time > correction of 4134 seconds exceeds sanity limit (1000); set clock manually to > the correct UTC time. > ... > Jan 20 22:58:53 store-02.cs.huji.ac.il Jan 20 21:50:00 danny: Sun Jan 20 > 21:50:00 IST 2013 > > > strangely, when running 8.3, ACPI-fast is chosen: > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) > dummy(-100) > but with 9.1 TSC-low gets chosen: > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) > i8254(0) > dummy(-100) > > so I did sysctl kern.timecounter.hardware=ACPI-fast, but the same happens - > unless it can't be changed after boot. > > I realy need help here! > > thanks, > danny What's the output of sysctl kern.eventtimer? Does the bad behavior change if you set kern.eventimer.periodic=1? -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0
On Sat, 2013-01-19 at 12:30 +0200, Marin Atanasov Nikolov wrote: > Hi, > > Re-sending this one, as I've attached an image which was too large to pass > the mailing lists, sorry about that :) > > After starting the system last night I kept monitoring the memory usage > just in case I see something strange and I've noticed a significant memory > drop of the free memory between 03:00am and 03:05am time. I've taken a > screenshot of the graph, which you can also see at the link below: > > * http://users.unix-heaven.org/~dnaeon/memory-usage.jpg > > At 03:00am I can see that periodic(8) runs, but I don't see what could have > taken so much of the free memory. I'm also running this system on ZFS and > have daily rotating ZFS snapshots created - currently the number of ZFS > snapshots are > 1000, and not sure if that could be causing this. Here's a > list of the periodic(8) daily scripts that run at 03:00am time. > [...] > What exactly is that graph displaying for "available memory?" That is, what is the source of info on the graph? If it's just showing memory that appears in top as "Free" that's not the whole picture; the memory in the Inactive category is also available. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0
On Fri, 2013-01-18 at 08:04 -0700, Warren Block wrote: > On Fri, 18 Jan 2013, Ronald Klop wrote: > > > Memory chips gone bad? Power (or other) cables gone loose? > > Memory failures will cause intermittent and mysterious things. Easy to > test, too, just run memtest86 on it for a while. Do that before > rebuilding. If memory is failing, corrupted data could be written to > disk. > > I had a Crucial DIMM fail spontaneously a couple of weeks ago. Working > one minute, totally failed the next. The machine rebooted, for no > visible reason. After it came back up, compiles failed, always with > different errors and in different places. > > Power supplies also fail, as do motherboards. These are both harder to > swap out than memory, so test the memory first. I tend to agree, a machine that starts rebooting spontaneously when nothing significant changed and it used to be stable is usually a sign of a failing power supply or memory. But I disagree about memtest86. It's probably not completely without value, but to me its value is only negative: if it tells you memory is bad, it is. If it tells you it's good, you know nothing. Over the years I've had 5 dimms fail. memtest86 found the error in one of them, but said all the others were fine in continuous 48-hour tests. I even tried running the tests on multiple systems. The thing that always reliably finds bad memory for me is /usr/ports/math/mprime run in test/benchmark mode. It often takes 24 or more hours of runtime, but it will find your bad memory. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Failsafe on kernel panic
On Thu, 2013-01-17 at 08:38 +0200, Sami Halabi wrote: > btw: i don't see any options in my kernel config for KBD / Unatteneded , th > eonly thing that mention its > is: device ukbd > > Sami I think if you don't have any kdb options turned on, then a panic should automatically store a crashdump to swap, then reboot the machine. If that's not working, perhaps it locks up trying to store the dump? If the hardware has a watchdog timer, enabling that might be the best way to ensure a reboot on any kind of crash or hang. -- Ian > On Thu, Jan 17, 2013 at 6:45 AM, Sami Halabi wrote: > > > Its only a kernel option? There is no flag to pass to the loader? > > > > SAMI <> 17 2013 05:18, "Ian Lepore" : > > > > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > >> > Thank you for your response, very helpful. > >> > one question - how do i configure auto-reboot once kernel panic occurs? > >> > > >> > Sami > >> > > >> > >> From src/sys/conf/NOTES, this may be what you're looking for... > >> > >> # > >> # Don't enter the debugger for a panic. Intended for unattended operation > >> # where you may want to enter the debugger from the console, but still > >> want > >> # the machine to recover from a panic. > >> # > >> options KDB_UNATTENDED > >> > >> But I think it only has meaning if you have option KDB in effect, > >> otherwise it should just reboot itself after a 15 second pause. > >> > >> -- Ian > >> > >> > >> > >> > >> > >> > >> > > >> > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote: > >> > > >> > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > >> > > > Hi everyone, > >> > > > I have a production box, in which I want to install new kernel > >> without > >> > > any > >> > > > remotd kvn. > >> > > > my problem is its 2 hours away, and if a kernel panic occurs I got a > >> > > > problem. > >> > > > I woner if I can seg failsafe script to load the old kernel in case > >> of > >> > > > psnic. > >> > > > >> > > man nextboot (if you are using UFS) > >> > > > >> > > -- > >> > > John Baldwin > >> > > > >> > > >> > > >> > > >> > >> > >> > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > ___ > freebsd-hack...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Failsafe on kernel panic
On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > Thank you for your response, very helpful. > one question - how do i configure auto-reboot once kernel panic occurs? > > Sami > >From src/sys/conf/NOTES, this may be what you're looking for... # # Don't enter the debugger for a panic. Intended for unattended operation # where you may want to enter the debugger from the console, but still want # the machine to recover from a panic. # options KDB_UNATTENDED But I think it only has meaning if you have option KDB in effect, otherwise it should just reboot itself after a 15 second pause. -- Ian > > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote: > > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > > > Hi everyone, > > > I have a production box, in which I want to install new kernel without > > any > > > remotd kvn. > > > my problem is its 2 hours away, and if a kernel panic occurs I got a > > > problem. > > > I woner if I can seg failsafe script to load the old kernel in case of > > > psnic. > > > > man nextboot (if you are using UFS) > > > > -- > > John Baldwin > > > > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 file content
On Mon, 2012-12-31 at 17:33 +0100, Zoran Kolic wrote: > I'm quite happy to see 9.1 out and want to ask polite and > benevolent question: > regarding times on the site, are iso and img files the same > as 2 weeks ago? To remind noble readers. I installed on my > computers what was release at that time and got it up and > working perfectly. In other words, is it the same file? > Best regards and happy new year > >Zoran There are md5 and sha256 sums posted at http://www.freebsd.org/releases/9.1R/announce.html for the official release. Just compare them to the sum for the image you downloaded and installed. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't build kernel with ndis
On Wed, 2012-12-26 at 05:35 -0500, Thomas Mueller wrote: > I am trying to build FreeBSD update, STABLE branch, and buildkernel > apparently snagged on ndis, which I don't want to do without. According to > "man ndis", I need in kernel config > > options NDISAPI > device ndis > device wlan > > which I have: > > device wlan# 802.11 support > options NDISAPI # This is in the hope of enabling Hiro USB wireless adapter > device ndis > > Error message, final lines of buildkernel log file, are > > MAKE=make sh /usr/src/sys/conf/newvers.sh SANDY > /usr/local/bin/svnversion > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall > -Wred > undant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointe > r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wm > issing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > -I > /usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_gl > obal.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param > la > rge-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables > -ffreestanding - > fstack-protector -Werror vers.c > linking kernel.debug > if_ndis.o: In function `ndis_detach': > /usr/src/sys/dev/if_ndis/if_ndis.c:1084: undefined reference to > `ndis_free_amem' > if_ndis.o: In function `ndis_attach': > /usr/src/sys/dev/if_ndis/if_ndis.c:563: undefined reference to > `ndis_alloc_amem' > *** [kernel.debug] Error code 1 > > Stop in /usr/obj/usr/src/sys/SANDY. > *** [buildkernel] Error code 1 > > Stop in /usr/src. > *** [buildkernel] Error code 1 > > Stop in /usr/src. Try adding "device pccard" -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory.
On Wed, 2012-12-12 at 20:52 +0200, Kimmo Paasiala wrote:
> On Wed, Dec 12, 2012 at 6:53 PM, Ian Lepore
> wrote:
> > On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote:
> >> Hello,
> >>
> >> My 9-STABLE buildworld broke in a very inexplicable way, I was
> >> getting an error on /usr/src/include/osreldate.h that I couldn't
> >> figure out until I started looking at the sys/conf/newvers.sh and what
> >> it does. It turned out that the thing that broke my buildworld was
> >> having .git directory at the root directory of the system because I
> >> recently started using GIT to track the configuration files.
> >>
> >> I added some debug echos to the newvers.sh and I found out it's
> >> setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set
> >> the gitdir to /.git and that seems to break the logic in newvers.sh.
> >>
> >> Isn't SYSDIR supposed to be set to the sys -subdirectory of the source
> >> tree (/usr/src/sys default)?
> >>
> >> I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in
> >> newvers.sh:
> >>
> >> SYSDIR=$(dirname $0)/..
> >>
> >> $0 is actually /bin/sh and not the path to newver.sh because the
> >> newvers.sh is sourced by the Makefile in /usr/src/include instead of
> >> executing it:
> >>
> >> osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh
> >> ${.CURDIR}/../sys/sys/param.h \
> >> ${.CURDIR}/Makefile
> >> @${ECHO} creating osreldate.h from newvers.sh
> >> @MAKE=${MAKE}; \
> >> PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
> >> . ${.CURDIR}/../sys/conf/newvers.sh; \
> >>
> >> Now the question is how to fix this?
> >>
> >> -Kimmo
> >
> > Perhaps it could be handled similar to PARAMFILE, something like this in
> > the makefile:
> >
> > PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
> > SYSDIR=${.CURDIR}/../sys; \
> > . ${.CURDIR}/../sys/conf/newvers.sh; \
> >
> > I'm not sure if newvers.sh needs to work in ways that don't involve
> > being invoked from that makefile rule, so to be safe it could have
> > default handling, something like:
> >
> > : ${SYSDIR:=$(dirname $0)/..}
> >
> > -- Ian
> >
> >
>
> Thanks, that works. Should I file a PR about this?
>
> -Kimmo
I think that would probably be a good idea, since no committer has
chimed in on this thread saying they're about to commit a fix.
-- Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory.
On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote:
> Hello,
>
> My 9-STABLE buildworld broke in a very inexplicable way, I was
> getting an error on /usr/src/include/osreldate.h that I couldn't
> figure out until I started looking at the sys/conf/newvers.sh and what
> it does. It turned out that the thing that broke my buildworld was
> having .git directory at the root directory of the system because I
> recently started using GIT to track the configuration files.
>
> I added some debug echos to the newvers.sh and I found out it's
> setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set
> the gitdir to /.git and that seems to break the logic in newvers.sh.
>
> Isn't SYSDIR supposed to be set to the sys -subdirectory of the source
> tree (/usr/src/sys default)?
>
> I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in
> newvers.sh:
>
> SYSDIR=$(dirname $0)/..
>
> $0 is actually /bin/sh and not the path to newver.sh because the
> newvers.sh is sourced by the Makefile in /usr/src/include instead of
> executing it:
>
> osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh ${.CURDIR}/../sys/sys/param.h \
> ${.CURDIR}/Makefile
> @${ECHO} creating osreldate.h from newvers.sh
> @MAKE=${MAKE}; \
> PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
> . ${.CURDIR}/../sys/conf/newvers.sh; \
>
> Now the question is how to fix this?
>
> -Kimmo
Perhaps it could be handled similar to PARAMFILE, something like this in
the makefile:
PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
SYSDIR=${.CURDIR}/../sys; \
. ${.CURDIR}/../sys/conf/newvers.sh; \
I'm not sure if newvers.sh needs to work in ways that don't involve
being invoked from that makefile rule, so to be safe it could have
default handling, something like:
: ${SYSDIR:=$(dirname $0)/..}
-- Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Using dhclient on WAN if on a box serving DHCP to LAN if
On Fri, 2012-12-07 at 11:38 +, Tom Evans wrote:
> Hi all
>
> Using 9.0-STABLE #1 r230946 - I found it out as I rebooted to prepare
> for 9.1, but I think it should be largely irrelevant of version.
>
> I have a freebsd router that provides all the things a soho router
> should on its LAN iface - DNS, DHCP, NAT (via pf). The WAN iface
> connects to a ADSL modem operating in bridge mode.
>
> My ISP has recently forced a change on to me, in order to get service
> I have to connect via DHCP, in order for them to give me my static IP.
> Apparently this makes their lives a lot easier. Even knowing the IP,
> netmask, broadcast and router is not enough, no service will flow
> unless a DHCP request has been registered.
>
> Relevant rc.conf, ale0 is the WAN, em0 is the LAN
>
> ifconfig_ale0="DHCP"
> ifconfig_em0="inet 192.168.1.1 netmask 255.255.255.0"
> gateway_enable="YES"
>
> dhcpd_enable="YES"
> dhcpd_flags="-q"
> dhcpd_ifaces="em0"
> dhcpd_conf="/usr/local/etc/dhcpd.conf"
>
> With this configuration, the default route is over the LAN iface. This
> causes the dhclient for ale0 to get a response from the local dhcpd
> server, not the ISP dhcpd server. This drove me potty! Can anyone
> explain why dhcpd, having been told only to listen for DHCP on em0,
> responds to ale0? Could this be related to my pf rules, or is it down
> to the default route being incorrect?
>
> Changing rc.conf to this allows the network to come up correctly:
>
> ifconfig_ale0="inet xx.xx.110.172 netmask 255.255.255.0 broadcast
> xx.xx.110.255 DHCP"
> defaultrouter="xx.xx.110.1"
>
> This relies on me knowing that these are the values that dhclient on
> the WAN iface will receive from my ISP's DHCP server. How would I
> achieve this setup if this information was dynamic or otherwise
> unknowable? My ISP could easily change my gateway IP, the only
> guarantee I have is that my allocated IP is static.
>
> So:
>
> 1) Why does the LAN dhcpd respond to the WAN dhclient?dhcpd_ifaces="sk0"
> 2) Is there a better way of specifying this setup, so that it does not
> have hard coded addresses in there?
>
> Thanks in advance for any pointers.
>
> Tom
I've been running this exact setup for years (although it's still
running on freebsd 7.x because I've been too lazy to update a setup that
works so well).
Make sure you're telling dhcpd to only listen for broadcasts on the lan
interface. You can do this in rc.conf with
dhcpd_ifaces="sk0"
Also, I found that dhcpd (at least the old version I'm running) whines
if you don't have a subnet statement for the wan interface in the config
even if it's not serving on that interface, so my dhcpd.conf has this
# The subnet that should be active via the cable modem.
# We don't serve it (no range statement).
# I don't remember why I need the broadcast-address thing here.
# It might be to match what comcast sets via their dhcp.
subnet 24.6.2.0 netmask 255.255.254.0 {
not authoritative;
option routers 24.6.2.1;
option broadcast-address255.255.255.255;
}
-- Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: What's the most effective way to restart net && children?
On Mon, 2012-12-03 at 08:05 -0800, Chris H wrote: > Greetings, > I've always maintained at least a /24 since the early 80's. > I'm now evaluating a new ISP, and am not ready to commit. Until then I'll be > forced to use DHCP. My problem is that they are really mercenary about their > lease(s) -- ~24hrs! So, given that I am treating the assigned IP(s) as > pseudo-static, > I would prefer not to bounce the box(es). > I currently bounce them alternating rc & hosts, etc. I can easily switch > configs > "on the fly" by restarting network & related services, but am looking for a > _graceful_ way to re-start the network. I see /etc/netstart, but it looks a > little > more /brutal/ than I was hoping for. Any and all suggestions _greatly_ > appreciated. > > Thank you for all your time, and consideration. > > --Chris > You can use "service netif restart" to restart / re-dhcp all the interfaces. Doing it that way will do ALL interfaces, including loopback, which can break running programs that are using it. You can name one or more interfaces to be restarted instead of letting it do all of them. Do you have any reason to think the short leases time will somehow lead to changing IPs? My provider gives me 12 hour leases, and my IP hasn't changed in like 7 years. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Library Problem
On Thu, 2012-11-29 at 13:33 -0800, Doug Hardie wrote: > On 29 November 2012, at 06:01, Gary Palmer wrote: > > > On Wed, Nov 28, 2012 at 10:46:51PM -0800, Doug Hardie wrote: > >> > >> On 28 November 2012, at 20:01, Devin Teske wrote: > >> > >>> > >>> On Nov 28, 2012, at 7:36 PM, Doug Hardie wrote: > >>> > I have installed 4 systems from the same FreeBSD 9.1-RC3 disk. Three of > them worked just fine. The last one is causing a problem. It will not > look in /usr/local/lib/ for shared libraries. I did the standard > install, moved in some source, compiled it and tried to run it. The > library is there. On the working systems ktrace shows: > > 2259 introCALL access(0x28066000,0) > 2259 introNAMI "/lib/libsermons.so" > 2259 introRET access -1 errno 2 No such file or directory > 2259 introCALL access(0x28066000,0) > 2259 introNAMI "/usr/lib/libsermons.so" > 2259 introRET access -1 errno 2 No such file or directory > 2259 introCALL access(0x28066000,0) > 2259 introNAMI "/usr/lib/compat/libsermons.so" > 2259 introRET access -1 errno 2 No such file or directory > 2259 introCALL access(0x28066000,0) > 2259 introNAMI "/usr/local/lib/libsermons.so" > 2259 introRET access 0 > > > On the failing system ktrace shows: > > 6746 introNAMI "/lib/libsermons.so" > 6746 introRET access -1 errno 2 No such file or directory > 6746 introCALL access(0x28066000,0) > 6746 introNAMI "/usr/lib/libsermons.so" > 6746 introRET access -1 errno 2 No such file or directory > 6746 introCALL access(0x28066000,0) > 6746 introNAMI "/usr/lib/compat/libsermons.so" > 6746 introRET access -1 errno 2 No such file or directory > 6746 introCALL access(0x28066000,0) > 6746 introNAMI "/lib/libsermons.so" > 6746 introRET access -1 errno 2 No such file or directory > 6746 introCALL access(0x28066000,0) > 6746 introNAMI "/usr/lib/libsermons.so" > 6746 introRET access -1 errno 2 No such file or directory > 6746 introCALL write(0x2,0x28060080,0x3c) > 6746 introGIO fd 2 wrote 60 bytes > "Shared object "libsermons.so" not found, required by "intro"" > > > It never attempts to check /usr/local/lib. I can't find any > configuration item that affects that. How can this be fixed? > > >>> > >>> What's the value of "ldconfig_paths" in rc.conf(5)? > >>> > >>> That includes: > >>> /etc/rc.conf > >>> /etc/rc.conf.local (if it exists) > >>> /etc/defaults/rc.conf > >>> > >>> Here on my 9.0-R system it has the following in /etc/defaults/rc.conf: > >>> /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg > >> > >> > >> /etc/defaults/rc.conf has: > >> > >> ldconfig_paths="/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg" > >> > >> > >> /etc/rc.conf has nothing for ldconfig_paths. > > > > Check that /usr/local/lib doesn't have group or other write perms. > > ldconfig ignores directories that are group/world writable. > > > > To fix: > > > > chmod go-w /usr/local/lib > > sh /etc/rc.d/ldconfig start > > sermons# ll -d /usr/local/lib > drwxr-xr-x 4 root wheel 512 Nov 28 19:07 /usr/local/lib > > > I think I found the cause of the problem. A reboot corrected the issue. > Apparently when ldconfig was run /usr/local/lib didn't exist. Apparently it > doesn't check for that except for in ldconfig. I was not aware of ldconfig > before. That explains why the reboot worked. Thanks to all who provided > information. Oh. Hmm, in that case, "service ldconfig restart" probably would have fixed it. (Seems sorta strange to "restart" a "service" that just builds a table and exits.) -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: When did Xorg remove support for keyboards, and mice?!
On Mon, 2012-11-26 at 12:25 -0800, Chris H wrote: > Greetings, > Seems I get bitten by this every time I build a desktop on a new freebsd > install. > After all these years, I'd have the _definitive_ answer by now. > I just put (built) a copy of 8.3 on an x(i)386 (AMD32) box. Built/installed > kernel && world. All went pretty well. Just finished building Xorg and > friends. > Chose xfce4 as a desktop. The mouse and keyboard work "famously" on a tty. But > HALD(8) && DBUS haven't a clue. I get the idea these have been abandoned. :/ > Anyway, I have hald_enable="YES" and dbus_enable="YES" in rc.conf(5). > I have the following in xorg.conf: > Section "ServerLayout" > Identifier "Layout0" > Screen 0 "Screen0" > InputDevice"Keyboard0" "CoreKeyboard" > InputDevice"Mouse0" "CorePointer" > Also tried: > Option"AutoAddDevices" "false" > but didn't work. > > Section "InputDevice" > # generated from default > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" > Option "ZAxisMapping" "4 5 6 7" > EndSection > > Section "InputDevice" > # generated from default > Identifier "Keyboard0" > Driver "keyboard" > EndSection > > The error(s) returned when attempting to use X is|are: > (II) config/hal: Adding input device AT Keyboard > (II) LoadModule: "kbd" > (WW) Warning, couldn't open module kbd > (II) UnloadModule: "kbd" > (EE) Failed to load module "kbd" (module does not exist, 0) > (EE) No input driver matching `kbd' > (EE) config/hal: NewInputDeviceRequest failed (15) > (II) config/hal: Adding input device PS/2 Mouse > (II) LoadModule: "mouse" > (WW) Warning, couldn't open module mouse > (II) UnloadModule: "mouse" > (EE) Failed to load module "mouse" (module does not exist, 0) > (EE) No input driver matching `mouse' > (EE) config/hal: NewInputDeviceRequest failed (15) > > There is nothing in dmesg(8) to indicate any trouble. > > Whats a person to do? install Windows? OSX? > > Thank you for all your time and consideration. Have you tried just not having an xorg.conf file? I'm running 8.3 with hal and it's working just fine for me with no conf file. Also, from those messages, I'd guess it's detecting the hardware, then failing to find the drivers. If so, I suppose it could be because they're missing, or because of a path problem of some sort. For me, the drivers are in: revolution > ll /usr/local/lib/xorg/modules/input/ total 82 -rwxr-xr-x 1 root wheel 919B Feb 12 2012 kbd_drv.la* -rwxr-xr-x 1 root wheel24k Feb 12 2012 kbd_drv.so* -rwxr-xr-x 1 root wheel 933B Feb 12 2012 mouse_drv.la* -rwxr-xr-x 1 root wheel50k Feb 12 2012 mouse_drv.so* -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Where do I purchace an unlock code to build a custom kernel?
On Sun, 2012-11-25 at 11:19 -0800, Jakub Lach wrote: > That's good idea, albeit you are missing two points: > > - GENERIC is expected too be able to boot almost all hardware (is this > correct approach?) > > - almost no one really needs custom stripped kernel, most people > (e.g. me) do it for fun. There is a reason only GENERIC is supported > in OpenBSD, mind. Those who want custom kernel one way or another > should just write full config themselves. > > $ wc -l /usr/src/sys/amd64/conf/STRIPPED > 83 /usr/src/sys/amd64/conf/STRIPPED On x86 platforms for most users, I'd agree that customized kernels are more geekware than necessity. For business use (when you're creating a system to sell to others, whether it's small/embedded or a large dedicated purpose server) the customizations make more sense. On the other hardware (arm, mips, powerpc, etc) I think the modular approach makes more sense. There are certain things that are required for every arm kernel. There are other things that change based on major architecture (armv4 vs. armv6 for example; the same sorts of distinctions as i386 vs amd64). There are also things that are very specific to the chip or system-on-a-chip the kernel is for. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Where do I purchace an unlock code to build a custom kernel?
On Sun, 2012-11-25 at 00:29 +0100, Andreas Nilsson wrote: > [big discussion snipped, including advice to include GENERIC] > > I full-heartedly agree that include-statement is good, but still > $ wc -l /usr/src/sys/amd64/conf/MINI > 174 /usr/src/sys/amd64/conf/MINI > > And this is just after removing network cards ( (usb)ethernet, > (usb)wlan, > raid drivers and firewire) for my pretty standard lenovo t510. There > is so > much in GENERIC today that seems to work just as well as modules. I > guess > one thread on a mailing list this summer tried to achieve a more > modular > config, which would make the include statement even more useful. > > Best regards > Andreas > I think including GENERIC and then trying to customize by disabling what you don't need is horrible advice, and results in just as big and unmaintainable a mess as writing a custom config file from scratch. Either way you do it, you are absolutely required on each OS release to carefully comb through every line of the new GENERIC and compare it to your customizations to make sure you're still turning on and off the right things to get the kernel you want. Where's the benefits? The problem, as I see it, is that GENERIC is not intended to be a baseline config to which various little extras can be added and maybe one or two things might be trimmed away. It's an ever-changing vision of a config that can be almost everything that almost everyone needs. The ever-changingness of that vision is the big problem. Things that had to be in GENERIC 10 years ago are all but meaningless now (NDIS drivers, anyone? device EISA?). It would be nice if kernel configs were truly modularized and designed to be used in a mix-ins sort of way. There should be an I386-BASE and AMD64-BASE and so on that contains just things that are truly required to get that hardware working. There should be useful mix-ins like FIREWALL and ROUTER and DESKTOP. I should be able to write a config file that looks like ident MYBEAST include AMD64-BASE include DESKTOP include DISKLESS-NFSROOT device frannistan # The cheap-o multi-io card I bought device uftdi # My favorite usb->serial adapters -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Increasing the DMESG buffer....
On Wed, 2012-11-21 at 16:51 +0100, Willem Jan Withagen wrote: > On 2012-11-21 16:08, Andriy Gapon wrote: > > on 21/11/2012 15:20 Willem Jan Withagen said the following: > >> On 2012-11-21 11:14, Peter Jeremy wrote: > >>> On 2012-Nov-21 10:57:49 +0100, Willem Jan Withagen > >>> wrote: > Probably because the kernelbuffer for it is too small. > I know there used to be a kernel option to increase it. > But I can not find it with the setting in NOTES or any other place I > looked > >>> > >>> # Size of the kernel message buffer. Should be N * pagesize. > >>> options MSGBUF_SIZE=40960 > >>> > >> > >> Right, > >> > >> That was the one > > > > > > Alternatively you could set kern.msgbufsize tunable. > > That is a fresh new one for me. > Now you tell me :) after I've started compiling a new kernel. > > Need to set that in loader.conf. > > Thanx, > --WjW You know what would be great? Have this value auto-tune itself upwards if bootverbose is true. The sound drivers now spit out so much stuff with bootverbose true that you need like a 128k buffer to see the early boot messages. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why is SU+J undesirable on SSDs?
On Sat, 2012-11-03 at 17:06 -0500, Adam Vande More wrote: > On Sat, Nov 3, 2012 at 4:30 PM, Brett Glass wrote: > > > Have been following the thread related to SU+J, and am wondering: why is it > > considered to be undesirable on SSDs (assuming that they have good wear > > leveling)? > > > Superstition > > Yeah, that's what it must be. Or... it could be well-informed choice. Journaling increases the number of writes. That puts wear on any disk, mechanical or SSD, and it takes time. What it buys you is better performance if you get into a crash recovery situation. It's perfectly reasonable for someone to make the decision that their SSD can finish an fsck so fast that there's no point in paying any penalty for the extra writes for journaling. I have a 256G SSD here with about 200G of data on it, and fsck without journaling takes about 3 minutes. I can live with that. With more data or a slower drive I might make a different choice. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [patch] Re: SU+J on 9.1-RC2 ISO
On Sat, 2012-11-03 at 09:08 -0500, Mark Felder wrote: > On Fri, 2 Nov 2012 20:00:27 +0100 > Bas Smeelen wrote: > > > Though the last 10 years I have not had the inconvenience of having to > > deal with long fsck' s or bgfsck' s on servers or workstation installs, > > so I think this should not be default on new installs. > > This is one man's opinion. On the other hand, SUJ by default is a godsend for > me because of the number of crashes/fscks I've been dealing with. So SUJ has been a godsend for you. I don't see anything in your statement that supports it being the default. Given how much trouble it has been for people in the past, I don't plan to embrace journaling any faster than I embraced softupdates originally. That is to say, it will be years before I use it. I suspect my attitude on this isn't all that uncommon, and is likely the explanation for why things increasingly become the default before their time these days. Developers are motivated to push new features into wide use quickly, because that gets the new features lots of testing. Prudent users aren't interested in being guinea pigs, and will push back. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1-RC1 Available...
On Thu, 2012-08-23 at 11:17 -0400, Ken Menzel wrote: > > I found two good primers: > http://mebsd.com/configure-freebsd-servers/update-freebsd-source-tree-using-subversion-svn.html > http://www.freebsd.org/doc/en/articles/committers-guide/article.html#SUBVERSION-PRIMER > > The second primer in the committer handbook seems to indicate that it > is difficult to run an SVN mirror. This appears to me to be the > biggest drawback. I have been using CVS and perforce for years, but > subversion is new to me. It may be difficult to run an svn mirror that allows you to commit locally and get those changes back to the project, but running a read-only mirror is trivial. The script I run nightly from cron to sync my local mirror is: #!/bin/sh # # svnsync to pull in changes from FreeBSD to my local mirror. # svnsync sync file:///local/vc/svn/base I can't remember how I initially created and populated the mirror, but it's likely I grabbed a snapshot of the mirror at work and brought it home on a thumb drive (just to avoid initial network DL time). -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.0 and (Kingspec) PATA drive ATA status errors. Drive unusable.
On Sun, 2012-08-12 at 12:42 -0400, Wajih Ahmed wrote: > Ok at the boot loader prompt i did as you suggested > > set hint.ata.0.mode="UDMA33" > > And that change did take effect as evedint by > >ada0: 33.300MB/s transfers (UDMA2, PIO 512bytes) > > Unfortunately i still get the error > > .ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) > > Regards, It's probably worth trying an even slower mode, such as UDMA16, and for testing purposes maybe even PIO4, but it's starting to sound like maybe the problem is something else. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.0 and (Kingspec) PATA drive ATA status errors. Drive unusable.
On Sun, 2012-08-12 at 12:29 -0400, Wajih Ahmed wrote: > Thank you. I'll try it out. One question though. How do i modify the > loader.conf on the usb image from which i am booting? Is there somethign i > can change in the boot loader? If this is RTFM kindly point me to it. You can enter the value interactively in the loader. Just hit a key while it's doing the boot countdown to get the interactive prompt, and enter set hint.ata.0.mode="UDMA33" boot -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.0 and (Kingspec) PATA drive ATA status errors. Drive unusable.
On Sun, 2012-08-12 at 10:57 -0400, Wajih Ahmed wrote: > I have a Dell D420 laptop with the ZIF interface and uses a 1.8" PATA > drive. I purchased a Kingspec 16GB SSD and installed it. The BIOS > recogonizes the drive. I am using the USB image to boot in verbose mode. > Upon boot the disk is recognized by FreeBSD 9.0 as follows (sorry for any > typos as i am reading this off the console): > > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-7 device > ada0: Serial number... > ada0: 100.MB/s transfers (UDMA5, PIO 512bytes) > > Then i see these errors > > (ada0:ata0:0:0:0): ATA status error > .READ_DMA. ACB: c8 > .CAM status: ATA status error > .ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) > .RES: 51 . > > > As a result the disk is rendered unusable and i cannot write (partition) to > it. I did test the drive with a linux boot disk and i was able to format > it. > > So my question is how can i make this drive work? Do i need to pass > something to the kernel at boot to lower the speed of the drive. Maybe to > UDMA66? Any help will be really appreciated. Whenever I've seen ICRC errors, it has been caused by using a 40-wire cable at speeds faster than UDMA33 [1]. A potential fix is to force the mode in loader.conf: hint.ata.0.mode="UDMA33" [1] I've also seen ICRC errors when there was no cable involved at all, such as with a surface-mount compact flash socket on a circuit board that has 50 pins spaced even closer together than a standard ata cable. I have no real proof that such closely-spaced pins cause the same kind of signal crosstalk as a 40-wire cable (they're close, but the length of the parallel wires is just a couple millimeters), but forcing the driver to UDMA33 or less always seems to fix the problem. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Who is responsible for Heimdal/Kerberos in FreeBSD
On Thu, 2012-08-02 at 13:52 +0100, Attila Bogár wrote: > Hello, > > I'm repeating my last month request. > > Who is responsible for Heimdal/Kerberos or GSSAPI/NFS in FreeBSD? > > I got a working NFSv3/Kerberos over UDP for EL6 nfs clients, but > suddenly I'm experiencing NFS I/O errors on high load/small files, which > I think are due to the buggy/old heimdal in FreeBSD. > > NFS+Kerberos with EL6 over TCP is broken anyway. > > Attila There was a newer version of Heimdal (but not the newest) checked in back in March by Stanislov Sedos (stas@) as r233294. In the checkin message he mentioned the possibility of bringing in an even newer version soon. While that doesn't amount to official responsibility for the package, there is a certain degree of "you touched it, you own it" in play, perhaps. :) -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: OpenSSL from Ports
On Mon, 2012-07-30 at 20:36 +0200, O. Hartmann wrote:
> Am 07/30/12 20:04, schrieb Beat Siegenthaler:
> > Hello,
> >
> > Until today, when I was asked what WITH_OPENSSL_PORT=yes should do.. i
> > was obviously wrong:
> > I think whole openssl should be replaced, but :
> >
> > [mym:~] # which openssl
> > /usr/bin/openssl
> > [mym:~] # openssl version
> > OpenSSL 0.9.8x 10 May 2012
> >
> > there IS a 1.0.1 version but it is not found whit which or whereis:
> >
> > [mym:~] # /usr/local/bin/openssl version
> > OpenSSL 1.0.1c 10 May 2012
> >
> > Maybe I simply miss some shell basics?
> > Regards, Beat
> >
>
>
> Hello.
>
> I guess you need to ensure that the path /usr/local/bin is searched
> BEFORE /usr/bin. If you're using sh(1) as the standard shell of yours,
> you should ensure this by using something like the following in .profile
> (or .cshrc, if csh(1)):
>
> PATH=/usr/local/bin:/usr/local/sbin:${PATH}; export PATH
>
> for sh(1) or for csh(1)
>
> set path = ( /usr/local/bin /usr/local/sbin $path )
>
> Although I use csh(1) as the login shell, I've also set ~/.profile with
> the propper PATH settings.
>
> Since I run FreeBSD 10.0-CURRENT, I have already OpenSSL 1.0.1c. I
> tested which(1) and whereis(1) on the command lpr(1), which is in my
> case provided by the FreeBSD base system and located in /usr/bin/lpr,
> AND by the port print/cups-base by the CUPS printing system. Luckily,
> since I adjusted the search paths that way, that /usr/local/bin is
> searched BEFORE /usr/bin, lpr(1) is found first in /usr/local/bin:
>
> ohartmann@thor: [~] which lpr
> /usr/local/bin/lpr
>
>
> But when using whereis(1), the result is the undesired:
>
> ohartmann@thor: [~] whereis lpr
> lpr: /usr/bin/lpr /usr/local/man/man1/lpr.1.gz /usr/src/usr.sbin/lpr
>
>
> The manpage of whereis(1) states, that the $PATH environment variable is
> searched - but this isn't obviously the case, since the shell's PATH
> environment variable points to the right lpr(1) in the first place while
> whereis(1) does ignore it.
> This behaviour is also identical on boxes which run 24/7 with periodic
> scripts enabled, updating the locate(1) database.
>
> Am I missing something, too?
The whereis(1) manpage says that the value of $PATH is *appended* to the
standard places it searches, so it still finds the base system version
of something before any ports-provided version in /usr/local regardless
of PATH.
-- Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.0-STABLE: Can't umount umass device
On Tue, 2012-07-03 at 20:42 -0400, George Mitchell wrote: > uname -a: > FreeBSD wonderland.m5p.com 9.0-STABLE FreeBSD 9.0-STABLE #9: Sun Jun 3 > 10:01:09 EDT 2012 > geo...@wonderland.m5p.com:/usr/obj/usr/src/sys/WONDERLAND amd64 > > dmesg | grep umass: > umass0: on usbus2 > umass0: SCSI over Bulk-Only; quirks = 0x4000 > umass0:3:0:-1: Attached to scbus3 > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not > ready to ready change, medium may have changed) > da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 > > # mount -t msdosfs /dev/da0s1 /flash > # umount /flash > umount: unmount of /flash failed: Device busy > > -- George Mitchell Are you running a desktop environment that automatically launches gam_server to watch for changes on mounted filesystems? If so, the fix is to edit /usr/local/etc/gamin/gaminrc and tell it to use polling rather than kernel notification on the mount points you use for removable media. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Need help with nfsv4 and krb5 access denied
On Thu, 2012-06-28 at 16:25 +0200, Herbert Poeckl wrote: > On 06/28/2012 02:07 AM, Rick Macklem wrote: > > The NFS server will authenticate nfs/tmp2.ist.intra against the Kerberos > > KDC, using the information in the keytab entry. The whole idea behind a > > host based principal like "nfs/tmp2.ist.intra" is that it can only be > > used by the host "tmp2.ist.intra". As such, when the Kerberos KDC receives > > an auathentication request for nfs/tmp2.ist.intra, it will DNS resolve > > tmp2.ist.intra (to 192.168.1.164 it seems) and will compare that to the > > IP address the authentication request is received from. I think this > > means the KDC will fail the request if it is sent to the KDC from > > 192.168.6.2. > > Yes, of course. There is and will be no traffic on 192.168.6.2. > > What I've tried to say (and probably failed), is that we have a network > card in the machine, where the result is always access denied (with the > correct server IP address set for that NIC). > > > > Your KDC should be logging something when this fails and the traffic you'd > > need to look at is the traffic between the NFS server and the KDC. (I'd use > > wireshark, since it probably knows a fair bit about Kerberos.) > > Thank you, I will give it a try. > > Kind regards, > Herbert When something in software works fine with one NIC but not another (nearly-) identical one, the first thing that comes to my mind is that the MAC address on the card is being used by the software as a sort of UUID. I had that happen with a commercial software once; when I changed NICs in the machine the software stopped working and said it wasn't registered on that machine. (I would have been annoyed except this sophisticed "security system" was circumvented by deleting a file that wasn't even hard to find, and it automatically re-authorized itself on the next run using the new MAC address.) -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to bind a route to a network adapter and not IP
On Mon, 2012-06-18 at 23:07 +0200, Hans Petter Selasky wrote:
> On Monday 18 June 2012 23:03:34 H wrote:
> > On Monday 18 June 2012 12:54 Hans Petter Selasky wrote:
> > > On Monday 18 June 2012 00:00:51 H wrote:
> > > > sth...@nethelp.no wrote:
> > > > >>> I loose packets because I use a WLAN adapter. Sometimes the link is
> > > > >>> down for various reasons, and then the routes start changing for
> > > > >>> manually created routes, and I want to prevent that.
> > > > >>
> > > > >> well that is certainly not a reason for changing routes
> > > > >>
> > > > >> I have the feeling you are not explaining good enough what really is
> > > > >> going on and it may help sending your configurations and an example
> > > > >> of routes and IP addresses before and after this route change
> > > > >
> > > > > Why is this so hard to understand? "Link down" leads to "static route
> > > > > is deleted". This is standard FreeBSD behavior, and has been this way
> > > > > for as long as I can remember (btw, I believe this behavior is from
> > > > > the original BSD, not FreeBSD specific).
> > > > >
> > > > > You can show this by having a static default route pointing to an
> > > > > address on an Ethernet interface which has link. And then pulling the
> > > > > TP cable from the Ethernet interface. Observe that the default route
> > > > > is automatically removed.
> > > >
> > > > may be you have not understood your own problem yet
> > > >
> > > > because so far is nothing to be understood because none of your
> > > > statements is correct, it is also not FreeBSD's standard behavior and
> > > > never has been
> > > >
> > > > as long as there is the valid IP address on the related interface, no
> > > > static route will be deleted, you can even boot without cable and the
> > > > [default] static route is there
> > > >
> > > > so you need to explain better your problem in order to understand it
> > > >
> > > > probably you have some other stuff running, thirdparty network manager
> > > > or something, incorrect or incomplete ppoe or dhc configuration or
> > > > whatever leads to the problem
> > > >
> > > > FYI static routes usually are the manually configured routes, so what
> > > > you say is redundant and not correct, I guess you're loosing some kind
> > > > of dynamic route
> > > >
> > > > since WL networks usually do not run RIP/OSPF/BGP I guess the route you
> > > > apparently loose is coming from some dhcp server and may be your
> > > > dhclient configuration is incomplete or none existent, but here now it
> > > > would be useful to see your config
> > >
> > > Hi,
> > >
> > > I think we need to distinguish between two matters. One is where the
> > > route is directly reachable on the local-net of the network adapter, and
> > > ARP is valid/responding. The second case is when the route is not
> > > directly reachable. The second case is where the problem happens, like
> > > Stian kindly explained.
> > >
> > > # For example:
> > >
> > > ifconfig wlan0 10.0.0.2 255.255.255.0 up
> > >
> > > # Assume the router is at 10.0.0.1
> > > # And we want to reach a certain destination through 10.0.0.1
> > > # Then we do:
> > >
> > > route add 10.22.1.1 10.0.0.1
> >
> > no no no my friend, wrong again
> >
> > that is a static route and it goes away same way it was created, manually
> > or by deleting the IP address 10.0.0.2 from the related interface
> >
> > wether there is or not an active link on that interface does not matter
> >
>
> Hi,
>
> Can it be that dhclient which I'm running on this interface with manual
> routes
> disrupts stuff then ??
>
> --HPS
I think you can get the effect you want with dhclient.conf. I just
experimented a bit and it works for me, installing the static route when
it gets an address (and it gets removed if I manually configure the
interface back to 0.0.0.0), using this dhclient.conf:
interface "re0" {
supersede static-routes 10.1.1.1 172.22.42.240;
}
It works with either the 'prepend' or 'supersede' verb, depending on
your needs. You can also specify multiple static routes, see
dhcp-options(5).
-- Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: su problem
On Sat, 2012-06-09 at 15:47 +0300, Sami Halabi wrote: > %su - > Password: > load: 0.00 cmd: su 30588 [ttydcd] 0.91r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 3.99r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 4.81r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 5.34r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 5.72r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 6.21r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 6.67r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 7.14r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 7.53r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 7.89r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 8.14r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 8.35r 0.00u 0.00s 0% 2092k > load: 0.00 cmd: su 30588 [ttydcd] 8.53r 0.00u 0.00s 0% 2092k > > > Thanks, > Sami Since the wait is "ttydcd", try "stty clocal" before doing the "su" command. I don't know why su would be waiting for dcd (modem carrier) but setting clocal mode should eliminate that wait. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Boot hangs on v9 system at CD device probe
On Wed, 2012-05-30 at 14:54 -0700, Kevin Oberman wrote: > I sent a note about this a couple of weeks ago, but have not heard > anything. I'm really getting a bit desperate. > > I have a system that I am trying to upgrade from 8.2 to 9.0. I have > built it and installed the kernel, but it fails to boot. The boot > freezes after probing for my hard drives during the probe of the > CDROM. It just sits there, seemingly forever, though I have never > waited longer then a few minutes. > > The system is a SuperMicro C25BX mother board. The DVD is PATA, > reported on boot of 8-Stable as: > acd0: DVDR at ata2-master UDMA66 > > If I unplug the CDROM, it boots fine, but I really need the device on > the system, so I really can't leave it unplugged. Also, after the 9 > kernel is installed, my Mk file have been updated so that I can't > build some ports if I boot the 8.2 kernel. Does anyone remember this > being reported by others? It was most likely on current, as it was > probably prior to the release of 9. I googled around, but could not > find it. > > I'd really appreciate it if anyone can point me toward a solution. > > Thanks, When faced with a mystery like this I sometimes go into the mode of "poke it with a stick and see if it twitches." If you can get it to twitch at all, maybe that's a starting point. In this case, I guess I might start with seeing if setting hw.ata.atapi_dma=0 in the loader makes any difference. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: /var getting full
On Fri, 2012-04-27 at 10:14 -0500, Efraín Déctor wrote: > Hello. I have a server using FreeBSD 8.2, and recently I’ve noticed that /var > is getting full But du hs /var shows me this: > > 14M/var/ > > How Can I know what is using var to free space? > > Thank you. > > OS info: > FreeBSD edh.edh 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 > UTC 2011 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > amd64 I would speculate that some process has unlinked a file but still has it open so the space is still in use. Try procstat -af | grep /var and look especially for lines that have a huge number in the OFFSET column (although I'm not sure that's definitive -- the file descriptor could be positioned at an offset less than the file size). -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Wed, 2012-04-04 at 15:05 +, jb wrote: > Ian Lepore damnhippie.dyndns.org> writes: > > > ... > > > But of interest to me is this: > > > "... > > > Text relocations are a way in which references in the executable code to > > > addresses not known at link time are solved. Basically they just write > > > the appropriate address at runtime marking the code segment writable in > > > order to change the address then unmarking it. This can be a problem as > > > an attacker could try to exploit a bug when the text relocation happens > > > in order to be able to write arbitrary code in the text segment which > > > would be executed. > > > ..." > > ... > > A kernel module is loaded and linked > > ONCE, at load time, into the kernel's address space. > > ... > > >From the point of view of an attacker it does not matter whether kernel > >module > is loaded and linked once only. That's enough to create a window of > opportunity > for interfering with relocation process and modifying text (code). > > jb Read again what I said. The same relocations would happen whether scattered through the text segment or gathered together in a single page. So the same window exists either way. But even more to the point: the memory has to be writable to initially populate it. The fact that it has to be changed as it is loaded doesn't in any way create an opportunity that doesn't already exist due to the pages being writable so that they can be loaded from disk. If there is some malicious in-kernel code (and it MUST be in-kernel code, because this is kernel memory, not mapped into any userland address space) it can already write to those pages because they're writable so that IO can happen. The pages are only visible to kernel code, and thus this hypothetical attack is being carried out by kernel code; if the pages weren't marked writable it would just make them writable, then write to them. If there is malicious in-kernel code that wants to do bad things, it doesn't have to wait for a .ko to get loaded to do the bad things. It's kernel code, it can do whatever it wants whenever it wants. This whole relocation question is just a big red herring. The kernel loader relocating a kernel module at load time does not open any opportunity for userland code to launch an attack on the memory pages into which the module gets loaded. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Wed, 2012-04-04 at 08:38 +, jb wrote: > pobox.com> writes: > > > ... > > You can appeal to authority by saying the Gentoo Hardened developers said > > such-and-such all you want, but it would be more useful for you to be able > > to make specific technical arguments yourself. Saying "it could be a > > problem" or "in the wild there may be" isn't useful. A valid technical > > argument giving a mechanism for relocations to be exploited is all that > > is needed for you to prove your point. > > ... > > I have a question regarding security of FreeBSD kernel module loading and > relocation. > > According to KLDLOAD(8): > "...The kldload utility loads file.ko into the kernel using the kernel > linker. ..." > > So, kernel module is loaded: > # kldload /boot/kernel/foo.ko > > Here is my question: is foo.ko modified at this time ? Due to relocations ? > > The reason I ask about it is this Gentoo Hardened FAQ item: > > http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#paxnoelf > > "I keep getting the message: "error while loading shared libraries: cannot > make > segment writable for relocation: Permission denied." What does this mean?" > > I understand this is about .so and does not apply directly to .ko . > > But of interest to me is this: > "... > Text relocations are a way in which references in the executable code to > addresses not known at link time are solved. Basically they just write > the appropriate address at runtime marking the code segment writable in order > to change the address then unmarking it. This can be a problem as an attacker > could try to exploit a bug when the text relocation happens in order to be > able > to write arbitrary code in the text segment which would be executed. > ..." > > Now, let me apply the above quoted paragraph to .ko and ask my question again, > this time being more specific: > > are you doing any "marking" and "unmarking" of it at relocations and load > time, > thus creating an attack window opportunity ? > > jb Even though you acknowledge it, your question seems to contradict an understanding of the concept that a .ko is not a shared library. The "marking and unmarking" you refer to would apply to pages that are shared among multiple processes and have to be relocated repeatedly into each process's address space. A kernel module is loaded and linked ONCE, at load time, into the kernel's address space. It is not shared and never needs to be relocated again into another address space. In other words, the paragraph you cite doesn't have any meaning in the context of a .ko, because a .ko isn't a userland shared library. It's also interesting to me to note that even in a userland shared library, whether there are text relocations scattered throughout the text segment or they're all gathered into one table the way PIC code works, the same number of relocations have to happen to link the library into a new address space. The only difference is whether many pages get touched because the relocations are scattered, or only a few pages because they're all clumped together. The PIC scheme is designed to maximize code sharing by eliminating the need to copy-on-write many modified pages. I wonder how it became associated with increased security? I don't see the increase. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't load many network kernel module in 8.3-PREREALEASE
On Fri, 2012-03-23 at 12:19 +0100, Quentin Schwerkolt wrote: > Hi, > > I can't load many if_* module on FreeBSD 8.3-PRERELEASE on amd64 and i386. > I have rebuild the system from the latest source. When I try a kldload > /boot/kernel/if_*.ko I have error such as "file exist" or "exec format > error". > > kldstat just after system start: > Id Refs AddressSize Name > 11 0x8010 e58280 kernel > > kldload -v /boot/kernel/if_*.ko: > kldload: can't load /boot/kernel/if_ae.ko: File exists > kldload: can't load /boot/kernel/if_age.ko: File exists > kldload: can't load /boot/kernel/if_alc.ko: File exists > kldload: can't load /boot/kernel/if_ale.ko: File exists > kldload: can't load /boot/kernel/if_an.ko: File exists > kldload: can't load /boot/kernel/if_ath.ko: Exec format error > kldload: can't load /boot/kernel/if_aue.ko: Exec format error > kldload: can't load /boot/kernel/if_axe.ko: Exec format error > kldload: can't load /boot/kernel/if_bce.ko: File exists > kldload: can't load /boot/kernel/if_bfe.ko: File exists > kldload: can't load /boot/kernel/if_bge.ko: File exists > kldload: can't load /boot/kernel/if_cdce.ko: Exec format error > kldload: can't load /boot/kernel/if_cue.ko: Exec format error > kldload: can't load /boot/kernel/if_dc.ko: File exists > kldload: can't load /boot/kernel/if_de.ko: File exists > kldload: can't load /boot/kernel/if_ed.ko: File exists > kldload: can't load /boot/kernel/if_em.ko: File exists > kldload: can't load /boot/kernel/if_en.ko: Exec format error > kldload: can't load /boot/kernel/if_et.ko: File exists > kldload: can't load /boot/kernel/if_faith.ko: Exec format error > kldload: can't load /boot/kernel/if_fatm.ko: Exec format error > kldload: can't load /boot/kernel/if_fwe.ko: Exec format error > kldload: can't load /boot/kernel/if_fwip.ko: Exec format error > kldload: can't load /boot/kernel/if_fxp.ko: File exists > kldload: can't load /boot/kernel/if_gif.ko: Exec format error > kldload: can't load /boot/kernel/if_hatm.ko: Exec format error > kldload: can't load /boot/kernel/if_igb.ko: File exists > kldload: can't load /boot/kernel/if_jme.ko: File exists > kldload: can't load /boot/kernel/if_kue.ko: Exec format error > kldload: can't load /boot/kernel/if_le.ko: File exists > kldload: can't load /boot/kernel/if_lge.ko: File exists > kldload: can't load /boot/kernel/if_msk.ko: File exists > kldload: can't load /boot/kernel/if_nfe.ko: File exists > kldload: can't load /boot/kernel/if_nge.ko: File exists > kldload: can't load /boot/kernel/if_patm.ko: Exec format error > kldload: can't load /boot/kernel/if_pcn.ko: File exists > kldload: can't load /boot/kernel/if_ral.ko: File exists > kldload: can't load /boot/kernel/if_re.ko: File exists > kldload: can't load /boot/kernel/if_rl.ko: File exists > kldload: can't load /boot/kernel/if_rue.ko: Exec format error > kldload: can't load /boot/kernel/if_rum.ko: Exec format error > kldload: can't load /boot/kernel/if_sf.ko: File exists > kldload: can't load /boot/kernel/if_sge.ko: File exists > kldload: can't load /boot/kernel/if_sis.ko: File exists > kldload: can't load /boot/kernel/if_sk.ko: File exists > kldload: can't load /boot/kernel/if_sn.ko: File exists > kldload: can't load /boot/kernel/if_ste.ko: File exists > kldload: can't load /boot/kernel/if_stge.ko: File exists > kldload: can't load /boot/kernel/if_ti.ko: File exists > kldload: can't load /boot/kernel/if_tl.ko: File exists > kldload: can't load /boot/kernel/if_tun.ko: File exists > kldload: can't load /boot/kernel/if_tx.ko: File exists > kldload: can't load /boot/kernel/if_txp.ko: File exists > kldload: can't load /boot/kernel/if_uath.ko: Exec format error > kldload: can't load /boot/kernel/if_udav.ko: Exec format error > kldload: can't load /boot/kernel/if_upgt.ko: Exec format error > kldload: can't load /boot/kernel/if_ural.ko: Exec format error > kldload: can't load /boot/kernel/if_vge.ko: File exists > kldload: can't load /boot/kernel/if_vlan.ko: Exec format error > kldload: can't load /boot/kernel/if_vr.ko: File exists > kldload: can't load /boot/kernel/if_vx.ko: File exists > kldload: can't load /boot/kernel/if_wb.ko: File exists > kldload: can't load /boot/kernel/if_wi.ko: File exists > kldload: can't load /boot/kernel/if_xl.ko: File exists > kldload: can't load /boot/kernel/if_zyd.ko: Exec format error > Loaded /boot/kernel/if_bridge.ko, id=2 > Loaded /boot/kernel/if_bwi.ko, id=4 > Loaded /boot/kernel/if_bwn.ko, id=5 > Loaded /boot/kernel/if_carp.ko, id=7 > Loaded /boot/kernel/if_cas.ko, id=8 > Loaded /boot/kernel/if_cxgb.ko, id=9 > Loaded /boot/kernel/if_cxgbe.ko, id=10 > Loaded /boot/kernel/if_disc.ko, id=11 > Loaded /boot/kernel/if_edsc.ko, id=12 > Loaded /boot/kernel/if_ef.ko, id=13 > Loaded /boot/kernel/if_epair.ko, id=15 > Loaded /boot/kernel/if_gem.ko, id=17 > Loaded /boot/kernel/if_gre.ko, id=18 > Loaded /boot/kernel/if_hme.ko, id=19 > Loaded /boot/kernel/if_ic.ko, id=20 > Loaded /boot/kernel/if_ipheth.ko, id=22 > Load
Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0
On Thu, 2012-03-22 at 18:13 +0200, Volodymyr Kostyrko wrote: > Andriy Gapon wrote: > > on 22/03/2012 17:33 Volodymyr Kostyrko said the following: > >> Andriy Gapon wrote: > >>> on 22/03/2012 15:19 Mike Tkachuk said the following: > kern.eventtimer.periodic: 0 > >>> > >>> It might make sense to try 1 here. > >>> Also you could attempt to involve mav@ directly - here is an author of > >>> the code > >>> and an expert on it. > >> > >> Better ask before setting as this doubles hpet0 (with HPET) or cpu0:timer > >> (with > >> LAPIC) interrupt rate for me. > > > > Does it make your system unusable? > > Are you comparing with pre-eventtimers version of FreeBSD? > > In short term - no. Haven't tested it thoroughly. Results are the same > (double interrupt rate according to `systat 1 -v`) for: > * i386 and amd64 9-STABLE; > * amd64 9.0. > > As everything related to timing/freq/acpi can be unpredictive I wouldn't > recommend this to anyone. I own at least two Intel CPU's failing > somewhere near timing/apic when loading cpufreq and enabling powerd. > I'm not sure I understand that advice. We have someone whose system is failing (time stops counting) when using the new event timer code. The recommendation is to set kern.eventtimer.periodic=1, which as I understand it makes the new code work more like it did before. That seems to be a reasonable attempt to work around the problem. If it works, the system becomes 100% more usable than it is now, even if that comes at the cost of timers interrupting twice as fast as they did in previous OS releases. It also generates another datapoint that might somehow help track down why the event timer code has trouble on some hardware. Enough such datapoints may eventually lead to an "aha -- it happens on all systems that have the xyz chipset." -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0
On Sat, 2012-03-10 at 15:07 +0700, Adam Strohl wrote: > I've now seen this on two different VMs on two different ESXi servers > (Xeon based hosts but different hardware otherwise and at different > facilities): > > Everything runs fine for weeks then (seemingly) suddenly/randomly the > clock STOPS. In the first case I saw a jump backwards of about 15 > minutes (and then a 'freeze' of the clock). The second time just 'time > standing still' with no backwards jump. Logging accuracy is of course > questionable given the nature of the issue, but nothing really jumps out > (ie; I don't see NTPd adjusting the time just before this happens or > anything like that). > > Naturally the clock stopping causes major issues, but the machine does > technically stay running. My open sessions respond, but anything that > relies on time moving forward hangs. I can't even gracefully reboot it > because shutdown/etc all rely on time moving forward (heh). > > So I'm not sure if this is a VMWare/ESXi issue or a FreeBSD issue, or > some kind of interaction between the two. I manage lots of VMWare > based FreeBSD VMs, but these are the only ESXi 5.0 servers and the only > FreeBSD 9.0 VMs. I have never seen anything quite like this before, and > last night as I mentioned above I had it happen for the second time on a > different VM + ESXi server combo so I'm not thinking its a fluke > anymore. I've looked for other reports of this both in VMWare and > FreeBSD contexts and not seeing anything. > > What is interesting is that the 2 servers that have shown this issue > perform similar tasks, which are different from the other VMs which have > not shown this issue (yet). This is 2 VMs out of a dozen VMs spread > over two ESXi servers on different coasts. This might be a coincidence > but seems suspicious. These two VMs run these services (where as the > other VMs don't): > > - BIND > - CouchDB > - MySQL > - NFS server > - Dovecot 2.x > > I would also say that these two VMs probably are the most active, have > the most RAM and consume the most CPU because of what they do (vs. the > others). > > I have disabled NTPd since I am running the OpenVM Tools (which I > believe should be keeping the time in sync with the ESXi host, which > itself uses NTP), my only guess is maybe there is some kind of collision > where NTPd and OpenVMTools were adjusting the time at the same time. > I'm playing the waiting game now to see what this brings (again though I > am running NTPd and OpenVMTools on all the other VMs which have yet to > show this issue). > > Anyone seen anything like this? Ring any bells? > I've run into the "time standing still" problem, but only on bringing up FreeBSD on new hardware (usually industrial single-board computers). In those cases time never advances beyond the time obtained from the RTC hardware at boot. I've never seen it happen that time runs normally for a while then stops advancing, but I have almost no experience with FreeBSD as a VM guest OS. When I have seen the problem, it's always been due to interrupt problems, such as the timer tick handler getting hung or the selected timer hardware not generating interrupts. It seems unlikely to me that ntpd and the vm tools would be fighting in a way that caused this symptom. The way ntpd affects timing is to step the clock (which gets logged), or to numerically steer the kernel's timekeeping routines. The steering is clamped at 500 ppm; to make the clock appear to stop it would have to steer at 1e6 ppm. I've always assumed that VM guest services daemons that handle timekeeping use the same ntp_adjtime() interface to the kernel timekeeping that ntpd itself uses, so the same steering limits would apply. If it happens again, interesting data might be found in the output of: sysctl kern.timecounter sysctl kern.eventtimer vmstat -i ntpdc -c kerninfo -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Xeon Processors with AES instructions and geli encryption
On Wed, 2012-03-07 at 09:09 -0600, Karl Denninger wrote: > Does the crypto(9) framework recognize and use these instructions? > Looks like the Windmere-series Xeons will drop into my system boards; I > gain two cores per CPU at the same time, so I'll go from an 8-way SMP > system to a 12-way one. > > I am considering spending the money to upgrade a couple of servers here > that run geli-encrypted disks, as during heavy I/O they spend a LOT of > their CPU time on the disk encryption. The differences I see in the use > of TrueCrypt on Windows machines that have AES instructions .vs. those > that do not are very significant and I'm curious if this carries over to > FreeBSD. > > Thanks in advance! > It looks like it does as of 8.2 when the aesni driver was added. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 8.2 - active plus inactive memory leak!?
On Tue, 2012-03-06 at 19:13 +, Luke Marsden wrote:
> Hi all,
>
> I'm having some trouble with some production 8.2-RELEASE servers where
> the 'Active' and 'Inact' memory values reported by top don't seem to
> correspond with the processes which are running on the machine. I have
> two near-identical machines (with slightly different workloads); on one,
> let's call it A, active + free is small (6.5G) and on the other (B)
> active + free is large (13.6G), even though they have almost identical
> sums-of-resident memory (8.3G on A and 9.3G on B).
>
> The only difference is that A has a smaller number of quite long-running
> processes (it's hosting a small number of busy sites) and B has a larger
> number of more frequently killed/recycled processes (it's hosting a
> larger number of quiet sites, so the FastCGI processes get killed and
> restarted frequently). Notably B has many more ZFS filesystems mounted
> than A (around 4,000 versus 100). The machines are otherwise under
> similar amounts of load. I hoped that the community could please help
> me understand what's going on with respect to the worryingly large
> amount of active + free memory on B.
>
> Both machines are ZFS-on-root with FreeBSD 8.2-RELEASE with uptimes
> around 5-6 days. I have recently reduced the ARC cache on both machines
> since my previous thread [1] and Wired memory usage is now stable at 6G
> on A and 7G on B with an arc_max of 4G on both machines.
>
> Neither of the machines have any swap in use:
>
> Swap: 10G Total, 10G Free
>
> My current (probably quite simplistic) understanding of the FreeBSD
> virtual memory system is that, for each process as reported by top:
>
> * Size corresponds to the total size of all the text pages for the
> process (those belonging to code in the binary itself and linked
> libraries) plus data pages (including stack and malloc()'d but
> not-yet-written-to memory segments).
> * Resident corresponds to a subset of the pages above: those pages
> which actually occupy physical/core memory. Notably pages may
> appear in size but not appear in resident for read-only text
> pages from libraries which have not been used yet or which have
> been malloc()'d but not yet written-to.
>
> My understanding for the values for the system as a whole (at the top in
> 'top') is as follows:
>
> * Active / inactive memory is the same thing: resident memory from
> processes in use. Being in the inactive as opposed to active
> list simply indicates that the pages in question are less
> recently used and therefore more likely to get swapped out if
> the machine comes under memory pressure.
> * Wired is mostly kernel memory.
> * Cache is freed memory which the kernel has decided to keep in
> case it correspond to a useful page in future; it can be cheaply
> evicted into the free list.
> * Free memory is actually not being used for anything.
>
> It seems that pages which occur in the active + inactive lists must
> occur in the resident memory of one or more processes ("or more" since
> processes can share pages in e.g. read-only shared libs or COW forked
> address space). Conversely, if a page *does not* occur in the resident
> memory of any process, it must not occupy any space in the active +
> inactive lists.
>
> Therefore the active + inactive memory should always be less than or
> equal to the sum of the resident memory of all the processes on the
> system, right?
>
> But it's not. So, I wrote a very simple Python script to add up the
> resident memory values in the output from 'top' and, on machine A:
>
> Mem: 3388M Active, 3209M Inact, 6066M Wired, 196K Cache, 11G
> Free
> There were 246 processes totalling 8271 MB resident memory
>
> Whereas on machine B:
>
> Mem: 11G Active, 2598M Inact, 7177M Wired, 733M Cache, 1619M
> Free
> There were 441 processes totalling 9297 MB resident memory
>
> Now, on machine A:
>
> 3388M active + 3209M inactive - 8271M sum-of-resident = -1674M
>
> I can attribute this negative value to shared libraries between the
> running processes (which the sum-of-res is double-counting but active +
> inactive is not). But on machine B:
>
> 11264M active + 2598M inactive - 9297M sum-of-resident = 4565M
>
> I'm struggling to explain how, when there are only 9.2G (worst case,
> discounting shared pages) of resident processes, the system is using 11G
> + 2598M = 13.8G of memory!
>
> This "missing memory" is scary, because it seems to be increasing over
> time, and eventually when the system runs out of free memory, I'm
> certain it will crash in the same way described in my previous thread
> [1].
>
> Is my understanding of the virtual memory system badly broken - in which
> case please educate me ;-) or is there a real problem here
Re: flowtable usable or not
On Sat, 2012-03-03 at 09:09 -0800, per...@pluto.rain.com wrote: > H wrote: > > > ... Forever installing FreeBSD Desktop, either KDE or Gnome, > > was a nightmare process, or better, to make it appear on screen > > was a nightmare. > > I have never understood the point of KDE or Gnome, other than > (perhaps) as eye candy for the uninitiated. If I wanted a > Windows desktop, I would install Windows. If I wanted a Mac > desktop, I would use a Mac. I've been getting paid to develop software since 1975 -- I'm hardly what you would call "the uninitiated." I couldn't imagine working without a fully functional desktop environment. Look at a calendar, it's 2012. Maybe you long for a return to punch cards and fanfold greenbar paper, but I'm not going back there. It's exactly because I don't want a Windows or Mac desktop that I use gnome. (I used to be a Mac user, starting in the 80s, but Apple lost their way during their struggle to survive 10 years ago. Soon you won't be able to boot a Mac without an account at the iTunes store, and my last Mac will go into the e-cycle pile at that point.) -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: flowtable usable or not
On Sat, 2012-03-03 at 03:44 -0300, H wrote: > Doug Barton wrote: > > Just looking at the committers, of which we have over 300, only a > > couple dozen at most have ever identified as actually using FreeBSD as > > a desktop at my count. Taking the larger development community into > > account I think the numbers are a little better, but not much. Sure, > > our strength is servers, and that is not going to change. > eventually that could be a good starting point, good question is, why not? > > > But how many real-life bugs have I personally uncovered in -current as > > a result of actually running it (mostly) daily? I'm not the only one, > > certainly, but if the numbers were flipped and the vast majority of > > our developers *did* use FreeBSD routinely, how much better off would > > we be? > again, why? > > let's face some reality. Forever installing FreeBSD Desktop, either KDE > or Gnome, was a nightmare process, or better, to make it appear on > screen was a nightmare. > > Even if somebody got all packages into his system (by miracle?), it > still did not popped up. Without some special knowledge _no_chance_. > > who knows, the guys who created and battled on area51 knew why they > chose this name :) > > Still now, kde4, hours of install, missing packages, compiling and still > nothing, somewhere over the process, flies over the screen please set > kdm4_enable="YES" ... I guess that will not be noticed by any user > > Even if some smart guy figures out that he needs xorg-server, the port > or package do not select all it needs for running, its own drivers and > so. How a user should know that? There is a windeco which installs > hundreds of deps, even sound what do not work on FreeBSD, but xorg do > not have deps for its functionality? god ... ohhh I forgot, that has > nothing to do with the desktop itself , sorry for mentioning ... > > Anybody can tell how somebody can find all this out? Don't say by > reading because we need to look at the real facts and that is nobody > want to read, they want a desktop nothing else, something silly and easy > to read email and write docs and surf on the net, listen to a CD, they > need to put a cd into the drive, running install process, reboot, using, > nothing else and such a thing ... we do not have > > so where this potential users should come from? Only from heaven ... > > And before anyone bothers to point it out, yes, I happen to be using > > Windows at this exact moment. I have some layer 9 work to get done and > > I need tools that are only available to me in Windows (more's the > > pity). The sad thing is, judging by the activity on the -ports@ list, > > the traffic in #bsdports, and just talking to/interacting with FreeBSD > > users, a lot of *them* are not only interested in FreeBSD as a desktop > > OS, they are actually doing it. > > IMO the weakest point is that we do not have the packages ready. > > Even if lots of you do not like it to hear, fact is that we must look > around and see how others do it. Windows, whatever it is, it is easy to > install for everybody. > > Same for Fedora, in order to stay with a Unix system, package handling, > update with YUM on Fedora hardly fails. > > ALL packages are compiled, you never need to compile anything. Even if > you need 800MB of packages, yum picks them all, installs them all, and > all is fine up top date. Such a process is where we need to get > orientation from. > > If it was my decision, it should be go to ports=no_no, packages=YES > > I mean, as long as the packages are not complete and ready, no new port > version should be released or announced > > So who dares,understand and can or like adventures, compiles from ports > > Such a decision would help FreeBSD in all means and would help the users > as well, in any case it will create more users > > Why somebody should chose FreeBSD as his daily desktop, oh man, only > some die-hard-guys like you and me, but you know, that is not hours of > work, that is days, weeks and constant setbacks for whatever reasons ... > that is not for anybody. And you are right, no traffic on the specific > lists, why? because the three on the list, two can help themselves (you > and me) and the other is the moderator ... :) not even the port > maintainer/packager is on that list ... :) > > ps. the last statement might be exaggerated and might not be valid in > all cases, so please do not shoot > > When the announcement of the 8.3-BETA1 release was made on these lists I had just finished building a new machine to become my everyday desktop machine for code development. I figured I should download and install using the new beta to help test the release. I was disappointed to find that the packages weren't on the beta dvd ISO, so the test wasn't as complete as I was hoping in terms of being similar to what a new user would experience. I ran through the sysinstall process without any glitches and rebooted to a working text-mode system. Then I d
Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?]
On Tue, 2012-02-28 at 19:15 +, Harry Newton wrote: > 9-RELEASE works fine. csup to 9-STABLE and make buildworld kernel etc > gives a system the hangs during the boot process. There are no error > messages during the part boot, and no panic. Last messages before hang > are: > > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > > I am stumped about how to diagnose this, and would be _very_ grateful > for any suggestions. > > When it's hung I can't force a break to debugger (BREAK_TO_DEBUGGER) > in kern conf: I imagine I'm too early in the boot sequence. > > - Harry > I assume booting verbose doesn't provide any more clues? I've sometimes gotten an extra clue from a hang during boot by building with option BUS_DEBUG. Even if you don't suspect the newbus routines as directly being the problem, sometimes you get a bit more info about what was happening at the time of lockup. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: geom vs. removable disks/cards (was: Re: random problem with 8.3 from yesterday)
On Sat, 2012-02-25 at 07:55 +0100, Juergen Lock wrote: > In article <1330126840.7317.60.ca...@revolution.hippie.lan> you write: > >On Sat, 2012-02-25 at 00:39 +0200, Andriy Gapon wrote: > >> on 24/02/2012 18:23 Ian Lepore said the following: > >> > I've always > >> > suspected something in the geom layer isn't noticing that a CF or SD > >> > card in the reader got removed/inserted/reformatted, and un-/re-plugging > >> > the whole reader (making the cam layer destroy and recreate the devices) > >> > makes geom aware of the change. > >> > >> This is a fact, actually. Nothing in GEOM layer (and below it) notices a > >> silent > >> card change, since most hardware doesn't have any notification for the > >> change > >> and FreeBSD disk stack doesn't do any polling for changes. > >> > > > >If the hardware did have change notification, is there a mechanism that > >would communicate that to geom? That's a precursor question to my real > >question: is there a way to manually kick geom when necessary? If the > >api exists but there's no userland app to make the needed calls, I'll > >write some code -- just point me at a manpage or header file. > > scsi has a mechanism called unit attention to report things like > media changes, not sure usb devices use that tho since the host can > only poll them... > > Anyway, the usual workaround is to force a geom retaste by opening > the device for writing without actually writing anything, e.g.: > > # : >/dev/da0 > > Btw this can't be Erich's problem I'd say since he said he's > plugging in a thumbdrive not a card into a reader (and also writing > /dev/zero to it) so geom _should_ already taste it. (Unless the > write fails since the thumbdrive is too slow initializing or something > like that...) > > HTH, > Juergen I was a bit concerned that the similarities between Erich's symptoms and mine were purely superficial, with different underlying causes. I've never seen the stale geom data problem I described on a thumb drive, except when I've used dd to zero out the beginning of a drive that was gpt-formatted but left the backup partition table at the end of the drive -- that always causes me problems that only get fixed by using gpart destroy -F. Thanks for the tip about forcing a re-taste, I think I'll be using that a bunch. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: random problem with 8.3 from yesterday
On Sat, 2012-02-25 at 00:39 +0200, Andriy Gapon wrote: > on 24/02/2012 18:23 Ian Lepore said the following: > > I've always > > suspected something in the geom layer isn't noticing that a CF or SD > > card in the reader got removed/inserted/reformatted, and un-/re-plugging > > the whole reader (making the cam layer destroy and recreate the devices) > > makes geom aware of the change. > > This is a fact, actually. Nothing in GEOM layer (and below it) notices a > silent > card change, since most hardware doesn't have any notification for the change > and FreeBSD disk stack doesn't do any polling for changes. > If the hardware did have change notification, is there a mechanism that would communicate that to geom? That's a precursor question to my real question: is there a way to manually kick geom when necessary? If the api exists but there's no userland app to make the needed calls, I'll write some code -- just point me at a manpage or header file. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: random problem with 8.3 from yesterday
On Fri, 2012-02-24 at 13:50 +0700, Erich Dollansky wrote: > Hi, > > On Thursday 23 February 2012 20:22:57 Stefan Bethke wrote: > > Am 22.02.2012 um 07:34 schrieb Erich Dollansky: > > > > > > > > tunefs -L NewDeviceName /dev/da0a > > > > > > Either this call or the mount command does not work randomly. > > > > > > When I then try to mount the device on /dev/da0a it does not work always. > > > > > > I do not know what this causes, I am only randomly able to reproduce it. > > > > > > It might be affected by removing the device or keeping it plugged in. > > > > You need to be more specific: what "does not work" mean? Output, results? > > > it seems that I forgot to copy the console output for this. > > Ok, as far as I remember, tunefs said something like it does not recognise > the slice. > > Mount has had two different messages. One also said that it could not > find/recognise the slice. The other one said that the file system was unknown > despite just running a newfs on it. > > I am very much aware that this kind of errors are very hard to find > especially if they are not reproduceable. > > Erich > > > > > Stefan > > > > -- > > Stefan BethkeFon +49 151 14070811 I've been putting up with problems like this since first upgrading to 8.2. I guess I haven't dug deeper into them because it's actually a huge improvement from what I was used to in 6.x and 7.x where complete system lockups were more common with removable usb drives. Here's an example sequence that just happened to me with a compact flash card in a usb multi-card reader... revolution # ll /dev/da* crw-r- 1 root operator0, 246 Feb 24 08:21 /dev/da0 crw-r- 1 root operator1, 26 Feb 24 08:21 /dev/da0s1 crw-r- 1 root operator1, 39 Feb 24 08:21 /dev/da0s1a crw-r- 1 root operator1, 40 Feb 24 08:21 /dev/da0s1e crw-r- 1 root operator1, 27 Feb 24 08:21 /dev/da0s2 crw-r- 1 root operator1, 29 Feb 24 08:21 /dev/da0s2a crw-r- 1 root operator1, 30 Feb 24 08:21 /dev/da0s2e crw-r- 1 root operator1, 28 Feb 24 08:21 /dev/da0s3 crw-r- 1 root operator1, 32 Feb 24 08:21 /dev/da0s3a crw-r- 1 root operator0, 248 Feb 23 12:01 /dev/da1 crw-r- 1 root operator0, 249 Feb 23 12:01 /dev/da2 crw-r- 1 root operator0, 250 Feb 23 12:01 /dev/da3 crw-r- 1 root operator1, 44 Feb 24 08:54 /dev/da4 revolution # mount /dev/da0s1a /mnt mount: /dev/da0s1a : Invalid argument revolution # fsck -y /dev/da0s1a fsck: Could not determine filesystem type revolution # fsck -t ufs -y /dev/da0s1a ** /dev/da0s1a Cannot find file system superblock ioctl (GCINFO): Inappropriate ioctl for device fsck_ufs: /dev/da0s1a: can't read disk label At this point I unplug the multi-card reader and plug it back in. revolution # fsck -y /dev/da0s1a fsck: Could not determine filesystem type revolution # fsck -t ufs -y /dev/da0s1a ** /dev/da0s1a ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1932 files, 45569 used, 385214 free (54 frags, 48145 blocks, 0.0% fragmentation) * FILE SYSTEM IS CLEAN * revolution # mount /dev/da0s1a /mnt At this point everything is fine and I can access the card. Sometimes I have to do the unplug/replug dance and sometimes I don't. I've always suspected something in the geom layer isn't noticing that a CF or SD card in the reader got removed/inserted/reformatted, and un-/re-plugging the whole reader (making the cam layer destroy and recreate the devices) makes geom aware of the change. Oh, a datapoint... notice how the timestamps on the /dev/da0* files above are all 08:21? I had just inserted that card at 08:57 when I ran the command sequence above, but apparently the geom layer was still reporting on a different card that was used and removed earlier this morning. I'm not sure whether or not this is related to the problem Erich originally reported, but there are some similarities in symptoms such as the inability to recognize the filesystem type, so I thought I'd mention it. This happens to me several times a week (often several times a day) so if anyone has suggestions on information-gathering I'll probably have lots of opportunities. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 6.2-Release ..ish.. CF + ata == freeze?
On Tue, 2012-02-14 at 00:12 -0500, Jason Hellenthal wrote: > > On Mon, Feb 13, 2012 at 08:43:08PM -0800, john fleming wrote: > > Just thought i would post over here as i'm not getting a warm fuzzy from > > checkpoint about being able to find the root cause of an issue. I have a > > large install base of IPSO checkpoint firewalls, which are based on FreeBSD > > 6.2. I've had 3 firewalls hang basically the same way, with something that > > looks like a filesystem issue or an issue with a CF card. > > > > Does anyone happen to know of any bugs (i've been looking around) that > > could cause something like that? Granted, it could be a batch of bad CF > > cards, but its odd that i'm seeing the same thing on 3 different boxes and > > once rebooted they seem ok. > > > > Also is it possible to get useful info form the atacontroller when things > > go south like this from the ddb prompt? > > > > This is what shows in show msgbuf > > ad0: timeout waiting to issue command > > ad0: error issuing WRITE command > > ad0: timeout waiting to issue command > > ad0: error issuing WRITE command > > ad0: timeout waiting to issue command > > ad0: error issuing WRITE command > > ad0: timeout waiting to issue command > > ad0: error issuing WRITE command > > g_vfs_done():ad0s4h[WRITE(offset=33849344, length=131072)]error = 5 > > g_vfs_done():ad0s4h[WRITE(offset=33980416, length=131072)]error = 5 > > g_vfs_done():ad0s4h[WRITE(offset=34111488, length=131072)]error = 5 > > g_vfs_done():ad0s4h[WRITE(offset=34242560, length=131072)]error = 5 > > g_vfs_done():ad0s4h[WRITE(offset=34373632, length=131072)]error = 5 > > > > ad0: 1882MB at ata0-master PIO4 > > atapci0: port > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5070-0x507f mem 0x80301000-0x803013ff > > at device 31.1 on pci0 > > ata0: on atapci0 > > ata1: on atapci0 > > atapci1: port > > 0x5088-0x508f,0x50a4-0x50a7,0x5080-0x5087,0x50a0-0x50a3,0x5060-0x506f irq > > 15 at device 31.2 on pci0 > > ata2: on atapci1 > > ata3: on atapci1ad0s4h is basically a r/w ufs partition on > > the box where almost anything that needs to be written goes. > > trace > > Tracing pid 1101 tid 100043 td 0x656d8460 > > kdb_enter(608cc388,6246,656d8460,64ba1400,6095d580,...) at kdb_enter+0x2b > > siointr1(64ba1400) at siointr1+0xf0 > > siointr(64ba1400) at siointr+0x38 > > intr_execute_handler(6095d580,f0a4ab04,6,6095d580,f0a4aafc,...) at > > intr_execute_handler+0x61 > > intr_execute_handlers(6095d580,f0a4ab04,6,0,656d8460,...) at > > intr_execute_handlers+0x40 > > atpic_handle_intr(4) at atpic_handle_intr+0x96 > > Xatpic_intr4() at Xatpic_intr4+0x20 > > --- interrupt, eip = 0x606044af, esp = 0xf0a4ab48, ebp = 0xf0a4ab5c --- > > lockmgr(e1456a04,6,0,656d8460) at lockmgr+0x58f > > getdirtybuf(e14569a4,60a405e4,1) at getdirtybuf+0x2e2 > > flush_deplist(68b30850,1,f0a4abb8) at flush_deplist+0x30 > > flush_inodedep_deps(656fa28c,1f235) at flush_inodedep_deps+0xcf > > softdep_sync_metadata(65964618) at softdep_sync_metadata+0x61 > > ffs_syncvnode(65964618,1) at ffs_syncvnode+0x3a2 > > ffs_fsync(f0a4ac74) at ffs_fsync+0x12 > > VOP_FSYNC_APV(60949260,f0a4ac74) at VOP_FSYNC_APV+0x38 > > fsync(656d8460,f0a4acb4) at fsync+0x170 > > syscall(805003b,806003b,5fbf003b,805,288be450,...) at syscall+0x2ee > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > This looks to be a problem with softupdates and CF cards. Can you get > this to repeat on a brand new (good) card ? > EIO errors on a write that lead to a panic nearly always backtrace into the softupdates code, because that code pretty much has to panic if it can't write things in the proper order. That doesn't imply that the softupdates code is at fault in any way, or that the errors would go away if softupdates were turned off. In fact, I consider it important to have softupdates enabled on CF and SDCard media. The number of writes (and especially of repeated re-writes of the same filesystem metadata sectors) goes way way up without SU enabled, and that's bad for media with a limited number of write cycles in its lifetime. We've been using 6.2 with SU enabled on CF cards for many years at Symmetricom; we're still shipping systems with that config. Depending on the motherboard or SBC, we often have to disable ata DMA, or limit it to a max of WDMA2 mode. The indication that you need to do so is typically a lockup either trying to load the kernel and modules, or sometimes that works but it locks up while initializing the ata driver. [1] If your systems have been running fine with DMA enabled, it's not the sort of problem that suddenly appears out of the blue. You find out when you need to disable it pretty quickly on new hardware because it doesn't boot reliably. I tend to agree with Jeremy's assesment that you may have some CF cards that have neared the end of their life, and especially if they're full the automatic wear leveling can't find any un-worn cells to use. If the cards are old they may have primitive wear-leve
Re: Disable DMA.
On Sun, 2012-02-12 at 10:29 +0100, Peter Ankerstål wrote: > On Feb 11, 2012, at 9:34 PM, Alexander Motin wrote: > > > On 02/11/12 20:15, Peter Ankerstål wrote: > >> In FreeBSD 8 i used the loader-variable hw.ata.ata_dma=0 to get my > >> computer boot on a CF card. But > >> in FreeBSD 9.0 it doesn't seem to work. Could it be another variable or is > >> it something else that doesn't work > >> in 9? The machine boots up the installer when the CF-card is not present > >> but when it is present it stops right > >> after the "Timecounter" stuff. > > > > On 9.0 you can to it with > > hint.ata.X.mode=PIO4 > > , where X is a bus number. > > > > In recent 8/9-STABLE I've also resurrected hw.ata.ata_dma=0. > > > That works, thanks! It's also useful to try modes other than PIO4 when using the finer-grained mode= control. We've been disabling dma completely on SBCs with CF sockets for years due to the kind of lockup you mention, but I recently discovered that some units run just fine with mode=WDMA2 (but not any dma modes faster than that). -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reducing the need to compile a custom kernel
On Fri, 2012-02-10 at 15:10 -0800, Jeremy Chadwick wrote: > * Addition: device ichwd > - Note: We do not use features of this driver given known problems > with the watchdog firing during ddb> and similar environments. I > have no idea if this has been fixed, but I do remember it being > confirmed as a problem. It used to be that "watchdog 0" in ddb disabled the watchdog, then when we upgraded to 8.2 that stopped working. One day I discovered (via typo) that now just "watchdog" without a numeric parm disables it. I'm not positive that applies to the ichwd but it works that way for the hardware watchdog on our arm platforms. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Marvel 88SE9480
On Fri, 2012-01-20 at 17:19 -0500, Mike Tancsa wrote:
> Hi,
>
> I tried this new controller
> http://www.addonics.com/products/ad2ms6gpx8.php
> which is based on the 88SE9480 chipset. Does anyone have it working ?
>
> I tried adding the PCI ID, but it does not attach unfortunately.
>
> {0x94801b4b, 0x00, "Addonics", AHCI_Q_NOBSYRES},
>
> ahci0: mem
> 0x4814-0x4815,0x4810-0x4813 irq 16 at device 0.0 on pci1
> device_attach: ahci0 attach returned 6
>
> pciconf shows
>
> ahci0@pci0:1:0:0: class=0x010400 card=0x94801b4b chip=0x94801b4b
> rev=0x03 hdr=0x00
> vendor = 'Marvell Technology Group Ltd.'
> class = mass storage
> subclass = RAID
> bar [10] = type Memory, range 64, base 0x4814, size 131072,
> enabled
> bar [18] = type Memory, range 64, base 0x4810, size 262144,
> enabled
> cap 01[40] = powerspec 3 supports D0 D1 D3 current D0
> cap 05[50] = MSI supports 1 message, 64 bit
> cap 10[70] = PCI-Express 2 endpoint max data 128(4096) link x8(x8)
> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
> ecap 0002[140] = VC 1 max VC0
>
> This was with today's RELENG_9
>
> ---Mike
>
pciconf says rev=0x03 and the second field in the ahci_ids struct is
named rev, maybe 0x03 needs to go there?
-- Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial port stops working after upgrade to 9-CURRENT
On Fri, 2012-01-20 at 07:28 -0800, Jeremy Chadwick wrote: > Also, does this machine have ACPI support? I do not use 9.x, but uartX > on our RELENG_8 systems is tied to acpi0, not isa0. It's been this way > for quite some time (even our RELENG_7 boxes are this way). It works on systems that don't have acpi, or have it disabled, as well. It seems that all the legacy isa devices are parented to both the acpi and isa busses, and some magic I don't understand makes the acpi bus take precedence over isa when it's available. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange 'hangs' with RELENG_9
On Thu, 2012-01-19 at 21:46 +0200, Alexander Motin wrote: > On 01/19/12 21:05, Ian Lepore wrote: > > I saw in the eventtimers(7) manpage that there's a sysctl to change the > > timer, but when I used it the system timing went completely wonky (ntpd > > reported it was off by many seconds, a few seconds after I changed it). > > When I just tried it again the system locked up and had to be power > > cycled. (I'm trying this on old hardware where my only choices are > > i8254 and RTC, and changing to RTC apparently doesn't work well.) So I > > didn't want to recommend it to someone else. :) > > That's strange. On all systems I have, I can safely set any event timer > in any way. Though for better precision it is better to set them using > loader tunable. As it turns out, this isn't a problem with eventtimers in any way, sorry for the confusion. I had checked out and built a completely clean RELENG_9_0_0_RELEASE so that I could be sure I was testing against the offical release before telling the OP "I do/don't see similar problems." As it turns out, one of my local hacks is required if I want use the RTC clock for anything (buggy old hardware). Once I applied that patch, I can now switch eventtimers without any problems. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange 'hangs' with RELENG_9
On Thu, 2012-01-19 at 19:14 +0200, Alexander Motin wrote: > On 19.01.2012 18:51, Oliver Pinter wrote: > > CC: Alexander Motin > > > > On 1/19/12, László KÁROLYI wrote: > >> László KÁROLYI wrote: > >>> Ok, couldn't get it through... So here is it, uploaded: > >>> > >>> http://www.freeimagehosting.net/s836i > >> Another screenshot here: > >> > >> http://www.freeimagehosting.net/xv26d > > I am not sure how freezes that could be fixed with key press could be > related to panics around storage. I would try to go two different ways: > - for panics, if dumping is not possible, I would try to resolve > address of the "instruction pointer" from both messages with `addr2line > -e /path/to/kernel address`. > - for freezes I would try to look on eventtimers(4) subsystem: check > what timer is used, try to switch to different one, try to switch into > periodic mode. > > Since cause of siis timeouts in SATA2 mode is also unclear, I can't also > exclude that it may be somehow related. The new eventtimers was also the first thing that came to my mind, but I couldn't quickly find the right way to boot with a different timer. I saw in the eventtimers(7) manpage that there's a sysctl to change the timer, but when I used it the system timing went completely wonky (ntpd reported it was off by many seconds, a few seconds after I changed it). When I just tried it again the system locked up and had to be power cycled. (I'm trying this on old hardware where my only choices are i8254 and RTC, and changing to RTC apparently doesn't work well.) So I didn't want to recommend it to someone else. :) For both eventtimers and timecounters, I think it'd be nice if a tunable or hint could let the user override the quality number. But maybe there's already some better way of influencing the choices the kernel makes? -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Timekeeping in stable/9
On Tue, 2012-01-17 at 20:12 +, Joe Holden wrote: > Hi guys, > > Has anyone else noticed the tendency for 9.0-R to be unable to > accurately keep time? I've got a couple of machines that have been > upgraded from 8.2 that are struggling, in particular a Virtual box guest > that was fine on 8.2, but now that's its been upgraded to 9.0 counts at > anything from 2 to 20 seconds per 5 second sample, the result is similar > with HPET, ACPI-fast and TSC. > > I also have physical boxes which new seem to drift quite substantially, > ntpd cannot keep up and as these boxes need to be able to report the > time relatively accurately, it is causing problems with log times and > such... > > Any suggestions most welcome! > > Thanks, > J I finally got a 9.0 generic build done today and I've been watching the timekeeping on 3 systems and they're all doing just fine. Two of the systems are performing pretty much identically to how they did on 8.2; the clock frequency correction calculated by ntpd differs by less than 1ppm. On the other system the kernel timekeeping routines are now choosing to use a different clock so I don't get a direct comparison of the old vs new drift rate, but the drift is still reasonable (100ppm now, used to be around 88, on an old 300mhz MediaGx-based system). I haven't had time yet to learn about the new eventtimer stuff in 9.0, but I know you can get some info on the choices it made via sysctl kern.eventtimer. Before 9.0 I'd check sysctl kern.clockrate and vmstat -i and make sure the chosen clock is interrupting at the right rate, but now with the eventtimer stuff there's not an obvious correlation between hz and profhz and stathz and any particular device's interrupt rate, at least for some clock choices (on the old MediaGx system without ACPI or HPET it seems to work more like it used to). -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
