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"
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: /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: 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: 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: 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: 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: 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: Drastic slowdown for geli attach
On Wed, 2021-02-24 at 21:34 -0800, Kevin Oberman wrote: > Sometime around the first week of this month (February) the time to > do a > geli attach on my 13.0-ALPHA3 amd64 system sharply increased. It > started > taking about 10 seconds. Prior to this, it took about 3-4 seconds. I > have > not seen any issues with the disc after it attaches, I am simply > concerned > that the longer time may be indicative of a deeper issue. > > The system is a ThinkPad L15 with a CometLake i5-10210U and a Seagate > ST2000LM007-1R8174 2T HDD. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to " > freebsd-stable-unsubscr...@freebsd.org" In my experience, the thing that takes the most time in a geli attach is the iterations of PKCS#5v2 it performs. When you setup geli on a partition it calculates how many iterations take about 2 seconds to perform (unless you provide a specific value with the -i flag). If you set up geli on a very fast machine then move the storage to a slower machine, it may take much longer than 2 seconds. (And if you have 10 drives to attach, 2 seconds each becomes annoying, so I tend to use -i with a small-ish number like 5000). Or, in your case, maybe something has changed like it used to use aesni accellerated instructions and now it doesn't for some reason, like different default flags got used on the build, or something changed in the crypto and/or driver framework. That's the kind of thing I'd be looking for. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On Sat, 2021-04-03 at 16:39 -0400, Ed Maste wrote: > I propose deprecating the ftpd currently included in the base system > before FreeBSD 14, and opened review D26447 > (https://reviews.freebsd.org/D26447) to add a notice to the man page. > I had originally planned to try to do this before 13.0, but it > dropped > off my list. FTP is not nearly as relevant now as it once was, and it > had a security vulnerability that secteam had to address. > > I'm happy to make a port for it if anyone needs it. Comments? > I would find the removal of ftpd to be very inconvenient unless there was a port/pkg to install it from. If there is a port, it would only be useful if I could set PREFIX=/usr when building/installing it, so that its behavior when installed as a port/pkg would be identical to how it was when it was part of base (in terms of where its config files are located). -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: clocked speed not showing in dev.cpu.[0-7].freq
On Tue, 2021-04-27 at 19:22 +0100, tech-lists wrote: > Hi, > > Not sure where to put this. system is amd64/stable/13. It's running > powerd but with no additional flags. > > CPU is Intel(R) Core(TM) i7-4770K CPU. Has 32GB RAM > > The system is clocked in the bios at 4.251 GHz. I never see this > value > in sysctl dev.cpu.[0-7].freq though. Here's the output: > > [...] > sysctl dev.cpu.0 > dev.cpu.0.cx_method: C1/hlt > dev.cpu.0.cx_usage_counters: 100878534 > dev.cpu.0.cx_usage: 100.00% last 185us > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/1/0 > dev.cpu.0.freq_levels: 3400/84000 3200/77169 3100/73848 2900/67388 > 2700/61182 2500/55201 2400/52298 2200/46677 2000/41272 1800/36091 > 1700/34277 1500/29407 1300/24752 1100/20312 1000/18167 800/14031 > dev.cpu.0.freq: 3400 > dev.cpu.0.temperature: 68.0C > dev.cpu.0.coretemp.throttle_log: 0 > dev.cpu.0.coretemp.tjmax: 100.0C > dev.cpu.0.coretemp.resolution: 1 > dev.cpu.0.coretemp.delta: 32 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 _CID=none > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%driver: cpu > dev.cpu.0.%desc: ACPI CPU > > Here's the cpu string on boot: > > CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (4251.32-MHz K8-class > CPU) > > So, is it really clocked? or does the sysctl show what is right? > > thanks, The same is true on my system: CPU: Intel(R) Xeon(R) CPU W3680 @ 3.33GHz (4250.09-MHz K8-class CPU) dev.cpu.0.freq_levels: 3334/143000 /13 3200/117000 3067/105000 2933/94000 2800/85000 2667/76000 2533/68000 2400/61000 2267/54000 2133/48000 2000/43000 1867/39000 1733/35000 1600/32000 I've clocked this cpu at various speeds between 4.25 - 5.0 ghz over the years (faster when it was younger, more conservative now that it's old). The value in parens (4250.09) changes accordingly, but the values in the sysctl never do. I'm sure this is running at the overclocked speed (various benchmark values change as they should when changing the OC values in the bios). -- Ian ___ freebsd-stable@freebsd.org mailing list https://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: 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: 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: 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 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.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: [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: 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: 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: 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: 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: 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: 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: 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: 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: /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: /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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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 15:20 -0600, Karl Denninger wrote: > On 2/4/2013 3:13 PM, Ian Lepore wrote: > > 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 > > The machine is fine. The adapter is fine too -- I powered up the old > machine and it works too, and recognizes the adapter immediately (on > FreeBSD-Stable 7.) No problems with either. > > I get identical behavior on multiple ports on the back of the machine > and the machine itself is known to be ok and has a USB KVM attached to > it which is working, along with a USB-communicating UPS which is also > working. > > When I added the definition it picked it up as an 8-port adapter with 8 > FTDI ports on it, but then it ALSO tried to attach it as a 7-port hub > (which is what usbdevs says it is) -- although I cannot find ANYWHERE in > the code under that directory that references that VID/PID tuple. The > second attachment attempt blew up the first (which makes sense.) > > Since the code obviously does know how to find hubs, there has to be > something else going on -- digging through it now to see if I can > isolate how it determines something is a "hub" without having a > structure with all the hubs defined in it, which I cannot find. > Ahh, I misunderstood what you said earlier. This is where HPS normally shows up and starts asking for usbconfig output using usbconfig options I have no idea how to use. :) -- 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 16:31 -0500, Charles Sprickman wrote: > On Feb 4, 2013, at 4:13 PM, Ian Lepore wrote: > > > 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. > > I assume we're talking about a multi-port usb to serial adapter, correct? > > If so, they generally do have a hub included in the device. > > Example: > > ugen1.3: at usbus1 > uhub4: on > usbus1 > uhub4: 7 ports with 7 removable, self powered > > Then the individual ports look like this: > > ugen1.4: at usbus1 > uftdi0: on usbus1 > ugen1.5: at usbus1 > uftdi1: on usbus1 > (etc.) > > We use these for serial console ports, they're (relatively) cheap and have > generally been well supported. > > The above info is from an 8.3 box. > > Just wanted to clarify that there is likely a hub in the serial box Karl is > working with… > > Charles Oh, interesting. The biggest ftdi dongle I have is 4 ports, using the ftdi 4232 chip. I guess to get more ports than that, folks are now using an internal hub and multiple ftdi chips. So for some reason there's a problem with the hub, and that's probably preventing it from getting as far as seeing the ftdi parts that are downstream of 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: Why can't gcc-4.2.1 build usable libreoffice?
On Tue, 2013-02-19 at 09:23 -0800, Adrian Chadd wrote: > Hi, > > The base compiler is supposed to compile base and bootstrap whatever > else you need to compile other software. > > It's not supposed to be continuously updated to new, major versions. :-) > > I bet *office just uses a bunch of either horrible syntax that breaks > things, or newer C/C++ features that are buggy in older compilers. > They could've made their code compile on older compilers.. they just > haven't bothered. > > In any case, why hasn't that port been blessed with the "requires gcc > 4.6+" port option/dependency? I thought that's why we _have_ that. It has been. The OP stated the he disabled that and forced use of gcc 4.2.1, and is now complaining that it doesn't work after specifically taking steps to make it not-work. -- 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 can't gcc-4.2.1 build usable libreoffice?
On Tue, 2013-02-19 at 13:03 -0500, Mikhail T. wrote: > On 19.02.2013 12:23, Adrian Chadd wrote: > > I bet *office just uses a bunch of either horrible syntax that breaks > > things, or newer C/C++ features that are buggy in older compilers. > Well, yes, this is, what I wanted to find out -- which case is it. There was > a > point, when we had a special compiler-port just for OpenOffice.org: > > http://www.freshports.org/lang/gcc-ooo > > That port was building gcc-3.4.1, which was NOT "too old" for the office only > a > few years ago (when gcc-4.2.1 already existed). > > I'd love to see a comment from people, who /know/ what is going on. Then we > may > be able to either patch-up the base compiler, or the office, code or both. > And > let the healing begin[TM]. > > I'm afraid, though, the compiler-people are too cool to use an office suit -- > finding vi (and, perhaps, TeX) sufficient for their documents, while the > office@ > maintainers prefer the easy way of just adding the newer compiler to the > requirements. Getting these two distinct groups to meet in one thread was the > point of this topic... > > On 19.02.2013 12:35, Ian Lepore wrote: > >> In any case, why hasn't that port been blessed with the "requires gcc > >> >4.6+" port option/dependency? I thought that's why we_have_ that. > > It has been. The OP stated the he disabled that and forced use of gcc > > 4.2.1, and is now complaining that it doesn't work after specifically > > taking steps to make it not-work. > Ian, contrary to your accusation, I never complained that the port does not > work. Moreover, to prevent that suspicion from entering sincere minds, I > explicitly said: "I do not blame the office@ team -- the port did not want to > use gcc-4.2.1, I forced it to." Did you not see that sentence, or do > deliberately misrepresent my original post? > > -mi Comments such as "compiler people are too cool..." as well as things such as > Upstream gcc? They may not be very interested, indeed, but it is > FreeBSD, that > delivered this compiler to me -- in the most recent stable version of > the OS. > and > > But I agree, that it is insane, that the base compiler can not compile > one of > the most popular open-source application-suits... All strike me as being "complaints," but if that seems like a mis-characterization to you, then I apologize. Licensing prevents us from updating gcc in the base. Maintainers of large opensource suites are likely to have little interest in supporting a buggy old compiler years after it has been obsoleted by newer versions. The reasonable solution is to use a newer compiler to compile newer ports, and put ongoing maintenance efforts into solidifying the replacement compiler rather than propping up the buggy old one. -- 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 can't gcc-4.2.1 build usable libreoffice?
On Tue, 2013-02-19 at 13:54 -0500, Mikhail T. wrote: > > Licensing prevents us from updating gcc in the base. > Licensing? Could you elaborate, which aspect of licensing you have in > mind? Versions of gcc after the 4.2.1 version we use are licensed under GPLv3. I'm not a lawyer, so I don't understand all the fine details of why GPLv3 is bad for the freebsd project, but I accept the analysis and decisions the project made on that subject some time ago. As you might imagine, switching to a new compiler isn't something you decide to do this afternoon and finish up tomorrow with a big checkin. It takes many months of testing and iteratively fixing bugs... bugs found in the new compiler, and bugs the new compiler exposes in the existing source base. I think we've been able to cherry-pick a few specific fixes from gcc upstream that weren't encumbered by GPLv3, but for the most part I think nobody is actively maintaining the GPLv2 code anymore. -- 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: svn - but smaller?
On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > Also, John, please consider using malloc(3) instead of heap-allocated > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > bytes). I'm referring to this: Why? I absolutely do not understand why people are always objecting to large stack-allocated arrays in userland code (sometimes with the definition of "large" being as small as 2k for some folks). -- 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: svn - but smaller?
On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote: > On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: > > On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > > > > > Also, John, please consider using malloc(3) instead of heap-allocated > > > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > > > bytes). I'm referring to this: > > > > Why? I absolutely do not understand why people are always objecting to > > large stack-allocated arrays in userland code (sometimes with the > > definition of "large" being as small as 2k for some folks). > > This is incredibly off-topic, but I'll bite. > > I should not have said "heap-allocated", I was actually referring to > statically-allocated. > > The issues as I see them: > > 1. Such buffers exist during the entire program's lifetime even if they > aren't actively used/needed by the program. With malloc(3) and friends, > you're allocating memory dynamically, and you can free(3) when done with > it, rather than just having a gigantic portion of memory allocated > sitting around potentially doing nothing. > > 2. If the length of the buffer exceeds the amount of stack space > available at the time, the program will run but the behaviour is unknown > (I know that on FreeBSD if it exceeds "stacksize" per resource limits, > the program segfaults at runtime). With malloc and friends you can > gracefully handle allocation failures. > > 3. Statically-allocated buffers can't grow; meaning what you've > requested size-wise is all you get. Compare this to something that's > dynamic -- think a linked list containing pointers to malloc'd memory, > which can even be realloc(3)'d if needed. > > The definition of what's "too large" is up to the individual and the > limits of the underlying application. For some people, sure, anything > larger than 2048 might warrant use of malloc. I tend to use malloc for > anything larger than 4096. That "magic number" comes from some piece of > information I was told long ago about what size pages malloc internally > uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it > appears to be a lot more complex than that. > > If you want me to break down #1 for you with some real-world output and > a very small C program, showing you the effects on RES/RSS and SIZE/VIRT > of static vs. dynamic allocation, just ask. > Actually, after seeing that the userland limit for an unpriveleged user on freebsd is a mere 64k, I'd say the only valid reason to not allocate big things on the stack is because freebsd has completely broken defaults. I see no reason why there should even be a distinction between stack size and memory use limits in general. Pages are pages, it really doesn't matter what part of your virtual address space they live in. Almost everything I've ever done with freebsd runs as root on an embedded system, so I'm not used to thinking in terms of limits at all. -- Ian [P.S. Having mail troubles today, sorry if this gets duplicated.] ___ 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: svn - but smaller?
On Sun, 2013-02-24 at 16:04 -0800, Jeremy Chadwick wrote: > On Sun, Feb 24, 2013 at 04:43:33PM -0700, Ian Lepore wrote: > > On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote: > > > On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: > > > > On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > > > > > > > > > Also, John, please consider using malloc(3) instead of heap-allocated > > > > > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > > > > > bytes). I'm referring to this: > > > > > > > > Why? I absolutely do not understand why people are always objecting to > > > > large stack-allocated arrays in userland code (sometimes with the > > > > definition of "large" being as small as 2k for some folks). > > > > > > This is incredibly off-topic, but I'll bite. > > > > > > I should not have said "heap-allocated", I was actually referring to > > > statically-allocated. > > > > > > The issues as I see them: > > > > > > 1. Such buffers exist during the entire program's lifetime even if they > > > aren't actively used/needed by the program. With malloc(3) and friends, > > > you're allocating memory dynamically, and you can free(3) when done with > > > it, rather than just having a gigantic portion of memory allocated > > > sitting around potentially doing nothing. > > > > > > 2. If the length of the buffer exceeds the amount of stack space > > > available at the time, the program will run but the behaviour is unknown > > > (I know that on FreeBSD if it exceeds "stacksize" per resource limits, > > > the program segfaults at runtime). With malloc and friends you can > > > gracefully handle allocation failures. > > > > > > 3. Statically-allocated buffers can't grow; meaning what you've > > > requested size-wise is all you get. Compare this to something that's > > > dynamic -- think a linked list containing pointers to malloc'd memory, > > > which can even be realloc(3)'d if needed. > > > > > > The definition of what's "too large" is up to the individual and the > > > limits of the underlying application. For some people, sure, anything > > > larger than 2048 might warrant use of malloc. I tend to use malloc for > > > anything larger than 4096. That "magic number" comes from some piece of > > > information I was told long ago about what size pages malloc internally > > > uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it > > > appears to be a lot more complex than that. > > > > > > If you want me to break down #1 for you with some real-world output and > > > a very small C program, showing you the effects on RES/RSS and SIZE/VIRT > > > of static vs. dynamic allocation, just ask. > > > > > > > Actually, after seeing that the userland limit for an unpriveleged user > > on freebsd is a mere 64k, I'd say the only valid reason to not allocate > > big things on the stack is because freebsd has completely broken > > defaults. > > The limits (i.e. what's shown via limits(1)) differs per architecture > (ex. i386 vs. amd64) and may adjust based on amount of physical memory > available (not sure on the latter part). The "64k" value you're talking > about, I think, is "memorylocked" -- I'm referring to "stacksize". > > > I see no reason why there should even be a distinction > > between stack size and memory use limits in general. Pages are pages, > > it really doesn't matter what part of your virtual address space they > > live in. > > You're thinking purely of SIZE/VIRT. > > I guess I'd best break the C program out. Apologise in advance for the > crappy code (system(3)!), but I wanted something that made the task > easy. > > $ limits -a > Resource limits (current): > cputime infinity secs > filesize infinity kB > datasize 2621440 kB > stacksize 262144 kB > coredumpsize infinity kB > memoryuseinfinity kB > memorylocked 64 kB > maxprocesses 5547 > openfiles 11095 > sbsize infinity bytes > vmemoryuse infinity kB > pseudo-terminals infinity > swapuse infinity kB > > $ cat x.c > #inc
Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd
On Sat, 2013-03-02 at 17:02 +0100, Dag-Erling Smørgrav wrote:
> Mike Tancsa writes:
> > The pcaps and basic wireshark output at
> >
> > http://tancsa.com/openssh/
>
> This is 6.1 with aesni vs 6.1 without aesni; what I wanted was 6.1 vs
> 5.8, both with aesni loaded.
>
> Could you also ktrace the server in both cases?
>
> An easy workaround is to change the list of ciphers the server will
> offer to clients by adding a "Ciphers" line in /etc/ssh/sshd_config.
> The default is:
>
> Ciphers
> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
>
> Either remove the AES entries or move them further down the list. The
> client will normally pick the first supported cipher. As far as I can
> tell, SecureCRT supports all the same ciphers that OpenSSH does, so just
> moving arcfour{256,128} to the front of the list should work.
>
> (AFAIK, arcfour is also much faster than aes)
The last time I tried to affect the chosen cypher by manipulating the
order of the list items in the config files was a couple years ago, but
I found then that you just can't do that. The client side, not the
server, decides on the order, and it's based on compiled-in ordering
within the client code (not the client config). From the server side
the only thing you can do to affect the order is leave items out of the
list (it will still try the remaining list items in the client-requested
order).
All of this was with "OpenSSH_5.4p1_hpn13v11 FreeBSD-20100308, OpenSSL
0.9.8q 2 Dec 2010" and may be completely out of date now.
-- 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 excessive memory allocations
On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: > Hi all > > > I have a heavily threaded C application, developed on an Intel Core i5 laptop > (2 cores) running FreeBSD 8.1-RELEASE. > > When this application compile and run on another Intel Core i7 laptop (4 > cores) running FreeBSD 9.1-RELEASE, this application immediately starts > grabbing memory by over 100MB per second and soon exit with not enough RAM. > > > Both laptops having 4GB RAM. > > All malloc and free are mutex locked. > > Very rarely this problem happens on the i5 (2 cores) laptop too, but on the > i7 laptop, it happens every time. > > Appreciate any feedback to identify and fix this issue. > > Best regards > Unga > Too many moving parts, you need to partition the problem. Is it the change in OS (and especially libraries) that causes the problem, or the change in the number of cores (more concurrent threads) is exposing some sort of application-side race condition? Given the fact that it does occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely an application problem. Perhaps you could use a tool such as valgrind to help track down the runaway allocations? Another way to expose thread race problems is to force more thread context switches. A blunt tool for doing so is to set hz=5000 or even higher in /boot/loader.conf. I've never done that on a desktop or laptop system, only on embedded systems, but it should still work okay. If changing the application code is easier, you can get a similar effect by creating a thread whose only job is to preempt other threads, by using rtprio_thread() to set it to real time priority, then just have it sleep for short random intervals (microseconds), all it does is wakes up and goes right back to sleep. Also, FYI, there's no need to use a mutex in your application to protect allocations. The memory allocator in libc is thread-safe, and in fact is particularly designed for efficient multi-threaded allocation. -- 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 excessive memory allocations [SOLVED]
On Wed, 2013-03-27 at 11:33 -0700, Unga wrote: > > - Original Message - > > > From: Ian Lepore > > To: Unga > > Cc: "freebsd-stable@freebsd.org" > > Sent: Wednesday, March 27, 2013 2:06 PM > > Subject: Re: FreeBSD 9.1 excessive memory allocations > > > > On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: > >> Hi all > >> > >> > >> I have a heavily threaded C application, developed on an Intel Core i5 > > laptop (2 cores) running FreeBSD 8.1-RELEASE. > >> > >> When this application compile and run on another Intel Core i7 laptop (4 > > cores) running FreeBSD 9.1-RELEASE, this application immediately starts > > grabbing > > memory by over 100MB per second and soon exit with not enough RAM. > >> > >> > >> Both laptops having 4GB RAM. > >> > >> All malloc and free are mutex locked. > >> > >> Very rarely this problem happens on the i5 (2 cores) laptop too, but on > >> the > > i7 laptop, it happens every time. > >> > >> Appreciate any feedback to identify and fix this issue. > >> > >> Best regards > >> Unga > >> > > > > Too many moving parts, you need to partition the problem. Is it the > > change in OS (and especially libraries) that causes the problem, or the > > change in the number of cores (more concurrent threads) is exposing some > > sort of application-side race condition? Given the fact that it does > > occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely > > an application problem. > > > > Perhaps you could use a tool such as valgrind to help track down the > > runaway allocations? > > > > Another way to expose thread race problems is to force more thread > > context switches. A blunt tool for doing so is to set hz=5000 or even > > higher in /boot/loader.conf. I've never done that on a desktop or > > laptop system, only on embedded systems, but it should still work okay. > > If changing the application code is easier, you can get a similar effect > > by creating a thread whose only job is to preempt other threads, by > > using rtprio_thread() to set it to real time priority, then just have it > > sleep for short random intervals (microseconds), all it does is wakes up > > and goes right back to sleep. > > > > Also, FYI, there's no need to use a mutex in your application to protect > > allocations. The memory allocator in libc is thread-safe, and in fact > > is particularly designed for efficient multi-threaded allocation. > > > > -- Ian > > > > Dear Tony, Alexander, Jan, Ian and Jeremy > > Thank you very much for your very valuable comments. > > Problem seems to be solved. But require more testing. > > 1. Fixed an application-level crucial bug. This is nearly a 7000 lines C app. > It was really hard to see as the application is designed with 8 dedicated > threads. > > 2. At run-time, this application shoots up to about 400 dynamic threads on > the i7 machine, whereas on the i5 machine, it only shoots up 57 dynamic > threads. It was bit scaring, therefore, made a hard limit on total number of > threads to 64. > > Regarding mutex locks on allocations, as per the malloc(3), it says small and > medium size allocations are done from per thread caches, therefore, > thread-safe. My allocations are large in nature, about 5-7MB. > > Best regards > Unga I think you may be reading too much into the malloc manpage. When it mentions the use of per-thread small-object caches to avoid locking it's talking about performance, not thread safety. Allocations of all sizes are thread-safe, the library just assumes that huge allocations are rare enough that it doesn't use extra per-thread resources to avoid locking for them, it just uses locking for huge blocks. -- 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: Any objections/comments on axing out old ATA stack?
On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: > On 28.03.2013 02:43, Adrian Chadd wrote: > > My main concern with the new stuff is that it requires CAM and that's > > reasonably big compared to the standalone ATA code. > > > > It'd be nice if we could slim down the CAM stack a bit first; it makes > > embedding it on the smaller devices really freaking painful. > > Are there many boards now with ATA, but without USB? But I agree, it > should be checked. > It's not necessarily what the boards have but how they're used. We use industrial SBCs at work that have ata compact flash sockets on the board which we do use, and usb interfaces which we don't use. I've never tested the new ata+cam stuff on some of these boards, most based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata code works, but not always very well -- for example, we usually have to set hw.ata.ata_dma=0 for absolutely no reason we've ever been able to figure out except that if we leave it enabled we get DMA errors and panics on some CF cards and not on others. I have no idea whether to expect such things to be better, worse, or no different by changing to the ata+cam way of doing things (but I don't really have time to do extensive testing right now either). -- 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-STABLE buildworld compile error
On Tue, 2013-04-02 at 14:28 +0300, Dmitry Luhtionov wrote: > When I put MALLOC_PRODUCTION=yes in /etc/make/conf, make buildworld hangs > with error > /usr/src/lib/libc/stdlib/ > malloc.c:126:1: error: "MALLOC_PRODUCTION" redefined > : error: this is the location of the previous definition > > This is a patch, which avoid this error > > --- /usr/src/lib/libc/stdlib/Makefile.inc.orig2012-12-04 > 11:53:28.0 +0200 > +++ /usr/src/lib/libc/stdlib/Makefile.inc2013-04-02 14:14:35.0 > +0300 > @@ -51,7 +51,3 @@ > malloc.3 realloc.3 malloc.3 reallocf.3 malloc.3 malloc_usable_size.3 > MLINKS+=tsearch.3 tdelete.3 tsearch.3 tfind.3 tsearch.3 twalk.3 > > -.if defined(MALLOC_PRODUCTION) > -CFLAGS+=-DMALLOC_PRODUCTION > -.endif > - That's because MALLOC_PRODUCTION is already defined in -stable. The right fix would be to remove it from your make.conf, because it's no longer necessary in -current either -- the performance problems that originally led to the advice to put MALLOC_PRODUCTION in make.conf for -current have been fixed. -- 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: ada(4) and ahci(4) quirk printing
On Wed, 2013-04-24 at 11:59 -0700, Adrian Chadd wrote: > I think this just outlines the problem - bootverbose is too verbose. > > eg, what the audio code outputs. And yes, net80211 when you're doing 11n. > I agree that the sound driver(s) output Too Much Stuff with bootverbose, so much so that it makes bootverbose kind of useless for other things. It would be nice if its output could be trimmed, and the fully-verbose spewage we see now would need some extra knob turned. More directly on-point to the overall thread, I think printing an extra line of info that gives more detail about how drives and controllers are being handled is a Good Idea. It's one extra line, one-time during 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: 9.1-stable: ATI IXP600 AHCI: CAM timeout
On Wed, 2013-05-29 at 16:21 +0200, Oliver Fromme wrote: > Steven Hartland wrote: > > Have you checked your sata cables and psu outputs? > > > > Both of these could be the underlying cause of poor signalling. > > I can't easily check that because it is a cheap rented > server in a remote location. > > But I don't believe it is bad cabling or PSU anyway, or > otherwise the problem would occur intermittently all the > time if the load on the disks is sufficiently high. > But it only occurs at tags=3 and above. At tags=2 it does > not occur at all, no matter how hard I hammer on the disks. > > At the moment I'm inclined to believe that it is either > a bug in the HDD firmware or in the controller. The disks > aren't exactly new, they're 400 GB Samsung ones that are > several years old. I think it's not uncommon to have bugs > in the NCQ implementation in such disks. > > The only thing that puzzles me is the fact that the problem > also disappears completely when I reduce the SATA rev from > II to I, even at tags=32. > It seems to me that you dismiss signaling problems too quickly. Consider the possibilities... A bad cable leads to intermittant errors at higher speeds. When NCQ is disabled or limited the software handles these errors pretty much transparently. When NCQ is not limitted and there are many outstanding requests, suddenly the error handling in the software breaks down somehow and a minor recoverable problem becomes an in-your-face error. I'm not saying any of the foregoing is true, just that you should consider the possibility that you're dealing with multiple problems which are only loosely coupled, but together can seem like a single more serious problem. You don't know enough yet to casually dismiss anything. -- 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: system sporadically hangs on shutdown after switching to WITH_NEW_XORG
On Sun, 2013-06-16 at 09:07 -0700, Jeremy Chadwick wrote: > On Sun, Jun 16, 2013 at 06:01:49PM +0200, Michiel Boland wrote: > > On 06/16/2013 17:55, Jeremy Chadwick wrote: > > [...] > > > > >Are you running moused(8)? Actually, I can see quite clearly that you > > >are in your core.txt: > > > > > >Starting ums0 moused. > > > > > >Try turning that off. Don't ask me how, because devd(8) / devd.conf(5) > > >might be involved. > > > > > > > The moused is started by devd - I don't see a quick way of turning that off. > > Comment out the relevant crap in devd.conf(5). Search for "ums" > and comment out the two "notify" sections. I don't understand why people treat devd as if it's some sort of evil virus that they're forced to live with (using phrases like "crap in devd.conf"). In general, the standard devd rules tend to fall into 3 categories: * use logger(1) to record some anomaly * kldload a module * invoke a standard /etc/rc.d script For moused, the devd rules invoke /etc/rc.d/moused, which implies that setting moused_enable=NO in rc.conf would be all that's needed to disable it. -- 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: gmirror crash writing to disk? Or is it su+j crash?
On Fri, 2013-08-30 at 21:50 +0200, Edward Tomasz Napierała wrote: > Wiadomość napisana przez Zaphod Beeblebrox w dniu 29 sie > 2013, o godz. 23:35: > > So I have a system running: > > > > FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55 > > EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 > > > > and it has two 2T SATA disks. To keep this post short, the crash.txt is > > here. > > > > https://uk.eicat.ca/owncloud/public.php?service=files&t=fea9d25579fe0c4afb808859e80e1493 > > Login error. > > > now curiously, while running a "make -j4 buildkernel" ... almost every time > > ... it crashes with: > > > > g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error = > > 11 > > /usr: got error 11 while accessing filesystem > > panic: softdep_deallocate_dependencies: unrecovered I/O error > > This is softupdates panic caused by write operation returning error 11, which, > according to 'man errno', is EDEADLK. > > To be honest, I have no idea why gmirror might be returning this error. > > > ... no error report from the hard drives, simply an error report from the > > mirror. > > Note that ahci(4) does not log errors unless you're running with bootverbose. > > > The filesystem is ufs with su+j... but I'm not sure this matters here. > > It does, kind of - without soft updates/SUJ, the error would be non-fatal - it > wouldn't panic the box, but it would (probably) cause data corruption. One of the few places in the kernel that uses EDEADLK is in geom_io.c (line 642 in -current) in g_io_transient_map_bio()... g_io_deliver(bp, EDEADLK/* XXXKIB */); -- 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote: > Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 11:24 > (localtime): > > On 09/17/13 11:06, Harald Schmalzbauer wrote: > >> ... > >> Shall we switch to non-list-comm? > > > > Hi, > > > > That's OK. > > > >> Hmm, in my case, this 4-port-serial-USB-hub will be used as console > >> concentrator. So most time it's doing nothing, just feeding tmux with > >> consoles output. What latency are we talking about? Less than a some > >> milliseconds should be fine. > >> What I'm curious about is why my prolific USB-serial converter doesn't > >> generate these high irqs. > > > > Try this patch and see what happens: > > > > == > > --- umcs.c(revision 255492) > > +++ umcs.c(local) > > @@ -230,6 +230,7 @@ > > .bufsize = 0,/* use wMaxPacketSize */ > > .callback = &umcs7840_intr_callback, > > .if_index = 0, > > +.interval = 20, /* ms */ > > }, > > }; > > > > > > BTW: I see that the umcs driver shouldn't do synchronous control > > transfers from the USB interrupt transfer callback. This should be > > postponed into some worker thread, for example the USB explore thread. > > See USB audio driver for an example. > > > > --HPS > > I tried your patch and it works as expected: IRQs decreased to ~64/s > when idle/disconnected. > > One interesting thing I never measured before: > Console connection with 115k2 via umcs and 'while ( 2>1 ) echo "---..." > end' results in 8000 irqs/s :-( But that's also true for the prolific > (uplcom). The latter just goes down to 0.0 irqs/s when idle. > > Doing the same with uart0 results in 1444irqs/s. > Is it by design/unavoidable that transfering the same via USB multiplies > by factor 5-6? > > Thanks, > > -Harry > I don't know about that chipset, but with the FTDI chips it does xfers in 64 byte chunks and high speed bulk data results in an astronomical number of interrupts (and if you go fast enough, lost data). I have some patches that assemble lots of the little chip-size buffers into bigger xfers that the ohci/ehci controller can handle without interrupting the processor; that helps the problem 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
On Tue, 2013-09-17 at 19:32 +0200, Harald Schmalzbauer wrote: > Bezüglich Ian Lepore's Nachricht vom 17.09.2013 18:16 (localtime): > > On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote: > >> ... > >>> Try this patch and see what happens: > >>> > >>> == > >>> --- umcs.c(revision 255492) > >>> +++ umcs.c(local) > >>> @@ -230,6 +230,7 @@ > >>> .bufsize = 0,/* use wMaxPacketSize */ > >>> .callback = &umcs7840_intr_callback, > >>> .if_index = 0, > >>> +.interval = 20, /* ms */ > >>> }, > >>> }; > >>> > >>> > >>> BTW: I see that the umcs driver shouldn't do synchronous control > >>> transfers from the USB interrupt transfer callback. This should be > >>> postponed into some worker thread, for example the USB explore thread. > >>> See USB audio driver for an example. > >>> > >>> --HPS > >> I tried your patch and it works as expected: IRQs decreased to ~64/s > >> when idle/disconnected. > >> > >> One interesting thing I never measured before: > >> Console connection with 115k2 via umcs and 'while ( 2>1 ) echo "---..." > >> end' results in 8000 irqs/s :-( But that's also true for the prolific > >> (uplcom). The latter just goes down to 0.0 irqs/s when idle. > >> > >> Doing the same with uart0 results in 1444irqs/s. > >> Is it by design/unavoidable that transfering the same via USB multiplies > >> by factor 5-6? > >> > >> Thanks, > >> > >> -Harry > >> > > I don't know about that chipset, but with the FTDI chips it does xfers > > in 64 byte chunks and high speed bulk data results in an astronomical > > number of interrupts (and if you go fast enough, lost data). I have > > According to ASIX product brief, MCS7840 has 512 byte buffer. Pretty > much for an UART I think, which should make 115k2 baud connections with > less than 30 transfers/s work, or am I missing something? That's the internal buffer, it still does usb transfers in smaller chunks. Some ftdi chips have 4k onboard buffers but do 64-byte usb transfers. -- 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
On Tue, 2013-09-17 at 23:08 +0400, Lev Serebryakov wrote: > Hello, Harald. > You wrote 17 сентября 2013 г., 21:43:17: > > HS> Is that worth a try? > HS> > http://www.asix.com.tw/FrootAttach/driver/MCS7840_7820_FreeBSD_driver_v1.1.zip > Nope. I've started from this driver, and it even doesn't support BREAK > signal (it is was first reason why I start to write new one -- I needed > BREAK to enter kernel debugger). > > HS> At least, it seems to be possible to enable RS485-mode :-) :-) > I could easily add RS485 mode, BUT! FreeBSD doesn;'t have any userland API > for it, and the same is true for higher and non-standard baud rates. There's no API needed for higher baud rates. I've used cfsetspeed() to set 3mbps on ftdi chips. I've also used it for completely arbitrary speeds like 554000bps (happens to be the fastest I can run an ftdi chip on a 180mhz arm without dropping chars, but going that fast requires other changes to the driver.). -- 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: Adaptec 7805H drivers
On Mon, 2015-04-20 at 09:53 +1200, Phil Murray wrote: > Hi, > > I have a few Adaptec 7805H HBA cards which FreeBSD doesn’t support natively. > However Adaptec have provided binary drivers for FreeBSD 9.2 (9.3 and 10.x > support sadly absent). > > The problem I have is with the GENERIC kernel the compiled in ahd driver > tries to attach to the controller and fails. This prevents the pmspcv > (Adaptec binary) driver from working. > > I’d like to keep using GENERIC for freebsd-update etc., so is there a way I > can stop the ahd driver from trying to attach without rebuilding the kernel? > Perhaps change their priority or precedence somehow? > > Is porting the open source Linux driver to FreeBSD a possibility? > > Cheers > > Phil Try setting hw.ahd.0.disabled=1 in /boot/loader.conf. -- 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 do I build a brand new /etc?
On Tue, 2015-05-26 at 22:20 -0400, kpn...@pobox.com wrote: > So, I built a new 9.3-p14 with these commands: > > #! /bin/sh > > set -x > export DESTDIR=/ROOT/in_progress/ > export MAKEOBJDIRPREFIX=$DESTDIR/usr/obj > > cd $DESTDIR/usr/src > > make buildworld && > make buildkernel > > > Then as root I: >make installkernel && >make installworld > > ... with DESTDIR and MAKEOBJDIRPREFIX set in the environment. > > This gave me a nearly full install. The only thing lacking is the new > /etc. The /etc in the $DESTDIR contains the usual 20+ subdirectories, > but no files. > > How do I populate an empty /etc? > make distribution -- 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: Will 10.2 also ship with a very stale NTP?
And let's all just hope that a week or two of testing is enough when jumping a major piece of software forward several years in its independent evolution. The import of 4.2.8p2 several months ago resulted in complete failure of timekeeping on all my arm systems. Just last week I tracked it down to a kernel bug (which I haven't committed the fix for yet). While the bug has been in the kernel for years, it tooks a small change in ntpd behavior to trigger it. Granted it's an odd corner-case problem that won't affect most users because they just use the stock ntp.conf file (and it only affects systems that have a large time step due to no battery-backed clock). But it took me weeks to find enough time to track down the cause of the problem. I wonder how many other such things could be lurking in 4.2.8, waiting to be triggered by other peoples' non-stock configurations? We've already had one report for 4.2.8p3 of someone's GPS refclock not working after the update. -- Ian On Sun, 2015-07-12 at 18:49 +0900, Tomoaki AOKI wrote: > Wow! Thanks for your time and quick response. > I'm looking forward to seeing it MFCed. :-) > > On Sun, 12 Jul 2015 08:56:26 + > Xin LI wrote: > > > I've spent some time on the MFC, the testing would still take some time > > (likely a day or two) and once that's finished I'll ask re@ for approval. > > On Sat, Jul 11, 2015 at 11:44 PM Tomoaki AOKI > > wrote: > > > > > As I already mentioned in another post, head has 4.2.8 p3 in-tree. > > > > > > So the answer should be MFC before creation of releng/10.2 is planned > > > or not. > > > > > > > > > On Sun, 12 Jul 2015 15:04:43 +1000 > > > Peter Jeremy wrote: > > > > > > > On 2015-Jul-11 23:22:56 -0400, Chris Nehren < > > > cnehren+freebsd-sta...@pobox.com> wrote: > > > > >On Sat, Jul 11, 2015 at 09:58:11 +1000, John Marshall wrote: > > > > >> It's me again with my annual NTP whinge. > > > > > > > > > >The answer to the perennial "will release $foo ship with old / insecure > > > > >/ otherwise deficient $bar?" is still "install $bar from ports". > > > > > > > > That's a non-answer. It just changes the question to "why bother to > > > > include $bar in base when I need to install the port anyway". > > > > > > > > -- > > > > Peter Jeremy > > > > > > > > > -- > > > Tomoaki AOKIjunch...@dec.sakura.ne.jp > > > ___ > > > 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" > > > > > ___ > > 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" > > > > ___ 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: Will 10.2 also ship with a very stale NTP?
On Mon, 2015-07-13 at 04:31 +1000, Peter Jeremy wrote: > On 2015-Jul-12 09:41:43 -0600, Ian Lepore wrote: > >And let's all just hope that a week or two of testing is enough when > >jumping a major piece of software forward several years in its > >independent evolution. > > Whilst I support John's desire for NTP to be updated, I also do not > think this is the appropriate time to do so. That said, the final > decision is up to re@. > > >The import of 4.2.8p2 several months ago resulted in complete failure of > >timekeeping on all my arm systems. Just last week I tracked it down to > >a kernel bug (which I haven't committed the fix for yet). While the bug > >has been in the kernel for years, it tooks a small change in ntpd > >behavior to trigger it. > > > >Granted it's an odd corner-case problem that won't affect most users > >because they just use the stock ntp.conf file (and it only affects > >systems that have a large time step due to no battery-backed clock). > >But it took me weeks to find enough time to track down the cause of the > >problem. > > I'm not using the stock ntp.conf on my RPis and didn't notice any NTP > issues. Are you able to provide more details of either the ntp.conf > options that trigger the bug or the kernel bug itself? A quick search > failed to find anything. > I just committed the kernel fix as r285424; the commit message has some info on why the new ntpd made the problem visible. I should have said "stock rc.conf and ntp.conf"... To get the problem to happen you've got to set rc.conf ntpd_sync_on_start=NO and allow ntpd to make a large step (-g without -q, or tinker panic 0). I don't remember why I had sync on start disabled on most of my arm systems (probably a one-time experiment that I forgot to undo and it got copied around), but I suspect most people who don't have battery clocks will have it set to yes, and that's why nobody else saw this problem. To me, the problem was mainly illustrative of how a tiny innocuous change (ntpd making a series of ntp_adjtime() calls in a different, but still correct, order than it used to) can expose a completely unexpected longstanding bug in our code. Gotta wonder if any more of those are lurking. :/ -- 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: struct timehands: th_generation field
On Thu, 2015-07-23 at 10:59 -0400, Brandon Allbery wrote: > On Thu, Jul 23, 2015 at 10:38 AM, wrote: > > > Is the maximum value for th_generation equal to 10 ? > > http://fxr.watson.org/fxr/source/kern/kern_tc.c?v=FREEBSD10#L77 > > > > I don't think those relate to generations. Generations change on every > clock tick; the multiple timehands structs relate to forcibly setting the > time, as opposed to the clock moving forward normally. It does appear serve > a similar purpose, since forcibly setting the time is even more "violent" > (to anything currently reading the clock) than advancing the clock on a > clock tick, since that's when other adjustments including possibly > switching the clock source will be applied. > Ummm, no. The multiple timehands and related generation count are all about time moving forward normally, and doing so without needing mutxes or other locking primitives to obtain the current time. I think you guys need to read this... http://phk.freebsd.dk/pubs/timecounter.pdf Especially the section named "Locking, lack of..." -- 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: 8-stable crashing recently in ufsdirhash
On Tue, 2015-08-04 at 23:54 -1000, parv wrote: > Please CC me as I cannot properly use my laptop, Thinkpad X200 (i386). > > 8-stable has been crashing a lot since source update of Jul 2015[0]. After > building debug kernel, kgdb shows lock reversal order & in ufsdirhash. File > systems (/, var, misc) are all UFS, with var & misc having soft updates > enabled. > > Crash had happened just after boot (during mktemp); when I tried to delete a > directory (/misc/obj); when I tried to edit (vi /etc/fstab) so that / would > be mounted readonly. Most recent crash ... > > http://imagebin.ca/v/2B50NARvIHsH > > Any clue would be appreciated. > > - parv > > > [0] crash also happened while svn was trying to update source of 8. Now "svn > log" wants to connect to the remote repo instead of showing the current > revision. > When you say you built a debug kernel, does that include option WITNESS_KDB? If so, remove that so you can find the real error. LORs related to ufs_dirhash have been reported for years, and nobody with the appropriate skills seems to be interested in fixing them; they just get declared to be harmless. (IMO the spewage related to this makes witness essentially useless.) -- 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: 10.2: ntp update breaks DCF77 clock
On Sun, 2015-08-16 at 08:10 +0100, Matthew Seaman wrote: > On 15/08/2015 16:46, Christian Weisgerber wrote: > > The ntp code is not very transparent, but I think the root cause > > are the ntp/config.h changes that came with the 4.2.8p3 update. A > > number of previously disabled obscure clock drivers were enabled, > > but crucially CLOCK_RAWDCF was disabled, and this is the PARSE > > subdriver needed to use the popular DCF77 serial receivers. > > > > Frankly, it looks like we used to have a carefully considered > > selection of clock drivers which has been blindly splattered with > > the upstream defaults in the last update. > > Hmmm I suggest raising a PR with patches to revert the changes in > the set of enabled clock drivers (or merge with the current list). It's > not going to get you a working DCF77 receiver in a -RELEASE version any > time soon, I'm afraid, as you'll have to wait until the next release for > the changes to percolate down, but having a sensible list of enabled > clock drivers in base is definitely a good move. > I wonder: is there a reason to not enable all (or most of) the refclocks in base and in ports? Well, at least all the ones that build on freebsd... a disturbing number of them fail to compile because they include linux-specific header files. Hmm, I just noticed that we actually compile most of the refclocks, but we don't enable them in the config. It looks like the cost of enabling all the refclocks that compile properly is pretty small... doing so increased the size of ntpd from 745K to 801K for me. I'll attach the diff just to save someone else the trouble of iteratively figuring out which ones won't build, but I think there may be a more-proper way to generate this config by tweaking the autotools stuff. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Will 10.2 also ship with a very stale NTP?
On Fri, 2015-07-24 at 15:19 +0200, Harald Schmalzbauer wrote: > Bezglich Ian Lepore's Nachricht vom 12.07.2015 17:41 (localtime): > > And let's all just hope that a week or two of testing is enough when > > jumping a major piece of software forward several years in its > > independent evolution. > … > > I wonder how many other such things could be lurking in 4.2.8, waiting > > to be triggered by other peoples' non-stock configurations? We've > … > > I'd like to report one, most likely an upstream problem: > > 'restrict' definitions in ntp.conf(5) no longer work with unqualified DNS > names. > A line like > "restrict time1 nomodify nopeer noquery notrap" > results in: > ntpd[1913]: line 7 column 7 syntax error, unexpected T_Time1 > ntpd[1913]: syntax error in /etc/ntp.conf line 7, column 7 > > I've always been using unqualified hostnames with 'restrict', and since > defining 'server' with unqualified hostname still works, this seems to be a > significant bug to me. People are forced to change 'restrict' definitions, > but not to also change other unqualified definitions, which potentially leads > to misconfigurations, since intentionally matching definitions can now differ > easily. > > Has anybody already noticed this problem? And any idea if upstream is aware? I had a quick look at this today. It appears that the problem isn't unqualified names exactly, but rather an unqualified name that exactly matches an ntp.conf keyword will be mistaken by the ntpd config parser as a misplaced keyword token. So most unqualified names should work, but there are about 200 words that won't, many of them very sensible names for ntp servers such as "ntp" and "time1" and "time2". When I look at the ntp_parser.y grammar file it's not clear to me why "server time1" works and "restrict time1" doesn't. I couldn't find any way to trick it into taking a keyword as a hostname following restrict (like using quotes). You might be able to work around it using the new "restrict source" syntax that applies the restrictions to every server association that doesn't have a more-explicit matching restrict line. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Will 10.2 also ship with a very stale NTP?
On Fri, 2015-08-21 at 08:51 +0200, Harald Schmalzbauer wrote: > Bezüglich Ian Lepore's Nachricht vom 21.08.2015 00:34 (localtime): > > On Fri, 2015-07-24 at 15:19 +0200, Harald Schmalzbauer wrote: > >> Bezglich Ian Lepore's Nachricht vom 12.07.2015 17:41 (localtime): > >>> And let's all just hope that a week or two of testing is enough when > >>> jumping a major piece of software forward several years in its > >>> independent evolution. > >> … > >>> I wonder how many other such things could be lurking in 4.2.8, waiting > >>> to be triggered by other peoples' non-stock configurations? We've > >> … > >> > >> I'd like to report one, most likely an upstream problem: > >> > >> 'restrict' definitions in ntp.conf(5) no longer work with unqualified DNS > >> names. > >> A line like > >> "restrict time1 nomodify nopeer noquery notrap" > >> results in: > >> ntpd[1913]: line 7 column 7 syntax error, unexpected T_Time1 > >> ntpd[1913]: syntax error in /etc/ntp.conf line 7, column 7 > >> > >> I've always been using unqualified hostnames with 'restrict', and since > >> defining 'server' with unqualified hostname still works, this seems to be > >> a significant bug to me. People are forced to change 'restrict' > >> definitions, but not to also change other unqualified definitions, which > >> potentially leads to misconfigurations, since intentionally matching > >> definitions can now differ easily. > >> > >> Has anybody already noticed this problem? And any idea if upstream is > >> aware? > > I had a quick look at this today. It appears that the problem isn't > > unqualified names exactly, but rather an unqualified name that exactly > > matches an ntp.conf keyword will be mistaken by the ntpd config parser > > as a misplaced keyword token. So most unqualified names should work, > > but there are about 200 words that won't, many of them very sensible > > names for ntp servers such as "ntp" and "time1" and "time2". > > > > When I look at the ntp_parser.y grammar file it's not clear to me why > > "server time1" works and "restrict time1" doesn't. I couldn't find any > > way to trick it into taking a keyword as a hostname following restrict > > (like using quotes). > > Thank you very much! This is very interesting and exactly matches my > tested host names. > I wish I had better C skills to find such things myself. Out of > curiosity: How much time took it to find the ntp_parser.y route? (and > with what “IDE” I'm stuck with vim) > > One additional observation was that the reserved-name-collision only > happens with CNAME records. > I hope I'll find some time to actually do look into sources - which I > didn't at first hand because of my lousy C skills :-( But that's the > place where to find hints :-) > > Thanks, > I started out pretty sure what I was going to discover, based on the error you reported "syntax error, unexpected T_Time1". That 'T_Time1' just said to me "that's a yacc/bison token constant, this is going to be an error in their grammar (.y) file". The tricky part is that the .y file isn't in the base source code, I had to go find it in the vendor branch. I don't think the CNAME part matters. I tried changing my 'ntp' CNAME to a regular A record and the error still happens if I use it as an unqualified name with restrict. The IDE I use is SlickEdit, running on freebsd under the linuxulator. It's a commercial product worth every penny I've paid for various versions since the 90s. It gets the credit for a lot of my productivity. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to boot from GPT partition without "bootme" attribute?
On Tue, 2018-10-30 at 21:37 +0300, Lev Serebryakov wrote: > I have disk with GPT scheme and three partitions: > > p1 - freebsd-boot > p2 - freebsd-ufs > p3 - freebsd-ufs > > pmbr is installed on this disk, and gptboot is installed on p1. Both > p2 > and p3 contains valid FreeBSD installation, with /boot/loader, > kernel, > and everything. > > I have attribute "bootme" set on p3, but not on p2. > > What should I do to boot from p2? > > I've tried to interrupt gptboot and override its choice: > > 0:ad(0p3)/boot/loader > > with > > 0:ad(0p2)/boot/loader > > After that loader, loaded from p2, loads kernel from p3 and boots > system from p3! > > If I have MBR, I could override "active" slice in boot0 MBR loader > interactively. > > Is it analogous feature for GPT? > While loader(8) is loading the kernel, interrupt it to get the console prompt (or ask the menu to give the prompt if you use menus) and do: unload set currdev=disk0p2 boot -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sudo not available after configuring ipmi serial over lan
On Thu, 2018-11-08 at 06:10 +0700, Eugene Grosbein wrote: > 08.11.2018 5:56, Jordan Caraballo wrote: > > > > > Hi guys, > > > > After configuring ipmi serial over lan console, I am not being able > > to > > execute any command related to sudo; not even "sudo su -". I am > > using ttyu0 > > and COM1 on a Dell R530. Everything regarding receiving output and > > typing > > at the serial console is fine; the only command not working is > > sudo. > > > > Any ideas? Below are the configurations. > > > > /etc/ttys > > > > # Serial terminals > > # The 'dialup' keyword identifies dialin lines to login, fingerd > > etc. > > #ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole secure > > ttyu0 "/usr/libexec/getty std.115200" vt100 on secure > Use network access to perform the following: > > 1) Change "on" to "off" for ttyu0 then run "init q" to apply changes. > 2) Replace "ttyu0" with "cuau0" within same line then run "init q" > again. > > Then retry using console and sudo. The easy way to accomplish the same thing is to change std.115200 to 3wire.115200 (and then do 'init q'). -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sudo not available after configuring ipmi serial over lan
On Thu, 2018-11-08 at 12:47 -0500, Jordan Caraballo wrote: > Hi Ian, > Changing the line following line from std.115200 to 3wire.115200 > worked. > Can you explain the why? I am not entirely sure of the difference > between > 3wire and std there. > > ttyu0 "/usr/libexec/getty 3wire.115200" vt100 on secure > > Thanks, > - Jordan > The standard setting honors the modem control lines on the serial port, so any attempt to open that serial device will block until the carrier- detect line on the port is asserted. The 3wire setting indicates that only RX, TX, and GND are connected, and modem-control signals should be ignored. An open of such a device will return immediately whether anything is actually connected to the serial port or not. A /dev/ttyN device is assumed to be a "call-in" device and has the blocking behavior by default. A /dev/cuaN device is assumed to be a "call-out" device that doesn't wait for modem carrier by blocking. Using the std vs 3wire designations in /etc/ttys causes init(1) to set termios(4) flags to implement blocking-open or immediate-open behavior without needing to change the device name as well. -- Ian > El jue., 8 nov. 2018 a las 10:39, Ian Lepore () > escribió: > > > > > On Thu, 2018-11-08 at 06:10 +0700, Eugene Grosbein wrote: > > > > > > 08.11.2018 5:56, Jordan Caraballo wrote: > > > > > > > > > > > > > > > Hi guys, > > > > > > > > After configuring ipmi serial over lan console, I am not being > > > > able > > > > to > > > > execute any command related to sudo; not even "sudo su -". I am > > > > using ttyu0 > > > > and COM1 on a Dell R530. Everything regarding receiving output > > > > and > > > > typing > > > > at the serial console is fine; the only command not working is > > > > sudo. > > > > > > > > Any ideas? Below are the configurations. > > > > > > > > /etc/ttys > > > > > > > > # Serial terminals > > > > # The 'dialup' keyword identifies dialin lines to login, > > > > fingerd > > > > etc. > > > > #ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole > > > > secure > > > > ttyu0 "/usr/libexec/getty std.115200" > > > > vt100 on secure > > > Use network access to perform the following: > > > > > > 1) Change "on" to "off" for ttyu0 then run "init q" to apply > > > changes. > > > 2) Replace "ttyu0" with "cuau0" within same line then run "init > > > q" > > > again. > > > > > > Then retry using console and sudo. > > The easy way to accomplish the same thing is to change std.115200 > > to > > 3wire.115200 (and then do 'init q'). > > > > -- Ian > > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
On Tue, 2018-12-04 at 21:51 +0200, Toomas Soome via freebsd-stable wrote: > > > > > On 4 Dec 2018, at 19:59, Mark Martinec > i> wrote: > > > > > > > > > > > > > 2018-11-29 18:43, Toomas Soome wrote: > > > > > > > > > > I just did push biosdisk updates to stable/12, I wonder if > > > > > you could > > > > > test those bits… > > Myself wrote: > > > > > > > > > > > Thank you! I haven't tried it yet, but I wonder whether this > > > > fix was > > > > already incorporated into 12.0-RC3, which would make my rescue > > > > easier. > > > > Otherwise I can build a stable/12 on another host and > > > > transplant > > > > the problematic file(s) to the affected host - if I knew which > > > > files > > > > to copy. > > 2018-12-02 18:59, Toomas wrote: > > > > > > The files are /boot/loader* binaries - to be exact, check which > > > one is > > > linked to /boot/loader. I can provide binaries if needed. > > > [...] > > > rgds, > > > toomas > > I got a maintenance window today so I tried with the new loader, > > and it did not help. > > > > More specifically: > > > > As it comes with 12-RC2, the /boot/loader was hard linked with > > loader_lua. > > Its size is 421888 bytes. So I concentrated on this loader. > > > > I build a fresh stable/12 on another host, and copied the newly > > built loader_lua (425984 bytes) to the /boot directory of the > > affected > > host, deleted the file 'loader', and hard-linked loader_lua to > > loader. > > > > The situation has not changed: the BTX loader lists all BIOS drives > > C..J (disk0..disk7), then a spinner starts and gets stuck forever. > > It never reaches the 'BIOS 635kB/3537856kB available memory' line. > > > > While trying to restore the old /boot from 11.2, I tried booting > > a live image from a 12.0-RC3 memory stick - and the loader got > > stuck again, same as when booting from a disk. > > > > So I had to boot from an 11.2 memstick to be able to regain > > control. > > > > Mark > > > > > ok, if you could perform 2 tests: > > 1. from loader prompt enter 0x413 0xa000 - @w . cr > > 2. on first spinner, press space and type on boot: prompt: > /boot/loader_4th and see if that will do better > thanks, > toomas > I don't think that will be an option. If it hasn't gotten to the point of saying how much BIOS available memory there is, it's only halfway through loader main() and has hung before getting to interact(). In fact, if that line hasn't printed, but some disk drives have been listed, it pretty much has to be hung in the "March through the device switch probing for things" loop. If all the disks are listed, then it got through that entry in the devsw, and is likely hanging in the dv_init calls for either the pxedisk or zfsdev devices. -- Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 29 Nov 2018, at 17:01, Mark Martinec > > > > > b...@ijs.si> wrote: > > > > > > After successfully upgraded three hosts from 11.2-p4 to > > > > > > 12.0-RC2 (amd64, > > > > > > zfs, bios), I tried my luck with one of our production > > > > > > hosts, and ended up > > > > > > with a stuck loader after rebooting with a new kernel > > > > > > (after the first > > > > > > stage of upgrade). > > > > > > These were the steps, and all went smoothly and normally > > > > > > until a reboot: > > > > > > freebsd-update upgrade -r 12.0-RC2 > > > > > > freebsd-update install > > > > > > shutdown -r now > > > > > > While booting, the 'BTX loader' comes up, lists the BIOS > > > > > > drives, > > > > > > then the spinner below the list comes up and begins > > > > > > turning, > > > > > > stuttering, and after a couple of seconds it grinds to a > > > > > > standstill > > > > > > and nothing happens afterwards. > > > > > > At this point the ZFS and the bootstrap loader is supposed > > > > > > to > > > > > > come up, but it doesn't. > > > > > > This host has too zfs pools, the system pool consists of > > > > > > two SSDs > > > > > > in a zfs mirror (also holding a freebsd-boot partition > > > > > > each), the > > > > > > other pool is a raidz2 with six JBOD disks on an LSI > > > > > > controller. > > > > > > The gptzfsboot in both freebsd-boot partitions is fresh > > > > > > from 11.2, > > > > > > both zpool versions are up-to-date with 11.2. The 'zpool > > > > > > status -v' > > > > > > is happy with both pools. > > > > > > After rebooting from an USB drive and reverting the /boot > > > > > > directory > > > > > > to a previous version, the machine comes up normally again > > > > > > with the 11.2-RELEASE-p4. > > > > > > I found a file init.core in the / directory, slightly > > > > > > predating the > > > > > > last reboot with a salvaged system - although it was > > > > > > probably not > > > > > > a cause of the problem, but a consequence of the rescue > > > > > > operation. > > > > > > It is unfortunate that this is a production host, so I > > > > > > can't play > > > > > > much with it. One or two more quick experiments I can > > > > > > probably > > > > > >
Re: /dev/crypto not being used in 12-STABLE
On Fri, 2018-12-07 at 18:38 -0500, Jung-uk Kim wrote: > > So while OpenSSL now uses more of its own native C and assembly code > > (e.g. for AES-NI support), and that's certainly faster than all the > > overhead that cryptodev(4) brings with it (see jhb@'s post), I wonder: > > > > 1. What happens to people using crypto hardware accelerators, ex. > > hifn(4), padlock(4), ubsec(4), and safe(4)? How exactly would OpenSSL > > utilise these H/W accelerators if the devcrypto engine is disabled? > > padlock has a dynamic engine, i.e., /usr/lib/engines/padlock.so. I > believe glxsb, hifn(4), safe(4), and ubsec(4) users are very rare > nowadays. If we have significant number of users and they show > reasonable performance, then I will reconsider my decision. What about non-x86 hardware? Most 32-bit ARM chips have crypto accelleration hardware which is not implemenented as cpu instructions (or accessible in any way from userland). -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfsboot@12.0: Shortening read at xxxx from 16 to -479991569
On Thu, 2018-12-13 at 08:59 -0700, Warner Losh wrote:
> On Thu, Dec 13, 2018, 6:19 AM Mark Martinec s.si
> wrote:
>
> >
> > On one of my hosts (now running 12.0-RELEASE) the zfsboot shows
> > this weird negative number, which sounds suspicious:
> >
> > Verifying DMI pool Data .
> > Shortening read at 3907029152 from 16 to 15
> > Shortening read at 7435283708 from 16 to -479991569
> >
> > BTX loader 1.0 BTX version is 1.02
> > Consoles: ...
> > BIOS drive C: is disk0
> > ...
> >
> > The machine boots up normally and is fine, zpool scrub is happy,
> > so, should I worry? Anything fishy there?
> >
> > Searching through sources, the message seems to come from
> > stand/i386/zfsboot/zfsboot.c :
> >
> > printf("Shortening read at %lld from %d to %lld\n",
> > alignlba, alignnb, (zdsk->dsk.size + zdsk->dsk.start) -
> > alignlba);
> >
>
> Do you have any encrypted disks?
>
> Warner
I ran into something like this once before, and tracked it down to
using the roundup2() and rounddown2() macros from sys/param.h. In
particular, a mix of 32 and 64 bit types of different signedness
resulted in zero-extension instead of sign-extension of one of the
values, and that masked off significant bits, then a later subtraction
turned a result into a negative number.
-- Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Success updating stable/11 to /12; a couple things to note
On Thu, 2018-12-27 at 05:53 -0800, David Wolfskill wrote: > * I found that I actually needed to create the ntpd user on the > running system prior to "make installworld" -- having run > "mergemaster -U" against the target (DESTDIF) was insufficient. The correct update sequence involves running mergemaster twice, once with the -p option, then again later without it. It's detailed at the bottom of UPDATING. People get in the habit of skipping the -p step because it's only really needed once every few years, such as when a new user is added to the base system. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Success updating stable/11 to /12; a couple things to note
On Thu, 2018-12-27 at 08:30 -0800, David Wolfskill wrote: > On Thu, Dec 27, 2018 at 09:13:09AM -0700, Ian Lepore wrote: > > > > On Thu, 2018-12-27 at 05:53 -0800, David Wolfskill wrote: > > > > > > * I found that I actually needed to create the ntpd user on the > > > running system prior to "make installworld" -- having run > > > "mergemaster -U" against the target (DESTDIF) was insufficient. > > The correct update sequence involves running mergemaster twice, > > once > > with the -p option, then again later without it. It's detailed at > > the > > bottom of UPDATING. People get in the habit of skipping the -p step > > because it's only really needed once every few years, such as when > > a > > new user is added to the base system. > > > > -- Ian > > > Yes, but the one after "make installworld" isn't likely to affect the > "make installworld". :-) > > The sequence of events: > > mount -u -r / > mount -u -r /usr > mount /dev/ada0s1a /S1 > mount /dev/ada0s1d /S1/usr > mount -u -w /S1 > mount -u -w /S1/usr > ln -fhs /var /S1/var > mount -o ro freebeast:/usr/src /usr/src > mount -o ro freebeast:/usr/obj /usr/obj > id > mount > cd /usr/src > uname -a > date > make LD=ld.lld installkernel DESTDIR=/S1 > date > mergemaster -U -u 0022 -p -D /S1 > date > rm -fr /S1/usr/include.old > date > mv -f /S1/usr/include /S1/usr/include.old > date > rm -fr /S1/usr/share/man > date > make installworld DESTDIR=/S1 > date > mergemaster -F -U -u 0022 -i -D /S1 > date > make delete-old DESTDIR=/S1 > date > date > df -k > date > > > My point was that running "mergemaster -U" against the new image > (/S1, > in the case above) is not sufficient for "make installworld > DESTDIR=/S!" > to work: it is necessary that the *running* system be aware of the > "ntpd" user (I presume, to allow ownership of files to be set by the > "ntpd" name, vs. the numeric "123"). > > Peace, > david I must have missed the part where you were using DESTDIR= during the install. In that case, the right magic is to add DB_FROM_SRC=yes to the make installworld command. There were a couple proposals to automate that somehow, but I didn't see anything proposed that didn't basically subvert the entire purpose of that check for whether the user exists. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:05.kqueue
On Tue, 2019-02-05 at 13:00 -0700, Alan Somers wrote: > On Tue, Feb 5, 2019 at 12:55 PM Shawn Webb wrote: > > > > On Wed, Jan 09, 2019 at 07:40:30PM +, FreeBSD Errata Notices wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA512 > > > > > > = > > > FreeBSD-EN-19:05.kqueue Errata > > > Notice > > > The FreeBSD > > > Project > > > > > > Topic: kqueue race condition and kernel panic > > > > > > Category: core > > > Module: kqueue > > > Announced: 2019-01-09 > > > Credits:Mark Johnston > > > Affects:FreeBSD 11.2 > > > Corrected: 2019-11-24 17:11:47 UTC (stable/11, 11.2-STABLE) > > > > Corrected November of 2018 or 2019? ;) > > 2019, of course. re@ does NOT make mistakes. What you fail to > realize is that NIST was using kqueue to check their atomic clock, and > they lost the race. Enjoy the rest of 2020. > -Alan > I think you meant that as a joke, but the reality is that NIST measures their atomic clocks using gear that runs FreeBSD (made by the company I work for). :) -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:05.kqueue
On Wed, 2019-02-06 at 03:46 +0700, Eugene Grosbein wrote: > 06.02.2019 3:18, Ian Lepore wrote: > > > > 2019, of course. re@ does NOT make mistakes. What you fail to > > > realize is that NIST was using kqueue to check their atomic > > > clock, and > > > they lost the race. Enjoy the rest of 2020. > > > -Alan > > > > > > > I think you meant that as a joke, but the reality is that NIST > > measures > > their atomic clocks using gear that runs FreeBSD (made by the > > company I > > work for). :) > > I do not know if it is related or not: some months ago my FreeBSD > 11.2-STABLE box > having GPS received attached at /dev/cuau0 for my local ntpd stratum > 1 server > went to late of 2020 insanely. I was forced to comment GPS out of > ntpd config to revive it > but I lost all data in hundreds of local RRD databases and > I found a race in libarchive being a reason why my backups had not > most part of databases. > > I still do not know exact reason and use Internet time source instead > of local GPS. The GPS week number rolls over in April 2019. At $work we have already been seeing glitches in gps receivers as early as last June that were caused by errors in the receivers' firmware that didn't handle the upcoming rollover properly. When a receiver first powers on, it has no real idea what gps era it's in (right now we're in the 2nd, about to roll over to the 3rd). It has to guess, which it mostly does the same way as software does that has to deal with 2-digit years: make a decision based on the current date being before/after some cutoff (like > 70 means 2070), and assume everyone will be running newer firmware before that date arrives. So your problem was most likely the gps receiver making a bad choice before it had enough info to make a good choice. It's one of many reasons why an ntp server should have at least 3 (really, at least 5) peers, so it can reject obviously-insane data from a single source. Even when you use a gps to get really accurate local time, you should have a handful of network peers that can serve as sanity-checkers. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Fwd: Serious ZFS Bootcode Problem (GPT NON-UEFI)
On Sun, 2019-02-10 at 11:54 -0600, Karl Denninger wrote: > On 2/10/2019 11:50, Ian Lepore wrote: > > On Sun, 2019-02-10 at 11:37 -0600, Karl Denninger wrote: > > > On 2/10/2019 09:28, Allan Jude wrote: > > > > Are you sure it is non-UEFI? As the instructions you followed, > > > > overwriting da0p1 with gptzfsboot, will make quite a mess if > > > > that > > > > happens to be the EFI system partition, rather than the > > > > freebsd- > > > > boot > > > > partition. > > > > > > [...] > > > > > > BTW am I correct that gptzfsboot did *not* get the ability to > > > read > > > geli-encrypted pools in 12.0? The UEFI loader does know how > > > (which I'm > > > using on my laptop) but I was under the impression that for non- > > > UEFI > > > systems you still needed the unencrypted boot partition from > > > which to > > > load the kernel. > > > > > > > Nope, that's not correct. GELI support was added to the boot and > > loader > > programs for both ufs and zfs in freebsd 12. You must set the geli > > '-g' > > option to be prompted for the passphrase while booting (this is > > separate from the '-b' flag that enables mounting the encrypted > > partition as the rootfs). You can use "geli configure -g" to turn > > on > > the flag on any existing geli partition. > > > > -- Ian > > Excellent - this will eliminate the need for me to run down the > foot-shooting that occurred in my update script since the unencrypted > kernel partition is no longer needed at all. That also significantly > reduces the attack surface on such a machine (although you could > still > tamper with the contents of freebsd-boot of course.) > > The "-g" flag I knew about from experience in putting 12 on my X1 > Carbon > (which works really well incidentally; the only issue I'm aware of is > that there's no 5Ghz WiFi support.) > One thing that is rather unfortunate... if you have multiple geli encrypted partitions that all have the same passphrase, you will be required to enter that passphrase twice while booting -- once in gpt[zfs]boot, then again during kernel startup when the rest of the drives/partitions get tasted by geom. This is because APIs within the boot process got changed to pass keys instead of the passphrase itself from one stage of booting to the next, and the fallout of that is the key for the rootfs is available to the kernel for mountroot, but the passphrase is not available to the system when geom is probing all the devices, so you get prompted for it again. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Fwd: Serious ZFS Bootcode Problem (GPT NON-UEFI)
On Sun, 2019-02-10 at 11:37 -0600, Karl Denninger wrote: > On 2/10/2019 09:28, Allan Jude wrote: > > Are you sure it is non-UEFI? As the instructions you followed, > > overwriting da0p1 with gptzfsboot, will make quite a mess if that > > happens to be the EFI system partition, rather than the freebsd- > > boot > > partition. > > [...] > > BTW am I correct that gptzfsboot did *not* get the ability to read > geli-encrypted pools in 12.0? The UEFI loader does know how (which I'm > using on my laptop) but I was under the impression that for non-UEFI > systems you still needed the unencrypted boot partition from which to > load the kernel. > Nope, that's not correct. GELI support was added to the boot and loader programs for both ufs and zfs in freebsd 12. You must set the geli '-g' option to be prompted for the passphrase while booting (this is separate from the '-b' flag that enables mounting the encrypted partition as the rootfs). You can use "geli configure -g" to turn on the flag on any existing geli partition. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
