Re: impossible packet length ...
On Feb 8, 2009, at 3:31 AM, Danny Braniss wrote:
--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2009-Feb-08 10:45:13 +0200, Danny Braniss
wrote:
Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard
frame w/o=20
leading ethernet header (len 0 pkt len 0)
=2E..
Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $
sequence in=20
"rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM-
^KoM- a=
base"
Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet
length=
=20
(2068989523) from nfs server sunfire:/dist
which seems to point fingers at bce...
It does rather suggest that bce is not behaving. What happens if you
turn off checksum off-loading? This should make the kernel drop the
corrupt packets instead of trying to process them. If practical, you
could also try (temporarily) plugging in a different NIC.
I have, and now it's a matter of waiting...
Q: with rxcsum on, and a bad checksum packet is received, is it
dropped by the NIC? if not, then it somewhat explains the behaviour
changing the nic is tough, but if needed will be done.
danny
Peter Jeremy
We were hitting this quite a bit (also bce), and updated to a recent 7-
branch and it seems to be behaving better for now. Running 12 days so
far (which is better than what we had been seeing).
Eric
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Analysis of disk file block with ZFS checksum error
Joe Peterson wrote: Gavin Atkinson wrote: Are the datestamps (Thu Jan 24 23:20:58 2008) found within the corrupt block before or after the datestamp of the file it was found within? i.e. was the corrupt block on the disk before or after the mp3 was written there? Hi Gavin, those dated are later than the original copy (I do not have the file timestamps to prove this, but according to my email record, I am pretty sure of this). So the corrupt block is later than the original write. If this is the case, I assume that the block got written, by mistake, into the middle of the mp3 file. Someone else suggested that it could be caused by a bad transfer block number or bad drive command (corrupted on the way to the drive, since these are not checksummed in the hardware). If the block went to the wrong place, AND if it was a HW glitch, I suppose the best ZFS could then do is retry the write (if its failure was even detected - still not sure if ZFS does a re-check of the disk data checksum after the disk write), not knowing until the later scrub that the block had corrupted a file. I think that anything is possible, but I know I was getting periodic DMA timeouts, etc. around that time. I hesitate, although it is tempting, to use this evidence to focus blame purely on bad HW, given that others seem to be seeing DMA problems too, and there is reasonable doubt whether their problems are HW related or not. In my case, I have been free of DMA errors (cross your fingers) after re-installed FreeBSD completely (giving it a larger boot partition and redoing the ZFS slice too), and before this, I changed the IDE cable just to eliminate one more variable. Therefore, there are too many variables to reach a firm conclusion, since even if the cable was "bad", I never saw one DMA error or other indication of anything wrong with HW from the Linux side (and I've been using that HW with both Linux and FreeBSD 6.2 for months now - no apparent flakiness of any kind on either system). So either it *was* bad and FreeBSD 7.0 was being more "honest", FreeBSD's drivers and/or ZFS was stressing the HW and revealing weaknesses in the cable, or it was a SW issue that got cleared somehow when I re-installed. Is it possible that the problem lies in the ATA drivers in FreeBSD or even in ZFS and just looks like HW issues? I do not have enough info/expertise to know. If not, then it may very well be true that HW problems are pretty widespread (and that disk HW cannot, in fact, be trusted), and there really *is* a strong need for ZFS *now* to protect our data. If there is a possibility that SW could be involved, any hints on how to further debug this would be of great help to those still experiencing recent DMA errors. I just want to be more sure one way or the other, but I know this issue is not an easy one (however, it's the kind of problem that should receive the highest priority, IMHO). I'm not sure what happened to this thread, but I also had a lot of similar issues. I was using SATA, and using a mirrored pair of SATA drives, brand new. It was suggested that my controller was junk. I'm starting to think there is a timing issue or some such problem with ZFS, since I can use the same drives in a gmirror with UFS, and never have any data problems (md5 checksums confirm it over-and-over). I highly doubt that everyone is seeing similar issues and it just is because ZFS is so intense. I've had plenty of systems under severe disk load that have never exhibited corrupt files because of something like this. I wish we could get our hands on this issue.. Seems like some common threads are ATA/SATA disks. Is your setup running 32bit or 64bit FreeBSD? (if you already mentioned it, I'm sorry, I missed it) Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive?
Dennis Melentyev wrote: Can't confirm, but it seems like formating card with phone will give you FAT12 even on 1Gb card. (Not volunteering to reformat my "player") :) It would be useful to some people to have access to a FAT12 formatted file system that is >32MB. Can you (or someone else) dd the flash to a file (the 64MB file is file), and then gzip it? Preferably a freshly formatted fat12 would be best. Eric 2007/7/2, Dennis Melentyev <[EMAIL PROTECTED]>: Hi! 2007/7/2, Raaf <[EMAIL PROTECTED]>: > Brian Chu wrote: > > Raaf, > > > > What's the size of the memory stick? Is it 32MB like Dennis has? It was 64MB card also. :) AFAIR, FAT12 is just not correct format for disks larger than 32Mb. It has to use clusters not handled by original MSDOS in this case. So, my answer is: SE just use wrong FAT. But, meanwile, it should be ok to allow this insanity be handled. Despite I'd rather use smaller clusters for such a tiny drive. > > > > It's a 64MB memory stick using FAT12. MSDOS 3.3 will go crazy with that :) > > > The check for the field that affected you isn't critical to msdosfs' > > operation, but the field itself is specified to be non-zero. > > Konstantin, is it alright to remove this field? > > > > It seems there are more people having problems with the sanity checking > code of msdosfs, see also this related pr: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=93860 > > -- Dennis Melentyev ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent VFS crashes with RELENG_6
On 10/31/06 08:03, Vlad Galu wrote: On 10/1/06, Cy Schubert <[EMAIL PROTECTED]> wrote: In message <[EMAIL PROTECTED]>, "Vlad GALU" writes: On 9/30/06, Martin Blapp <[EMAIL PROTECTED]> wrote: Hi, 1.) Bad ram ? Have you run some memory tester ? Yes, memtest86 didn't show anything weird. 2.) Have you background fsck running on this disk ? If so try to boot into single user and do a full fsck on this disk. I have background_fsck="NO" in rc.conf and I checked the whole disk several times. Something I forgot to mention earlier: the crash is easier to reproduce when running rtorrent. The machine did crash without running it as well, but far more seldom. I've been experiencing the same problem as well. I discovered that the disk on which the filesystem was had some bad sectors causing dump -0Lauf to fail while taking snapshot causing the system to panic. Running smartctl on the device indicated that there were bad sectors 40% within the surface scan being performed by SMART. The drive, an 80 GB Maxtor, was replaced with a 250 GB Western Digital (for a very good price, so good a price I purchased two of them). It was 906 days old, having only been powered off maybe a dozen times over the last three years. During the last 2 weeks I ran the same system with WITNESS turned on. The fact that the purpose of this machine is not I/O dependant allowed me to run bonnie++ and iozone every second day for the whole 24 hours. At the same time I ran several instances of rtorrent. This morning I rebooted to a non-WITNESS kernel (the same sources from 2 weeks ago) and the exact same crash occured within a few hours from bootup. In all this time, smartd didn't report anything suspicious. WITNESS only reported a LOR related to kqueue that is already known. Any ideas for further stresstesting would be welcome. I am familiar with a few parts of the kernel, but VFS is a total stranger to me. Did you get a crash dump? If not, you might want to start with adding all the debugger options into the kernel. Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall creates corrupt filesystems after repartitioning
On 03/01/07 17:42, Steven Hartland wrote: I've been repartitioning some of our machines here and found that using the following method sysinstall creates corrupt filesystems. 1. Boot a machine using an nfs mounted /usr 2. Run: sysctl kern.geom.debugflags=16 to enable writing to the disk mbr 3. run sysinstall, Customise -> Label 4. Delete the /usr partition e.g. /dev/da0s1f 5. Create two partitions from the space left as ufs with mount points /usr and /data 6. Write the changes. Now two strange things happen: 1. /usr ends up mounted twice once from nfs and once from the new ufs. This requires umount -f /dev/da0s1f to correct but doesnt always work properly requiring a reboot to restore system functionality. 2. The FS on both partitions is totally corrupt even fsck cant repair them, even after a reboot. So the question is why would sysinstall create two corrupt FS's with this procedure? Fixing is trivial just rerun the newfs commands and all is good but its really odd that they should be corrupt in the first place and caught me out big time when I first did this as I had restored a full dump back onto /usr and rebooted only for it to blow up horribly as the fs was so badly corrupted. Steve I don't know about the fs corruption, but the double mounts is something you asked it to do (maybe unknowingly). When you added that partition, one of the options is to mount it. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall creates corrupt filesystems after repartitioning
On 03/02/07 07:46, Steven Hartland wrote: Eric Anderson wrote: I don't know about the fs corruption, but the double mounts is something you asked it to do (maybe unknowingly). When you added that partition, one of the options is to mount it. Clearly an easy work around in that case then but personally I would expect a mount to a directory already in use by another mount point to fail. Taking even further a mount to a directory that is not actually empty should fail. IIRC this is how solaris behaves but its been a while. Checking for an empty target directory certainly makes sence to me is there some case where it would be desirable to allow this to happen? If so maybe a force flag should created without which a mount to a none empty dir would fail. Either way allowing multiple mounts to the same location is bound to cause all manor of confusion and should be prevented. Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall creates corrupt filesystems after repartitioning
On 03/02/07 08:37, Steven Hartland wrote: Eric Anderson wrote: On 03/02/07 07:46, Steven Hartland wrote: Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Interesting if that's a valid thing to do why does everything break when its done? Is it ment to be doing a union hence you get the combined contents of both? If so its not working correctly in this case :( Can you provide me with more info on how this is supposed to work eric please. No, it won't do a union unless you use union. Things break because you mounted an empty /usr on top of a working /usr. That just breaks things, because you probably need binaries in /usr. The OS doesn't know whether you want to mount an empty fs on a populated one, or what. It does exactly what you ask it to do, and in this case, it was a bad thing. Think of a thin client that has just enough stuff in /usr to make it boot and run a few tools. Then, depending on a startup option, it mounts a more populated /usr from NFS (or even a local disk, doesn't really matter) over the previous /usr. The fact is this: you made a new partition, called it /usr, and told sysinstall to mount it. It did. That happened to be a problem for you, which I could imagine it would be. Now, I'm not claiming this is the cause of your file system corruption issues. I'm just saying the duplicate mount is not a bug, it's a feature. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall creates corrupt filesystems after repartitioning
On 03/02/07 08:44, Jeremy Chadwick wrote: On Fri, Mar 02, 2007 at 08:11:52AM -0600, Eric Anderson wrote: Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Are we absolutely sure overlaying NFS + local UFS filesystems like this is the cause of the filesystem corruption? If Eric's doing it and it's working fine, I'm left wondering if there's maybe sysinstall isn't handling something right. No no no - I don't think there's anything wrong with that at all, and I don't think the two are related. I was merely trying to point out that the doubling of mounts is normal, expected, and a feature. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall creates corrupt filesystems after repartitioning
On 03/02/07 09:37, Steven Hartland wrote: Jeremy Chadwick wrote: On Fri, Mar 02, 2007 at 08:11:52AM -0600, Eric Anderson wrote: Mounting an NFS share on top of a skimmed down /usr is very common, and very desirable. You may mount /usr from a small read-only partition (vnode file, etc) and then mount a different partition or NFS over it if you detect the one you want. I think this comes down to: if it hurts, stop doing it. :) Maybe sysinstall should warn you that you are double mounting, but I don't want it to stop letting me do it. Are we absolutely sure overlaying NFS + local UFS filesystems like this is the cause of the filesystem corruption? If Eric's doing it and it's working fine, I'm left wondering if there's maybe sysinstall isn't handling something right. I've rerun the test just to confirm but there are definitely two seperate issues here: 1. The ufs created by sysinstall after a repartition is corrupt. This is totally unrelated to the overlay of /usr as both /usr and /data ( which didnt previously exist ) where corrupted. 2. Once the blank /usr was mounted over the working nfs /usr apps under /usr couldnt be run e.g. vim gave me no such file.. After unmounting the ufs /usr using "umount -f /dev/da0s1f", without -f it gave a error due to use even know nothing was in use on it, the functionaility returned. Now this could be related to the corruption of the underlying ufs partition. If this is the case then solving #1 will also fix #2 So try the same test, with *only* the data partition, without messing with the /usr stuff.. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mount on non-empty directories (Was: sysinstall creates corruptfilesystems after repartitioning)
On 03/02/07 09:56, Steven Hartland wrote: Mike Meyer wrote: In <[EMAIL PROTECTED]>, Steven Hartland This is just a special case of mounting on a non-empty directory. It should work right. The last mounted file system is the one you get (unless you're using a file system that's designed to behave another way). If you unmount the directory, the last mounted device is unmounted. This makes sence but is not what happens hence the confusion. If the last mounted FS is the one you get that makes sence but in this case thats not what I observed. Are you sure? In your last email, you described the above interaction exactly (you had an NFS mounted /usr, then you made a new empty /usr, and it mounted it on top, then you couldn't execute things in /usr anymore (vim was your example), then you unmounted the last mounted fs (the empty one), and your vim was accessible again.. ? As a general rule, deciding that something is "useless and dangerous" and removing it isn't the Unix way of doing things. Just because you can't see a use for something doesn't mean that no one else will. That's true even if you wrote the code. Someone doing something with your program you never thought of is a sign that you developed a generally useful tool. As for dangerous, Unix users - especially root, and mount is restricted to root by default - are assumed to know what they're doing. Appreciated but the issue I'm trying to understand is that the result didn't make any sence i.e. ls returned the files but trying to run them didnt work. Result my head started to spin a bit :P As mentioned this seemed to easily resolved by force unmounting the second device but as has been explained this has a clear use for which I was unaware but I'd still like to understand by I saw what I did i.e. ls displayed the files yet running vim didnt. I'm going to investigate this more in an effort to determine why I got these results and report back. Thanks for everyone's feedback so far most appreciated. Ok, at this point, you need to send df, mount, and your ls output between each step. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Some Unix benchmarks for those who are interesed
On 03/07/07 23:13, Fluffles wrote: Ivan Voras wrote: Fluffles wrote: If you use dd on the raw device (meaning no UFS/VFS) there is no read-ahead. This means that the following DD-command will give lower STR read than the second: no read-ahead: dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 read-ahead and multiple I/O queue depth: dd if=/mounted/mirror/volume of=/dev/null bs=1m count=1000 I'd agree in theory, but bonnie++ gives WORSE results than raw device: On what hardware is this? Using any form of geom software RAID? The low Per Char results would lead me to believe it's a very slow CPU; maybe VIA C3 or some old pentium? Modern systems should get 100MB/s+ in per-char bonnie benchmark, even a Sempron 2600+ 1.6GHz 128KB cache which costs about $39. Then it might be logical DD gets higher results since this is more 'easy' to handle by the CPU. The VFS/UFS layer adds potential for nice performance-increases but it does take it's toll in the form of cputime overhead. If your CPU is very slow, i can imagine these optimizations having a detrimental effect instead. Just guessing here. Before making speculative claims about slow CPU's and putting the VIA C3 in with that pile, please at least refer to what makes you believe that it is an issue. Comparing the VIA C3 to 'some old pentium' isn't exactly fair or accurate, and inferring it isn't a modern system isn't true either. Forgive me though, I'm biased. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Some Unix benchmarks for those who are interesed
On 03/08/07 09:58, Fluffles wrote: Eric Anderson wrote: On 03/07/07 23:13, Fluffles wrote: On what hardware is this? Using any form of geom software RAID? The low Per Char results would lead me to believe it's a very slow CPU; maybe VIA C3 or some old pentium? Modern systems should get 100MB/s+ in per-char bonnie benchmark, even a Sempron 2600+ 1.6GHz 128KB cache which costs about $39. Then it might be logical DD gets higher results since this is more 'easy' to handle by the CPU. The VFS/UFS layer adds potential for nice performance-increases but it does take it's toll in the form of cputime overhead. If your CPU is very slow, i can imagine these optimizations having a detrimental effect instead. Just guessing here. Before making speculative claims about slow CPU's and putting the VIA C3 in with that pile, please at least refer to what makes you believe that it is an issue. Comparing the VIA C3 to 'some old pentium' isn't exactly fair or accurate, and inferring it isn't a modern system isn't true either. I'm sorry if i offended you. But it is well-known that C3 Nehemiah has a much lower IPC than processors from AMD and Intel. For general purpose comparisons, i would guess a 400MHz Athlon 64 to outperform the 1GHz C3 Nehemiah; just guessing here! Not to talk about Core2Duo who has even higher IPC. No offense, I just prefer the fud to be kept off lists - it's essentially trolling I suppose. No doubt the C3 and C7 processors are slower than the top of the line Intel and AMD's - that's like comparing a Prius with a Porsche. If you can find a 400MHz Athlon 64, I'd enjoy seeing the benchmarks. :) However, just simple benchmarks for IPC don't tell much about a processor. Though Nehemiah does have some fancy MPEG/AES hardware acceleration stuff built-in, which makes it a suitable platform for a Media Center or anything like that. Personally i think a budget AMD processor to be a better option; they have the same power consumption under standby mode (thanks to Cool'N'Quiet) but can deliver much higher performance when needed (such as HighDef 1080p video?). Well, not actually the same power consumption at all. Again, do a little googling here, and you might find some actual numbers (not just reported numbers). The bonnie Per Char-benchmark is often bottlenecked by the CPU since it requires either a lot of cpu power or a lot of memory activity; both which puts demands on the cpu. If i see only 0.5MB in the Per Char-benchmark, i would suspect a slow CPU. Slow is a relative term though; C3 can be powerful enough for the task you bought it, so i don't want to discredit it. Dunno. I was merely trying to keep things honest, since what was communicated (whether intended or not) was that a C3 isn't modern, and is akin to a Pentium, which it isn't. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Some Unix benchmarks for those who are interesed
On 03/09/07 12:55, Chuck Swiger wrote: On Mar 8, 2007, at 9:24 PM, Eric Anderson wrote: [ ... ] Dunno. I was merely trying to keep things honest, since what was communicated (whether intended or not) was that a C3 isn't modern, and is akin to a Pentium, which it isn't. I've got a VIA C3 Samuel myself, and it is fine for what it is, which is a low-power clone of the Pentium-MMX in terms of capabilities; the newer C3 Nehemiah is roughly comparable to a P2, plus SSE and the extra AES/RNG crypto stuff. Look at dmesg or cpuid and compare CPU features. I'm pretty familiar with C3 and C7 chips. I wouldn't compare performance of a CPU based on CPU features. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck: cannot increase directory list and Out of Memory .
Ricardo A. Reis wrote: Hi, I have severals problems with one server ibm x346, i use FreeBSD 6-STABLE, After a electric panic, this system refused to pass fsck with a message "fsck: cannot increase directory list" , the ibm bios not notified per "memory errors", i rebooting and boot with fresbie and pass fsck and this work. In the same machine i have a geom concat volume with +/- 90 GB, i don't have success to pass fsck on console "cannot alloc 6404196 bytes for bockmap ". Before fail geom mount i comment this partition on fstab, i resolved reboot for normal boot but any commands and login resulted in "out of memory" You need to increase the maxdsiz setting to something bigger - the default I believe is 512MB, so if you have say, 1GB of memory, you may try setting it to 800MB. You set it in /boot/loader.conf by adding a line like this: kern.maxdsiz="76800" Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: g_vfs_done with offset greater than disk size
Steven Hartland wrote: I've been trying to get a problem fixed with a Highpoint 1820a crashing out with errors like: kernel: IAL: COMPLETION ERROR, adapter 0, channel 2, flags=104 kernel: ATA regs: error 10, sector count 20, LBA low ff, LBA mid ff, LBA high ff, device 4f, status 51 which results in the disk being dropped from the array. A sharp eyed engineer at Highpoint has just spotted the fact that the read error reported later is well beyond the end of the array ( 750Gb ): kernel: g_vfs_done():da0s1h[READ(offset=535260184576,length=131072)]error = 5 As such is it possible there is a problem in the FS that fsck is not detecting which could be causing this behaviour when an rsync ( read only ) is performed against it? If there is indeed a vfs error which fsck is not detecting how would I go about: 1. finding it 2. fixing it I recently sent a very similar issue to freebsd-geom list, with no responses yet (just sent it last week). I've got a system with ICH6 (or ICH7 maybe) controller, and a SATA disk. I don't believe it's a driver issue, and I don't think it's an fs issue, since I was dd'ing an image onto the disk, and the image contained linux partitioning and an ext2 fs. I think it has to do with the tasting (or re-tasting) of the GEOM devices, but that's pretty much a guess. Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: ffs_valloc: dup alloc
I get the above panic after nfs clients attach to this nfs server and being read/write ops on it after an unclean shutdown. I've fsck'ed the fs, and it marks it as clean, but I get this every time. It's an NFS share of a GEOM stripe (about 2TB). mode = 0100600, inum = 58456203, fs = /mnt panic: ffs_valloc: dup alloc I do have dumps from two crashes so far. This is FreeBSD-6.1-PRERELEASE from Friday-ish. What should I do with these vmcores? (please cc/to me since I am not on -stable list) Thanks! Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: ffs_valloc: dup alloc
Uwe Doering wrote: Eric Anderson wrote: I get the above panic after nfs clients attach to this nfs server and being read/write ops on it after an unclean shutdown. I've fsck'ed the fs, and it marks it as clean, but I get this every time. It's an NFS share of a GEOM stripe (about 2TB). mode = 0100600, inum = 58456203, fs = /mnt panic: ffs_valloc: dup alloc Do you happen to have disk mirroring on this server (RAID 1)? At work, on a workstation with RAID 1, we once had a case where after a power failure fsck would succeed, but subsequently, when mounting and using the partitions, the kernel still paniced because of a corrupt filesystem. Repeatedly. This caused some major head scratching on our part until we figured out what was happening. The mirrored disks had gone out of sync. For performance reasons, a RAID 1 controller reads data from one disk drive or the other, depending on which drive is less busy in that particular moment. So while fsck was able to find and fix some filesystem inconsistencies there were still some more left in disk sectors it didn't access. The RAID controller we used turned out to have a verification mode where it would scan the disks and re-synchronize them. Afterwards we did another fsck run, and this fixed the remaining filesystem inconsistencies. The kernel panics were gone. Now, with the information you've provided I can't tell whether these findings apply to your case, but perhaps this story helps at least others in a similar situation. I do have mirroring enabled on the OS drives, but this is happening with an external fiber channel array of SATA disks, striped using gstripe. Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: ffs_valloc: dup alloc
Mike Tancsa wrote:
At 04:48 PM 13/03/2006, Eric Anderson wrote:
I get the above panic after nfs clients attach to this nfs server and
being
I do have dumps from two crashes so far.
This is FreeBSD-6.1-PRERELEASE from Friday-ish.
Dont know if it was fixed or not, but there were a lot of VM changes
committed last night that might help.
http://lists.freebsd.org/pipermail/freebsd-stable/2006-March/023526.html
I just updated, and it still happens. More information for those
interested:
mode = 0100600, inum = 58456203, fs = /mnt
panic: ffs_valloc: dup alloc
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc064482f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0644b55 in panic (fmt=0xc0890967 "ffs_valloc: dup alloc") at
/usr/src/sys/kern/kern_shutdown.c:555
#3 0xc077ee3c in ffs_valloc (pvp=0xc8eab440, mode=33152, cred=0xc8a91d80,
vpp=0xe83a5824) at /usr/src/sys/ufs/ffs/ffs_alloc.c:945
#4 0xc07a5933 in ufs_makeinode (mode=33152, dvp=0xc8eab440, vpp=0xe83a5acc,
cnp=0xe83a5ae0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2165
#5 0xc07a2b0d in ufs_create (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:171
#6 0xc082dc98 in VOP_CREATE_APV (vop=0x0, a=0xe83a5a18) at vnode_if.c:204
#7 0xc0737590 in nfsrv_create (nfsd=0xc8a91d00, slp=0xc8816700, td=0xc7d99780,
mrq=0xe83a5c98) at vnode_if.h:111
#8 0xc0744e95 in nfssvc_nfsd (td=0x0) at
/usr/src/sys/nfsserver/nfs_syscalls.c:472
#9 0xc0744688 in nfssvc (td=0xc7d99780, uap=0xe83a5d04) at
/usr/src/sys/nfsserver/nfs_syscalls.c:181
#10 0xc081cd7f in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 1, tf_esi = 0, tf_ebp =
-1077941448, tf_isp = -398828188, tf_ebx = 4, tf_edx = 672385208, tf_ecx = 25,
tf_eax = 155, tf_trapno = 12, tf_err = 2, tf_eip = 671840155, tf_cs = 51,
tf_eflags = 662, tf_esp = -1077941476, tf_ss = 59}) at
/usr/src/sys/i386/i386/trap.c:981
#11 0xc0809e8f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#12 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Maybe that helps somebody?
Should I sent this to -current instead, since it appears this would
happen under -current also, and possibly there is a larger base of
people watching the list?
Thanks!
Eric
--
----
Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD/i386 6-stable + 4 GB RAM
Oliver Fromme wrote: Hi, I'll be getting a few new machines for a customer soon. They will be SMP (dual processor Pentium-IV) with 4 GB RAM, and I plan to install FreeBSD/i386 6-stable on them. What's the current status of running with that amount of memory? I'm not completely up to date in that regard, and searching the archive didn't get any definitive answers. I remember that there were several issues in the past, but I have no idea if they still exist. They required fiddling with VM_KMEM_SIZE_MAX, or KVA_PAGES or similar things. Will FreeBSD/i386 6-stable run on a 4 GB machine out of the box? Do I have to apply special tuning (kernel config or sysctl or whatever)? Using PAE shouldn't be necessary, I assume. It would also be interesting to know if 4-stable (which is currently running on the predecessor machines) would run without problems on those new 4 GB ones, too. Thanks in advance for any information! The base install, running GENERIC will only use 3GB. I believe you would either need to use the PAE kernel option, or use the 64bit version of FreeBSD on a corresponding 64bit hardware. Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD/i386 6-stable + 4 GB RAM
Ivan Kolosovskiy wrote: Eric Anderson wrote: The base install, running GENERIC will only use 3GB. :[ ]. Why so?! How make FreeBSD to use 4GB? it is possible? Sure, as the rest of my email said. man pae Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: ffs_valloc: dup alloc in 6.1-BETA4
[moved to -current due to lack of response]
Eric Anderson wrote:
Mike Tancsa wrote:
At 04:48 PM 13/03/2006, Eric Anderson wrote:
I get the above panic after nfs clients attach to this nfs server
and being
I do have dumps from two crashes so far.
This is FreeBSD-6.1-PRERELEASE from Friday-ish.
Dont know if it was fixed or not, but there were a lot of VM changes
committed last night that might help.
http://lists.freebsd.org/pipermail/freebsd-stable/2006-March/023526.html
I just updated, and it still happens. More information for those
interested:
mode = 0100600, inum = 58456203, fs = /mnt
panic: ffs_valloc: dup alloc
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc064482f in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0644b55 in panic (fmt=0xc0890967 "ffs_valloc: dup alloc") at
/usr/src/sys/kern/kern_shutdown.c:555
#3 0xc077ee3c in ffs_valloc (pvp=0xc8eab440, mode=33152,
cred=0xc8a91d80, vpp=0xe83a5824) at /usr/src/sys/ufs/ffs/ffs_alloc.c:945
#4 0xc07a5933 in ufs_makeinode (mode=33152, dvp=0xc8eab440,
vpp=0xe83a5acc, cnp=0xe83a5ae0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2165
#5 0xc07a2b0d in ufs_create (ap=0x0) at
/usr/src/sys/ufs/ufs/ufs_vnops.c:171
#6 0xc082dc98 in VOP_CREATE_APV (vop=0x0, a=0xe83a5a18) at
vnode_if.c:204
#7 0xc0737590 in nfsrv_create (nfsd=0xc8a91d00, slp=0xc8816700,
td=0xc7d99780, mrq=0xe83a5c98) at vnode_if.h:111
#8 0xc0744e95 in nfssvc_nfsd (td=0x0) at
/usr/src/sys/nfsserver/nfs_syscalls.c:472
#9 0xc0744688 in nfssvc (td=0xc7d99780, uap=0xe83a5d04) at
/usr/src/sys/nfsserver/nfs_syscalls.c:181
#10 0xc081cd7f in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 1, tf_esi = 0,
tf_ebp = -1077941448, tf_isp = -398828188, tf_ebx = 4, tf_edx =
672385208, tf_ecx = 25, tf_eax = 155, tf_trapno = 12, tf_err = 2,
tf_eip = 671840155, tf_cs = 51, tf_eflags = 662, tf_esp = -1077941476,
tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:981
#11 0xc0809e8f in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:200
#12 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Maybe that helps somebody?
Should I sent this to -current instead, since it appears this would
happen under -current also, and possibly there is a larger base of
people watching the list?
Also, here's a screenshot of the crash, and I have a good dump if anyone
wants me to get more debugging info.
http://www.googlebit.com/freebsd/fbsd-6.1b4-nfscrash.png
Eric
--
----
Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
Mike Jakubik wrote: Craig Boston wrote: On Tue, Mar 07, 2006 at 09:04:02AM -0800, Freddie Cash wrote: There's no need to copy files around. gmirror handles it all for you behind the scenes. Just create the gmirror labels using the existing disks/slices/partitions, then insert the second set of disks/slices/parittions. gmirror will handle synchonising the data across the mirror. AFAIK, gmirror causes whatever provider it's mirroring to "lose" the last block to metadata. I've always avoided mirroring an existing filesystem for fear that shrinking a UFS filesystem's underlying device might cause problems down the road. Can someone with knowledge of the UFS internals please confirm one way or the other if this is dangerous or not? I'm curious to know this as well, as i have some systems using gmirror, that were setup in this fashion. Could someone knowledgeable on the matter shed some light? I've gmirrored existing disks/slices before, and it's worked fine. I'm not 100% certain about all cases, but it's possible that the filesystem could be right up against the last block of the partition, and it could get stomped on I suppose. I'm not sure what this command tells you for sure, but it dumps the last block of a slice, or disk, or whatever: dd if=/dev/ad0s3a iseek=`diskinfo ad0s3a | perl -ne '@d = split; print ($d[2]/$d[1] - 1)'` count=512 | hexdump Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bluetooth on Acer Ferrari 4005
Maher Mohamed wrote: Hello I have the a Ferrari 4005 LMWI, the laptop comes with a bluetooth mouse, did anyone made it work under freebsd? And how ? There's a great bluetooth mailing list for FreeBSD, that this question is better suited on, but anyway: http://destari.blogspot.com/2006/01/setting-up-bluetooth-mouse-on-freebsd.html Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
Pawel Jakub Dawidek wrote: On Tue, Apr 04, 2006 at 05:51:26PM -0400, Mike Jakubik wrote: +> >>>Can someone with knowledge of the UFS internals please confirm one way +> >>>or the other if this is dangerous or not? +> >>> +> >> +> >>I'm curious to know this as well, as i have some systems using gmirror, that were setup in this fashion. Could someone knowledgeable on the matter shed some light? +> > +> > +> >I've gmirrored existing disks/slices before, and it's worked fine. I'm not 100% certain about all cases, but it's possible that the filesystem could be right up against +> >the last block of the partition, and it could get stomped on I suppose. +> > +> >I'm not sure what this command tells you for sure, but it dumps the last block of a slice, or disk, or whatever: +> > +> > +> >dd if=/dev/ad0s3a iseek=`diskinfo ad0s3a | perl -ne '@d = split; print ($d[2]/$d[1] - 1)'` count=512 | hexdump +> +> Could someone provide an authoritative answer to this please? Pawel, it would be nice to see some support for your own code from you. This is a very easy method to create a +> mirror on an existing system, but if its going to cause problems then its useless (All the more reason for geom enabled installer). I can't give you an authoritative answer, because I don't know UFS internals so well. All I know is that it (UFS) thinks the last sector is available and may want to use it at some point getting EIO then. I'm not using this method, but I've heard of many people using it without problems. Speaking about installer. I don't think I'll be able to add configuration of my GEOM classes to the sysinstall in the near future (and I hope never - I'd prefer to wait for a new installer). One can still see how many sectors exactly has the partition he is going to create file system on and add additional newfs(8) flag '-s '. I suppose one could look at the output of diskinfo, and compare against the output of df, and see if there is a spare 512+ bytes at the end of the partition. I think there's a possibility that newfs won't use the last chunk if it's less than BLOCKSIZE bytes.. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: some simple nfs-benchmarks on 5.4 RC2
Claus Guttesen wrote: Hi. Sorry for x-posting but the thread was originally meant for freebsd-stable but then a performance-related question slowly emerged into the message ;-) Inspired by the nfs-benchmarks by Willem Jan Withagen I ran some simple benchmarks against a FreeBSD 5.4 RC2-server. My seven clients are RC1 and is a mix of i386 and amd64. The purpose of this test was *not* to measure throughput using various r/w-sizes. So all clients were mounted using r/w-sizes of 32768. The only difference was the usage of udp- or tcp-mounts. I only ran the test once. The server has net.isr.enable set to 1 (active), gbit-nic is em. Used 'systat -ifstat 1' to measure throughput. The storage is ide->fiber using a qlogic 2310 hba. It's a dual PIII at 1.3 GHz. I'm rsyncing to and from the nfsserver, the files are some KB (thumbnails) and and at most 1 MB (the image itself). The folder is approx. 1.8 GB. The mix of files very much reflects our load. *to* nfs-server *from* nfs-server tcp41 MB/s 100 MB/s udp 30 MB/s 74 MB/s In my environment tcp is (quite) faster than udp, so I'll stick to that in the near future. So eventhough I only made one run the tcp-times are so much faster and it utilized the cpu more that I beleive doing more runs would only level the score a bit. Q: Will I get better performance upgrading the server from dual PIII to dual Xeon? A: rsync is CPU intensive, so depending on how much cpu you were using for this, you may or may not gain. How busy was the server during that time? Is this to a single IDE disk? If so, you are probably bottlenecked by that IDE drive. Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology A lost ounce of gold may be found, a lost moment of time never. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: some simple nfs-benchmarks on 5.4 RC2
Claus Guttesen wrote: Q: Will I get better performance upgrading the server from dual PIII to dual Xeon? A: rsync is CPU intensive, so depending on how much cpu you were using for this, you may or may not gain. How busy was the server during that time? Is this to a single IDE disk? If so, you are probably bottlenecked by that IDE drive. The storage is ide->fiber. Using tcp-mounts and peaking 100 MB/s it used just about 100 % cpu. Rsync was only used to copy the folder recursively (-a), it used nfs to trasnfer the files to the nfs-server. When you say 'ide->fiber' that could mean a lot of things. Is this a single drive, or a RAID subsystem? Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology A lost ounce of gold may be found, a lost moment of time never. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-RC2 keyboard problem on Dell PowerEdge 2850
SÅawek Åak wrote: On 4/18/05, c0ldbyte <[EMAIL PROTECTED]> wrote: On Mon, 18 Apr 2005, [ISO-8859-2] SÂawek Âak wrote: Hi, After install from CD the keyboard doesn't work on this machine. Has anyone else seen it? /S Select the correct key map screen map etc... ? Erm. When I say keyboard doesn't work I *mean* it doesn't work at all. The only key which works on the box is BRS, which doesn't give me sufficient interaction with the system. I've skipped morse code lessons and boy scouting in my life altogether. Did you get this solved? I have some Dell 2850's I might be able to test this on. Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology A lost ounce of gold may be found, a lost moment of time never. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fsck_ufs: cannot increase directory list
I rebooted my server, and fsck'ed the disks, and here's what I get: # fsck -y /vol1 ** /dev/da0s1d ** Last Mounted on /vol1 ** Phase 1 - Check Blocks and Sizes fsck_ufs: cannot increase directory list # df -i Filesystem 1K-blocksUsed Avail Capacity iused ifree %iused Mounted on /dev/da0s1d1891668564 1643042028 9729305294% 32927755 211542003 13% /vol1 What's wrong? It lets me mount it rw and ro, but I'm afraid data is going to get corrupt. Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology A lost ounce of gold may be found, a lost moment of time never. ___ 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 nfs+TCP - Resource temporarily unavailable
Oliver Lehmann wrote: Hi Mohan, Mohan Srinivasan wrote: Is this consistently reproducible ? it is - everytime I tried reproducing this with this morning's current, it also happens with STABLE How big was your file that you tried to dd ? I need to reproduce this here in order to track it down. dd if=/dev/urandom of=/usr/tmp.data bs=512k count=200 Also, can you try the test without using the soft mount option ? I don't see soft causing this, but just to eliminate those code paths. I removed soft and bb, but still the same results: [EMAIL PROTECTED] olivleh1> dd if=/usr/tmp.data of=/mnt/files/temp bs=32k dd: /mnt/files/temp: Resource temporarily unavailable 1797+0 records in 1796+0 records out 58851328 bytes transferred in 33.651500 secs (1748847 bytes/sec) ## I tried the same with an other nfs server (using dill as nfs server this time - system description is in my 1st mail, same mount options like / mnt/files). And guess what? dill rebooted immediate... dd came never back, gave no output Just for a data point here - I have a 5.3-STABLE (from about January 15th) that is serving up data via NFS (tcp and udp, FreeBSD, Linux, Solaris clients) to about 1000 clients. The server is constantly getting pounded. I haven't seen any issues like this on this machine. I'm about to bring up a 5.4R box that will be in the same environment. If I have any issues, I'll make sure to note them here. Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology A lost ounce of gold may be found, a lost moment of time never. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with Dell laptops
Greg 'groggy' Lehey wrote: On Tuesday, 22 November 2005 at 17:12:46 -0800, Graham North wrote: Am currently trying to choose between a couple of laptops, the luck winner of which will have Freebsd loaded alongside WinXP. Dell Latitude d600 with Radeon 9000? video, intel pro wireless or IBM R51 - Intel Extreme2, intel pro wireless. The main differences will likely be the video and maybe bios, acpi...? Can someone suggest to me whether these are both safe choices? Am I better off installing 5.4 or 6.0? I've had both Dell and ThinkPad (no longer IBM). I prefer Dell, despite their attempts to convince me otherwise. However, we currently seem to have significant ACPI problems with Dell laptops. I'm writing this on an Inspiron 6000 running 7-CURRENT, but the same problems occur with 6.0: if I enable ACPI, timing goes to hell, and some things just time out. There was a similar message a couple of days ago from an owner of (I think) the latest Latitude machine, which sounded even worse. My requests for feedback about how to solve the problem have so far not been resolved. If you're otherwise tending towards Dell, I'd suggest you watch this space until there's some indication that the problems will be resolved. Nothing of this says that ThinkPads will do better, of course. I don't know what the situation is there. Which scheduler are you using? Also, have you tried disabling apic? I had these same troubles, and worked around them, but I can't recall the exact trick - I seem to recall disabling apic and/or using 4BSD scheduler. Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with Dell laptops
Greg 'groggy' Lehey wrote: On Saturday, 26 November 2005 at 20:25:58 -0600, Eric Anderson wrote: Greg 'groggy' Lehey wrote: I've had both Dell and ThinkPad (no longer IBM). I prefer Dell, despite their attempts to convince me otherwise. However, we currently seem to have significant ACPI problems with Dell laptops. I'm writing this on an Inspiron 6000 running 7-CURRENT, but the same problems occur with 6.0: if I enable ACPI, timing goes to hell, and some things just time out. There was a similar message a couple of days ago from an owner of (I think) the latest Latitude machine, which sounded even worse. My requests for feedback about how to solve the problem have so far not been resolved. If you're otherwise tending towards Dell, I'd suggest you watch this space until there's some indication that the problems will be resolved. Which scheduler are you using? The standard (ULE). I don't think the problem's related to the scheduler: it shows all the signs of being an interrupt space problem. Fine - I'm just offering the parts that I recall working around it for me - if you are unwilling to at least try it, maybe someone else can and report back so we know if it is or isn't related. Also, have you tried disabling apic? I think you mean ACPI. This machine doesn't have an APIC. No, I meant apic. I realize it doesn't have one, but did you try disabling it? To answer the presumed question: Yes, as I said above, the problems only occur when I enable ACPI. Since then I've also discovered that the builtin wireless card doesn't work either. It's: iwi0: mem 0xdfcfd000-0xdfcfdfff irq 10 at device 3.0 on pci3 iwi0: Ethernet address: 00:13:ce:46:28:49 After downloading the firmware, I can set IP addresses and such, but I always get "no carrier": iwi0: flags=8802 mtu 1500 ether 00:13:ce:46:28:49 media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid "" channel 1 (2412) authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF powersavesleep 100 txpowmax 100 txpower 100 rtsthreshold 2346 fragthreshold 2346 -pureg protmode CTS -wme roaming AUTO bintval 0 When I run dhclient on the interface, I get: DHCPDISCOVER on iwi0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on iwi0 to 255.255.255.255 port 67 interval 15 send_packet: Network is down On the console I get the detailed error message: iwi0: fatal error This machine also has Linux on it, and the card works fine with Linux, so it's obviously a FreeBSD-related problem. I also had problems with it. I ended up replacing it with a mini-pci atheros card. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSH login takes very long time...sometimes
Michael A. Koerber wrote: All, I have three machines that have had 5.4 and 6.0 installed. Two of the three machines have very well behaved "ssh". However, the machine (laptop) named OBOE does not. Specifically "ssh oboe" will (most of the time) hang for around one minute before asking for a prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the other machines) a password is requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE and ssh will work just fine...hmmm.) I have looked through the /var/log files for clues and skimmed "man ssh" for time out related stuff, but no luck. Where should I start looking for clues? All machines have had clean installs from "newfs'd" drive under both 5.4 and 6.0 so I'm sure no left over configs are getting propagated. Check your DNS (or reverse DNS really) on the laptop (OBOE). Eric -- ---- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
