Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
On 9/9/06, Matthew Jacob <[EMAIL PROTECTED]> wrote: > > > > Insofar as the Error 22- that's normal to see those for verbose > > booting. They should be more informative as to why those are > > occurring. > > > > You're right. Those messages are evident only while verbose booting, > so, I'm not really concerned about them but the huge delay on booting > (up to 18 min) they represent on 6-STABLE. > Hmm. I'll have to dig back thru the mail here but I don't get this. On 6-STABLE, those "Error 22" messages on boot, show up too slowly, one character at a time, at about one line every 30 seconds, which delays the boot process on almost 20 (twenty) minutes. After that huge delay, the disc information is shown and the file system is fsck'ed, as usually. However, disabling APIC, eliminates this delay. On 7-CURRENT, there is not such delay, even though APIC was enabled. Regards. -- Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 12:55:42AM -0300, Marc G. Fournier wrote: > On Sat, 9 Sep 2006, Kris Kennaway wrote: > > >On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote: > >> > >>This should be documented somewhere clearly then, as my understanding was > >>that -STABLE meant that anything MFCd back to it *was* tested and deemed > >>stable ... > > > >You mean like in the FreeBSD handbook? It's not anyone else's fault > >if you haven't read the documentation. > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html > > I swear, the last time I searched for a definition of STABLE vs > CURRENT/HEAD, that wsan't there ... but, granted, that was a very very > long time ago ... Well, now you know. Might be a good idea to reread the handbook and other documentation to bring yourself up to date on anything else you might have missed too. Kris pgpNQkqiGvM8J.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, 9 Sep 2006, Kris Kennaway wrote: On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote: This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... You mean like in the FreeBSD handbook? It's not anyone else's fault if you haven't read the documentation. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html I swear, the last time I searched for a definition of STABLE vs CURRENT/HEAD, that wsan't there ... but, granted, that was a very very long time ago ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, 9 Sep 2006, Mark Linimon wrote: On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote: This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... http://www.freebsd.org/doc/en_US.ISO8859-1/articles/version-guide/decision-points.html but "blantant and obvious bugs due to insufficient testing", IMHO, doesn't classify as an 'oops' You've already made this point -- 3 times. What would you like us to do now, punish the committer? Huh? My first post on this thread was in defense of MFCng into STABLE and acknowledging that 'mistakes happen', and then this one ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
If by "all the time" you mean every time certain disk operations are performed (tarball extraction, files download...), then, yes. All the time. Otherwise, no error shows up. Hmm. Okay. I'll work on this. > > Insofar as the Error 22- that's normal to see those for verbose > booting. They should be more informative as to why those are > occurring. > You're right. Those messages are evident only while verbose booting, so, I'm not really concerned about them but the huge delay on booting (up to 18 min) they represent on 6-STABLE. Hmm. I'll have to dig back thru the mail here but I don't get this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote: > > This should be documented somewhere clearly then, as my understanding was > that -STABLE meant that anything MFCd back to it *was* tested and deemed > stable ... You mean like in the FreeBSD handbook? It's not anyone else's fault if you haven't read the documentation. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html Kris pgpJvUwwnTWKq.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, Sep 09, 2006 at 11:16:29PM -0300, Marc G. Fournier wrote: > This should be documented somewhere clearly then, as my understanding was > that -STABLE meant that anything MFCd back to it *was* tested and deemed > stable ... http://www.freebsd.org/doc/en_US.ISO8859-1/articles/version-guide/decision-points.html > but "blantant and obvious bugs due to insufficient testing", IMHO, doesn't > classify as an 'oops' You've already made this point -- 3 times. What would you like us to do now, punish the committer? Simply reiterating your criticism and unhappiness isn't going to do anything to fix this problem (for which, of course, a fix has already been made), or the next one(s) either. It was an error, it's been fixed, may I suggest we move on to the next bug? mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... and yes, I do run stable, and yes, I do expect to hit the occasional 'oopses', but "blantant and obvious bugs due to insufficient testing", IMHO, doesn't classify as an 'oops' On Sun, 10 Sep 2006, Mark Andrews wrote: Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. Most of the time beta code is perfectly fine to run but occasionally things will go wrong. The point of BETA code is to catch those errors that escape detection in the ALPHA stage before they make it into a release. That is done by having a wider diversity of clients run the BETA code. Occasionally you have bugs that make it through both the ALPHA and BETA stages. Mark -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
> Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. Most of the time beta code is perfectly fine to run but occasionally things will go wrong. The point of BETA code is to catch those errors that escape detection in the ALPHA stage before they make it into a release. That is done by having a wider diversity of clients run the BETA code. Occasionally you have bugs that make it through both the ALPHA and BETA stages. Mark -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
On 9/9/06, Matthew Jacob <[EMAIL PROTECTED]> wrote: Oops- mangled reply. On 9/9/06, Matthew Jacob <[EMAIL PROTECTED]> wrote: > > > > is gone, but a new error message appears as often as the former, > > and under the same circumstances: > > > > > mpt0: QUEUE_FULL: Bus 0x00 Target 0x00 Depth 128 > Do you see these all the time? If so I'll have to connect up some logic to take and shut down openings to match the Depth field- although this is a step I've been resisting. If by "all the time" you mean every time certain disk operations are performed (tarball extraction, files download...), then, yes. All the time. Otherwise, no error shows up. Insofar as the Error 22- that's normal to see those for verbose booting. They should be more informative as to why those are occurring. You're right. Those messages are evident only while verbose booting, so, I'm not really concerned about them but the huge delay on booting (up to 18 min) they represent on 6-STABLE. -- Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: suggestions for SATA RAID cards
Steven Hartland wrote: Mark Kirkwood wrote: If you are using RAID0|5, then something is slowing you down (possible clash between disk firmware and the Areca, or unfortunate choice of strip chunk size). Dont know which test I was remembering but just did a quicky: OS: FreeBSD 6.1 RAID: 5 on 5 * 400GB Seagate Controller: HighPoint 1820a CPU: Dual Opteron 244 RAM: 2Gb /usr/bin/time -h dd if=/dev/da0 of=/dev/null bs=1048576 count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 44.887239 secs (233602250 bytes/sec) 44.88s real 0.03s user 2.40s sys In comparison: OS: FreeBSD 5.4 RAID: 5 on 6 * 300GB Seagate Controller: Areca 1120 CPU: Dual Opteron 248 RAM: 4Gb /usr/bin/time -h dd if=/dev/da0 of=/dev/null bs=1048576 count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 81.598938 secs (128503633 bytes/sec) 1m21.60s real 0.00s user 2.69s sys Hmmm - I've found that FreeBSD 6.1 is a considerably better performer than 5.4, so that is not helping the comparison above. Another thing to check is that both systems have the same vfs.read_max sysctl tunable, as that makes quite a difference on RAID systems! If you have the time to keep playing with these machines, it might be interesting to try block sizes other than 1M - could expose different behavior too! Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, Sep 09, 2006 at 04:04:40PM -0300, Marc G. Fournier wrote: > On Sat, 9 Sep 2006, Karl Denninger wrote: > > >Yeah, -STABLE is what you should run if you want stable code, right? > > > >C'mon guys. This sort of thing belies a total lack of concern when > >changes are MFC'd into production branches of the code. This kind of > >thing is expected if you're running -CURRENT, but not -STABLE. > > > >How long would it have taken to actually test the change and detect this > >once it was put in? All of 30 seconds? > > In this case, I don't know ... but I *do* know that I do hit a fair > number of "bugs" that a simple 30 second test won't uncover ... a > production box *can* and *will* tend to hit bugs that a test box won't, > just because of the randomness of what is running on it ... trust me, I've > had my share of headaches over the years, but it doesn't (and won't) deter > me from running -STABLE, for the simple fact that if I don't, there is a > good chance that those bugs that I do get "lucky" enough to hit won't get > hit by anyone else and *someone* had to get it ;) Well sure, if its one of those "corner cases" I understand. This is the price of not doing FULL regression testing, and expecting that from a free project is unreasonable. Hell, you don't get that from Micro$oft, why would anyone think you'd get it here? But in this situation its not a corner case. I've got a (different) open issue on 6.x where it appears that SELECT on serial lines is badly screwed; this may be specific to the ROCKETPORT cards and it may not - not real sure yet. I reported that one recently too, and its giving me a 5-alarm migrane at the moment trying to find a workaround that actually functions. I can't find anything in the commit logs that would lead me to believe that the ttyio code has changed in a way that should have caused this, and the driver hasn't been updated either. That's a head-scratcher for a whole host of reasons with the first one being that I don't have the first clue where to look for the source of trouble (to use a pun.) Its not as simple as "serial I/O doesn't work at all"; it appears to be specific to using VMIN, non-blocking I/O and select() to handle multiple sources of input coming into a single thread. Now how often do people do this? I dunno. but what I do know is that the common "single thread" application works fine on the same port This is different. We're talking about the very basic functionality of the gmirror system - to be able to rebuild a disk that is out of sync. In this case my "notice" of the problem came in the form of a production machine that went down overnight - apparently, it would seem, during an attempt to back itself up using that functionality. It went down HARD and corrupted the root partition directory structure badly enough to prevent fsck from being able to rebuild it on an automated restart attempt, and what was worse, the bug caused the system to block in I/O permanently as of course when it came back up from the crash it tried to resync the out-of-date providers, making the reboot hang! So what I had was a production machine that couldn't be brought back up without significant "wizardry" at the physical console, and frankly, what it LOOKED LIKE at first blush was a disk failure - one of those "that's not supposed to happen" things. I was very close to putting the day-old backup disk online - I'm darn glad I didn't, because the bug would have likely trashed THAT one too, and then I'd be both a day back on the data AND have an unstable system! Not good, especially when the commit log on the last delta to the gmirror code was basically "removed uses of the F-word in comments; we're nice people". Uh, obviously not. The obvious question is how does the protocol for committing changes to -STABLE work if the committer isn't required to first test the basic function set of the module he/she modifies, on -STABLE, before those changes are MFC'd back into the -STABLE tree? I see that the (actual) code changes were backed out (apparently yesterday) and I've rebuilt the kernel with those, which has put the immediate fire out, but this is one of those instances where the usual "check and balance" process that is as being present in -STABLE failed badly, and it failed simply due to a lack of checking at all! -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, 9 Sep 2006, Karl Denninger wrote: Yeah, -STABLE is what you should run if you want stable code, right? C'mon guys. This sort of thing belies a total lack of concern when changes are MFC'd into production branches of the code. This kind of thing is expected if you're running -CURRENT, but not -STABLE. How long would it have taken to actually test the change and detect this once it was put in? All of 30 seconds? In this case, I don't know ... but I *do* know that I do hit a fair number of "bugs" that a simple 30 second test won't uncover ... a production box *can* and *will* tend to hit bugs that a test box won't, just because of the randomness of what is running on it ... trust me, I've had my share of headaches over the years, but it doesn't (and won't) deter me from running -STABLE, for the simple fact that if I don't, there is a good chance that those bugs that I do get "lucky" enough to hit won't get hit by anyone else and *someone* had to get it ;) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
missing hardware
Greetings, Currently I have FBSD 6.1 release (custom build, DMI, DRM, took out some drivers that I don't use) however, 6.1 release generic didn't quite work either*. (Works on a different (slower) harddrive controller) ACPI doesn't seem to work on this computer. The problem is that I have two host -> PCI adapters, and two PCI -> PCI bridges in my computer, and a Symbios 53c896 behind one of them isn't being seen. Essentally, there is... (edited output from pciconf -lv) === [EMAIL PROTECTED]:0:0:class=0x06 card=0x chip=0x00071166 rev=0x04 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'NB6635 (CNB20-LE/HE) CPU to PCI Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:1: class=0x060400 card=0x0080 chip=0x00051166 rev=0x02 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'NB6536 (CNB20-LE) PCI to PCI Bridge, bus/dev/func 0/0/1' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:17:0: class=0x06 card=0x chip=0x00071166 rev=0x04 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'NB6635 (CNB20-LE/HE) CPU to PCI Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:17:1: class=0x06 card=0x chip=0x00051166 rev=0x02 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'NB6536 (CNB20-LE) PCI to PCI Bridge, bus/dev/func 0/0/1' class= bridge subclass = HOST-PCI === However, (edited dmesg (boot -v)) === pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1166, dev=0x0007, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x6200, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base e000, size 28, enabled map[14]: type 1, range 32, base febee000, size 12, enabled found-> vendor=0x1166, dev=0x0005, revid=0x02 bus=0, slot=0, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x22b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0007, revid=0x04 bus=0, slot=17, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x6200, cachelnsz=8 (dwords) lattimer=0x30 (1440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0005, revid=0x02 bus=0, slot=17, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x2200, cachelnsz=8 (dwords) lattimer=0x30 (1440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 0.1 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode0xf000-0xfff pcib1: memory decode 0xfff0-0xf pcib1: prefetched decode 0xfff0-0xf pci1: on pcib1 pci1: physical bus=1 xl0: miibus0: xlphy0: drm0: isab0: isa0:... pcib3: pcibus 3 on motherboard pci3: on pcib3 pci3: physical bus=3 === As you can see, pcib2 and pci2 have been dropped. I can see that within the source code (pci_bus.c L#387) there is an if statement that looks for duplicate busses. I inserted a quick printf statement in there, and it showed up, once. Thus, something, somehow is being kicked. (Due to my lack of knowledge with regards to C code, I don't know how to find out what board is, because I don't know how to find out how the variable has been defined in C. (%x, %d ...) lspci -Mvvv === 00:00.0 0600: 1166:0007 (rev 04) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR+ TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [80] AGP version 1.0 Status: RQ=17 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW- Rate=x1 ## 00.00:1 is a bridge from 00 to 01-01 00:01.0 0200: 10b7:9055 (rev 24) Subsystem: 1091:9055 00:11.0 0600: 1166:0007 (rev 04) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR+ (32-bit, prefetchable) 00:11.1 0600: 1166:0005 (rev 02) Control:
Re: Patch for GBDE rc-script
On 14:13 Fri 08 Sep, Tobias Roth wrote: > On Thu, Sep 07, 2006 at 08:13:11PM +0200, Daniel Bond wrote: > > Hi, > > > > I just setup GBDE on my laptop, encrypting my 512M cf-card. > > This works like a charm, but I felt the need to enchance the rc-script a > > little to automatically mount the encrypted drive(s), if you have the > > following in /etc/rc.conf: > > [snip] > > How is this better/different from just adding the gbde device to > /etc/fstab and have it mounted along with all other filesystems? > > Thanks, > Tobias It says in the handbook: "Since encrypted file systems cannot yet be listed in /etc/fstab for automatic mounting, the file systems must be checked for errors by running fsck(8) manually before mounting." -- Med vennlig hilsen / Best regards, -- Daniel Bond PGP: C822C4BD -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Reproducible data corruption on 6.1-Stable
I set up a new server recently and transferred all the information from my old server over. At the time it appeared there where no problems. I just tried to use unison to synchronize the backup of pictures I have taken and noticed that a shockingly high number of pictures where marked as changed on the server. After checking the pictures by hand I confirmed that many of the pictures on the server where corrupted. I attempted to use unison to update the files on the server with the correct local copies but it would fail on almost all the files with the message "destination updated during synchronization." I have since tried copying the files over using both samba and rsync and both exhibit corruption. I do know the files are transferred correctly over the network because a diff initially shows everything as identical until I read enough to flush the cache at which point when it hits the disk I start seeing the corruption. Not every file gets corrupted but it seems like >10% do each time and it's not always the same files. The larger files seem to be corrupted more often so it seem to be related more to the amount of data written than the number of files. I cvsuped and rebuilt world and kernel last night in hope that it had been fixed recently but with no luck. I have not seen any error messages on the console at all either. I have a pair of 320GB SATA hard drives setup as RAID0 on a HighPoint RocketRaid 1520 card. This being a data corruption issue I can afford any amount of downtime needed for trouble shooting as it's not very useful to have the server up if everything is going to get corrupted. Thank you, Jonathan uname -a: FreeBSD X 6.1-STABLE FreeBSD 6.1-STABLE #1: Fri Sep 8 23:53:36 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 dmesg: Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-STABLE #1: Fri Sep 8 23:53:36 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC mptable_probe: MP Config Table has bad signature: 4\^C\^_ Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 3200+ (2090.17-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 real memory = 1073676288 (1023 MB) avail memory = 1041698816 (993 MB) kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 Correcting nForce2 C1 CPU disconnect hangs agp0: mem 0xd800-0xdbff at device 0.0 on pci0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xe1085000-0xe1085fff irq 5 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe1082000-0xe1082fff irq 5 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xe1083000-0xe10830ff irq 12 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered nve0: port 0xe400-0xe407 mem 0xe1084000-0xe1084fff irq 12 at device 4.0 on pci0 nve0: Ethernet address 00:0c:6e:7d:e0:79 miibus0: on nve0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: Ethernet address: 00:0c:6e:7d:e0:79 pci0: at device 5.0 (no driver attached) pci0: at device 6.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 atapci0: port 0xa000-0xa007,0xa400-0xa403,0xa800-0xa807,0xac00-0xac03,0xb000-0xb0ff irq 11 at device 6.0 on pci1 ata2: on atapci0 ata3: on atapci0 pci1: at device 9.0 (no driver attached) pci1: at device 9.1 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 9.0 on pci0 ata0: on atapci1 ata1: on atapci1 pcib2: at device 12.0 on pci0 pci2: on pcib2 xl0: <3Com 3c920B-EMB Integrated Fast Etherlink XL> port 0xc000-0xc07f mem 0xdd00-0xdd7f irq 5 at device 1.0 on pci2 miibus1: on xl0 acphy0: on mii
Re: panic: integer divide fault on 6.1
On Sat, Sep 09, 2006 at 09:02:35PM +0100, Joao Barros wrote: > On 9/9/06, Max Laier <[EMAIL PROTECTED]> wrote: > > > >Can you try to get a dump, trace, or at least figure out which function > >the IP is refering to? > > > > Well, the problem only occurs when I boot from the disk and the > installed kernel doesn't have debug support. > Does 'set dumpdev=' work from the boot loader? I tried some > combinations with no success. No. > I can try and install a 6-STABLE snapshot if there's no way of getting > the info needed. You can either try to install a new kernel with DDB support, or follow the "instruction pointer" method in the developers handbook chapter on kernel debugging. Kris pgpW9Nmdl5WvQ.pgp Description: PGP signature
Re: panic: integer divide fault on 6.1
On 9/9/06, Max Laier <[EMAIL PROTECTED]> wrote: Can you try to get a dump, trace, or at least figure out which function the IP is refering to? Well, the problem only occurs when I boot from the disk and the installed kernel doesn't have debug support. Does 'set dumpdev=' work from the boot loader? I tried some combinations with no success. I can try and install a 6-STABLE snapshot if there's no way of getting the info needed. -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror RAID-1: rebuilding freezes machine
On Sat, Sep 09, 2006 at 04:26:52PM +0200, Volker wrote: > One feature request on gmirror: > > If a system comes up and more than one mirror is out of sync, > currently gmirror tries (in automatic mode) to re-sync all providers > at the same time which slows down the system. > > When gmirror tries to do a resync, it would make sense to do that > one by one and not all at the same time as the disk head moves > erratically and seek time is wasted time. Because of that I'm now > using automatic rebuild mode on the first (root-fs) gmirror slice > and will fire a manual re-sync on the others one by one if needed. I > guess I'll put that logic in an rc script but gmirror might avoid > doing concurrent re-syncs and instead using a queue like behavior. This is quite complex issue to solve: - If you have 8 disks in your server, every two are in mirror configuration, you do want to synchronize all the mirrors in parallel. - If you have 2 disks and 4 mirrors configured on partitions from those disks, you want to synchronize them one by one. - If you have UFS file system on a mirror provider, you want to delay synchronization or delay fsck, but don't want them to run together. - Hmm, maybe you have also raid3 configured on the same disks you have mirrors? Basically every mirror is a separate entity and doesn't have any knowledge about the rest of mirrors (or any other GEOM classes). Keeping it that way is a good thing, IMHO. Another thing is that GEOM as an infrastructure doesn't want me to treat some providers as special, ie. I shouldn't care if mirror is configured on plain disks or on partitions. And maybe one component is a disk and one is a partition (it could be useful when one has disks of different sizes). Taking all of this into account, I don't think such logic should be implemented in gmirror itself. I do agree that we should provide some userland (rcNG? daemon?) infrastructure to allow to easly configure order of gmirror synchronization, graid3 synchronization, fsck, gvinum synchronization(?), etc. For example we have those providers: mirror/foo1 (ad0s1 ad1s1) mirror/foo2 (ad0s2 ad1s2) mirror/foo3 (ad0s3 ad1s3) mirror/bar (ad2s1 ad3s1) raid3/baz (ad0s4 ad1s4 ad2s2) We have a daemon (shell script?) runing heavy disk tasks in the given order: fsck:mirror/foo1 fsck:mirror/bar fsck:mirror/foo2 (after fsck:mirror/foo1) fsck:mirror/foo3 (after fsck:mirror/foo2) fsck:raid3/baz (after fsck:mirror/foo2,fsck:mirror/bar) sync:mirror/foo1 (after fsck:raid3/baz) sync:mirror/bar (after fsck:raid3/baz) sync:mirror/foo2 (after sync:mirror/foo1) sync:mirror/foo3 (after sync:mirror/foo2) sync:raid3/baz (after sync:mirror/foo2,sync:mirror/bar) I hope this is easy. I'm also planning to implement some messages which will be passed via devd(8), like 'component X disconnected from Y', 'synchronization of component X in Y finished', etc. which could be helpful for such a daemon. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgppPnabptqya.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sat, Sep 09, 2006 at 01:28:31PM -0500, Karl Denninger wrote: > Yeah, -STABLE is what you should run if you want stable code, right? > > C'mon guys. This sort of thing belies a total lack of concern when changes > are MFC'd into production branches of the code. This kind of thing is > expected if you're running -CURRENT, but not -STABLE. > > How long would it have taken to actually test the change and detect this once > it was put in? All of 30 seconds? Please try to calm down, getting angry on the mailing list is only going to make everyone else angry too. Kris pgpTIX8aPwctO.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Yeah, -STABLE is what you should run if you want stable code, right? C'mon guys. This sort of thing belies a total lack of concern when changes are MFC'd into production branches of the code. This kind of thing is expected if you're running -CURRENT, but not -STABLE. How long would it have taken to actually test the change and detect this once it was put in? All of 30 seconds? -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind On Sat, Sep 09, 2006 at 08:23:10PM +0200, Max Laier wrote: > On Saturday 09 September 2006 19:38, Karl Denninger wrote: > > This is not cool folks. > > Want a refund? > > -- > /"\ Best regards, | [EMAIL PROTECTED] > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] > / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
Oops- mangled reply. On 9/9/06, Matthew Jacob <[EMAIL PROTECTED]> wrote: > > is gone, but a new error message appears as often as the former, > and under the same circumstances: > > > mpt0: QUEUE_FULL: Bus 0x00 Target 0x00 Depth 128 Do you see these all the time? If so I'll have to connect up some logic to take and shut down openings to match the Depth field- although this is a step I've been resisting. Insofar as the Error 22- that's normal to see those for verbose booting. They should be more informative as to why those are occurring. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
is gone, but a new error message appears as often as the former, and under the same circumstances: > mpt0: QUEUE_FULL: Bus 0x00 Target 0x00 Depth 128 -- Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Saturday 09 September 2006 19:38, Karl Denninger wrote: > This is not cool folks. Want a refund? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpabFdsW8NAv.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Hi! On Sat, Sep 09, 2006 at 12:38:13PM -0500, Karl Denninger wrote: > This is not cool folks. > ... I experienced the same problem - luckily on a lab machine. As much as I understand your anger, -stable is not guaranteed bug free. And to answer your question: RELENG_6_1 doesn't show this problem. I recommend running RELENG_X_Y instead of RELENG_X for recent values of X and Y on production systems, anyway. HTH, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
This is not cool folks. Anyone know what I have to roll back to - and what files I have to roll back - to stop this [EMAIL PROTECTED] tty ad4 ad6twed0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 224 453 0.61 0 0.00 120.16 427 50.06 0.61 0 0.00 2 0 4 2 92 See that? There's nothing really running. What I tried to do was "gmirror insert b500 ad4s1" The command took, but NO IO WAS TAKEN TO THE TARGET DRIVE FOR REBUILDING; the SOURCE disk was locked in a 100% I/O run, and after stopping the rebuild THE I/O INFINITE LOOP IS STILL GOING ON! I had a PRODUCTION MACHINE go down on my last night over this when it attempted to run its backup process and wedged due to process table overflow; the first attempt apparently never finished the day before and the second, to a SECOND backup disk (I have a rolling disk backup system using GMIRROR's resync) caused the system to wedge in an I/O wait. This was also not cleanly restartable, as the root partition had multiple error on it that fsck -p couldn't fix. This is a SEVERE emergency in that anyone who has a disk that has to be rebuilt under -STABLE right now (sources as of 7 September) is screwed, blued and tattooed. That PRODUCTION machine is running UNPROTECTED right now (no mirroring) as a consequence of this, and I can neither back it up using the usual mirror NOR restore its redundancy! I see only one comment about GMIRROR changes in the commitlogs since 9/1, and it claims to be (mostly) cosmetic. Obviously not! -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: integer divide fault on 6.1
On Saturday 09 September 2006 13:56, Joao Barros wrote: > Hi, > > I just installed 6.1 on my new (with old parts) machine and when > booting for the first time after installation I got this panic: > > ad0: 19130MB at ata0-master UDMA100 > > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc0853017 > stack pointer = 0x28:0xc0c20b28 > frame pointer = 0x28:0xc0c20bb0 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > trap number = 18 > panic: integer divide fault > cpuid = 0 > Uptime: 1s > Cannot dump. No dump device defined Can you try to get a dump, trace, or at least figure out which function the IP is refering to? > The system is a single Xeon with HTT enabled and the HDD used is > somewhat old. I can try installing on another one. The swapper > process somehow points me to the HDD. > Of course any clues are most welcome. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpCLKuw5e8ob.pgp Description: PGP signature
Re: panic: integer divide fault on 6.1
On 9/9/06, Joao Barros <[EMAIL PROTECTED]> wrote: Hi, I just installed 6.1 on my new (with old parts) machine and when booting for the first time after installation I got this panic: ad0: 19130MB at ata0-master UDMA100 Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc0853017 stack pointer = 0x28:0xc0c20b28 frame pointer = 0x28:0xc0c20bb0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 18 panic: integer divide fault cpuid = 0 Uptime: 1s Cannot dump. No dump device defined The system is a single Xeon with HTT enabled and the HDD used is somewhat old. I can try installing on another one. The swapper process somehow points me to the HDD. Of course any clues are most welcome. I tried disabling the SATA controller, just leaving the PATA part enabled with no success. I even tried disabling HTT and installing on another IDE disk with a UP kernel rather than a SMP one (I'm trying to eliminate variables) The odd thing is that everything runs fine during the installation booting from a CD. Does anyone have an Asus NCCH-DL motherboard successful booting from an IDE disk? -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror RAID-1: rebuilding freezes machine
regarding the gmirror issue, I've seen the following cvs commit: > Revision 1.66.2.9 / (download) - annotate - [select for diffs], Fri Sep 8 > 17:39:41 2006 UTC (20 hours, 35 minutes ago) by pjd > Branch: RELENG_6 > Changes since 1.66.2.8: +5 -12 lines > Diff to previous 1.66.2.8 (colored) to branchpoint 1.66 (colored) next main > 1.67 (colored) > > Back out previous change from RELENG_6. There is a problem with > synchronization with those changes and I need some time to investigate it. I've csup'ed again, rebuild world + kernel and now gmirror sounds fine again and does the syncing. Thanks, pjd for fast fixing! One feature request on gmirror: If a system comes up and more than one mirror is out of sync, currently gmirror tries (in automatic mode) to re-sync all providers at the same time which slows down the system. When gmirror tries to do a resync, it would make sense to do that one by one and not all at the same time as the disk head moves erratically and seek time is wasted time. Because of that I'm now using automatic rebuild mode on the first (root-fs) gmirror slice and will fire a manual re-sync on the others one by one if needed. I guess I'll put that logic in an rc script but gmirror might avoid doing concurrent re-syncs and instead using a queue like behavior. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: suggestions for SATA RAID cards
Mark Kirkwood wrote: Just out of interest what RAID level was the 5 disk array? - as 180Mb/s from an Areca 5 disk RAID0 or RAID5 array is not that good - my old 3Ware 7506 with 4 Maxtor IDE RAID0 gets 175Mb/s. Obviously if your array is RAID10, the 180MB/s is very good! If you are using RAID0|5, then something is slowing you down (possible clash between disk firmware and the Areca, or unfortunate choice of strip chunk size). Dont know which test I was remembering but just did a quicky: OS: FreeBSD 6.1 RAID: 5 on 5 * 400GB Seagate Controller: HighPoint 1820a CPU: Dual Opteron 244 RAM: 2Gb /usr/bin/time -h dd if=/dev/da0 of=/dev/null bs=1048576 count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 44.887239 secs (233602250 bytes/sec) 44.88s real 0.03s user 2.40s sys In comparison: OS: FreeBSD 5.4 RAID: 5 on 6 * 300GB Seagate Controller: Areca 1120 CPU: Dual Opteron 248 RAM: 4Gb /usr/bin/time -h dd if=/dev/da0 of=/dev/null bs=1048576 count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 81.598938 secs (128503633 bytes/sec) 1m21.60s real 0.00s user 2.69s sys So for the money they HighPoint is nothing to be sneezed at. Of course this is a very crude test not comparing totally like for like. Under load the Areca is quicker and has the flexibility of online capacity expansion and raid level migration but... Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: suggestions for SATA RAID cards
Mark Kirkwood wrote: Mark Kirkwood wrote: Obviously if your array is RAID10, the 180MB/s is very good! Also unlikely - RAID10 with 5 disks?? - brain fade - sorry. RAID5 with 5 disks ( 6 with hot swap ). Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: integer divide fault on 6.1
Hi, I just installed 6.1 on my new (with old parts) machine and when booting for the first time after installation I got this panic: ad0: 19130MB at ata0-master UDMA100 Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc0853017 stack pointer = 0x28:0xc0c20b28 frame pointer = 0x28:0xc0c20bb0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 18 panic: integer divide fault cpuid = 0 Uptime: 1s Cannot dump. No dump device defined The system is a single Xeon with HTT enabled and the HDD used is somewhat old. I can try installing on another one. The swapper process somehow points me to the HDD. Of course any clues are most welcome. -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Warning: MFC of security event audit support RELENG_6 in the next 2-3 weeks
On Sat, 2 Sep 2006, Robert Watson wrote: After a couple of weeks of settling, polishing, etc, the MFC of audit support is about to begin. Over the next couple of days, the 6-STABLE build may be briefly broken as inter-dependent components are merged. I do not anticipate any serious disruption, but some caution is called for. In principle, all the potentially tricky kernel ABI dependencies, etc, were dealt with before 6.0-RELEASE, such as changes in the size of the kernel system call data structures. The approximate merge plan, run by re@ a few days ago, is as follows: Just as a status update -- the vast majority of audit code has now been MFC'd to -STABLE. There are a few areas where the merge is not yet complete -- primarily as relates to non-native/emulated/compatibility system calls, and non-i386/amd64 system calls. I anticipate these being merged in the near future. We've also seen a number of problem reports relating to starting the auditd daemon, a problem not seen during testing on -CURRENT, so we're working on debugging that, and we've found some bugs in audit log rotation. I'm currently travelling for a few days, but will follow up when I get back to the UK on Tuesday on where things stand, and what (if any) further changes are in the pipeline. Once these problems are fixed, it sounds like we're well on track to ship with audit as a 6.2 (experimental) feature. thanks, Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: suggestions for SATA RAID cards
Mark Kirkwood wrote: Obviously if your array is RAID10, the 180MB/s is very good! Also unlikely - RAID10 with 5 disks?? - brain fade - sorry. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Symbolic Links in /dev of a jail
On 6. sep. 2006, at 18.03, Anish Mistry wrote: Previously posted to -questions: In my quest to get asterisk+iaxmodem+hylafax working together in a jail I've run into one final roadblock. I can't seem to figure out how to create a symbolic link (ln -s doesn't work) in /dev in the jail environment while in the jailed environment. When trying to create a link with ln I receive: ln -s somedev targetdev ln: targetdev: Operation not permitted Adding a link entry to devfs.conf in the jail fails too since it receives the same error. I can create a link in the jailed /dev from the host environment, so there seems to be some restriction on creating links in /dev while in the jail. The reason I need to be able to do this is that iaxmodem needs to create a /dev/ttyIAX device to point to the correct ttyp* device when it starts in the jail. Any suggestions would be appreciated. Have you tried to change the devfs ruleset? Try to boot up a jail without any devfs restrictions and see if your devfs.conf alias works then. Search for jail_example_devfs in /etc/defaults/rc.conf, and have a look at /etc/defaults/devfs.rules. I guess specifying jail_example_devfs_ruleset="" is enough to disable the rules. If you succeed, you will need to find some way of enforcing rules, but allowing what you want. Running a jail without devfs rules gives the jail too much access to the system. -- Frode Nordahl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
