Re: vm_map.c lock up (Was: Re: NFS Locking Issue)
On 14/07/2006 6:08 PM, User Freebsd wrote: Just in case, do you use mlocked mappings ? Also, why so huge number of crons exist in the system ? The are all forking now. It may be (can not say definitely without further investigation) just a fork bomb. re: crons ... this, I'm not sure of, but my suspicion was that the crons weren't able to complete, since the file system was locked up, but the next one was being attempted to run ... *shrug* This seems consistent with behaviour I've seen in on several 6.0-RELEASE machines.. from the limited information I've been able to get from the machines, there has appeared to be multiple tasks from cron all piled up upon one another. In particular, the daily periodic tasks that run the various 'find' were one of the things I noticed (although we run numerous tasks out of cron)... If something is blocking the filesystem and causing find (and possibly other processes) to become stuck, these would just keep mounting up until it all falls over (with numerous maxproc exceeded etc errors). These are on machines without NFS, but the symptoms are very very similar.. NWFS and SMBFS are commonly used on a number of the machines I've seen the problem on, which may be relevant -- perhaps it affects more than just NFS? I may experiment with building up a test server locally and trying to reproduce similar loads to see if I can trigger the problem in-house.. at least that way I can hook up a serial console and get some more detailed information... Regards Antony ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel ICH7R RAID controller working on 6.1/STABLE?
Javier Henderson wrote: * Mike Jakubik [EMAIL PROTECTED] [060714 17:15]: The chipset is supported, but i wouldn't recommend onboard raid for any production server. Get a real raid controller, or use gmirror if you plan to mirror. I use several of these board sin production with gmirror. Why do you recommend against on-board RAID controllers? Think about what happens if one of your disks dies. Sure, the machine will carry on running. With an on-board controller there are two problems: i) How do you get notified that a disk has died ii) How do you replace the drive (i) you'ld likely only find out about at reboot time, or by noticing a change in the pattern of blinken-lights on the machine. (Don't laugh -- it happens) (ii) is not just about having to power off the machine and swap out the hardware: it's not uncommon for on-board RAID-1 setups to be unable to rebuild a mirror by duplicating the good disk onto the replacement one. That means blowing everything away and recovering from backup. By which time you've had so much downtime that you might as well not have bothered with RAID in the first place. The advantage of a good RAID controller -- like one of the 3ware cards -- or of gmirror is that combined with hot-swap disk (and pretty much all SATA drives nowadays have hot-swap capability; you just need to find a chassis with the right sort of drive bays) then you can take out the dead disk, replace it with a good one and rebuild the array *without taking the machine down*. gmirror will alert you to failures in the nightly e-mail if you enable the 406.status-gmirror periodic script. Similarly a good hardware RAID controller will have a system level control application to let you interface with the card from the OS level, and it will have some mechanism for alerting the admin to problems. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: FreeBSD 6.1 Tor issues (Once More, with Feeling)
Robert Watson [EMAIL PROTECTED] wrote: On Wed, 28 Jun 2006, Fabian Keil wrote: I just got: Jun 28 23:01:19 tor kernel: lock order reversal: Jun 28 23:01:19 tor kernel: 1st 0xc3795000 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1053 Jun 28 23:01:19 tor kernel: 2nd 0xc1043144 system map (system map) @ /usr/src/sys/vm/ Looks similar to http://sources.zabbadoz.net/freebsd/lor.html#185. Could you run vmstat -z, netstat -m, and vmstat -m please? I enabled polling three days ago and saw this lor two times since then. It may or may not be a coincidence. I log: top -S -d 2 pfctl -si netstat -ss sysctl -a vmstat -z netstat -m vmstat -m every five minutes, the output before and after the lor can be found at: http://www.fabiankeil.de/tmp/lor-185.txt The system is still up at the moment, so the lor might have nothing to do with the crashes/hangs/whatever. I have the feeling that polling does increase the uptime, but I'm not sure yet. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: FreeBSD 6.1 Tor issues (Once More, with Feeling)
Fabian Keil [EMAIL PROTECTED] wrote: Robert Watson [EMAIL PROTECTED] wrote: On Wed, 28 Jun 2006, Fabian Keil wrote: I just got: Jun 28 23:01:19 tor kernel: lock order reversal: Jun 28 23:01:19 tor kernel: 1st 0xc3795000 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1053 Jun 28 23:01:19 tor kernel: 2nd 0xc1043144 system map (system map) @ /usr/src/sys/vm/ Looks similar to http://sources.zabbadoz.net/freebsd/lor.html#185. Could you run vmstat -z, netstat -m, and vmstat -m please? I enabled polling three days ago and saw this lor two times since then. It may or may not be a coincidence. The system is still up at the moment, so the lor might have nothing to do with the crashes/hangs/whatever. Actually I had to reset the box about two hours ago, I just forgot and overlooked the few minutes downtime in the logs. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: nvidia-driver related (?) panic on 5.5-RELEASE
On Wednesday, 14. June 2006 18:26, Michael Nottebrock wrote: On Tuesday, 13. June 2006 01:03, Michael Nottebrock wrote: I'm getting similar kernel panics even when running (and quitting) much simpler applications than secondlife in wine - for instance, this is a panic I got quitting foobar2000 (a very unfancy Windows audio player): #0 doadump () at pcpu.h:160 #1 0xc04edd29 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:412 #2 0xc04ee04d in panic (fmt=0xc0697a7d %s: interrupts disabled) at /usr/src/sys/kern/kern_shutdown.c:568 #3 0xc064d6eb in pmap_invalidate_range (pmap=0xc07065a0, sva=3684024320, eva=3684040704) I'm getting this on FreeBSD 6.0 as well. Can't anybode else reproduce this? It is a little alarming that a mere userland application can reliably down the system like that. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp6eORKqJcIp.pgp Description: PGP signature
Re: FreeBSD 6.1 Tor issues (Once More, with Feeling)
Hey Fabian, To you have pf running? If so can you turn it off for a bit a see if you still crash. On my box I was getting all sorts of witness kbd backtraces on pf and since turning pf off (maybe a week ago), haven't crashed yet. Going to let it keep running unmetered for another 2 weeks and see if I crash or not. -Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1 Tor issues (Once More, with Feeling)
Peter Thoenen [EMAIL PROTECTED] wrote: To you have pf running? If so can you turn it off for a bit a see if you still crash. On my box I was getting all sorts of witness kbd backtraces on pf and since turning pf off (maybe a week ago), haven't crashed yet. Going to let it keep running unmetered for another 2 weeks and see if I crash or not. I'm running Tor jailed and use PF for NAT, port forwarding and filtering: http://tor.fabiankeil.de/pf-stats/ So far I didn't see a single PF related complaint from witness, but I'll try disabling PF in a few days anyway. At the moment I'm still testing if enabling polling really increases the uptime. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
burncd blank and format problems
Sorry to have to bring this up again, seems like it was an issue 4 years ago, but I don't know if it's really resolved. If I do: #burncd -f /dev/acd0 blank then burncd will sleep forever. (I have to Ctrl-C for it to exit) It doesn't really hang, but please read this: http://www.freebsd.org/cgi/query-pr.cgi?pr=44803 (I looked at the source code, the only thing I could figure that CDRIOCPROGRESS is ALWAYS returning 0. Inside a while(1), that will never break; Same results with erase instead of blank. On that pr (44803), user says blank worked, however, even when I Ctl-C and break after a while, any data that I write on the disk is invalid: I mean that if I copy it, it will not pass diff. Now this could be a problem with my DRD-RW device, but all of the other ports work with it. So is this my configuration problem? I doubt it, since the usr/ports stuff work ok (cdrecord, growifofs, cdrdao...) I've spent a lot of time on burncd, and it just doesn't work for me. I'm on FreeBSD 6.1R, Pioneer DVD: cd0 at ata1 bus 0 target 0 lun 0 cd0: PIONEER DVD-RW DVR-109 1.50 Removable CD-ROM SCSI-0 device cd0: 66.000MB/s transfers cd0: cd present [115847 x 2048 byte records] If you need any more config data, let me know. -- Bo Briggs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vm_map.c lock up (Was: Re: NFS Locking Issue)
On Saturday 15 July 2006 00:08, User Freebsd wrote: On Sat, 15 Jul 2006, Kostik Belousov wrote: On Sat, Jul 15, 2006 at 12:10:29AM -0300, User Freebsd wrote: On Wed, 5 Jul 2006, Robert Watson wrote: If you can get into DDB when the hang has occurred, output via serial console for the following commands would be very helpful: show pcpu show allpcpu ps trace traceall show locks show alllocks show uma show malloc show lockedvnods 'k, after 16 days uptime, the server that I got all the debugging turned on for finally hung up solid ... I was able to break into DDB over the serial link, and have run all of the above on it ... and the output is attached ... One thing to note is that the ps listing is not complete ... there are 6k processes running at the time, and I don't know how to get rid of the '--more--' prompt :( After 1k processes, I just hit 'q' and went onto the other commands ... set lines=0 Also, traceall gave me a 'No such command' error ... now that I think about it, my luck, it was supposed to be 'trace all'? It is alltrace. If this doesn't provide enough information, please let me know what else I should do the next time through, besides the above commands ... Missing alltrace output seems to be critical. If this is not feasible, please, provide at least the output of the bt pid for each pid shown in the show lockedvnods and show alllocks. In you case, bt 64880 was the most interesting. It is pity that you had reset the machine. Was down for too long as it was ... it, of course, happened while I was out with the family :( Will keep all of this in mind next time I get a chance to run through things ... Any idea why 'panic' doesn't produce core like it used to? call doadump Should force a core dump. -- Anish Mistry pgpR6RAW6o4vE.pgp Description: PGP signature
Re: burncd blank and format problems
On Sat, 15 Jul 2006, B Briggs wrote: Sorry to have to bring this up again, seems like it was an issue 4 years ago, but I don't know if it's really resolved. If I do: #burncd -f /dev/acd0 blank then burncd will sleep forever. (I have to Ctrl-C for it to exit) It doesn't really hang, but please read this: http://www.freebsd.org/cgi/query-pr.cgi?pr=44803 (I looked at the source code, the only thing I could figure that CDRIOCPROGRESS is ALWAYS returning 0. Inside a while(1), that will never break; Same results with erase instead of blank. On that pr (44803), user says blank worked, however, even when I Ctl-C and break after a while, any data that I write on the disk is invalid: I mean that if I copy it, it will not pass diff. Now this could be a problem with my DRD-RW device, but all of the other ports work with it. So is this my configuration problem? I doubt it, since the usr/ports stuff work ok (cdrecord, growifofs, cdrdao...) I've spent a lot of time on burncd, and it just doesn't work for me. I have something similar[1] on my ATAPI CD-RW drive. It is the ioctl() that is the problem since it is always returning zero. The reason the ports you mention work (at least cdrecord) is that they use the SCSI emulator atapicam(4) as opposed to the ATAPI driver itself. Another burncd bug I have is kern/96171[2]. That is in case anyone wants to fix that too. :) Sean 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83702 2. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/96171 -- [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: Intel ICH7R RAID controller working on 6.1/STABLE?
* Matthew Seaman [EMAIL PROTECTED] [060715 02:30]: Javier Henderson wrote: * Mike Jakubik [EMAIL PROTECTED] [060714 17:15]: The chipset is supported, but i wouldn't recommend onboard raid for any production server. Get a real raid controller, or use gmirror if you plan to mirror. I use several of these board sin production with gmirror. Why do you recommend against on-board RAID controllers? Think about what happens if one of your disks dies. Sure, the machine will carry on running. With an on-board controller there are two problems: i) How do you get notified that a disk has died ii) How do you replace the drive (i) you'ld likely only find out about at reboot time, or by noticing a change in the pattern of blinken-lights on the machine. (Don't laugh -- it happens) Good point. The Intel motherboard I have with on-board RAID controller doesn't have a notification features as I've seen on stand-alone controllers. (ii) is not just about having to power off the machine and swap out the hardware: it's not uncommon for on-board RAID-1 setups to be unable to rebuild a mirror by duplicating the good disk onto the replacement one. That means blowing everything away and recovering from backup. By which time you've had so much downtime that you might as well not have bothered with RAID in the first place. Well, in my case, I mentioned I have the Intel D945PVS motherboard. Before storing valuable data, I did take out a drive (out of four in a RAID 5 configuration) while reading and writing to/from the array, and it just kept on going. Then I put the disk back, and things got slow while parity was rebuilt, but in the end the array was back to healthy status. The advantage of a good RAID controller -- like one of the 3ware cards -- or of gmirror is that combined with hot-swap disk (and pretty much all SATA drives nowadays have hot-swap capability; you just need to find a chassis with the right sort of drive bays) then you can take out the dead disk, replace it with a good one and rebuild the array *without taking the machine down*. gmirror will alert you to failures in the nightly e-mail if you enable the 406.status-gmirror periodic script. Similarly a good hardware RAID controller will have a system level control application to let you interface with the card from the OS level, and it will have some mechanism for alerting the admin to problems. Yes, there are indeed good advantages to stand-alone controllers, and in some cases they justify the expense. Thanks for taking the time to post a reply. -jav ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
asus wl 530-g router
Hi all! I'd like to know if someone has experience with this router. The signal comes from cable modem, to wan port. It has 4 lan ethernets and wireless G. The chip is (probably) Marwell, os linux embeded. Internet provider offers dhcp dynamic address. I would use static IPs in lan. Has nat and some kind of firewall. Question? Should I take this? Does it pass through telnet, ssh, ping (from inside out)? How nice works wi-fi component? Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
