Re: smbfs hang
Chris Coleman wrote: I'm doing a large transfer from an SMB mounted drive, about 2TB of files. After about 250G, it hanging. Of course any process that tries to access that drive hangs as well. Is there anyway to get those processes killed off and remount the drive without rebooting? I haven't had much luck so far. They don't seem to want to die. I'm pretty sure that your answer is going to be no. Most of my experience with SMBFS comes in the opposite direction - trying to write large files to an SMB-mounted filesystem and that was so problematic that we switched to NFS. That's a bit more work to set up, but well worth it, imho. See http://technet.microsoft.com/en-us/library/bb463212.aspx So far, fingers cross and touch wood, with Windows virus checking turned off on the remote drive, writing large files has been problem free and tests reading those files have had no problems either. Only talking in the 40Gb range though. hth, --Alex PS The problems we experienced didn't include wedging, iirc. Files would fail to rename, but if you waited 30 seconds and looked for your target file, it would, hey presto, have appeared. But writes also timed out, taking, in this case, a backup job with it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: emulate an end-of-media
Tim Kientzle wrote:
Why compress? It's ancient technology and will be vastly outperformed
Yes, gzip or bzip2 compress better, but they also:
* Are a lot slower.
* Use a lot more data memory.
* Require a lot more code.
I don't understand what a lot more code has to do with anything.
gzip/zlib is part of base and portable.
In my quick tests on some real dump files, *if* you are able to specify
the compression quality, then gzip -1 is both faster and better
compressing than compress. If I'm reading time correctly, then gzip at
any compression level used less memory than compress. bzip2 uses more
memory but -9 always uses roughly the same amount of memory: ~9Mb.
180672 -r--r- 1 root alex - 184893440 Feb 26 09:08
cartman-root.dump.0
131 {root @ ren} # time compress cartman-root.dump.0
7.948u 0.264s 0:08.93 91.8% 15+744k 0+725io 0pf+0w
92896 -r--r- 1 root alex - 95051115 Feb 26 09:08
cartman-root.dump.0.Z
134 {root @ ren} # time gzip -1 cartman-root.dump.0
6.543u 0.288s 0:06.93 98.4% 56+585k 1+549io 2pf+0w
70368 -r--r- 1 root alex - 71979780 Feb 26 09:08
cartman-root.dump.0.gz
137 {root @ ren} # time gzip -9 cartman-root.dump.0
44.588u 0.304s 0:46.53 96.4%56+584k 0+494io 0pf+0w
63344 -r--r- 1 root alex - 64800326 Feb 26 09:08
cartman-root.dump.0.gz
140 {root @ ren} # time bzip2 cartman-root.dump.0
51.327u 0.398s 0:53.44 96.7%30+9638k 3+471io 3pf+0w
60384 -r--r- 1 root alex - 61769750 Feb 26 09:08
cartman-root.dump.0.bz2
And for a largely text filesystem dump:
58352 -r--r- 1 root alex - 59699200 Feb 26 09:13 cartman-var.dump.0
152 {root @ ren} # time compress cartman-var.dump.0
2.179u 0.102s 0:02.31 98.2% 15+737k 0+156io 1pf+0w
2 -r--r- 1 root alex - 20456769 Feb 26 09:13
cartman-var.dump.0.Z
155 {root @ ren} # time gzip -1 cartman-var.dump.0
1.441u 0.069s 0:01.53 98.0% 57+592k 0+116io 0pf+0w
14992 -r--r- 1 root alex - 15328819 Feb 26 09:13
cartman-var.dump.0.gz
158 {root @ ren} # time gzip -9 cartman-var.dump.0
4.807u 0.062s 0:04.89 99.3% 56+583k 0+104io 0pf+0w
13424 -r--r- 1 root alex - 13727598 Feb 26 09:13
cartman-var.dump.0.gz
161 {root @ ren} # time bzip2 cartman-var.dump.0
28.057u 0.132s 0:28.97 97.2%30+9629k 0+91io 0pf+0w
11792 -r--r- 1 root alex - 12052157 Feb 26 09:13
cartman-var.dump.0.bz2
--Alex
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: emulate an end-of-media
Mike Meyer wrote: On Mon, 25 Feb 2008 21:19:33 +0100 Martin Laabs [EMAIL PROTECTED] wrote: Hi, On Mon, 25 Feb 2008 20:34:31 +0100, wrote: You might want to play with the -P option to dump. Your above could be written as: dump -aL0 -P 'compress -c' /MYFILESYSTEM | cdrecord dev=... - Why compress? It's ancient technology and will be vastly outperformed by gzip (and bzip2 but that's slower). Assuming that compress -c cdrecord play nice (which your magic device solution also requires) My solution can just close the pipe at the one end of the magic device which would be realy simple to implement in a script. While you're proposing a magic device that catches sigpipe, and delivers an EOM to make dump -a happy. I'm proposing that dump catch the sigpipe, and treat it like an EOM if it has -a. This may be non-workable, in that you have to be able to tell if it was the -P process or a slave process that generated the sigpipe, but I think it's the best solution. Are there not (at least) two more alternatives? 1) Add gzip/zlib support to dump. That would seem easier than new devices. Then -a would just work. 2) Instead of using cdrecord directly you have a wrapper which emulates the dump -a behaviour by writing 650/700Mb of data using cdrecord then prompting for the next cd. You don't close the pipe, and dump should just block waiting for your device to be ready. Might have trouble accessing /dev/tty - not sure. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
Giorgos Keramidas wrote: On 2008-02-23 16:48, M. Warner Losh [EMAIL PROTECTED] wrote: This knee-jerk reaction against gnu find functionality baffles me. The changes are trivial and make FreeBSD more compatible. It is such an obvious no-brainer that I frankly didn't expect anybody to bat an eye. So should I expect similar knee-jerk reactions to the just committed `finger compatibility' option to implement du -l for hardlinks? FWIW, a vote in favour of compatibility shims. It's just a shame that this won't cut both ways - it would be nice, for example, if Linux find would implement proper units to -atime etc. The FreeBSD syntax of -atime +12h is so much nicer than -amin +720. Ah well, can but dream... --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvi strangeness
Dag-Erling Smørgrav wrote: That doesn't work, however, and neither does 1,; only X,Y works, so if you want to substitute in the entire file, you first have to find out how long it is, then manually type in that number. Does 1,$ not work? That's what I always used in ed. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing C program to core dump
Niclas Zeising wrote: Garrett Cooper wrote: Hello, This may be obvious to some, but after some Googling (apparently with the wrong search terms, perhaps) and reading the gcc/gdb manpages, I can't seem to find out how to get a program to produce core dumps. So I was wondering, is there some simple means to produce core dumps or a set of conditions that I need to adhere to in order to get the OS to core dump the progrdam??? Thanks, -Garrett Just kill it with the abort signal (SIGABRT) or some other signal that makes the program dump core. Be aware though that if you are catching or ignoring the signal, this won't work. Regards! //Niclas Which usually defaults to ctl-\ from the shell so it's easy to kill a foreground program with bothering to find process id's etc. OK, not what you actually wanted to do, but for completeness :-) --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: Re[2]: can't get to work SMBUS or simmilar method for getting thermal sensor data
Andris wrote: Andris wrote: I'm having Asus A7V880 motherboard (AthlonXp, KT880, VT8237) and can't get to work any thermal viewing and control program. I've tried mbmon, healtd, consolehm etc. Some don't work at all (NO HW SENSOR AVAILABLE or simmilar message) or showing constant temperature 255C. Are you sure mbmon or healthd won't work? Forget smbus just try to access the status chip directly. e.g. mbmon -p winbond -c 1 or healthd -c 1. I have two (different from yours) ASUS motherboards with VIA chipsets and healthd works on both and mbmon only on the newer one, but neither needs smbus (and I never managed to get them to work that way when I tried briefly). --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed: On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Are there plans to bump the default up from 8? I'm honestly torn on this topic whenever I install a new system. On the one hand I like having a lot of discrete mountpoints to control potential usage. On the other hand with drive space being so inexpensive I sometimes wonder if I need to bother and can get away with very few mountpoints. I would think that cheap disk space would mean larger disks which implies more mountpoints ??? Nope. One of the historical uses of partitions was to act as firewalls between subsystems, so that subsystem A running out of space didn't cause subsystem B to die for lack of space. This had the downside of making it more likely that one of the two would run out of space because the excess space from another subsystem could only be used by it. With cheap disk space, you overallocate by enough to give you plenty of warning before you have to deal with the issue. You can safely share that space, and doing so means you have to deal with the issue less often. You assume that running out of space happens over time, but with some runaway process logging to a file, for example, the partition filling up will still happen without you expecting it. It might take a bit longer with a big disk, but 20 minutes instead of 5 minutes isn't much different in terms of warning. Fill /tmp or /var and many things can fail. Fill /home and it's just users who suffer a little but mail, demons etc. just carry on. A further reason to separate partitions is that dump works at the level of a partition. Different partitions may have very different backup requirements, and for those of us without huge tape drives, partitioning to a size that can be dumped on one tape makes life easier. In some environments, fewer partitions may indeed be the new norm, but in others it would not. Personally, I would like a limit of 16. It would mean that I could fit all my regular partitions inside a single slice, freeing up other slices for, for example, experimenting with 64-bit, or -current, or whatever. Bootable FreeBSD slices will be stuck at 4 for the foreseeable future - extending the number of partitions within a slice frees up slices, which are the really limited resource. I have no real idea how hard it would be to extend from 8 to 16, but if the effort required were reasonably low, then it would get my vote. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: You assume that running out of space happens over time, but with some runaway process logging to a file, for example, the partition filling up will still happen without you expecting it. It might take a bit longer with a big disk, but 20 minutes instead of 5 minutes isn't much different in terms of warning. Yes, I'm assuming that running out of space happens over time. Sustained I/O speeds on modern hardware was around 100MB/sec last time I looked. So a good, large disk - say a terabyte raid (you need raid to get those performance numbers, so call it 2 500GB disks to keep it simple) - will take about three hours to fill *if you do nothing but write to the disk*. A runaway process - especially one generating log data - is normally doing other things that it's trying to log information about. I don't have terabyte raids and for me a big disk is 250Gb. A runaway system demon writing to disk might well do other things. A badly written user program might do nothing but write to disk. If you run servers that just run a bunch of standard ports and system demons, then this is unlikely to happen to you. If you work in an environment where one or more fallible programmers churn through gigabytes of data it's depressingly easy to accidentally do *nothing* but write to disk. A further reason to separate partitions is that dump works at the level of a partition. Different partitions may have very different backup requirements, and for those of us without huge tape drives, partitioning to a size that can be dumped on one tape makes life easier. That's one of the technical reasons I mentioned in the part you didn't quote. To my mind, it only takes *one* technical reason. If I need multiple partitions to make backups easy, then arguments about log files are irrelevant :-) Well, there are always special cases. But hardware is so cheap these days, I'm used to fine-tuning the *system*, not just the partition. If something is so critical that it needs it's own partition, it's probably so critical that it needs it's own system as well. In fact, most of the thing I work on these days are so critical that they need several systems, half of them at a second site with automatic failover between them. Not everyone is in a position to throw money at everything and what's cheap to you isn't cheap to everyone. I can't possibly justify one system for everything that needs a partition, nor do I even feel the need to do that. If anything, it would be a major inconvenience. Frankly, if you're really worried about bootable slices, you should be advocating giving FreeBSD the ability to boot from a logical volume. Who said I didn't? I have no objection to such a facility and would welcome it. It just imagined that extending the number of partitions from 8 to 16 would have been easier than booting from logical slices. If booting from logical slices is easier then I'm all for it. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: A further reason to separate partitions is that dump works at the level of a partition. Different partitions may have very different backup requirements, and for those of us without huge tape drives, partitioning to a size that can be dumped on one tape makes life easier. That's one of the technical reasons I mentioned in the part you didn't quote. To my mind, it only takes *one* technical reason. If I need multiple partitions to make backups easy, then arguments about log files are irrelevant :-) If you're going to count 1, 2, many, then we already have many partitions, and don't need more. Once you get into finer distinctions of many, you need to figure out which reasons are actually valid, and which are spurious, so you can pick from among those manys. I have no real idea what this means, sorry. It seems to me that whoever made the initial decision to stop at 8 (size of an integer?) clearly thought counting past 2 was worthwhile. Maybe the original reasons no longer apply since quite a lot has changed since then :-) Well, there are always special cases. But hardware is so cheap these days, I'm used to fine-tuning the *system*, not just the partition. If something is so critical that it needs it's own partition, it's probably so critical that it needs it's own system as well. In fact, most of the thing I work on these days are so critical that they need several systems, half of them at a second site with automatic failover between them. Not everyone is in a position to throw money at everything and what's cheap to you isn't cheap to everyone. Boxes are cheaper than disk space - my last two low-end boxes cost less than my last small disk drive, even though I ordered them all about the same time. If you can afford the disk for some process, then chances are good you can afford a system instead, or as well. I don't understand this either. Surely the box has to include the disk space so how can it cost less? If it costs less because it's a cheap piece of junk, why would I even want it? And the cost of the system doesn't stop at the up front price - running costs including maintaining the box surely count (not to mention that I have nowhere to put the damn thing). And I'm not sure where needing a separate partition and criticality became the same thing. I don't claim to want or need separate partitions because any particular subset of the filesystem is critical, but because I want it to be separate for at least the two reasons outlined below. I can't possibly justify one system for everything that needs a partition, nor do I even feel the need to do that. If anything, it would be a major inconvenience. My claim is that your everything that needs a partition probably includes things that don't. But to prove that, we need to examine the reasons you think those things need a partition. I believe the only one you've given so far - as a space firewall - is specious. Except that we also have the dump, and the different params for different parts of the filesystem arguments. I think you agreed that you counted those as technical reasons. Your arguments remind me of the environments I worked on in the 70s and 80s. Minis and mainframes that did all the computing for an organization. All the daemons that talked to the outside world ran on the same box as the developers ran compiles and tests on, etc. While that worked really well when it came to generating a robust OS, I haven't seen an environment like that in decades. Hell, most of my clients would shit bricks at the thought of putting their source or data on a machine that could be reached from the internet at large at all. Every developler has a box - or three - on their desks. The ETL boxes are distinct from the database boxes are distinct from the internal mail server is distinct from the external mail server, etc. If I want to have a process send email notices about something, I usually have to beat on them if I want a mail server on the box. And so on Fine. You have access to lots of money and infrastructure. I don't. Throwing money at a problem is not a solution available to everyone. Frankly, if you're really worried about bootable slices, you should be advocating giving FreeBSD the ability to boot from a logical volume. Who said I didn't? I have no objection to such a facility and would welcome it. It just imagined that extending the number of partitions from 8 to 16 would have been easier than booting from logical slices. If booting from logical slices is easier then I'm all for it. You're not asking the right question just yet. The question shouldn't be which is easier to add, but which provides the most benefit for the least pain (which subsumes the pain involved in adding it). I believe that the benefits of adding more partitions per slice are minimal - there are at least three ways to add more file
Re: [Fwd: Interrupts question]
John Polstra wrote: The problem involving the em device was solved in -current around January by making the device use a fast interrupt handler. If you can update to the latest driver from -current (if it will build on whatever version you are running), you can solve that part of the problem. I don't think there's an equivalent fix for the amr driver, though. Thanks for the info. When we finally upgrade to 6.1 I can see if the -current driver will work and what difference it makes. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Interrupts question]
Oliver Fromme wrote: Thanks for the suggestion. Can you tell me how to disable specific controllers? Were you thinking BIOS? or FreeBSD? I meant to say to disable them in the BIOS. I'm afraid there is no generic way to disable specific devices in FreeBSD anymore. That's what I thought, thanks. I'll have a look at the BIOS next time I can reboot and see what can set turned off. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Interrupts question]
Oliver Fromme wrote: Alex Zbyslaw wrote: John Baldwin wrote: There's no easy answer on this. You'll have to run your own benchmarks. If you don't need USB, then you may just want to leave it out of your kernel which might help some. OK, thanks for the info and suggestions. Regrettably, leaving out USB isn't an option for us. From your dmesg excerpt it seems that you have at least three USB controllers in that machine. Depending on your requirements, it might make sense to disable all of them _except_ one, and then connect your USB devices to that one controller (using additional USB hubs if necessary). Of course, the controller that you keep enabled should be the one that's causing the least problems (which seems to be uhci1 USB-B in your case, if I read your first email Thanks for the suggestion. Can you tell me how to disable specific controllers? Were you thinking BIOS? or FreeBSD? Can device.hints do this? uhci man page is somewhat brief. I'm not sure which of those controllers I might actually need and it might be none of them. The USB requirement is because there is a DRAC (remote console) card which simulates a USB keyboard/mouse and offhand I'm not sure what they are connected to. But if I know how to turn specific controllers off, I can just try and see if what I need still works :-) (Probably studying the dmesg will give me some hints). Thanks, --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Interrupts question]
John Baldwin wrote: Interrupt storm detected on irq18: uhci2; throttling interrupt source which ties to the disk interrupt. Will that be slowing things down? Would increasing the storm threshold help (especially disk performance)? Guess I'm looking for any mitigation that might be possible. There's no easy answer on this. You'll have to run your own benchmarks. If you don't need USB, then you may just want to leave it out of your kernel which might help some. OK, thanks for the info and suggestions. Regrettably, leaving out USB isn't an option for us. I'll schedule some benchmarking for all that ample free time I have :-) Best, --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[Fwd: Interrupts question]
No responses from [EMAIL PROTECTED] Anyone here understand what's going on? Thanks]. __ I was monitoring a machine with systat -vmstat and noticed something about the interrupts and I don't know if it's a problem or not. If it is a problem, is there anything I can do about it? The interrupts for the network interface (em0) on irq 64 exactly match those for a uhc device on irq 16. And the interrupts for the hardware raid (amr) on irq 46 exactly match those for a uhc device on irq 18. The machine is a Dell 2850 running 5.4. Relevant bits from the dmesg are: ioapic0: Changing APIC ID to 2 ioapic1: Changing APIC ID to 3 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 4 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 5 ioapic3: WARNING: intbase 96 != expected base 88 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 32-55 on motherboard ioapic2 Version 2.0 irqs 64-87 on motherboard ioapic3 Version 2.0 irqs 96-119 on motherboard [...] amr0: LSILogic MegaRAID 1.51 mem 0xdfdc-0xdfdf,0xd80f-0xd80f irq 46 at device 14.0 on pci2 [...] em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xecc0-0xecff mem 0xdfae-0xdfaf irq 64 at device 7.0 on pci6 [...] uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xace0-0xacff irq 16 at device 29.0 on pci0 [...] uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xaca0-0xacbf irq 18 at device 29.2 on pci0 [...] Turning off USB isn't an option as it's required for the pseudo-keyboard/mouse used by the DRAC. Here a sample of the interrupt section. The number of interrupts for [EMAIL PROTECTED]/[EMAIL PROTECTED] can easily be in the thousands rather than hundreds. Interrupts 1950 total 6: fdc0 128 8: rtc 13: npx 14: ata 450 16: uhc 409 18: uhc 19: uhc 23: ata 409 46: amr 450 64: em0 4 65: em1 106: ah 107: ah Any insight appreciated, --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Interrupts question]
John Baldwin wrote: On Monday 17 July 2006 10:22, Alex Zbyslaw wrote: No responses from [EMAIL PROTECTED] Anyone here understand what's going on? Thanks]. __ I was monitoring a machine with systat -vmstat and noticed something about the interrupts and I don't know if it's a problem or not. If it is a problem, is there anything I can do about it? The interrupts for the network interface (em0) on irq 64 exactly match those for a uhc device on irq 16. And the interrupts for the hardware raid (amr) on irq 46 exactly match those for a uhc device on irq 18. The machine is a Dell 2850 running 5.4. Relevant bits from the dmesg are: FAQ. It's due to brain damage in the Intel PCIX hubs and can't be fixed directly. Thanks. I did search and couldn't find anything; guess I didn't search for the right thing :-( Any idea how much this might impact performance, especially of the disk? One thing I realised I missed from original dmesg was Interrupt storm detected on irq18: uhci2; throttling interrupt source which ties to the disk interrupt. Will that be slowing things down? Would increasing the storm threshold help (especially disk performance)? Guess I'm looking for any mitigation that might be possible. Thanks again, --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
Giorgos Keramidas wrote: On 2006-05-01 14:02, John Baldwin [EMAIL PROTECTED] wrote: How about the patch below. It restores the behavior of the beep only happening for invalid input by axeing the BSD/OS partition type from the lookup table. Much better, since this is the behavior we initially had, as you explained. Thanks :) Seconded! Thanks, --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
John Baldwin wrote: On Tuesday 02 May 2006 07:36 am, Alex Zbyslaw wrote: Giorgos Keramidas wrote: On 2006-05-01 14:02, John Baldwin [EMAIL PROTECTED] wrote: How about the patch below. It restores the behavior of the beep only happening for invalid input by axeing the BSD/OS partition type from the lookup table. Much better, since this is the behavior we initially had, as you explained. Thanks :) Seconded! Thanks, Does it work? :-) I downloaded the latest boot0.s from cvs, applied you patch and put it on all three disks in this box. On my tests it worked beautifully. Beeped when I selected a non-existent partition and didn't beep when I selected a legitimate one, or just let it time out to the default. (I tried both FreeBSD and WinXP/NTFS partitions for booting and auto-boot). I can't confirm what boot0sio does as I don't have anything set up with a serial console. You'll probably want some more confirmations, but I'd say this was the bees knees. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
Giorgos Keramidas wrote: On 2006-04-30 22:34, Eric Anderson [EMAIL PROTECTED] wrote: This thread: http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020572.html mentions a patch to disable the boot manager beep, and also discusses having it optional. Does something like the following sound reasonable (I haven't had a chance to run this through a build-test, so use with care). The default behavior should be to *include* a beep, but it can be turned off by setting WITHOUT_BOOTEASY_BEEP in `/etc/src.conf'. I have a very similar patch which I pulled from somewhere not long after switching to 5.4. That wrapped the beep inside #ifdef SIO (which I assumed was something standard, but don't know) so that you got a beep with a serial console and not without. I can see the advantage of the beep when running headless, but for anything with a console the beep just seems like something out of the 1970s. My vote (fwiw) would be to reverse the logic and have WITH_BOOTEASY_BEEP so that it's off by default unless you turn it on with the option *or* if you have a serial console (assuming that SIO is something standard). At the same time I also patched so that NTFS filesystem was recognised as DOS, to get rid of the ?? on standard dual-boot Win/FreeBSD machines. For me, this still comes in under 512 bytes, though I don't know by how much since the make process seems to pad to 512 bytes. The ?? has been a recurring complaint and the fix was easy enough and works for me (TM). --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
Giorgos Keramidas wrote: I'd certainly prefer it if the beep was turned *off* by default, but I'm not sure if that's what everyone prefers. This is why I opted for keeping the current behavior and making my personal preference an option :) The beep didn't appear until 5.X (and generated quite a few complaints), so the weight of history is behind no beep! The only argument in favour of the beep that I ever so was headless machines. I suspect this could easily turn into a bit of a bikeshed, and a way to turn off beeps without patching boot.S every time would be good regardless of what the default is. But my vote definitely goes for: headless=beep, headed=no beep. IMHO, the beep in 5.X astonished me (in a minor, but particularly irritating, way) and I bet you'd get lots of people saying thank you for getting rid of that damn beep. The trouble I see with on-by-default is that many people won't realise they can now turn it off. I probably shouldn't suggest that it should be an option in sysinstall ;-) --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot manager beep (revisited)
Dag-Erling Smørgrav wrote: Alex Zbyslaw [EMAIL PROTECTED] writes: At the same time I also patched so that NTFS filesystem was recognised as DOS, to get rid of the ?? on standard dual-boot Win/FreeBSD machines. Huh? I did that more than a year ago: You beat me to it then ;-) http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1506483+0+archive/2005/freebsd-questions/20050612.freebsd-questions Since I'm on 5.4 I guess I just haven't got your changes yet. Thanks for doing it, though. Be nice not to have to remember to patch boot.S every time I rebuild. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Crash without Errors, Warnings, or Panics
Paul Saab wrote: The amr driver was not MPSAFE in 5.4 (i think) so you would not have run into these problems. You should be able to just take the driver from RELENG_6 and use it on a released branch. If it doesn't compile, let me know and I'll generate you a tarball or diff that will work. We had major issues with amr at work until Scott Long and I (mostly Scott) helped iron out the stability issues with amr. You should either run RELENG_6 or take the driver from RELENG_6 and use that. You'll get the added benefit of being able to use the Linux management tools (megarc) to see the status of your raid. Presumably this change will make it into 6.1 and is already in the betas/RCs? I'm confused by the megarc comment. There is a port of megarc in the ports which appears to work under 5.4 already, though I've only used it for simple reporting. I've seen references to Scott and your work on improving the driver which uses the same phrase Linux management tools but have no real idea what that refers to. Are there tools beyond megarc which now work? If so, any pointers much appreciated. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Crash without Errors, Warnings, or Panics
Matthew Hagerty wrote: Can anyone shed some light on this, give me some options to try? What happened to kernel panics and such when there were serious errors going on? The only glimmer of information I have is that *one* time there was an error on the console about there not being any RAID controller available. I did purchase a spare controller and I'm about to swap it out and see if it helps, but for some reason I doubt it. If a controller like that was failing, I would certainly hope to see some serious error messages or panics going on. I have been running FreeBSD since version 1.01 and have never had a box so unstable in the last 12 or so years, especially one that is supposed to be server quality instead of the make-shift ones I put together with desktop hardware. And last, I'm getting sick of my Linux admin friends telling me told you so! should have run Linux..., please give me something to stick in their pie holes! Several times now I have had Linux servers (and production quality ones, not built by me ones :-)) die in a somewhat similar fashion. In every case the cause has been either a flaky disk or a flaky disk controller, or some combination. What seems to happen is that the disk is entirely lost by the OS. At that point any process which never accesses the disk (i.e. is already in memory) is able to run but the moment any process tries to access the disk it locks up. So you can't ssh in to the server, but if you happen to be logged in, you shell is probably cached and keeps working. If you typed ls recently, you can run ls (but see nothing or get a cryptic error message like I/O Error), for example. Clearly nothing is logged as the disk has gone AWOL. Often the machines behaved fine after a reboot and then did the same some time later. In one case, the supposedly transparent RAID-1 array was completely broken, but Linux logged precisely nothing to tell you :-( You can stick that where you like in your Linux friends :-O This somewhat fits with your symptoms. If the disk vanished, then all those postgres processes would probably fail unless everything they needed happened to be cached in RAM. The Web server and PHP scripts probably are cached in RAM if they are called frequently so you might well see lots of postgres processes stacked up. LSI MegaRAID has a CLI of sorts in sysutils/megarc. You might start with that (and check the RAID BIOS next time the machine reboots). I'd say that if you have an alternative RAID controller that would be a good place to start. If LSI do any stndalone diagnostics, you could try those. --Alex PS Kernel's usually panic when some internal state is just too wrong to continue. A disk or even a controller disappearing isn't going to make the internal state wrong - it's just a device gone missing - so I would not be surprised if the machine just locked up. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Crash without Errors, Warnings, or Panics
Matthew Hagerty wrote: Alex Zbyslaw wrote: Matthew Hagerty wrote: Can anyone shed some light on this, give me some options to try? What happened to kernel panics and such when there were serious errors going on? The only glimmer of information I have is that *one* time there was an error on the console about there not being any RAID controller available. I did purchase a spare controller and I'm about to swap it out and see if it helps, but for some reason I doubt it. If a controller like that was failing, I would certainly hope to see some serious error messages or panics going on. I have been running FreeBSD since version 1.01 and have never had a box so unstable in the last 12 or so years, especially one that is supposed to be server quality instead of the make-shift ones I put together with desktop hardware. And last, I'm getting sick of my Linux admin friends telling me told you so! should have run Linux..., please give me something to stick in their pie holes! Several times now I have had Linux servers (and production quality ones, not built by me ones :-)) die in a somewhat similar fashion. In every case the cause has been either a flaky disk or a flaky disk controller, or some combination. What seems to happen is that the disk is entirely lost by the OS. At that point any process which never accesses the disk (i.e. is already in memory) is able to run but the moment any process tries to access the disk it locks up. So you can't ssh in to the server, but if you happen to be logged in, you shell is probably cached and keeps working. If you typed ls recently, you can run ls (but see nothing or get a cryptic error message like I/O Error), for example. Hmm, that just seems odd that a disk controller just vanishing would not cause some sort of console message? Even if the disk device is gone, /dev/console should still be intact to display an error, no? Also, a disk device that is all of a sudden missing seems pretty serious to me, since a disk is one of the main devices that modern OSes cannot run without (generally speaking.) I would think *some* console message should be warranted. Not if syslogd tries to access the disk :-( All can say is that I have seen three Linux boxes go this way; I've never had this kind of failure on a BSD box (touch wood) so all I can do is speculate about the similarities. Also, you did get a console message once, didn't you? I'll see if there are any diag programs for the controller and I'll go ahead and swap the controller out. I wonder if the RAID configuration in stored in the controller or on the disks? I'd hate to have to rebuild the server install... I believe both and the RAID controller will compare what it thinks it should see with what it sees on the disks. If you are moving to a new, identical controller I would have thought that the worst you would have to do is to reconfigure it to accept the disks you give it as your specified configuration without it trying to rebuild anything. hth, --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
No auto reboot after panic
(This message started life on questions, but no responses :-( If there's a better list to try, please point me! I have no clue how rebooting actually works). Setup: Dell 2850 running i386 FreeBSD 5.4-p5 (or so), ACPI enabled and apparently working (shutdown -p or -r work fine). After a kernel panic, the console showed Automatic reboot in 60 seconds or press any key to interrupt, (or words to that effect), but actually the machine just sat there for several hours. When I got to the console, pressing a key said it was interrupting the automatic reboot (as if the key press had happened in the 60 second window) and pressing another key rebooted the server. Does anyone have any idea why the server didn't reboot automatically, and what might make it reboot next time it panics (if there is a next time)? I'm sure I've seen a similar problem mentioned before, but searching the mail archives and google didn't turn up anything useful that I could see. Thanks, --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Programs not accepting input?
Greg 'groggy' Lehey wrote: Same here. As mentioned in the original message, I can use the mouse to open a new window under firefox. The new window will accept keyboard input, the old one won't. It's almost as if it's deadlocking on input. Just a me too. I used to get this with mozilla just as you described for Firefox but haven't had it in a while (fingers crossed). This is using standard Xorg server, single head display, simple window manager (fvwm2). Some time ago I switched to the NVidia driver over the Xorg one, but I really don't know that this is related. Just that I switched some time ago and that I haven't had the lockup in a while. For all I know, I unconsciously stopped doing whatever it was that triggered the lockup :-( --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A smarter mergemaster
Brian Candler wrote: That's my biggest bugbear with mergemaster - it asks you about a zillion files in /etc/rc.d which you have to manually agree to overwrite just because the RCS ID has changed. In those cases where you've not altered them yourself, I think you should just get the latest version. However to do this properly, you'd need checksums of the original files. [*] Not necessarily. Diff can be made to ignore changes which match specific regular expressions (-I), so if you can reliably match the RCS Id lines you can ignore those changes. Note, though, that this is different from files which you haven't changed. The new version might change more than the RCS Id, in which you would be back to checksums, or some such. However, a change to automatically install files where *only* the RCS Id had changed would be easier and quicker to effect than the general case of all files which you hadn't changed. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to reset root passwd FreeBSdD4.7
Vyacheslav Sotnikov wrote: but what to do if i have consoleinsecure in /etc/ttys? I believe you can Boot cdrom Pick Change system manager's password Type the new password. Worked fine from /stand/sysinstall, but you have to be root to do that from the command line :-) --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing a packet through an interface (OT?)
Mario Lobo wrote: Yeah Stefan. They do take the default route. That is what I am already doing. I even wrote a little prog using a variation of ping to do just that. The problem lies with the fact that, there is a router between my rl0 and the internet. 1) rl0 --- router -- antenna -- ISPx -- internet So the fact that i can ping the hop next to rl0 doesn´t mean the link is up :(. That is why I NEED to ping something on the internet. I don't think so. You can follow Chad Leigh's advice and ping a router on your ISP. Figure out where your packets through ISP1 are routed (try traceroute) and then add a static route through ethernet1 to that router. You can do similar for ISP2. Then a ping of either router will always try to go through the network card appropriate to that ISP. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
