Re: How is the patchlevel set?
On 06/30/05 15:47, lars wrote: I can't seem to find out how the patchlevel is set. Is it incremented with each SA's patch, kernel or world, or only kernel or only world? Could anyone point me to some documentation by the FreeBSD project? I know this is the stable list, but I don't want to subscribe to one more list just for this question. The patch level is set in src/sys/conf/newvers.sh. I believe this means that it is only updated after rebuilding the kernel (see 'sysctl kern.version'). I have often applied patches from Security Advisories and rebuilt only what was necessary instead of world/kernel. With a userland vulnerability, this is often the most expedient and unintrusive method. However, the new patch level is not set this way so you have to document the update for yourself. On client machines I sometimes do the full world/kernel rebuild and schedule a reboot just to avoid questions about whether the machine is up-to-date. -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
Re: named coredumping
On Thu, Jun 30, 2005 at 12:57:32PM -0500, Doug Barton wrote: D FYI, I had a chat with the ISC folks this week, and they said in clear terms D that enabling threads on current versions of BIND would be a pessimization. D I have already turned off threads in the port of 9.3.1, and am looking at D doing that for the base as well. D D Could you give the port a try for now (with or without the option to D overwrite the base system BIND), and let me know if that helps/solves your D problems? I'll rebuild base bind with threads disabled, and report after a week. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with 5.x
Hi Matt, On Thu, 2005-Jun-30 11:57:38 -0400, Matt Emmerton wrote: First, I tried to install 5.2. Booting from CD, BTX would halt with a register dump. There are some people around who can read BTX dumps. Any chance of you posting it? The CD boot mode was changed from floppy emulation mode in 4.x to no emulation mode in 5.x (for slightly more details, see the '-b' and '-no-emul-boot' options to mkisofs). At a guess, it looks like your BIOS doesn't handle the latter very well. My two suggestions are: 1) A BIOS upgrade. If your BIOS is flashable, check out the vendor's website. 2) Boot from physical floppies. The images are in the 'floppies' directory on the CD-ROM. I presume you've satisfied yourself that the CD-ROMs aren't corrupt. (Unlikely but possible). You might have to experiment with dis/enabling ACPI to get things working. Next, I installed 4.10 (which installs fine) and tried to cvsup to -stable, but had problems with buildworld. Generally, upgrading to version N from version N-1 is only supported from the latest version of N-1, so you might need to upgrade your 4.10 system to 4-STABLE first. Alternatively, you will need to post more details (cut-and-paste) of the errors you are getting. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Jails that won't die...
On Tuesday 28 June 2005 09:37, Eirik Øverby wrote: Hi, I have, since upgrading to 5.x and updating my management tools, seen a number of problems relating to stopping jails. I'm maintaining several hosts with a number of full-featured jails (i.e. full virtual FreeBSD installations in each jail), and in general this works fine. However, whenever I stop a jail using 'jexec id kill -SIGNAL -1' or 'jexec id /bin/sh /etc/rc.shutdown' (in various combinations), jails have a tendency to stick around for minutes or hours - according to 'jls'. Often I see an entry in 'netstat -a' indicating that there is one or more sockets in FIN_WAIT state, preventing the jail from coming down. Taking the virtual network interface (alias) down does not help. All I can do at this point is wait. You could use tcpdrop(8) to close them? That might be enough to kick the jail out. I normally use 'jls' to determine whether or not a jail can be restarted (i.e. it's not running), but this is pretty useless in such cases. And right now I have a case where 'netstat -a' shows me nothing pertaining to the jail, though it has no processes running. I have therefore force-started the jail again, which seems to work nicely, but now 'jls' gives me two entries for this jail, with different JIDs. What am I doing wrong here? /Eirik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] HTH, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in RELENG_5 UMA - two new stack traces
On Tue, Jun 28, 2005 at 11:24:47AM -0400, Gary Mu1der wrote: G I spent the day yesterday trying to reproduce the crash that I posted G last week and you kindly replied to. This is due to the fact that I G stupidly managed to overwrite the kernel.debug that I used to generate G the stack trace. Sadly I could not cause the system to crash again with G the same sb* errors. G G I did however remove both the Berkley Packet Filter and IPFilter from my G custom kernel to try and isolate the problem. This has caused the crash G to occur in a different and more reproducible form. I have both G INVARIANTS and WITNESS enabled, as you can see from my kernel conf. G which is included at the end of this e-mail. G G Below are the latest stack traces (using bge and then fxp NICs), kernel G conf. and dmesg. Any help would be appreciated. This time I have a copy G of both the core files and corresponding kernel.debug so I can hopefully G provide you with any info you need. How often does it crash? Does debug.mpsafenet=0 increases stability? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: init: can't exec getty 'none' for port /dev/console: No such file or directory
On Fri, 2005-Jul-01 08:23:52 +0300, Bashar wrote: i noticed one of my boxes had the message init: can't exec getty 'none' for port /dev/console: No such file or directory into messages and repeating forever. You should have the following line in /etc/ttys: console noneunknown off secure The only change you can validly make to this line is to change 'secure' to 'insecure' but I suspect you've changed 'off' to 'on'. Try turning the console back off and sending a SIGHUP to init. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 with FreeBSD 5.4
I suppose the question is was there a problem with the Tyan S5350 motherboard and its ATA controller - I know that two identical motherboards with different hard disks exhibit the same problem. And if so why is it that there has been little on these lists about problems with the chipset which is on this motherboard (a fairly common one I believe from Intel). Although the problem went away the machines filesystem seems to have got corrupted so maybe all was not fixed after all. There have been a number of comments and queries about ATA problems and SATA problems with 5.4 but no views as to if this is a real problem. Any insights would be gratefully received. One aside when trying to upgrade using CVSUP does the tag need to be RELENG_5 or RELENG_5_4? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Today's RELENG_5_4 and 'lock cmpxchgl'
Somehow, this sounds familiar, i.e.: the lock cmpxchgl: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc05160c3 stack pointer = 0x10:0xebf499ac frame pointer = 0x10:0xebf499b8 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 = 1299 (screen) [thread pid 1299 tid 100428 ] Stopped at 0xc05160c3 = knote+0x27:lock cmpxchgl %ecx,0x1c(%edx) db tr Tracing pid 1299 tid 100428 td 0xc670cc00 knote(c5fdde80,0,0,c5fdde10,c5fdde00) at 0xc05160c3 = knote+0x27 ttwakeup(c5fdde00,c5fdde00,c5fdde00,c5f93000,ebf49a04) at 0xc0560ad9 = ttwakeup+0x65 ttymodem(c5fdde00,1) at 0xc055f73c = ttymodem+0x170 ptcopen(c5f93000,3,2000,c670cc00,c0717d40) at 0xc0563427 = ptcopen+0x63 spec_open(ebf49a70,ebf49b2c,c05913f9,ebf49a70,180) at 0xc04f4f82 = spec_open+0x2b6 spec_vnoperate(ebf49a70) at 0xc04f4cc7 = spec_vnoperate+0x13 vn_open_cred(ebf49bd4,ebf49cd4,0,c6614900,5) at 0xc05913f9 = vn_open_cred+0x419 vn_open(ebf49bd4,ebf49cd4,0,5,58) at 0xc0590fde = vn_open+0x1e kern_open(c670cc00,bfbfdf40,0,3,0) at 0xc058af5b = kern_open+0xeb open(c670cc00,ebf49d04,3,0,292) at 0xc058ae6c = open+0x18 syscall(bfbf002f,2f,bfbf002f,,28104c2d) at 0xc069e5e3 = syscall+0x2b3 Xint0x80_syscall() at 0xc068d2ff = Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x2816c7bb, esp = 0xbfbfdf0c, ebp = 0xbfbfdf68 --- What am I doing wrong ? It's an SMP dual Xeon machine. Same kernel config as I used on my older kernels that didn't crash though... Marc pgp2JEex7NytX.pgp Description: PGP signature
Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 with FreeBSD 5.4
Hello Alan, AJ There have been a number of comments and queries about ATA problems and SATA AJ problems with 5.4 but no views as to if this is a real problem. I have to agree. I've had nothing but trouble with various Intel boards with Intel ICH5 controllers and SATA hard disks under FreeBSD and yet the problem either doesn't seem to be widespread and isn't recognized by the community in general. I find that strange since the ICH5 must be common in the field along with SATA disks from Western Digital. I would have believed faulty hardware to be the cause, but I have *three* machines that are capable of generating DMA TIMEOUTs while reading or writing SATA disks. Regards, Tony. -- Tony Byrne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Fri, Jul 01, 2005 at 12:14:58PM +0200, Marc Olzheim wrote: Somehow, this sounds familiar, i.e.: the lock cmpxchgl: Fatal trap 12: page fault while in kernel mode ... Stopped at 0xc05160c3 = knote+0x27:lock cmpxchgl %ecx,0x1c(%edx) Somehow I think I solved this last time by activating 'INVARIANTS'... I'll try that now. Marc pgpdLf31AfdGk.pgp Description: PGP signature
Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 with FreeBSD 5.4
Tony Byrne [EMAIL PROTECTED] writes: ICH5 must be common in the field along with SATA disks from Western Digital. I would have believed faulty hardware to be the cause, but I have *three* machines that are capable of generating DMA TIMEOUTs while reading or writing SATA disks. In my case here, it's ICH6 and Seagate. Normally this is a good combination that should work flawlessly... I mean, you can't get more conservative than an Intel chipset and a Seagate disk. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ndis no longer detects netgear wg311v2
FWIW, I am having the *exact* same problem starting today. I hadn't updated my STABLE machine since April. NDIS was working fine (save a frew crashes) before I updated last night.. and now NDIS will not even talk about the card. There is also a slight freeze on the machine after the if_ndis module is loaded. I will do some more investigating, but now there's at least two of us. Did you ever find a fix? On 6/19/05, Evan Dower [EMAIL PROTECTED] wrote: I recently moved, and for some reason my computer started crashing when I tried to make it associate with my new wireless network. (It worked fine on the old wireless network.) I figured the first thing I should do to fix the problem is update my sources, since it may have already been fixed. Unfortunately the updated sources don't recognize my wireless card at all. Before the update (hand-transcribed): # uname -a FreeBSD lojak.washington.edu 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #0: Sat Apr 2 11:50:53 PST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CUSTOM i386 # kldload FwRad16.bin.ko # kldload ndis # kldload if_ndis ndis0: NETGEAR WG311v2 802.11g Wireless PCI Adapter mem 0xfb02-0xfb03,0xfb04-0xfb041fff irq 16 at device 4.0 on pci2 ndis0: NDIS API version: 5.1 ndis0: Ethernet address: 00:09:5b:ba:da:ef ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps # ifconfig ndis0 ndis0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 ether 00:09:5b:da:ef media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid channel -1 authmode OPEN powersavemode OFF powersavesleep 100 rtsthreshold 2312 protmode CTS wepmode OFF weptxkey 1 # wicontrol ndis0 -l 0 stations: # ifconfig ndis0 ssid The Penthouse channel 11 up ndis0: link up # dhclient ndis0 ndis0: link up I can't see the whole panic screen, but here's the bottom: panic: page fault cpuid = 0 boot() called on cpu#0 Uptime: 11m20s Dumping 1023 MB Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address= 0x0 fault code = supervisor read, page not present intruction pointer = 0x8:0x0 stack pointer= 0x10:0xe4e1fcec frame pointer= 0x10:0xe4e1fd0c 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 = 5 (thread taskq) trap number = 12 I can work on getting the crash dump if that's useful, but the behavior seems to have changed in the last couple of months. Now I get: # uname -a FreeBSD lojak.washington.edu 5.4-STABLE FreeBSD 5.4-STABLE #0: Sat Jun 14:20:40 PDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CUSTOM i386 # kldload FwRad16.bin.ko # kldload ndis warning: KLD '/boot/kernel/if_ndis.ko' is newer than the linker.hints file # kldload if_ndis kldload: can't load if_ndis: File exists # kldstat Id Refs AddressSize Name 1 10 0xc040 4a42f0 kernel 2 14 0xc08a5000 56270acpi.ko 31 0xc2e83000 14000FwRad16.bin.ko 41 0xc2e97000 9000 if_ndis.ko 51 0xc2ea 12000ndis.ko 61 0xc2ec5000 b000 pccard.ko # ifconfig ndis0 ifconfig: interface ndis0 does not exist # kldunload if_ndis # kldload if_ndis # ifconfig ndis0 ifconfig: interface ndis0 does not exist I haven't seen anything in UPDATING that accounts for this. Does anyone have any idea of where to look for clues? Thanks very much, -- Evan Dower Software Development Engineer Amazon.com, Inc. Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Phil Bowens He who is the greatest of warriors overcomes and subdues himself. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ndis no longer detects netgear wg311v2
On 1 Jul, Phil Bowens wrote: FWIW, I am having the *exact* same problem starting today. I hadn't updated my STABLE machine since April. NDIS was working fine (save a frew crashes) before I updated last night.. and now NDIS will not even talk about the card. There is also a slight freeze on the machine after the if_ndis module is loaded. I will do some more investigating, but now there's at least two of us. Did you ever find a fix? I had a similar problem with a recent system update two days ago. I noticed that the if_ndis.ko was half smaller and there was not any reference to my NIC anymore. After a few search I noticed that ndisgen is a tool able to generate a specific loadable module based on .inf and .sys. So I used ndisgen, copied the generated ko to /boot/kernel and manually kldload it : my NIC was back. Unfortunately, I haven't been able to find a good resource about the correct procedure to generate the module but I have a bigger problem than this one at the moment :( Hope that helps. Phil. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Fri, Jul 01, 2005 at 12:41:39PM +0200, Marc Olzheim wrote: On Fri, Jul 01, 2005 at 12:14:58PM +0200, Marc Olzheim wrote: Somehow, this sounds familiar, i.e.: the lock cmpxchgl: Fatal trap 12: page fault while in kernel mode ... Stopped at 0xc05160c3 = knote+0x27:lock cmpxchgl %ecx,0x1c(%edx) Somehow I think I solved this last time by activating 'INVARIANTS'... I'll try that now. Let's paraphrase: I think i solved this last time by activating 'INVARIANTS'... Anyway, tried that and yes, it didn't crash in the last few hours, so I guess it works. Without INVARIANTS, it crashed within seconds. On the downside, my Gigabit performance dropped from 99 MB/sec to 80 MB/sec because of INVARIANTS. Marc pgpuGTS7uzdRi.pgp Description: PGP signature
Possible exploit in 5.4-STABLE
Hi all, My site has been cracked yesterday (don't worry it's not about that) and the cracker uploaded a script to delete stuff. Anyway, not important. The script contained a link to a russian site. This site, of course (almost) completely in Russian, had a file to gain root access with a modified su utility. It's maybe not so useful for me to attach the binary, but I'll do it anyway because I don't have anything else but that and a readme file. It didn't seem to work (out of the box) with 5.4-RELEASE though. This is a translation from babelfish: Plain replacement of standard su for FreeBSD. It makes it possible to become any user (inc. root) with the introduction of any password. For this necessary to neglect su with the option -!. with the use of this option does not conduct ravine- files. Was tested on FreeBSD 5.4-STABLE. My apologies if I am sending in something completely useless and not important, but I figured it wouldn't hurt just to make sure. Cheers, Jorn. su.tgz Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 with FreeBSD 5.4 (Adaptec AIC-8110 Compatibility maybe?)
Totally agree - I have 2 idential machines that have the same problem And have tried alternate hard disks all of which exhibit the same Problem. I would agree with you that the ICH5 must be common and the Tyan S3530 (http://www.tyan.com/products/html/tigeri7320r_spec.html ) with the Intel 6300SEB which I would have thought (as you say) was very common. I did notice that Tyan offer the Adaptec AIC-8110 SATA I controller as an add on module and I wondered if that might be supported but it doesn't seem by that number to be on the release list (any thoughts). -Original Message- From: Tony Byrne [mailto:[EMAIL PROTECTED] Sent: Friday, July 01, 2005 11:29 AM To: Alan Jay Cc: freebsd-stable@freebsd.org Subject: Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 with FreeBSD 5.4 Hello Alan, AJ There have been a number of comments and queries about ATA problems and SATA AJ problems with 5.4 but no views as to if this is a real problem. I have to agree. I've had nothing but trouble with various Intel boards with Intel ICH5 controllers and SATA hard disks under FreeBSD and yet the problem either doesn't seem to be widespread and isn't recognized by the community in general. I find that strange since the ICH5 must be common in the field along with SATA disks from Western Digital. I would have believed faulty hardware to be the cause, but I have *three* machines that are capable of generating DMA TIMEOUTs while reading or writing SATA disks. Regards, Tony. -- Tony Byrne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible exploit in 5.4-STABLE
Argelo, Jorn [EMAIL PROTECTED] wrote: [...] This site, of course (almost) completely in Russian, had a file to gain root access with a modified su utility. [...] This is a translation from babelfish: Plain replacement of standard su for FreeBSD. It makes it possible to become any user (inc. root) with the introduction of any password. For this necessary to neglect su with the option -!. with the use of this option does not conduct ravine- files. Was tested on FreeBSD 5.4-STABLE. To install such a modified su utility, you need to be root anyway. So this is not an exploit. It could be useful to install hidden backdoors on cracked machines, though, as part of a root kit or similar. You could achieve the same effect by copying /bin/sh to some hidden place and make it setuid- root (which also requires root priviledges in the first place). The advantage of a modified su utility is the fact that su(1) is setuid-root anyway, so it might be more difficult to detect the backdoor. However -- In both cases the modified suid binary should be found and reported by the nightly security cronjob, unless you also modify find(1) and/or other utilities. This is a very good reason to actually _read_ the nightly cron output instead of deleting it immediately or forwar- ding it to /dev/null. ;-) (Also, local IDS tools like tripwire or mtree might be useful for such cases, too.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 with FreeBSD 5.4
I thought that as well. My machine is using a Tyan motherbaord with the Intel 6300SEB and I thought that was a reasnably conservative choice of motherboard. I don't know if this is a hint not to use SATA/IDE controllers any more but there are lots of occasions when it is more than enough power to be going on with. What is annoying is that there doesn't seem to be enough in the way of problem reports to say this is not supported so we know we are on to a loosing streak and need to find an alternate type of hardware. Does anyone know if the Adaptec AIC-8110 SATA I controller, which Tyan offer, as an add on module is supported. The release notes which I have checked do not mention this number. But hten this is probably a part number and not the chip number. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Buelow Sent: Friday, July 01, 2005 12:49 PM To: Tony Byrne Cc: Alan Jay; freebsd-stable@freebsd.org Subject: Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 with FreeBSD 5.4 Tony Byrne [EMAIL PROTECTED] writes: ICH5 must be common in the field along with SATA disks from Western Digital. I would have believed faulty hardware to be the cause, but I have *three* machines that are capable of generating DMA TIMEOUTs while reading or writing SATA disks. In my case here, it's ICH6 and Seagate. Normally this is a good combination that should work flawlessly... I mean, you can't get more conservative than an Intel chipset and a Seagate disk. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible exploit in 5.4-STABLE
[skip] to attach the binary, but I'll do it anyway because I don't have anything else but that and a readme file. It didn't seem to work (out of the box) with 5.4-RELEASE though. This is a translation from babelfish: Plain replacement of standard su for FreeBSD. It makes it possible to become any user (inc. root) with the introduction of any password. For this necessary to neglect su with the option -!. with the use of this option does not conduct ravine- files. Was tested on FreeBSD 5.4-STABLE. My apologies if I am sending in something completely useless and not important, but I figured it wouldn't hurt just to make sure. Cheers, The attached file needs to be setuid to root, so, someone needed to have increased privileges before, in order to install this prg. In this case a one-line C program w/ root setuid would do the same job. -- Patrick Tracanelli patrick @ freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fatal trap 12 in pagedaemon on dual-core opteron machine
On Thu, 30 Jun 2005, Kris Kennaway wrote:
On Thu, Jun 30, 2005 at 04:00:47PM -0400, Rob Watt wrote:
#7 0x80400c0b in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:171
#8 0xff007c3b00f0 in ?? ()
#9 0xff007b78c500 in ?? ()
#10 0x0001840f in ?? ()
#11 0x in ?? ()
#12 0x in ?? ()
[..]
All these bogus stack frames can be caused by having compiled the
kernel with -O2 instead of -O. Is this the case?
It seems the default for amd64 is to compile with:
COPTFLAGS=-O2 -frename-registers -pipe
I changed the -O2 to -O, and there are still a large number of bogus stack
frames (although there are more readable frames then before):
#0 doadump () at pcpu.h:167
#1 0x in ?? ()
#2 0x802aca23 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:410
#3 0x802ace8b in panic (fmt=0xff007b78c500 \u\022y{) at
/usr/src/sys/kern/kern_shutdown.c:566
#4 0x804275bc in trap_fatal (frame=0xff007b78c500,
eva=18446742976269456104)
at /usr/src/sys/amd64/amd64/trap.c:639
#5 0x80427220 in trap_pfault (frame=0xb1c129c0,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:562
#6 0x80426e99 in trap (frame=
{tf_rdi = -1097427386128, tf_rsi = -1097440115456, tf_rdx = 100956,
tf_rcx = 0, tf_r8 = 0, tf_r9 = 0, tf_rax = 100956, tf_rbx = 0, tf_rbp =
-1098510893056, tf_r10 = 30, tf_r11 = 29, tf_r12 = -1097364252160, tf_r13
= -2143265920, tf_r14 = 0, tf_r15 = -2141262160, tf_trapno = 12, tf_addr =
136, tf_flags = 0, tf_err = 0, tf_rip = -2144628916, tf_cs = 8, tf_rflags
= 66050, tf_rsp = -1312740736, tf_ss = 16}) at
/usr/src/sys/amd64/amd64/trap.c:341
#7 0x80413c5b in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:171
#8 0xff007c3b00f0 in ?? ()
#9 0xff007b78c500 in ?? ()
#10 0x00018a5c in ?? ()
#11 0x in ?? ()
#12 0x in ?? ()
#13 0x in ?? ()
#14 0x00018a5c in ?? ()
#15 0x in ?? ()
#16 0xff003ba6 in ?? ()
#17 0x001e in ?? ()
#18 0x001d in ?? ()
#19 0xff007ffe5a00 in ?? ()
#20 0x80405b80 in vm_pageout_page_stats () at
/usr/src/sys/vm/vm_pageout.c:1350
#21 0x in ?? ()
#22 0x805eeeb0 in sysctl___kern_sched_runq_fuzz ()
#23 0x000c in ?? ()
#24 0x0088 in ?? ()
#25 0x in ?? ()
#26 0x in ?? ()
#27 0x802b8f4c in thread_fini (mem=0x0, size=0) at
/usr/src/sys/kern/kern_thread.c:271
#28 0x0010 in ?? ()
#29 0xff007ffe4620 in ?? ()
#30 0x in ?? ()
#31 0xff003ba60f98 in ?? ()
#32 0x80407a41 in zone_drain (zone=0x10202) at
/usr/src/sys/vm/uma_core.c:749
#33 0x80408ed6 in zone_foreach (zfunc=0x80407810
zone_drain) at /usr/src/sys/vm/uma_core.c:1494
#34 0x8040acb5 in uma_reclaim () at
/usr/src/sys/vm/uma_core.c:2623
#35 0x80404836 in vm_pageout_scan (pass=0) at
/usr/src/sys/vm/vm_pageout.c:674
#36 0x80405f1e in vm_pageout () at
/usr/src/sys/vm/vm_pageout.c:1476
#37 0x80292e4b in fork_exit (callout=0x80405b80
vm_pageout, arg=0x0, frame=0xb1c12c50)
at /usr/src/sys/kern/kern_fork.c:791
#38 0x80413e5e in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:296
#39 0x in ?? ()
#40 0x in ?? ()
#41 0x0001 in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x in ?? ()
#47 0x in ?? ()
#48 0x in ?? ()
#49 0x in ?? ()
#50 0x in ?? ()
#51 0x in ?? ()
#52 0x in ?? ()
#53 0x in ?? ()
#54 0x in ?? ()
#55 0x in ?? ()
#56 0x in ?? ()
#57 0x in ?? ()
#58 0x in ?? ()
#59 0x in ?? ()
#60 0x in ?? ()
#61 0x in ?? ()
#62 0x in ?? ()
#63 0x in ?? ()
#64 0x in ?? ()
#65 0x in ?? ()
#66 0x in ?? ()
#67 0x in ?? ()
#68 0x in ?? ()
#69 0x in ?? ()
#70 0x in ?? ()
#71 0x0081e000 in ?? ()
#72 0x806457f4 in vm_page_max_wired ()
#73 0x in ?? ()
#74 0x0001 in ?? ()
#75 0xff007b7912e8 in ?? ()
#76 0xff007b7f5000 in ?? ()
#77 0xb1c12ae8 in ?? ()
#78 0xff007b78c500 in ?? ()
#79 0x802c0c84 in sched_switch (td=0x0, newtd=0x0, flags=1) at
/usr/src/sys/kern/sched_4bsd.c:881
...
-
Rob Watt
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL
SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350
Further to this the same ATA Timeout is seen in the latest SNAP binaries (1st July). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Port build issue mod_auth_kerb - 5.4-Stable
Hi, I'm trying to build /usr/ports/www/mod_auth_kerb, and I'm hitting the following error (full build script attached): + libtool15 --mode=link cc -shared -o libkrb5support.so.0 threads.so fake-addrinfo.so -R/usr/local/lib libtool15: link: unable to infer tagged configuration libtool15: link: specify a tag with `--tag' gmake[2]: *** [libkrb5support.so.0] Error 1 gmake[2]: Leaving directory `/usr/ports/security/krb5/work/krb5-1.4.1/src/util/support' gmake[1]: *** [all-recurse] Error 1 gmake[1]: Leaving directory `/usr/ports/security/krb5/work/krb5-1.4.1/src/util' gmake: *** [all-recurse] Error 1 *** Error code 2 Stop in /usr/ports/security/krb5. *** Error code 1 Stop in /usr/ports/www/mod_auth_kerb. This is on a freshly built system: FreeBSD ruby.breakawayltd.com 5.4-STABLE FreeBSD 5.4-STABLE #2: Wed Jun 29 16:12:10 EDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/RUBY i386 Based on some messages with similar symptoms I've rebuilt every ports, including libtool15 from scratch and done a complete system rebuild to no effect. Any pointers would be appreciated. Thanks in advance, --- Mark Thomas - IT Manager - BreakAway, Ltd. [EMAIL PROTECTED] make.txt.gz Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350
On Friday 01 July 2005 16:34, Alan Jay wrote: Further to this the same ATA Timeout is seen in the latest SNAP binaries (1st July). Do you see them with ATA mkIII as well? http://people.freebsd.org/~sos/ATA/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] HTH, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
geom nudge
I have SanDisk SDDR-75 usb dual card reader (CF and SM) detected by FreeBSD as SanDisk ImageMate CF-SM 0100. There is some minor annoyance/oddity while using it that I would like to talk about. It seems that the device needs a few seconds (up to 5) after plugging in to settle in normal operating state. Apparently current code is not a good friend of such retarded devices. umass-cam-geom detection sequence does not seem to have sufficient delays and retries to wait for such a long initialization. This is what I am getting in logs: umass0: SanDisk Corporation ImageMate CF-SM, rev 1.10/1.00, addr 2 umass0:0:0:-1: Attached to scbus0 pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: SanDisk ImageMate CF-SM 0100 Removable Direct Access SCSI-0 device pass0: Serial Number pass0: 1.000MB/s transfers GEOM: new disk da0 (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk ImageMate CF-SM 0100 Removable Direct Access SCSI-0 device da0: Serial Number da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present Unretryable error (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present Unretryable error (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 - 6 If I understand the messages and the code correctly, geom created a new disk and tried to do subsequent magic stuff starting with querying medium size, but that operation failed because of the said retardness. If I execute this command: camcontrol cmd 2:0:0 -v -c 25 00 00 00 00 00 00 00 00 00 -i 8 i4 i4 in a loop with 1 second sleep, I see that READ CAPACITY fails for 3-5 seconds but then it works correctly. I am actually OK with such situation. The problem is that the only device created is obviously da0 i.e. there are no devices for slices present on medium. So, when the card reader comes to senses I would like to give a nudge to geom to re-scan or re-create da0. So far I have failed to find a nice way to do it. camcontrol rescan and reset do not help. The only thing that works is trying to mount /dev/da0, that obviously fails but makes geom take a new look at the disk: $ mount_msdosfs /dev/da0 /mnt/flash mount_msdosfs: /dev/da0: Invalid argument (note: mount ufs does it as well but with different error message) $ ls -1 /dev/da* /dev/da0 /dev/da0s1 /dev/da0s1s4 this is what I get in logs: (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed Retrying Command (per Sense Data) (da0:umass-sim0:0:0:0): Retrying Command [0] f:80 typ:6 s(CHS):0/1/1 e(CHS):982/15/32 s:32 l:503264 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da0s1, start 16384 length 257671168 end 257687551 [0] f:20 typ:32 s(CHS):356/97/46 e(CHS):357/116/40 s:1919950958 l:544437093 [1] f:61 typ:107 s(CHS):288/110/57 e(CHS):269/101/57 s:1330184202 l:538976288 [2] f:20 typ:83 s(CHS):345/32/19 e(CHS):324/77/19 s:538989391 l:1398362912 [3] f:80 typ:73 s(CHS):87/1/0 e(CHS):335/78/2 s:1394627663 l:21337 GEOM: Configure da0s1s4, start 714049363456 length 10924544 end 714060287999 As you can see, there is an oddity to this operation - what is the da0s1s4 ? CF card has only one DOS filesystem and da0s1 works well, da0s1s4 produces error on any access attempt and its name is very weird. Anyway, my main question is - is there any nice way to tell geom to re-evaluate a disk ? My secondary question is - is it possible to make geom(/cam?) try harder to query disk than its current single-shot effort ? My tertiary question
Re[2]: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350
Hello Dominic, DM Do you see them with ATA mkIII as well? I tried the ATA mkIII patches a few weeks ago on one of servers, which was suffering DMA TIMEOUTs, but they made no difference. This problem may only occur with certain combinations of controller and SATA hard drive. For example, I have a workstation with an ICH5 controller which had been frequently emitting TIMEOUT messages when it had a 80Gb 7200k Seagate Barracuda SATA drive installed. As a test this afternoon, I swapped out the Seagate for a new 250Gb Western Digital SATA drive, and installed 5.4 RELEASE. The machine is now in the process of building world, and I've yet to see any TIMEOUTs. Regards, Tony. -- Tony Byrne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350
Thanks for this - I haven't try but will do so - but I do need a little help. I have downloaded the STABLE version and put it onto my machines. Do I have to compile the ATA driver into the system and if so how do I do so (sorry to ask no instructions on the web site below). Thanks. -Original Message- From: Dominic Marks [mailto:[EMAIL PROTECTED] Sent: Friday, July 01, 2005 5:00 PM To: freebsd-stable@freebsd.org; [EMAIL PROTECTED] Subject: Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 On Friday 01 July 2005 16:34, Alan Jay wrote: Further to this the same ATA Timeout is seen in the latest SNAP binaries (1st July). Do you see them with ATA mkIII as well? http://people.freebsd.org/~sos/ATA/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] HTH, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How is the patchlevel set?
Thanks guys.
It seems
src/sys/conf/newvers.sh
is only triggered by a recompilation of the kernel,
at least the lines
i=`${MAKE:-make} -V KERN_IDENT`
and
char kern_ident[] = ${i};
make me believe that.
I also try to cvsup my src and recompile the kernel and world
in one go instead of only patching and recompiling the subsystem,
since that bumps the patchlevel and keeps all synchronised.
That's not possible in all scenarios, of course.
Again thanks for the answers, but how did you find that out?
Kind regards,
lars.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible exploit in 5.4-STABLE
Oliver Fromme wrote: Argelo, Jorn [EMAIL PROTECTED] wrote: [...] This site, of course (almost) completely in Russian, had a file to gain root access with a modified su utility. [...] This is a translation from babelfish: Plain replacement of standard su for FreeBSD. It makes it possible to become any user (inc. root) with the introduction of any password. For this necessary to neglect su with the option -!. with the use of this option does not conduct ravine- files. Was tested on FreeBSD 5.4-STABLE. To install such a modified su utility, you need to be root anyway. So this is not an exploit. It could be useful to install hidden backdoors on cracked machines, though, as part of a root kit or similar. You could achieve the same effect by copying /bin/sh to some hidden place and make it setuid- root (which also requires root priviledges in the first place). The advantage of a modified su utility is the fact that su(1) is setuid-root anyway, so it might be more difficult to detect the backdoor. However -- In both cases the modified suid binary should be found and reported by the nightly security cronjob, unless you also modify find(1) and/or other utilities. This is a very good reason to actually _read_ the nightly cron output instead of deleting it immediately or forwar- ding it to /dev/null. ;-) (Also, local IDS tools like tripwire or mtree might be useful for such cases, too.) Best regards Oliver Thank you for clearing this up Oliver. I just wanted to make sure it's a harmless thing. Better safe then sorry ;) Cheers, Jorn. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: geom nudge
In message [EMAIL PROTECTED], Andriy Gapon writes: I am actually OK with such situation. The problem is that the only device created is obviously da0 i.e. there are no devices for slices present on medium. So, when the card reader comes to senses I would like to give a nudge to geom to re-scan or re-create da0. true /dev/da0 will do it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Re[2]: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350
Tony, Interesting that you have seen different disks producing different timeout issues (or not) so far on my experiments with 4 different disks 2 SATA 2 IDE (different dises) is that the timeout error has appears on all of them. Regads ALan -Original Message- From: Tony Byrne [mailto:[EMAIL PROTECTED] Sent: Friday, July 01, 2005 5:12 PM To: Dominic Marks Cc: freebsd-stable@freebsd.org; [EMAIL PROTECTED] Subject: Re[2]: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 Hello Dominic, DM Do you see them with ATA mkIII as well? I tried the ATA mkIII patches a few weeks ago on one of servers, which was suffering DMA TIMEOUTs, but they made no difference. This problem may only occur with certain combinations of controller and SATA hard drive. For example, I have a workstation with an ICH5 controller which had been frequently emitting TIMEOUT messages when it had a 80Gb 7200k Seagate Barracuda SATA drive installed. As a test this afternoon, I swapped out the Seagate for a new 250Gb Western Digital SATA drive, and installed 5.4 RELEASE. The machine is now in the process of building world, and I've yet to see any TIMEOUTs. Regards, Tony. -- Tony Byrne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: init: can't exec getty 'none' for port /dev/console: No such file or directory
True its set to on, but i believe this change was requested from the DC to enable the remote console for the box. would turning it off effect the remote console from working? Peter Jeremy wrote: On Fri, 2005-Jul-01 08:23:52 +0300, Bashar wrote: i noticed one of my boxes had the message init: can't exec getty 'none' for port /dev/console: No such file or directory into messages and repeating forever. You should have the following line in /etc/ttys: console noneunknown off secure The only change you can validly make to this line is to change 'secure' to 'insecure' but I suspect you've changed 'off' to 'on'. Try turning the console back off and sending a SIGHUP to init. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in RELENG_5 UMA - two new stack traces
Gleb Smirnoff wrote: On Tue, Jun 28, 2005 at 11:24:47AM -0400, Gary Mu1der wrote: G I spent the day yesterday trying to reproduce the crash that I posted G last week and you kindly replied to. This is due to the fact that I G stupidly managed to overwrite the kernel.debug that I used to generate G the stack trace. Sadly I could not cause the system to crash again with G the same sb* errors. G G I did however remove both the Berkley Packet Filter and IPFilter from my G custom kernel to try and isolate the problem. This has caused the crash G to occur in a different and more reproducible form. I have both G INVARIANTS and WITNESS enabled, as you can see from my kernel conf. G which is included at the end of this e-mail. G G Below are the latest stack traces (using bge and then fxp NICs), kernel G conf. and dmesg. Any help would be appreciated. This time I have a copy G of both the core files and corresponding kernel.debug so I can hopefully G provide you with any info you need. How often does it crash? Does debug.mpsafenet=0 increases stability? I can reproduce the crash within 60 seconds of firing off 30+ ping/arp -d scripts, all running in parallel. debug.mpsafenet=0 seems to have solved the problem. I'm running 100+ instances of the above script and the system has been stable for over an hour. As I wanted some background on what debug.mpsafenet=0 does, I did some Googling and found a good write up here: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2004-08/2280.html Thanks, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
linuxthreads compilation error
My system: Athlon Xp 2000+ FreeBSD 6.0-CURRENT (build 30/06/2005) CFLAGS = -march=athlon-xp -O2 -pipe COPTFLAGS = -O -pipe I am trying to compile linuxthreads on my brand new FreeBSD system but I encounter some problems whith this port. I tried the compilation with CFLAGS= -O -pipe but it seems there are some conflicts between these threads and those one from FreeBSD (native). === Vulnerability check disabled, database not found You can use an experimental patch to reduce the number of condition variable triggered context switches by defining WITH_CONDWAIT_PATCH Some unsafe calls to exit() can be detected by defining LINUXTHREADS_DETECT_UNSAFE_EXIT, see files/README.FreeBSD for more info. Some conflicts with native threads can be avoided by defining LINUXTHREADS_WRAP_API, see files/README.FreeBSD for more info. Use of POSIX priority scheduling can be turned off by defining LINUXTHREADS_NO_POSIX_PRIORITY_SCHEDULING, see files/README.FreeBSD for more info. === Extracting for linuxthreads-2.2.3_16 = Checksum OK for glibc-linuxthreads-2.2.3.tar.gz. === Patching for linuxthreads-2.2.3_16 === Applying FreeBSD patches for linuxthreads-2.2.3_16 === Configuring for linuxthreads-2.2.3_16 === Building for linuxthreads-2.2.3_16 Warning: Object directory not changed from original /usr/cvs/ports/devel/linuxthreads/work/linuxthreads-2.2.3_16/libgcc_r make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc tm.h echo '#ifndef GCC_TM_H' tm.h echo '#define GCC_TM_H' tm.h echo '#ifdef IN_GCC' tm.h echo '#include i386/i386.h'tm.h echo '#include i386/unix.h'tm.h echo '#include i386/att.h' tm.h echo '#include dbxelf.h' tm.h echo '#include elfos.h'tm.h echo '#include freebsd-native.h' tm.h echo '#include freebsd-spec.h' tm.h echo '#include freebsd.h' tm.h echo '#include i386/freebsd.h' tm.h echo '#include defaults.h' tm.h echo '#if !defined GENERATOR_FILE !defined USED_FOR_TARGET' tm.h echo '# include insn-constants.h' tm.h echo '# include insn-flags.h' tm.h echo '#endif'tm.h echo '#endif'tm.h echo '#define EXTRA_MODES_FILE i386/i386-modes.def' tm.h echo '#endif /* GCC_TM_H */' tm.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc tconfig.h echo '#ifndef GCC_TCONFIG_H' tconfig.h echo '#define GCC_TCONFIG_H' tconfig.h echo '#ifdef IN_GCC' tconfig.h echo '# include ansidecl.h'tconfig.h echo '#endif'tconfig.h echo '#define USED_FOR_TARGET' tconfig.h echo '#endif /* GCC_TCONFIG_H */'tconfig.h cc -c -O -pipe -D_PTHREADS -I../ -I../sysdeps/i386 -I../sysdeps/pthread -I. ./sysdeps/unix/sysv/linux -fexceptions -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_N OT_NEEDED -DFINE_GRAINED_LIBRARIES -D_PTHREADS -DGTHREAD_USE_WEAK -I/usr/sr c/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libgcc/../../ ../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -D L_muldi3 -o _muldi3.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c cc -c -O -pipe -D_PTHREADS -I../ -I../sysdeps/i386 -I../sysdeps/pthread -I. ./sysdeps/unix/sysv/linux -fexceptions -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_N OT_NEEDED -DFINE_GRAINED_LIBRARIES -D_PTHREADS -DGTHREAD_USE_WEAK -I/usr/sr c/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libgcc/../../ ../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -D L_negdi2 -o _negdi2.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c cc -c -O -pipe -D_PTHREADS -I../ -I../sysdeps/i386 -I../sysdeps/pthread -I. ./sysdeps/unix/sysv/linux -fexceptions -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_N OT_NEEDED -DFINE_GRAINED_LIBRARIES -D_PTHREADS -DGTHREAD_USE_WEAK -I/usr/sr c/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libgcc/../../ ../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -D L_lshrdi3 -o _lshrdi3.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c cc -c -O -pipe -D_PTHREADS -I../ -I../sysdeps/i386 -I../sysdeps/pthread -I. ./sysdeps/unix/sysv/linux -fexceptions -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_N OT_NEEDED -DFINE_GRAINED_LIBRARIES -D_PTHREADS -DGTHREAD_USE_WEAK -I/usr/sr
Re: Possible exploit in 5.4-STABLE
What are the chances of a base 5.4-RELEASE system with PF and securelevel 2 and updated packages being cracked and rooted? Is this something that occurs every day? Or is it difficult? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Fri, Jul 01, 2005 at 03:03:35PM +0200, Marc Olzheim wrote: On Fri, Jul 01, 2005 at 12:41:39PM +0200, Marc Olzheim wrote: On Fri, Jul 01, 2005 at 12:14:58PM +0200, Marc Olzheim wrote: Somehow, this sounds familiar, i.e.: the lock cmpxchgl: Fatal trap 12: page fault while in kernel mode ... Stopped at 0xc05160c3 = knote+0x27:lock cmpxchgl %ecx,0x1c(%edx) Somehow I think I solved this last time by activating 'INVARIANTS'... I'll try that now. Let's paraphrase: I think i solved this last time by activating 'INVARIANTS'... Anyway, tried that and yes, it didn't crash in the last few hours, so I guess it works. Without INVARIANTS, it crashed within seconds. On the downside, my Gigabit performance dropped from 99 MB/sec to 80 MB/sec because of INVARIANTS. The panic appears to be an instance of a known bug in 5.4 (and INVARIANTS will not fix it, but may just delay the inevitable by changing timings). See Doug White's recent emails which point to a patch you should test. Kris pgphUQQX1w87x.pgp Description: PGP signature
Re: Possible exploit in 5.4-STABLE
On Fri, Jul 01, 2005 at 02:02:16PM -0400, Matt Juszczak wrote: What are the chances of a base 5.4-RELEASE system with PF and securelevel 2 and updated packages being cracked and rooted? Is this something that occurs every day? Or is it difficult? I don't know of any root exploits in 5.4. Kris pgpy9Yf7At8hN.pgp Description: PGP signature
Re: linuxthreads compilation error
On Fri, Jul 01, 2005 at 07:56:21PM +0200, BLONDEL Vincent wrote: My system: Athlon Xp 2000+ FreeBSD 6.0-CURRENT (build 30/06/2005) You sent it to the wrong list (6.0 is *current* not *stable*), but this is a known problem. Talk to the port maintainer (although he has already been informed). Kris pgpYyH91QnczE.pgp Description: PGP signature
Re: FreeBSD -STABLE servers repeatedly crashing.
On Wed, Jun 29, 2005 at 06:05:35AM -0400, Kris Kennaway wrote: On Tue, Jun 28, 2005 at 11:26:06AM -0400, Matt Juszczak wrote: OK, when it crashes next and is sat at the db prompt, type tr and press enter to get a trace. Copy this down (or have a serial console to capture the output). Also, try typing call doadump() and see if that succeeds in generating a crash dump. How were you trying to generate one before? Gavin I can't type anything. The machine locks up. See: http://paste.atopia.net/126 After CPUID: 1, the machine locks cold and nothing else is printed to the screen. Try two things: 1) adding 'options KDB_STOP_NMI' to your kernel config. I just learned that you also need to set the debug.kdb.stop_cpus_with_nmi=1 sysctl (e.g. in sysctl.conf). Kris pgpw48l0Z9fZN.pgp Description: PGP signature
Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350
On Friday 01 July 2005 17:12, Tony Byrne wrote: Hello Dominic, DM Do you see them with ATA mkIII as well? I tried the ATA mkIII patches a few weeks ago on one of servers, which was suffering DMA TIMEOUTs, but they made no difference. Tried Linux on the same hardware? A strange suggestion perhaps, but I suspect that something is wrong with the hardware, or its configuration. It might turn up something interesting, at least it will rule the possibility of bad hardware in, or out. This problem may only occur with certain combinations of controller and SATA hard drive. For example, I have a workstation with an ICH5 controller which had been frequently emitting TIMEOUT messages when it had a 80Gb 7200k Seagate Barracuda SATA drive installed. As a test See below for what is possibily a very similar story. this afternoon, I swapped out the Seagate for a new 250Gb Western Digital SATA drive, and installed 5.4 RELEASE. The machine is now in the process of building world, and I've yet to see any TIMEOUTs. I have lots of ICH5 and ICH6 systems and I haven't had any WRITE_DMA errors on them (to my knowledge). All of my problems in this area are to with Sil3112 based cards. An 80GB seagate drive attached to an Adaptec RAID controller with the Sil3112 in had absolutely terrible performance, about 4MB/s (r+w) at best. Replacing the Seagate disc with a Maxtor fixed the problem. I wasn't looking for these messages at the time, so they may have been a factor. What I did notice is that the drive (according to gstat) was improbably busy almost all the time for the minor load I was placing on it. I have another two Sil3112 based cards from no-name suppliers, these also seem to have issues - but they vary quite a lot. Just this week I have been setting up a SATA RAID using graid3 and 3x 250GB WD discs. In my test system I installed two of the Sil3112 cards, in addition to the integrated ICH6 onboard. Attaching a drive to each controller gives good performance ~105MB/s peak according to diskinfo. However trying to use the raid array in this configuration results in either of the drives dedicated to data having frequent problems, including the drives dropping out of the array at random during periods of load because of write FAILUREs. This makes the array useless since it is incapable of sustaining even a rebuild of the array without one, or both of the data drives failing. I never have any errors from the disc used for parity, which I put on the ICH6. If I reconfigure the machine and put both data discs on one of the Sil3112 controllers the system is stable and I can work with it. Performance suffers quite a bit, dropping to a peak of 98MB/s (ok, it's not much to cry about :-)). If I put the parity drive on either of the Sil3112 controllers I normally get a write failure, followed by a panic within minutes. What concerns me more about this configuration is that the speed limit on a rebuild of array. If I place a drive on each controller the rebuild runs at ~50MB/s (from memory, might be a little less). However, in the stable configuration the rebuild cannot pass 20MB/s. Which on a 500GB array, makes quite a difference to the rebuild time. Incidentally, this configuration is only stable on one of the Sil3112 cards I have (no RAID). I have one with RAID (probably almost exactly like the Adaptec), and one without. If your stuck with the hardware you have, like I am, I suggest that you setup a gmirror of your two dodgy drives, if one of them happens to encounter a read/write failure its less likely to take the system down. Hardly a fix though. Mikhail, I hope you don't mind me CC'ing you here. I read in a message that you had cured some problems like this by changing some of the PCI timers (?). Could you possibly say a little about what you did? Regards, Tony. Cheers, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350
On Friday 01 July 2005 17:27, Alan Jay wrote: Thanks for this - I haven't try but will do so - but I do need a little help. I have downloaded the STABLE version and put it onto my machines. Do I have to compile the ATA driver into the system and if so how do I do so (sorry to ask no instructions on the web site below). This should be the procedure, but I could be wrong. o Get a fresh RELENG_5 o Copy the ata mkIII update to your source tree o Apply the diff for RELENG_5 to your source tree o Build a fresh world + kernel For proper instructions Google about for [EMAIL PROTECTED]'s original instructions. I think the subject was 'UPDATE: ATA mkIII patches' or something along those lines. Thanks. -Original Message- From: Dominic Marks [mailto:[EMAIL PROTECTED] Sent: Friday, July 01, 2005 5:00 PM To: freebsd-stable@freebsd.org; [EMAIL PROTECTED] Subject: Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350 On Friday 01 July 2005 16:34, Alan Jay wrote: Further to this the same ATA Timeout is seen in the latest SNAP binaries (1st July). Do you see them with ATA mkIII as well? http://people.freebsd.org/~sos/ATA/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] HTH, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA Problems - ATA_Identify timeout ERROR - using Tyan S5350
On 7/1/05, Dominic Marks [EMAIL PROTECTED] wrote: On Friday 01 July 2005 17:27, Alan Jay wrote: Thanks for this - I haven't try but will do so - but I do need a little help. I have downloaded the STABLE version and put it onto my machines. Do I have to compile the ATA driver into the system and if so how do I do so (sorry to ask no instructions on the web site below). This should be the procedure, but I could be wrong. o Get a fresh RELENG_5 o Copy the ata mkIII update to your source tree Instead of just copying the files into your source tree, you should rename the following directories: sys/modules/ata sys/modules/ata-old (if it exists) sys/dev/ata sys/dev/ata-old NOTE: Just incase you wish to go back to the old ata driver. Then extract the ata mkII update into your source tree. o Apply the diff for RELENG_5 to your source tree o Build a fresh world + kernel For proper instructions Google about for [EMAIL PROTECTED]'s original instructions. I think the subject was 'UPDATE: ATA mkIII patches' or something along those lines. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: init: can't exec getty 'none' for port /dev/console: No such file or directory
Please don't top-post. On Fri, 2005-Jul-01 20:17:47 +0300, Bashar wrote: Peter Jeremy wrote: You should have the following line in /etc/ttys: console noneunknown off secure True its set to on, but i believe this change was requested from the DC to enable the remote console for the box. would turning it off effect the remote console from working? No. The 'console' entry is just a marker. By remote console I presume you mean serial console. The easiest way to get a serial console is to put -P into /boot.config and unplug the keyboard. (For other ways, see boot(8) and sio(4)). In order to enable logins on a serial console, you will need to turn on the getty for ttyd0. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in RELENG_5 UMA - two new stack traces
On Fri, Jul 01, 2005 at 01:54:59PM -0400, Gary Mu1der wrote: G On Tue, Jun 28, 2005 at 11:24:47AM -0400, Gary Mu1der wrote: G G I spent the day yesterday trying to reproduce the crash that I posted G G last week and you kindly replied to. This is due to the fact that I G G stupidly managed to overwrite the kernel.debug that I used to generate G G the stack trace. Sadly I could not cause the system to crash again with G G the same sb* errors. G G G G I did however remove both the Berkley Packet Filter and IPFilter from G my G custom kernel to try and isolate the problem. This has caused the G crash G to occur in a different and more reproducible form. I have both G G INVARIANTS and WITNESS enabled, as you can see from my kernel conf. G G which is included at the end of this e-mail. G G G G Below are the latest stack traces (using bge and then fxp NICs), kernel G G conf. and dmesg. Any help would be appreciated. This time I have a copy G G of both the core files and corresponding kernel.debug so I can G hopefully G provide you with any info you need. G G How often does it crash? Does debug.mpsafenet=0 increases stability? G G I can reproduce the crash within 60 seconds of firing off 30+ ping/arp G -d scripts, all running in parallel. G G debug.mpsafenet=0 seems to have solved the problem. I'm running 100+ G instances of the above script and the system has been stable for over an G hour. Thanks! We definitely see that the bug is a race, not a broken logic. I am almost sure, that you are experiencing the same bug as I described in the beginning of the thread. Although there is no yet fix available for race between 'arp -d' and outgoing packet, there is one for race between incoming ARP reply and outgoing packet. We will probably commit it soon, after more review. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in RELENG_5 UMA - two new stack traces
Gleb Smirnoff wrote: G I can reproduce the crash within 60 seconds of firing off 30+ ping/arp G -d scripts, all running in parallel. G G debug.mpsafenet=0 seems to have solved the problem. I'm running 100+ G instances of the above script and the system has been stable for over an G hour. Thanks! We definitely see that the bug is a race, not a broken logic. I am almost sure, that you are experiencing the same bug as I described in the beginning of the thread. Although there is no yet fix available for race between 'arp -d' and outgoing packet, there is one for race between incoming ARP reply and outgoing packet. We will probably commit it soon, after more review. Is this bug specific to only using arp -d, or does it look like the arp -d tests identify a bug that might cause TCP/IP related crashes with other types of real-world network traffic. To rephrase: Does it look like fixing this bug may fix a lot of the network-related crashes a number of people have reported? Thanks, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in RELENG_5 UMA - two new stack traces
On Fri, Jul 01, 2005 at 04:32:38PM -0400, Gary Mu1der wrote: G G I can reproduce the crash within 60 seconds of firing off 30+ ping/arp G G -d scripts, all running in parallel. G G G G debug.mpsafenet=0 seems to have solved the problem. I'm running 100+ G G instances of the above script and the system has been stable for over G an G hour. G G Thanks! We definitely see that the bug is a race, not a broken logic. I am G almost sure, that you are experiencing the same bug as I described in G the beginning of the thread. G G Although there is no yet fix available for race between 'arp -d' and G outgoing packet, there is one for race between incoming ARP reply and G outgoing packet. We will probably commit it soon, after more review. G G Is this bug specific to only using arp -d, or does it look like the G arp -d tests identify a bug that might cause TCP/IP related crashes G with other types of real-world network traffic. G G To rephrase: Does it look like fixing this bug may fix a lot of the G network-related crashes a number of people have reported? See above in the thread. We have two races: one that can fire anytime in runtime, and we are going to fix it. The other with 'arp -d', not fixed yet. I am not sure how many reports on network related panics where related to this race. Let's fix it and see. You can patch your boxes with the patch and see whether they are more stable in runtime. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
GCC on RELENG_5: www/libgtkhtml ICE?
Hello, Today I'm trying to portupgrade my FreeBSD box as I usually do each (month|few weeks). During the build of libgtkhtml-2.6.3, I got the following error: | rm -f .libs/htmlboxtable.lo | cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../libgtkhtml -DXTHREADS -DXUSE_MTSAFE_API -I/usr/local/include/atk-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/X11R6/include/pango-1.0 -I/usr/local/include/freetype2 -DG_LOG_DOMAIN=\HtmlLayout\ -I/usr/local/include -O -pipe -MT htmlboxtable.lo -MD -MP -MF .deps/htmlboxtable.Tpo -c htmlboxtable.c -fPIC -DPIC -o .libs/htmlboxtable.lo | cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../libgtkhtml -DXTHREADS -DXUSE_MTSAFE_API -I/usr/local/include/atk-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/X11R6/include/pango-1.0 -I/usr/local/include/freetype2 -DG_LOG_DOMAIN=\HtmlLayout\ -I/usr/local/include -O -pipe -MT htmlboxtable.lo -MD -MP -MF .deps/htmlboxtable.Tpo -c htmlboxtable.c -o htmlboxtable.o /dev/null 21 | gmake[4]: *** [htmlboxtable.lo] Error 1 | gmake[4]: Leaving directory `/space0/tmp/ports/build/space0/ports/www/libgtkhtml/work/libgtkhtml-2.6.3/libgtkhtml/layout' | gmake[3]: *** [all-recursive] Error 1 | gmake[3]: Leaving directory `/space0/tmp/ports/build/space0/ports/www/libgtkhtml/work/libgtkhtml-2.6.3/libgtkhtml/layout' | gmake[2]: *** [all-recursive] Error 1 | gmake[2]: Leaving directory `/space0/tmp/ports/build/space0/ports/www/libgtkhtml/work/libgtkhtml-2.6.3/libgtkhtml' | gmake[1]: *** [all-recursive] Error 1 | gmake[1]: Leaving directory `/space0/tmp/ports/build/space0/ports/www/libgtkhtml/work/libgtkhtml-2.6.3' | gmake: *** [all] Error 2 | *** Error code 2 | | Stop in /space0/ports/www/libgtkhtml. So I tried to run the command manually: | (zonk) /space0/tmp/ports/build/space0/ports/www/libgtkhtml/work/libgtkhtml-2.6.3/libgtkhtml/layout # cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../libgtkhtml -DXTHREADS -DXUSE_MTSAFE_API -I/usr/local/include/atk-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/X11R6/include/pango-1.0 -I/usr/local/include/freetype2 -DG_LOG_DOMAIN=\HtmlLayout\ -I/usr/local/include -O -pipe -MT htmlboxtable.lo -MD -MP -MF .deps/htmlboxtable.Tpo -c htmlboxtable.c -o htmlboxtable.o | htmlboxtable.c: In function `paint_rows': | htmlboxtable.c:1197: internal compiler error: Segmentation fault | Please submit a full bug report, | with preprocessed source if appropriate. | See URL:http://gcc.gnu.org/bugs.html for instructions. I'm not sure if it's wise to report it to GNU anyway, because the version I'm using, is the one shipped with FreeBSD 5.4: | (zonk) ~ # gcc --version | gcc (GCC) 3.4.2 [FreeBSD] 20040728 | Copyright (C) 2004 Free Software Foundation, Inc. | This is free software; see the source for copying conditions. There is NO | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. My machine is running FreeBSD 5.4-STABLE (RELENG_5 from Jun 12): | FreeBSD zonk.fxq.nl 5.4-STABLE FreeBSD 5.4-STABLE #0: Sun Jun 12 17:20:29 CEST 2005 [EMAIL PROTECTED]:/usr/obj/space0/src/sys/ZONK i386 Is anyone also having problems with www/libgtkhtml's htmlboxtable.lo in combination with RELENG_5's gcc? Does anyone know if this bug is squashed in RELENG_5 in the mean time? Yours, -- Ed Schouten [EMAIL PROTECTED] pgpqxKWVhjYn0.pgp Description: PGP signature
Re: GCC on RELENG_5: www/libgtkhtml ICE?
On Fri, Jul 01, 2005 at 11:02:23PM +0200, Ed Schouten wrote: Is anyone also having problems with www/libgtkhtml's htmlboxtable.lo in combination with RELENG_5's gcc? Does anyone know if this bug is squashed in RELENG_5 in the mean time? The package builds fine on a clean system, so you should try to rule out hardware failure on your end. Kris pgpVsDYdkJDJS.pgp Description: PGP signature
Re: GCC on RELENG_5: www/libgtkhtml ICE?
* Kris Kennaway [EMAIL PROTECTED] wrote: On Fri, Jul 01, 2005 at 11:02:23PM +0200, Ed Schouten wrote: Is anyone also having problems with www/libgtkhtml's htmlboxtable.lo in combination with RELENG_5's gcc? Does anyone know if this bug is squashed in RELENG_5 in the mean time? The package builds fine on a clean system, so you should try to rule out hardware failure on your end. Argh, kick-myself-in-the-face; after a reboot it all worked fine? (kinda odd though...) Thanks for your time though. Yours, -- Ed Schouten [EMAIL PROTECTED] pgpFZeBeMqSem.pgp Description: PGP signature
Re: How is the patchlevel set?
On 7/1/2005 11:36 AM, lars wrote:
It seems
src/sys/conf/newvers.sh
is only triggered by a recompilation of the kernel,
at least the lines
i=`${MAKE:-make} -V KERN_IDENT`
and
char kern_ident[] = ${i};
make me believe that.
I also try to cvsup my src and recompile the kernel and world
in one go instead of only patching and recompiling the subsystem,
since that bumps the patchlevel and keeps all synchronised.
That's not possible in all scenarios, of course.
Again thanks for the answers, but how did you find that out?
I originally suspected as much based on experience. I got curious and
noticed that newvers.sh was one of the files changed with every security
update. From there it was code inspection...
--
Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195
signature.asc
Description: OpenPGP digital signature
Re: ndis no longer detects netgear wg311v2
I am reminded of Fri, Jul 01, 2005 at 03:53:59PM +0200 when [EMAIL PROTECTED] said: On 1 Jul, Phil Bowens wrote: FWIW, I am having the *exact* same problem starting today. I hadn't updated my STABLE machine since April. NDIS was working fine (save a frew crashes) before I updated last night.. and now NDIS will not even talk about the card. There is also a slight freeze on the machine after the if_ndis module is loaded. I will do some more investigating, but now there's at least two of us. Did you ever find a fix? I had a similar problem with a recent system update two days ago. I noticed that the if_ndis.ko was half smaller and there was not any reference to my NIC anymore. After a few search I noticed that ndisgen is a tool able to generate a specific loadable module based on .inf and .sys. So I used ndisgen, copied the generated ko to /boot/kernel and manually kldload it : my NIC was back. Unfortunately, I haven't been able to find a good resource about the correct procedure to generate the module but I have a bigger problem than this one at the moment :( Hope that helps. Phil. Okay, so if you take a look at cvsweb, you'll find some information in a commit message somewhere. I'm not going to make you look for it, don't worry. The procedure for creating the kernel module has changed. For some reason this never made it to updating, and appears to only be documented in the commit message. The commit message references ndisgen(8). It could have been some other number, but it doesn't matter because the man page doesn't exist anywhere anyway. Luckily, ndisgen is basically self-documenting. You just run it, maybe choose to read the explanation text, and choose the option to create the kernel module. It will prompt you for your sys and inf files, along with any firmware files you might need. You should be warned though, that you'll want to have the paths to your files available because there's no file browser functionality and if you suspend ndisgen while you look up the path, ^L won't redraw the screen. It would be handy to have a non-interactive version again, but oh well. -- Evan Dower Software Development Engineer Amazon.com, Inc. Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfilter LOR-fest
Gang, Is anything going to be done about the slew of LORs that opfilter generates? I have a production box rebooting on me and I'm *very* suspicious about ipfilter here. the LORs in question are: LOR 51 lock order reversal 1st 0xc35fbea0 inp (udp6inp) @ /nfs/freebsd/5.x/src/sys/netinet6/udp6_usrreq.c:738 2nd 0xc06a9ae0 ipf filter rwlock (ipf filter rwlock) @ /nfs/freebsd/5.x/src/sys/contrib/ipfilter/netinet/fil.c:1107 KDB: stack backtrace: kdb_backtrace(,c06bc110,c06bc3e0,c068caec,c06e08b0) at kdb_backtrace+0x29 witness_checkorder(c06a9ae0,1,c0648afd,453,c06b5e1c,0,c065c663,6f) at witness_checkorder+0x49d _sx_slock(c06a9ae0,c0648afd,453,0,c369e600) at _sx_slock+0x29 fr_check(c369e684,28,c3253400,1,e8f9d970) at fr_check+0x430 fr_check_wrapper6(0,e8f9d970,c3253400,2,c35fbe10) at fr_check_wrapper6+0x21 pfil_run_hooks(c06e5560,e8f9d9f8,c3253400,2,c35fbe10) at pfil_run_hooks+0xb3 ip6_output(c369e600,0,e8f9da64,0,0) at ip6_output+0xd1d udp6_output(c35fbe10,c369e600,c33fc7a0,0,c3466180) at udp6_output+0x452 udp6_send(c35f28dc,0,c369e600,c33fc7a0,0) at udp6_send+0x168 sosend(c35f28dc,c33fc7a0,e8f9dc40,c369e600,0) at sosend+0x593 kern_sendit(c3466180,4,e8f9dcbc,0,0) at kern_sendit+0x104 sendit(c3466180,4,e8f9dcbc,0,806c3a0) at sendit+0x161 sendto(c3466180,e8f9dd04,6,4,292) at sendto+0x4d syscall(2f,2f,2f,806a000,bfbfea40) at syscall+0x227 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (133, FreeBSD ELF32, sendto), eip = 0x280f50ef, esp = 0xbfbfe9ac, ebp = 0xbfbfeae8 --- lock order reversal 1st 0xc3778f54 inp (tcpinp) @ /nfs/freebsd/5.x/src/sys/netinet/tcp_usrreq.c:371 2nd 0xc06a9ae0 ipf filter rwlock (ipf filter rwlock) @ /nfs/freebsd/5.x/src/sys/contrib/ipfilter/netinet/fil.c:1107 KDB: stack backtrace: kdb_backtrace(,c06bda60,c06bc3e0,c068caec,c06e08b0) at kdb_backtrace+0x29 witness_checkorder(c06a9ae0,1,c0648afd,453,c06b5e1c,0,c065c663,6f) at witness_checkorder+0x49d _sx_slock(c06a9ae0,c0648afd,453,0,c3731100) at _sx_slock+0x29 fr_check(c3731140,14,c3253400,1,e8fb5b28) at fr_check+0x430 fr_check_wrapper(0,e8fb5b28,c3253400,2,c3778ec4) at fr_check_wrapper+0x2a pfil_run_hooks(c06e2180,e8fb5b9c,c3253400,2,c3778ec4) at pfil_run_hooks+0xb3 ip_output(c3731100,0,e8fb5b68,0,0) at ip_output+0x4de tcp_output(c37efde0,c3812944,c38128dc,c3466d80,e8fb5c98) at tcp_output+0x1090 tcp_usr_connect(c38128dc,c3243600,c3466d80) at tcp_usr_connect+0xeb soconnect(c38128dc,c3243600,c3466d80,0,c383bc7c) at soconnect+0x7c kern_connect(c3466d80,4,c3243600,c3243600,0) at kern_connect+0x74 connect(c3466d80,e8fb5d04,3,5,282) at connect+0x2f syscall(2f,2f,2f,82c4000,82c4000) at syscall+0x227 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (98, FreeBSD ELF32, connect), eip = 0x2869132f, esp = 0xbfbfdfcc, ebp = 0xbfbfdff8 --- lock order reversal 1st 0xc06e2d4c udp (udp) @ /nfs/freebsd/5.x/src/sys/netinet/udp_usrreq.c:246 2nd 0xc06a9ae0 ipf filter rwlock (ipf filter rwlock) @ /nfs/freebsd/5.x/src/sys/contrib/ipfilter/netinet/fil.c:1107 KDB: stack backtrace: kdb_backtrace(,c06bdad8,c06bc3e0,c068caec,c06e08e8) at kdb_backtrace+0x29 witness_checkorder(c06a9ae0,1,c0648afd,453,c06b5e1c,0,c065c663,6f) at witness_checkorder+0x49d _sx_slock(c06a9ae0,c0648afd,453,0,c35fd800) at _sx_slock+0x29 fr_check(c35fd8c8,14,c3253400,1,e63daaec) at fr_check+0x430 fr_check_wrapper(0,e63daaec,c3253400,2,0) at fr_check_wrapper+0x2a pfil_run_hooks(c06e2180,e63dab60,c3253400,2,0) at pfil_run_hooks+0xb3 ip_output(c35fd800,0,e63dab2c,0,0) at ip_output+0x4de icmp_send(c35fd800,0,c35fd800) at icmp_send+0x55 icmp_reflect(c35fd800,c36009d0,c35fd8c8,14) at icmp_reflect+0x2d6 icmp_error(c3600900,3,3,0,0) at icmp_error+0x212 udp_input(c3600900,14,17f,0,0) at udp_input+0x4d0 ip_input(c3600900) at ip_input+0x4f1 netisr_processqueue(c06e1818) at netisr_processqueue+0x6e swi_net(0) at swi_net+0x88 ithread_loop(c3095b00,e63dad38,c06b4c20,0,c0659fba) at ithread_loop+0x10c fork_exit(c04fd400,c3095b00,e63dad38) at fork_exit+0x66 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe63dad6c, ebp = 0 --- lock order reversal 1st 0xc3909090 inp (rawinp) @ /nfs/freebsd/5.x/src/sys/netinet/raw_ip.c:268 2nd 0xc06a9ae0 ipf filter rwlock (ipf filter rwlock) @ /nfs/freebsd/5.x/src/sys/contrib/ipfilter/netinet/fil.c:1107 KDB: stack backtrace: kdb_backtrace(,c06bc0c0,c06bc3e0,c068caec,c06e0840) at kdb_backtrace+0x29 witness_checkorder(c06a9ae0,1,c0648afd,453,c06b5e1c,0,c065c663,6f) at witness_checkorder+0x49d _sx_slock(c06a9ae0,c0648afd,453,0,c33e6c00) at _sx_slock+0x29 fr_check(c33e6cd0,14,c3229000,1,e90bfaec) at fr_check+0x430 fr_check_wrapper(0,e90bfaec,c3229000,2,c3909000) at fr_check_wrapper+0x2a pfil_run_hooks(c06e2180,e90bfb60,c3229000,2,c3909000) at pfil_run_hooks+0xb3 ip_output(c33e6c00,0,e90bfb2c,20,0) at ip_output+0x4de rip_output(c33e6c00,c381ca20,fa04a8c0,1c,c33e6c00) at rip_output+0x293 rip_send(c381ca20,0,c33e6c00,c3243a50,0) at rip_send+0x93
panic in ata_end_transaction
Hello, I was testing the latest -STABLE (cvsupped just an hour ago), to check if my ATA DMA problems have been fixed. This time I got a panic as result of my small test. What I did is a bit stress testing (dd if=/dev/ad0 of=/dev/null bs=32768). Here is the panic description: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0491c6e stack pointer = 0x10:0xd4405c6c frame pointer = 0x10:0xd4405c9c 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 = 24 (irq14:ata0) [thread pid 24 tid 100018] Stopped at ata_end_transaction+0xe: movl 0(%eax),%esi db where Tracing pid 24 tid 100018 td 0xc1d7fc00 ata_end_transaction(c20a7960,73,2e8b6191,246,246) at ata_end_transaction+0xe ata_interrupt(c1f11200,0,0,0,0) at ata_interrupt+0x137 ithread_loop(c1d79600,d4405d38,0,0,0) at ithread_loop+0x1b8 fork_exit(c05a7df0,c1d79600,d4405d38) at fork_exit+0x7f fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip=0, esp=0xd4405d6c, ebp=0 --- Btw, first time I have seen that the reset command did not work in the kernel debugger. It froze the PC totally. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
