Re: Sysinstall is still inadequate after all of these years
Hear, hear! To be honest, this is the only bit about the current sysinstall that I really dislike: the fact that it can be used for post-installation configuration and package installation. This causes no end of trouble for newbies, who seem to view sysinstall as The One True System Admin Tool and try to use it for configuring/installing everything. Too many times, on various BSD forums, I've had to walk people through cleaning up /etc/rc.conf and showing them how to correctly install/configure things (using standard FreeBSD tools), since they used sysinstall for everything. That may be true, but sysinstall did help me do basic, essentical configuration of my very first installed system, and a few installs after that (until I learned about /etc/rc.conf et al). And I never regarded it as The One True Sysadmin Tool, because I did not use Linux distros, thus never got used to their ways. It's just that the simple configuration menu really helped me to get a useful system running in a few minutes (though menu items certainly could make use of more verbose descriptions). And then I could play with the working system and learn ways to configure it. So, IMHO, a basic curses system configuration utility is still needed, and should be run after sysinstall or it should tell the user how to run it (maybe in motd, or sysinstall itself?). IMO, the installer should allow you to partition the disk(s), format the partition(s), install the OS, configure a user, and reboot the system. Anything beyond that should be handled by the OS tools, from within the installed and running OS. The tricky part will be getting the disk slicing, slice partitioning, and filesystem formatting to work reliably, with all the power of FreeBSD's GEOM modules, and ZFS. [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/Makefile instructions
On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? Close to implausible, perhaps? That would indeed be the case, unless you truly are longing for a major workout, either with mergemaster et al, or both with mergemaster and the ports. The former case, which assumes you don't have many ports installed, is often a no-brainer: install a fresh system. The latter case may be somewhat more complicated: install a fresh system for the least effort on your side, or go the update route if you need to keep your system up and usable during the process. I should note that I always took the update trail, and never regretted it afterwards (well, if only so slightly). For instance, my workstation lived through 5.2.1-R, 6.2-R, RELENG_6, and finally RELENG_7, all with the aid of cvsup. The process is straightforward, well-designed and easily executed (thanks to the developers), but problems often pop-up with ports (especially such messy ones as Gnome, etc) which take lots of time to correct. So, in summary, a sane person should probably go with clean system update. P.S.: whoever replies next, it's safe to drop hackers@ from CC: anytime now Kayven Riese, BSCS, MS (Physiology and Biophysics) [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Saving entire console sessions
Is there any way to save entire console sessions ? Screen asks me to copy and paste what I want. I don't want to do that I need to save entire sessions. like a start till I do a exit or quit the application. Is there a utility like that ? man 1 script Regards, Sanjeev. [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ports system woes
-driver-96xx]# time make fetch
=== Vulnerability check disabled, database not found
=== Found saved configuration for nvidia-driver-96.43.01
real0m53.340s
user0m0.299s
sys 0m0.886s
[EMAIL PROTECTED] /usr/ports/x11/nvidia-driver-96xx]# time make maintainer
deleted
real0m22.817s
user0m0.265s
sys 0m0.685s
[EMAIL PROTECTED] /usr/ports/x11/nvidia-driver-96xx]#
So all these examples are only tip of the iceberg that is currently making
pkg_* ports sink, but of course no other bugs are as serious as the one with
pkg_delete (or so I hope).
And I'm not even talking about portupgrade. Dragging it's feet at a snail pace,
running sluggish 'pkgdb -Q' each tiny step... it's a rather useful tool. But,
I believe portupgrade is not really needed -- if FreeBSD's base ports/packaging
tools get fixed and extended, they'd do the job (yah, there's portmaster, but
with broken pkg_*, it's just as good as portupgrade).
BTW, to make `portupgrade -a` at all useful, a while ago I whipped up a bash
command that lists all dependencies of installed packages:
export PORTSBASE=/usr/ports; cd /var/db/pkg
for dir in `ls`; do tmp=`(grep '@comment ORIGIN' ${dir}/+CONTENTS|awk -F :
'{ print $2 }')`; echo ${tmp}; cd ${PORTSBASE}/${tmp} (make
package-depends-list|awk -F '{ print $3 }'); cd /var/db/pkg/;
done|sort|uniq /tmp/deps.lst
Allow it 3-5 hours per 1000 installed ports 8-) The good thing is that
theoretically this should get all the dependencies in fresh ports tree
right, when fed from old (not updated) /var/db/pkg, so then you could do:
for dir in `cat /tmp/deps.lst`; do cd ${PORTSBASE}/${dir} make
config-conditional; done
which in ~10 minutes should take care care of all the new unconfigured
(`make config`) ports in single attempt. Practically, there are always some
problems with the gazillion versions of tcl* and tk* (go to ports tree and
manually run `make config` for each and every version of tcl* and tk* that's
there), and any cases where 'dialog' coredumps (long lists of options).
/tmp/deps.lst can be usually reused. Now, just to convert these commands to
normal /bin/sh script...
[SorAlx] ridin' VN1500-B2
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cool feature of dmesg.boot file
On Fri, Feb 22, 2008 at 11:31:36AM +0100, Oliver Fromme wrote: If you insist on writing a patch, then please make it default off. rink@ just provided one, and it does default to off. I fully agree with defaulting it to off as well; those of us that want it on can set it as such in loader.conf. I'll try out said patch this weekend. Assuming it works, and does get committed, I'll be more than happy to submit a PR along with a patch to update the loader.8 manpage, documenting kern.ignore_old_msgbuf. IMHO, 'kern.forget_old_msgbuf' would more accurately describe what it does [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stale mount on disconnected device: how to delete it?
The problem is that the detach event can be caught only too late to unmount the device properly. How may it be possible to sync a disk ``as soon as it is detached'' (that is when it is not physically connected to the computer anymore)? Mounting the disk read-only may be a workaround, just as not caching writes (default behaviour of some versions of Windows) and syncing the disk all the time, but this is not as reliable as the mount system provided by Unix and Unix like operating systems. AFAICR, this is the sole weakness of the FreeBSD operating system I know :) And since it is, according to me, an operator error, the best we can do is to use the system as it was designed for ;) Off the top of my head, what is wrong/hard with just logging a device failure, discarding all remaining cached operations, and unmounting the fs when a disk device goes missing? I understand that this is not a viable solution for critical filesystems, but I can see nothing wrong with this approach for removable devices and/or non-critical fs's. I was wondering that myself. The possibility of losing data (after some timeout, of course) sure as heck beats recovering from the annoying panicks when something happens with the filesystem's underlying device. And who said those panicks are no problem for production systems? My workstation is a production system, and it is very hard to recover from reboots in general, and crashes in particular. Unfortunately, they do happen fairly often, usually caused by USB-related stuff (FreeBSD's USB stack is _the_ worst I've seen lately -- I take it that the stack's favorite hobby is panicking the kernel with unrivaled efficiency), sometimes by ATA/ATAPI/SATA (interestingly, SCSI code is quite stable), someimes by something obscure (e.g., just exiting qbittorrent kills the kernel -- NFS woes maybe? just an example). Hot-swapping with some ATA and SCSI drivers is impossible, too (result in panics). I hope you don't mind me, an ol' whiner here, too much, but I really had to say that FreeBSD used to be far more stable. So it seems the trade-off stability-features could not be avoided... Comment: Nikos Ntarmos [EMAIL PROTECTED] [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: handling pdfs?
I personally find that xpdf looks OK. Same here, though I do remember to have that cramped characters problem before. I think it was in PDFs created by OpenOffice swriter. When I used the other OS to print these PDFs, there were cramped characters THe other OS? Are you talking about Linux? Nope, there's a whole crapload of Linuxen, but nearly all people out there seem to be aware only of _the_ OS made by Macrobug. on paper. I have this problem occasionally only with xpdf. Evince displays the files then without any problem just as kpdf. Can you upload a screen bitmap? I wonder if that's the same snag I stumbled upon... BTW, 'tis slightly off-topic, but had anyone else noticed that xpdf is rather slow in rendering pages? I remember, when I had a chance to I think so too. I seem to believe it's X.org's problem. Consider: -- resize xpdf to a small window, and it get much faster; -- if you open hundreds of tabs in Opera, everything in Opera get unbelievably slow (scrolling pages, even moving cursor with cursor keys is very slow). 'opera' and 'X' eat all the CPU cycles; -- some graphics-intensive (lots of vector objects?) apps (Eagle, Opera) take too long to redraw when changing workspaces. I'm thinking about sending a PR. Should I bother, or it's a known bug? Erich [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: handling pdfs?
I'm not sure why, maybe I have too poor a font selection here, but the fonts, I mean, the onscreen fonts that xpdf seems to choose, always seems to run characters together, so it gets hard to read them. So, xpdf wouldn't be my first choice. I use kpdf to view pdfs for that particular reason, and onthe same document, kpdf does a distinctly better job, If kpdf uses xpdf's engine, then it must find some way to pick better fonts for itself, it actually does look better. I personally find that xpdf looks OK. Same here, though I do remember to have that cramped characters problem before. I think it was in PDFs created by OpenOffice swriter. When I used the other OS to print these PDFs, there were cramped characters on paper. BTW, 'tis slightly off-topic, but had anyone else noticed that xpdf is rather slow in rendering pages? I remember, when I had a chance to use that other OS, there was some program to view PDF -- AcrobatReader it was called, AFAIR -- well, that thing rendered pages almost instantly. I avoid things like kpdf because I don't use KDE and don't really need all the bloat associated with it. But that's just me. No, that's not just you. That KDE and GNOME bloat is getting barely tolerable already. And not only because of the weight -- instability and departure from UNIX/XFree conventions are driving me crazy (did you notice that copying text to buffer by selecting it with a mouse doesn't seem to work anymnore with GTK?). Still, how can it be that just starting an app should waste tens of seconds of your time and more RAM than necessary? And that's on a dual-core 2GHz machine! Who would have imagined... [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Welcome to Hell / Mysterious networking troubles on FreeBSD
As a lot of people recommended using tcpdump, here it is. The only thing that stands out, are hundreds and thousands of lines like this: 13:45:49.991592 IP 82.165.252.222.36887 ns1.galandrex.ee.43077: UDP, length 9216 13:45:49.996482 IP 82.165.252.222.36887 ns1.galandrex.ee.33803: UDP, length 9216 13:45:50.001174 IP 82.165.252.222.36887 ns1.galandrex.ee.63574: UDP, length 9216 13:45:50.005955 IP 82.165.252.222.36887 ns1.galandrex.ee.36618: UDP, length 9216 13:45:50.010749 IP 82.165.252.222.36887 ns1.galandrex.ee.48231: UDP, length 9216 That IP resolves to u15194704.onlinehome-server.com. Seems to be a german ISP. After five seconds the capture.out file was already 2.8MB. You can see the file here: https://89.219.136.126/capture.out Thank you again to all the nice people who contacted me. And again, it would be nice if you could send me a copy of your reply, because I'm not a member of the list (either reply or cc to [EMAIL PROTECTED]). Thanks! Looks like a case of DDoS indeed. The node's DNS A-record better be left pointing to the old IP#, and the IP address changed. Joel V. [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Welcome to Hell / Mysterious networking troubles on FreeBSD
On Fri, 23 Nov 2007 23:59:41 +0200 Joel V. [EMAIL PROTECTED] wrote: Hello all, I'm not experiencing this problem, my friend is. He's simply too pissed off to write here and I'm afraid he's going to set his office on fire if he doesn't solve the problem soon, so without further ado, here's the problem: He has two fbsd boxes, main server running 6.1 and dns server running 4.3. He has 4 public IPs which he can use and the main server is running on x.x.x.122. He's main box is NOT acting as a gateway/NAT box in the office. Today he noticed that net is getting awfully slow. Sometimes there would be 50% pl when pinging, sometimes pinging would be all OK, but SSH is dead-slow and the webpages running on the main server are not displaying. E-mails are not going through. He calls the ISP, who say that his network is showing major uploading activity. He switches off networking services one by one in the main box but situation does not improve. He disconnects the main server and puts a windows xp box instead, which seems to run fine. He puts back the freebsd box, disables all networking services again except for SSH and connects the network: instant 100% networking slow-down. He tried to change the switch, thinking it's faulty. He disconnect every other computer in the office from the network: nothing. He put the public IP address on the second, internal network NIC: same thing. Now it gets really mysterious: he puts the old dns server with the x.x.x.122 IP and instantly it becomes slow as death. The logical conclusion would be that someone is flooding that IP? Only the windows xp box seemed to work fine and the ISP guy said it was upload bandwidth that was excessive... Netstat -a doesn't show anything interesting, arp -a doesn't show any incomplete addresses He tried to build and install a new fresh kernel. Nothing. This is the most creepy networking problem I've heard of. Can YOU help? Any ideas where to start looking? Not enough information (a bit hard to extract from above...) To date I remember experiencing only 2 causes that had symptoms very similar to your buddie's: 0. DDoS attack -- started suddenly one day after I scanned some spammer's gateway with Nessus (or just nmap? can't remember); 1. All my home network is 10/100, but workstation has a Gigabit NIC, Marvell Yukon 88E8056, using their driver myk(4) [thanks, Marvell! but where is the source code? ;)]. Right after I replaced an old 10/100 switch by a gigabit one, the network speed dropped to less than 100 kbytes/s. Turns out the NIC began autonegotiating to 1000baseTX for some reason. Setting media manually to 100baseTX improved things to my satisfaction. I'm not in the freebsd-hackers list, so if you want the e-mail to reach me, send a copy to [EMAIL PROTECTED] Thank you in advance! Joel [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A more tenuously package-related question
I used to use pkg_update from the 'pkg_install-devel' toolset to upgrade systems via replacement of binary packages. Its implementation had some minor flaws - it was essentially a perl wrapper for an iterative pkg_delete -f followed by pkg_add -f, which made it problematic to upgrade either the perl or pkg_install packages, for instance - but the core idea was excellent. Despite those flaws it was very useful in maintaining servers via binary packages, because it would reconnect the pkgdb dependencies on the old package version to the new package version. However, it's not part of the current base package tools. Is there any better equivalent tool at the moment, or should I just resuscitate the old pkg_update? Did you try ports-mgmt/portupgrade? You can run it as `portupgrade -P` for binary updates. Besides actual 'portupgrade', it has a set of useful tools, too. But be warned -- the utility is snail-slow. -- Clifton [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what happened to make world?
: On Thursday 30 August 2007, Pietro Cerutti wrote: : # make world : WARNING: make world will overwrite your existing FreeBSD : installation without also building and installing a new : kernel. This can be dangerous. Please read the handbook, : 'Rebuilding world', for how to upgrade your system. : Define DESTDIR to where you want to install FreeBSD, : including /, to override this warning and proceed as usual. : You may get the historical 'make world' behavior by defining : HISTORICAL_MAKE_WORLD. You should understand the implications : before doing this. [...] : I don't want my OS to treat me like a stupid. I will note that since we switched to the multi-phase world with explicit reboot instructions, the support load for 'oh no, I shot myself in the foot' has gone way down. There are times that one must put a few safety rails in place. Since we have limited resources for support for users, it is better to make them make sure they know what they are doing so we can focus our resources better. Sometimes we have to optimize for developer time in the tradeoffs that are made. Against any bit of modesty that's left in me, I'll crawl out of my cave for a second here -- to make a wise comment, no doubt ;) Not trying to start offtopic, just a little remark that's of importance to me (and to many other FreeBSD users, I bet). Not every FreeBSD user is [still] a computer enthusiast. It just so happens that the OS at the time is the best one for many, many different uses, such as: server, router, research workstation, 'desktop', etc. It is basically an excellent universal tool for many (computer_science|IT)-unrelated tasks, e.g. machine in a physics lab. The ideal tool, of course, is the one that Just Works. Some of the folks using it can't afford the time expense of figuring out how exactly it's geared -- as long as things are working. If it Just Dies at any wrong move -- then, well, one can loose a lot of time, and be pretty screwed. I just hope that you developers won't be forgetting about the users. None of that Are you sure? nonsense is needed (it interferes with work as one gains experience), but just a helpful info message or a warning at the right moment is sure nice -- it makes things less painful and more productive. You see, it'd make me really sad to see FBSD go in the direction of Linux one day, and be geared towards (hackish) developers. Meaningless (to a mere mortal) error messages, obscure ways of doing things, chaotic development, and so on. Quite user-unfriendly. These things aren't bad, they just tend to make the OS less useful as a tool. BTW, if this thread doesn't burn out, then perhaps it's about time it should start drifting in the general direction of [EMAIL PROTECTED] Warner [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what happened to make world?
# make world WARNING: make world will overwrite your existing FreeBSD installation without also building and installing a new kernel. This can be dangerous. Please read the handbook, 'Rebuilding world', for how to upgrade your system. Define DESTDIR to where you want to install FreeBSD, including /, to override this warning and proceed as usual. You may get the historical 'make world' behavior by defining HISTORICAL_MAKE_WORLD. You should understand the implications before doing this. Bailing out now... *** Error code 1 Stop in /usr/src. Now, THIS is quite funny... do you really thing that a person with - root access - the knowledge of the existence of make world needs this sort of things? it says 2 very important things: -- `make world` will overwrite (keywords here) existing base system (very well known as the 'world') without you explicitly telling it to (i.e., no 'install' string visible anywhere in the command line, but that's actually what it does); -- kernel is outside the world (slightly counter-intuitive), and installing world before kernel _can_ be dangerous (anyone disagrees?). so yes, it is more user friendly but this change causes very little inconvenience, thus could be considered an improvement Enough said I didn't see anything about this new-wave-of-user-friendly-bsd going on the list.. have I missed something? [SorAlx] ridin' VS1400 ___ 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 stop attached USB device / send IRP_MN_REMOVE_DEVICE?
Is there a tool under FreeBSD 6.2 that properly stops a USB device, equivalent to Windows XPs Safely Remove Hardware? I noticed that Windows sends a IRP_MN_REMOVE_DEVICE command, after which my LaCie external HDD spins down. Same applies to any USB stick: the light goes out on the stick. I would like to do this under FreeBSD too. camcontrol eject or stop don't do anything. So, the question really is: how to send a IRP_MN_REMOVE_DEVICE command? `camcontrol da? stop` seemed to do the trick before (5.2.1-R, AFAIR), but now I'm not sure (looks like it doesn't) tested with SCSI hard drives and Adaptec 29160 Sven [SorAlx] ridin' VS1400 ___ 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 stop attached USB device / send IRP_MN_REMOVE_DEVICE?
On Tue, 14 Aug 2007 03:08:33 -0700 [EMAIL PROTECTED] wrote: Is there a tool under FreeBSD 6.2 that properly stops a USB device, equivalent to Windows XPs Safely Remove Hardware? I noticed that Windows sends a IRP_MN_REMOVE_DEVICE command, after which my LaCie external HDD spins down. Same applies to any USB stick: the light goes out on the stick. I would like to do this under FreeBSD too. camcontrol eject or stop don't do anything. So, the question really is: how to send a IRP_MN_REMOVE_DEVICE command? `camcontrol da? stop` seemed to do the trick before (5.2.1-R, AFAIR), but now I'm not sure (looks like it doesn't) sorry, I meant to say that `camcontrol da? stop` does not power down the device anymore; nonetheless, it is probably safe to disconnect it tested with SCSI hard drives and Adaptec 29160 Sven [SorAlx] ridin' VS1400 [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device drivers to be commited.
On Sun, 1 Jul 2007 01:26:09 -0700 Josef Grosch [EMAIL PROTECTED] wrote: There are 3 drivers that I have been using with FreeBSD 6.2-RELEASE and 6.2-RELEASE-p5. They are 1) Intel's new driver for em 2) Adaptec's new driver for the 3805 3) 3ware's new SATA RAID controller (9500) 04. myk by Marvell (88E8056 -- gigabit NIC) [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device drivers to be commited.
On Sun, 1 Jul 2007 11:58:27 +0200 Erik Trulsson [EMAIL PROTECTED] wrote: The msk(4) driver should support that chip. This driver is also available in both -CURRENT and 6-STABLE and thus will appear in both FreeBSD 6.3 and 7.0. great! is it as good as Marvell's one? [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Ivan Voras [EMAIL PROTECTED] wrote: Because the information is not a constant. For example, the mpg123 port changes its PKGNAME as soon as esound is installed. Maybe the time has come to give up on some of the flexibility the ports tree has (and this particular one is confusing to the users) [...] maybe more confusing to portupgrade -- one day I'll get tired of running 'pkgdb -F' almose every time before portupgrade to fix old dependencies (packages with old config or things like ru-xmms instead of xmms). This is portupgrade's problem really, but doing away from such flexibility would make life slightly easier... [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discovering list of open files from kernel level without using utils like lsof
good_localtime(all); I'm thinking of changing spinning down to adjusting acoustics level, i.e. reduce spindle speed to avoid pricey spin-downs, which may cause long-term serious damage to disks. Whoa, hold your horses. Recall that the friction between air and rotating plates inside your winchester creates a definite gas flow. I can think of at least 3 design objectives (there could be more) that utilize that circulation: 0a. Float the magnetic head micrometers above plate's surface; AFAICT, it is this fluid 'cushion' that resists any force directed normal to the head towards the plate, thus preventing head crashes. 0b. Circulate the inside air throug a filter and a dessicant. 0c. Detract arm's stopper when the plates get up to speed. 0d. Cooling of other components? Modern low-speed (7200 RPM) IDE hard drives have bearings quiet enough to cause little trouble. You're better off switching the 'acoustic mode' setting (or what ever it is called) from 'performace' mode to 'low noise'. I know, it's hard (lowering performace of the 'puter with your own hands -- OMG!), and the heart rightfully rebels agains such a [lacking the right word], but mediate, let out your deep Zen powers, and just do it ;) This way, the drive should try to keep itself quiet (not throw the arm round too fast, slow down [maybe?] when possible), and it should really know better how and when to do that (given that the factory blessed it's brain with a good firmware). 'Tis supposed to be better than just slowing down the motor. Trying to keep my electric bills down and keep my disk life up :). 00. Risking disk life to save a few watts? That's rather crazy, or too much courage? Undue stress on electronics (the inverter, plus maybe something else) as well... 01. I know that some gyro rotors (which use ball bearing and spin at 22k RPM) may last a decade or even two. If you don't quite believe me, then you're right: they are not running with 100% duty cycle. Still, the idea here is that precision ball bearings may last for some time. Now, sleeve bearings (such as those used in modern hard drives -- the fancy term 'hydrodynamic uber-duper whatever means not a lot more than that) last even longer. Sometimes far longer. I've seen a lot of failed disks in my life (notably, all of them IDE), but none died because of bearing failure. In fact, I still have an ancient Seagate Barracuda that sounds like a whole platoon of high speed drills working their chucks off, but still is functional. BTW, I've done autopsy on many of them, and the most common causes of malfunction are: 0a. electronics going crazy in the head; 0b. head crash. -Garrett [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unique hardware identification
I'm thinking of something like combining serial numbers from CPU/disks for example, but there does not seem to be a clear way to obtain these (not all cpu's even have a serial number in there). the simplest thing that comes to my mind is parsing `dmidump` for serial numbers, hoping there are some... (there are a few in the dump I obtained, but it's a laptop) [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Capturing Parallel Port Data
No, I didn't try that but I certainly will now. I wasn't sure you could just cat the port and read the data back. I will let you know how this works. Well, you should certainly try it, but don't count on it: Daniel says that lpt returns only printer status (BTW, this means full 5 bits, right?). What you need is to either write support for the 'byte mode' in lpt, or utilize the nibble mode if your device supports it. See `man ppbus` friends, and `man lptcontrol`. -J. Hunt [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Capturing Parallel Port Data
Now, my real question is: how do I read data from the parallel port on the FreeBSD computer that is coming from the tester which is trying to 'print' to the FBSD computer's parallel port? Is there a did you try to set LPT0 mode to bi-directional in the BIOS, and then `cat /dev/lpt0`? suggested pinout for a parallel crossover calbe to accomplish this task with ppi? Is the crossover cable even required? as I understand it, either the 8 parallel lines can be driven on both sides to send data both ways, or the 5 control inputs (paper out, ACK, busy, etc) are used to receive data, or both. -J. Hunt [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syncing cpus on a multi-cpu, dual core system
On a computational chemistry list I subscribe to there is a current thread about multi-cpu systems needing to have the cpu frequencies synced (this is in a Linux context). This is evidently not just having the cpus running at nominally the same frequency but something else in addition. A posting in the thread said variations less than 0.1% were not problematic. However, the poster said it was an issue in a dual cpu, dual core system he had set up. My questions are: 1. Is this real or an urban legend? If CPUs use the same FSB (as is the case with dual-core chip), they are already in sync. Right? For system that use multiple FSB clocks [like dual-(dualcore-CPU) systems], it might be possible to vary the clocks (as much as the manufacturer allows without hw modifications: e.g., SpeedStep, or something similar). Why someone would want to have CPUs running at precisely the same frequency is beyond my imagination. Bud Dodson [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keyboard issue
I have installed FreeBSD 6.1 on my Gateway Solo 1450 Laptop and my keyboard doesn't work right. A example is my letter l displays o not the letter l. It will work if I hold the fn key down just like if I were pressing the Caps Lock key down continously. I have researched this a little bit. Do you have any ideas on what this. Perhaps it's not 'o', but '0'? Could it be that NumLock or ScrollLock are set, so part of the keyboard is acting like a numeric pad? Depends on the BIOS and layout... Please, let me know if anyone can help or not. I have installed it on a desktop just fine but it appears there is something it doesn't like about my keyboard drivers. Thanks, Sean Sneed. [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] rm can have undesired side-effects
Having cleared my head a bit more, I realise most of this can be done with consecutive runs of 'dd'. I think I've reached a conclusion here. that is, install ports/sysutils/obliterate/? Tim. [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] rm can have undesired side-effects
protections at a later date. Unless Alice notices that her file
has a second link before she deletes it, when she issues rm -P,
she will lose her link to the file (and her only way of uniquely
identifying it) whilst leaving the remaining link to the file in
Mallory's control.
well, that's the whole point of '-P' -- erase file's data _before_
unlinking the file, is it not?
That isn't really that nice, true. But why can i link files that I
have no business with in the first place? Is there is specific reason?
if you can't see the contents of other user's directory (think '0750')
you really will get no buisiness there, whether you want it or not
Of course, one must be careful when using `rm -P` (which, ironically,
is very likely to happen in limited-time situations), and even the
protection of requiring the '-f' flag if {(inode count) 1} is
inadequate protection for fools like me (who are used to good ol'
`rm -rf` on large directory structures) ;P
[SorAlx] ridin' VN1500-B2
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another SimpleDrive problem also...
it detects it and reports it as a umass0 device, but nothing else is reported. In otherwords, it is not being assigned to a da0 device or anything of that nature, thus preventing me from being able to mount it. I'm using FreeBSD 5.4 instead of 4.x. Any suggestions would really help out a ton. Try cvsupp'ing /usr/src/sys/dev/usb/* to 5.5-RELEASE, and then replace those if_*.c files that don't compile with their old (5.4-R) versions. If you want, I can roll you a tarball of dev/usb/ tree that worked for me (~1Mb). [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jails, cron and sendmail
I have the following problem: since I need and do not like any kind of smtp activity in my jails (there's no 127.0.0.1 in a jail, all services [...] cron tries to deliver its status mails and fails. try 'MAILTO=' in /etc/crontab [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: D-Link DSL210 USB in FreeBSD 6.x ?
Is sat a wireless network USB adapter? If so, then there is no way to run USB Wi_Fi in FreeBSD nor in Linux, only PCI or PCMCIA adapters are supported for now as far as I know. Even with Windows native drivers. But no USB... I used NetGear 'WG111' USB successfully (without encryption, though). [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pagedaemon and shared memory [was: Heavy system load by pagedaemon].
with 512Mb. The vmware guest (a Windows 2000) is allocated 256Mb. Every once in a while (around five times a day), the machine freezes. The clock on the toolbar stops counting the seconds. I have top running on a session from another machine (it is a second machine I can switch to using KVM) which also freezes (no screen refresh). Disk activity is heavy (lamp is on). After over 30 seconds, the machine is back to normal and everything works fine. The vmware process resident size goes down from ~200Mb to ~100Mb. I also notices some relations to running acroread 7 with large PDF files (which might also need shared memory for its operation). I had the exact same problem on the same box when I was running FreeBSD 4.10 (which I attributed at first to a bad disk, which was replaced when I upgraded from 4.10 to 6.1). Isn't this normal? I noticed long time ago that paging always causes freezes, as though there is no context switching during swapping at all. [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1, crashes and a lack of vmcores
We started with memtest and CPU tests with no errors. As part of our troubleshooting we have replaced (or swapped out with the other servers) every piece of hardware in this box, replaced every cable and cord and moved to different switch and power ports. We've even changed physical locations in our data center. We have so far been unable resolve the more 0. how many hours did you run memtest86 for? 1. did you try to swap the mainboard? 2. do you suspect any corelation between net traffic intensity,type,etc, and crashes? 3. disabling ACPI made no change? [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] Linksys PCM200
[no reply on -hardware]
This adds Linksys PCM200 10/100 PCMCIA NIC device IDs.
It's probably a good idea to update dc(4) and supported hw list also.
Index: if_dc.c
===
RCS file: /home/ncvs/src/sys/pci/if_dc.c,v
retrieving revision 1.152
diff -u -p -r1.152 if_dc.c
--- if_dc.c 1 Oct 2004 15:23:31 - 1.152
+++ if_dc.c 21 Oct 2004 22:32:39 -
@@ -218,6 +218,10 @@ static struct dc_type dc_devs[] = {
Microsoft MN-130 10/100 },
{ DC_VENDORID_MICROSOFT, DC_DEVICEID_MSMN130_FAKE,
Microsoft MN-130 10/100 },
+ { DC_VENDORID_LINKSYS, DC_DEVICEID_PCM200_AB08,
+ Linksys PCM200 10/100 CardBus NIC, v.03 [ADMtek Centaur-C] },
+ { DC_VENDORID_LINKSYS, DC_DEVICEID_PCM200_AB09,
+ Linksys PCM200 10/100 CardBus NIC, v.03 [ADMtek Centaur-C] },
{ 0, 0, NULL }
};
@@ -1917,10 +1921,16 @@ dc_attach(device_t dev)
case DC_DEVICEID_FA511:
case DC_DEVICEID_FE2500:
case DC_DEVICEID_EN2242:
- case DC_DEVICEID_HAWKING_PN672TX:
+ case DC_DEVICEID_HAWKING_PN672TX:
+#if 0 /* DC_DEVICEID_HAWKING_PN672TX has the same ID as the following */
+ case DC_DEVICEID_FE2500MX:
+ case DC_DEVICEID_FNW3602T:
+ case DC_DEVICEID_PCM200_AB08:
+#endif
case DC_DEVICEID_3CSOHOB:
case DC_DEVICEID_MSMN120:
case DC_DEVICEID_MSMN130_FAKE: /* XXX avoid collision with PNIC*/
+ case DC_DEVICEID_PCM200_AB09:
sc-dc_type = DC_TYPE_AN985;
sc-dc_flags |= DC_64BIT_HASH;
sc-dc_flags |= DC_TX_USE_TX_INTR;
Index: if_dcreg.h
===
RCS file: /home/ncvs/src/sys/pci/if_dcreg.h,v
retrieving revision 1.42
diff -u -p -r1.42 if_dcreg.h
--- if_dcreg.h 29 Jun 2004 20:38:44 - 1.42
+++ if_dcreg.h 21 Oct 2004 22:32:40 -
@@ -998,6 +998,17 @@ struct dc_softc {
#define DC_DEVICEID_MSMN130_FAKE 0xFFF2
/*
+ * Linksys vendor ID
+ */
+#define DC_VENDORID_LINKSYS0x1737
+
+/*
+ * Linksys device IDs
+ */
+#define DC_DEVICEID_PCM200_AB080xab08
+#define DC_DEVICEID_PCM200_AB090xab09
+
+/*
* PCI low memory base and low I/O base register, and
* other PCI registers.
*/
Timestamp: 0x4462D4BE
[SorAlx] ridin' VN1500-B2
___
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
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 I have. I've got a Seagate X15k SCSI HDD with SCA2-68pin adapter, and sometimes it used to lose power and shut off (bad contact in the adapter perhaps). FreeBSD would spit SCSI diagnostic messages onto the console about failed field-replacable unit (which I couldn't see in X Windows), restart the HDD a few times (at this point the machine would hang until HDD is restarted), and then reboot (panic?). Timestamp: 0x443EC707 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Adding a ``user'' mount option
So why not have GNOME/KDE create mount points for the user if vfs.usermount is 1? Since FreeBSD uses devfs, every device in /dev that usually represents a device with removable media can assumed to be present in hardware. GNOME/KDE could be patched to create mount points somewhere in the user's home directory, and issue a 'mount device mount_point' instead of 'mount mount_point' if the user clicks the device icon. pardon my ignorance, but how any of those methods described earlier may be superior to simply using sudo? Timestamp: 0x44335A44 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cloning a FreeBSD HDD
On Saturday 25 March 2006 04:42, Mike Meyer wrote: One thing: 1m is a bit small for modern systems. Or for not-so-modern systems. Since nothing else is running, you might as well use all the memory you've got, or as big as you can get a process to be. 128m or more is perfectly reasonable. It won't go any faster.. In a modern system the CPU is so much faster than the disk than anything above about 16k would be enough. I found 64k to be optimal (e.g, max performance) on most machines Timestamp: 0x4428D30F [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: install the FreeBSD (notbook Toshiba)
This is not an error message. It is just a status message. Timecounter TSC frequency 1862079434 Hz quality 800 Timecounters tick every 1.000 msec ad0: 76319MB TOSHIBA MK8026GAX PA000U at ata0-master PIO4 acd0: CDRW UJDA750 DVD/CDRW/1.60 at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s3a But if I enter way single functions. What do you try to express here? I think he means that if he enters (boots) in single-user mode, things function properly. Timestamp: 0x441DF47A [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange ARP problem
[ workstation  ]             [ mail server  ] [192.168.10.250]---[ small  ][ 192.168.10.15] [192.168.20.250]---[ switch ][ 192.168.20.15]               |               |          [router 192.168.10.1]               |             public IP 10.15 handles SMTP to the public, 20.15 is for admin and POP to/from the workstation on 20.250 wouldn't it be better this way: [ workstation ] [ mail server ] [192.168.20.250]-[ 192.168.20.15] [192.168.10.250]---[ switch ][ 192.168.10.15] | | [router 192.168.10.1] | public IP ? In any case, I believe there's some kind of problem with FreeBSD's net stack, as 'arp: 192.168.10.15 is on lo0' is imposiible. Timestamp: 0x441BAC4A [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Spam from NAT boxes
ipfw add fwd xx.xx.xx.xx,25 tcp from 192.168.0.0/24 to any 25 I got some matches in this rule when I try to send an email, but I didnt get redirected to my email server. our email server needs the same rule, fwd 127.0.0.1 .. so that the incoming packet is not rejected. remember, fwd doesn't alter the packet, justr where it is sent.. Without the extra rule your mail server will say why the heck did *I* get his packet? and discard it. Any ideas and/or sugestions? try natd's '-redirect_port'? Timestamp: 0x440CC7EC [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/60163
Hmm, could it be that the data track is always the last track ? Yes. so that CD players would be able to play the disks? or does not matter? Timestamp: 0x3E59D6A9 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID5 on athlon64 machines
Theoretically the sequential write rate should be same or higher than the sequential read rate. Given an N+1 disk Seq write rate for the whole RAID5 array will always be lower than the write rate for it's single disk. You compute max data rates by considering the most optimistic scenario, which is large sequetial writes. For *this* situation write rate will be higher than a single disk's. How can the RAID5 write rate be higher for the whole array if not only it needs to write the data to all if its drives, but also compute and write a parity block? The parity blocks are not read on data reads, since this would be unnecessary overhead and would diminish performance. The parity blocks are read, however, when a read of a data sector results in a cyclic redundancy check (CRC) error. You can only do so if you know the array is consistent. If the system crashed there is no such guarantee. So you either have to rebuild the whole array to get to a consistent state or do a parity check. If you don't check parity and you have an inconsistent array, you can have a silent error (the data may be trashed but you don't know that). But if you use RAM without parity or ECC, you probably already don't care about such errors. IMO, RAID does not protect against system crashes - all it does is provide performance increase and/or some protection against hardware failure (which will be detected with extremely high probability) enabling the admin to restore some data. p.S.: this is not hackers@ discussion. Timestamp: 0x43EEF1C0 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID5 on athlon64 machines
On Sun, 12 Feb 2006, [EMAIL PROTECTED] wrote: [missing attribution] You compute max data rates by considering the most optimistic scenario, which is large sequetial writes. For *this* situation write rate will be higher than a single disk's. How can the RAID5 write rate be higher for the whole array if not only it needs to write the data to all if its drives, but also compute and write a parity block? Easy, you can write simultaneously to more than one drive, assuming the drive was the bottleneck in the first place. Sorry, my mistake. Confused some RAID levels... Of course, with RAID5, the data block will be split (not mirrored) across several drives (plus a parity block will be added). Perhaps the original poster (bitblocks.com!bakul) may want to resend his question? Since he's experiencing performance problems with gvinum, this could very well be a hackers@ question; some more details may be needed, though. I apologize for all the confusion created here. Timestamp: 0x43EF2B47 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID5 on athlon64 machines
Theoretically the sequential write rate should be same or higher than the sequential read rate. Given an N+1 disk Seq write rate for the whole RAID5 array will always be lower than the write rate for it's single disk. See 'http://en.wikipedia.org/wiki/RAID#RAID_5' Traditional RAID5 A1 A2 A3 Ap B1 B2 Bp B3 C1 Cp C2 C3 Dp D1 D2 D3 [...] If another block, or some portion of a block, is written on that same stripe the parity block (or some portion of the parity block) is recalculated and rewritten. For small writes, this requires reading the old parity, reading the old data, writing the new parity, and writing the new data. [...] The parity blocks are not read on data reads, since this would be unnecessary overhead and would diminish performance. The parity blocks are read, however, when a read of a data sector results in a cyclic redundancy check (CRC) error. Timestamp: 0x43EE7046 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ASUS DRW-1608P, doesn't write anything
I have problem with an ASUS DRW-1609P with both 5.3 and 5.4. It won't write any media. Even burncd fails with the following error: (Yes, I know I have test mode on, I got tired of making coasters) burncd -f /dev/acd0 -s max -v -t data file.iso fixate adding type 0x08 file mp3.iso.aa size 72 KB 36 blocks next writeable LBA 2136 addr = 2136 size = 73728 blocks = 36 writing from file mp3.iso.aa size 72 KB written this track 1120 KB (0%) total 1120 KB only wrote -1 of 32768 bytes: Device busy Relevent line from dmesg: acd0: DVDR ASUS DRW-1608P/1.17 at ata1-master PIO4 atapicam doesn't fix it. UDMA doesn't fix it. GENERIC kernel. Reading works fine. Suggestions? Same with: acd1: ASUS DRW-0402P/D/1.05 DVDR drive at ata1 as slave acd1: read 5511KB/s (5511KB/s) write 2755KB/s (2755KB/s), 2000KB buffer, PIO4 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd1: Writes: CDR, CDRW, DVDR, test write, burnproof acd1: Audio: play, 256 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc I simply use it through ATAPICAM layer with cdrecord - always worked perfectly. Would be interesting to know why these devices don't behave properly. Timestamp: 0x4260B31F [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system identification
ISTR that there is a semi-standard way of obtaining the system (or motherboard) manufacturer and model from the BIOS or CMOS on PC clones, but all I can find right now is the BIOS copyright string starting at fe00:000e. Can anyone here refresh my memory? DES This might not be exactly what you need, but see '/usr/ports/sysutils/dmidecode' for some code. AFAIK, this approach should work on most newer machines. Is it necessary to obtain the mainboard manufacturer/model, or knowing chipset would be enough? Timestamp: 0x425518CE [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FUD about CGD and GBDE
I also believe that it would be beneficial to implement regular rewriting of randomly picked lock sector(s) at random times during a user specified interval (up to x rewrites within n seconds) in order to further obscure the write pattern and provide additional protection for lock sectors. ALeine I agree. I would also add random reads (or specially designed, combined random reads and writes) to make traffic analysis and differential attacks a real PITA for the hacker (although this idea may not be very effective against a highly motivated and determined attacker, such as some government, for instance). Every data storage device has to be hot, initially at least. Moreover, it is much better to keep the disk attached until the last minute before the attacker will get access to it, because this offers the user protection: deleting keys from a cold disk is not possible. Therefore, it is important for GBDE to protect hot disks as much as possible (including protection methods against cleaning lady copy differential attacks, for SAN environments other traffic analysis attacks, etc). BTW, PHK, why did you choose the scheme of encrypting offsets of lock sectors with part of key material and storing them somewhere, instead of just using part of the key material itself to determine the offsets? Timestamp: 0x422BE3D9 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FUD about CGD and GBDE
I agree. I would also add random reads (or specially designed, combined random reads and writes) to make traffic analysis and differential attacks a real PITA for the hacker (although this idea may not be very effective against a highly motivated and determined attacker, such as some government, for instance). If you want to do something like this, you want to do sectorrenaming and journaling since that means you can only see that something was written but not what it was that was written. So you think that just adding specially crafted, random reads/writes will have no significant positive impact on security of hot disks? The performance cost can be considerable and the complexity formidable. There are incredibly many cornercases to handle. But you do not deny that providing strong protection for hot disks is very important? After all, user protection is only available when the disk is hot. Speaking of user protection, how did you implement the procedure of erasing keys? Did you account for the properties of magnetic media and RAM that make data recovery possible? See, for example: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html Timestamp: 0x422C930D [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FUD about CGD and GBDE
If you want to do something like this, you want to do sectorrenaming and journaling since that means you can only see that something was written but not what it was that was written. So you think that just adding specially crafted, random reads/writes will have no significant positive impact on security of hot disks? No I don't think so, because I tried it and were able to see straight through it myself. The trouble is that normal disk activity is not random. Randomness sticks out like a sore thumb in any sort of analysis, this is why plausible denial of existence of encrypted data is so hard that it is almost impossible when faced with a good adversary. The main goal of the idea was not to hide the encrypted slice (which would be indeed extremely hard), but to help obscure the locations of GBDE's sensitive sectors. It is true that, as you said, completely random queries to the disk can be identified and filtered out by an expert adversary, but it will be much more of a challenge (or at least a significant difficulty) for him when researching the disk structure (using snapshots, traffick analysis, etc) if the following example points are implemented: - randomized (but not completely random) rewrites of lock sectors; perhaps a lock sector could be rewritten intermittently when a nearby data sector is written, so that the attacker is either fooled into thinking that it can't be a lock sector, or will know that statistical analysis on the disk will not yield lock sectors' locations. - randomized (user-configurable) and out-of-sequence reads and/or writes of key sectors so that it will be harder to figure out zone size and offset. These are just an oversimplified approximation of the concept. Hmm... Suddenly the idea doesn't seem so good anymore. Likely it will cause more PITA to the developer than to the attacker. The attacker would still be able to gather some info about the filesystem (superblock locations, maybe even inode locations, etc), and this even bigger threat can be prevented only by using journalling sectorrenaming. But you do not deny that providing strong protection for hot disks is very important? After all, user protection is only available when the disk is hot. It is very important, but it is also a task which is very formidable in comparison with protecting cold disks. When done properly and right from the start - yes, but IMO there always will be some for improvement which may be added with time, so protection of hot disks should not be ignored. Seeing that you agree to this, now I'm not worried that GBDE is not or will be not as strong as reasonably possible, in all modes of operation. (Hint: attend BSDcan2005). 3.5 thousand km one way may be a bit too long a ride for me :) this would be at least a 10-day trip... Speaking of user protection, how did you implement the procedure of erasing keys? Did you account for the properties of magnetic media and RAM that make data recovery possible? See, for example: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html No I did not, because there is no reliable way to counter it from software. There may have been once upon a time when that paper was written 10 years ago (although I seriously doubt the actual efficiency of the proposed schedules), but these days with Giant Magnetoresitive head technology and Partial Response Maximum Likelyhood decoding you can write and write and write and you will have no idea if it works or not. Bad sector forwarding is another issue in this area. There are commercial companies who have specialized in recovering deleted data from trackfringes. Still, you could just add a few hundred rewrites with random data. This would decrease probability that the key can be recovered, just as the crypto techniques used in GBDE increase the safety of the data (comparing to CGD, for instance), but never guarantee it. Also, one may even change (if needed) the way GBDE keeps masterkey, salt, etc in memory: avoiding keeping this data at one place in RAM for a long time will practically ruin the hopes to recover anything useful from deenergized RAM. Timestamp: 0x422CABCF [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple hard disk failures - coincidence ?
I've just had *THREE* Maxtor 250GB hard disk failures on my FreeBSD 4.10 server within a matter of days. One I could attribute to actual failure. Two made me suspicious. Three has me wondering if this is some software problem... (or a conspiracy (just kidding) ;-) ) Are the errors occuring at around the same block numbers? I recall a thread on -current talking about how some drives reported failures around the 133GB mark. Soren recently committed a patch to -current changing the point at which 48bit addressing is used to work around this. It may be worth investigating. that would be different kind of error: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=268435455 Timestamp: 0x41C40644 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Re: Linksys PCM200
Okay, so I got unlazy and threw some stuff together. Try these patches; this will default the PCM200 cards to store-and-forward. This might help. -ksaihr [...] --- /usr/src/sys/pci/if_dcreg.h Thu Aug 5 13:46:14 2004 +++ if_dcreg.h Sun Oct 24 13:09:31 2004 @@ -98,6 +98,13 @@ #defineDC_IS_XIRCOM(x) (x-dc_type == DC_TYPE_XIRCOM) #define DC_IS_CONEXANT(x) (x-dc_type == DC_TYPE_CONEXANT) +/* Cards requiring specific workaround */ + /* Linksys PCM200 */ +#define DC_IS_LINKSYS(x) \ + (x-dc_type == DC_TYPE_AN985 \ +pci_get_vendor(dev) == DC_VENDORID_LINKSYS \ +pci_get_device(dev) == DC_DEVICEID_PCM200_AB08) + /* MII/symbol mode port types */ #define DC_PMODE_MII 0x1 #define DC_PMODE_SYM 0x2 I've tested the patch. The kernel won't compile with it: 'dev' [as in pci_get_vendor(dev)] is not defined. Don't have time now to investigate :( Timestamp: 0x419C4B20 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linksys PCM200
I applied the patch that Brooks suggested to my 5.2 system uname -a output: FreeBSD 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE $4: Mon Nov 8 23:27:59 PST 2004 root@:/usr/obj/usr/src/sys/COGNITION i386 I still get watchdog timeouts, and eventually a kernel panic which seems to be related. Is there an additional patch to the 5.2 code that I can apply to take care of the watchdog timeout? When I first wrote the patch for 5.2.1-R, it didn't work (search the archives). Then I tested it on 5.3-BETA7 - it works flawlessly for me so far. There were quite a few changes to the driver since 5.2.1-R Thanks. Richard Schilling Timestamp: 0x419C4C4A [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linksys PCM200
Looks like there's a couple of versions of the card. I have the PCM200 Version 2, whatever that means for the chipset. Linksys tech support now, that's why I suggested to leave the card's version number in the description string, as in my original patch! the patch _is_ for PCM200 v.2 (and possibly others), and it does seem to be based on AN985 chipset. thought it was the ADMtek chipset, but I suppose there could be a couple different ADMtek chipsets available ... I'm waiting to hear back from technical support. I've also sent in an e-mail to the people who wrote the Linux driver. It would be really nice to see, for each version of the card, what the chipset is... Timestamp: 0x419C4CE3 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad0: FAILURE - WRITE_DMA
This sounds very possible to me. I have been experiencing the same error, on a system that I've been trying to set up using 5.3-RC1 and a new 160Gbyte SATA drives My hardware is: atapci0: SiI 3112 SATA150 controller port 0xb000-0xb00f,0xac00-0xac03,0xa800-0xa807,0xa400-0xa403,0xa000-0xa007 mem 0xdf081000-0xdf0811ff irq 18 at device 11.0 on pci1 ad4: 152627MB ST3160023AS/3.18 [310101/16/63] at ata2-master SATA150 (I notice that Michail and I both have Seagate drives ...). I had problems with a filesystem on a partition which crossed the LBA=268435455 threshold. After googling and reading this thread and Søren's posting, I tried removing the filesystem and making a little 1000 sector partition which straddled the lba48 transition sector - I was able to get read and write failure messages of the above form reproducibly, by dd-ing between the test partition and /dev/zero. The same problem with similar IDE Seagate HDD: ad0: ST3160023A/3.06 ATA-6 disk at ata0-master ad0: 152627MB (312581808 sectors), 310101 C, 16 H, 63 S, 512 B [...] ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=268435455 It had 312581808 sectors, but failed at = 268435455 : bash-2.05b# dd if=/dev/ad0 of=/dev/null bs=512 skip=268435453 dd: /dev/ad0: Input/output error 2+0 records in 2+0 records out 1024 bytes transferred in 0.163827 secs (6250 bytes/sec) bash-2.05b# dd if=/dev/ad0 of=/dev/null bs=512 skip=268435454 dd: /dev/ad0: Input/output error 1+0 records in 1+0 records out 512 bytes transferred in 0.156888 secs (3263 bytes/sec) bash-2.05b# dd if=/dev/ad0 of=/dev/null bs=512 skip=268435455 dd: /dev/ad0: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.149888 secs (0 bytes/sec) Decreasing the 48-bit LBA threshold by 1 really helped: bash-2.05b# dd if=/dev/ad0 bs=512 skip=312581808 0+0 records in 0+0 records out 0 bytes transferred in 0.88 secs (0 bytes/sec) bash-2.05b# dd if=/dev/ad0 bs=512 skip=312581807 1+0 records in 1+0 records out 512 bytes transferred in 0.019809 secs (25847 bytes/sec) Timestamp: 0x41826DE9 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Re: Linksys PCM200
I don't see a way how it could break other cards' functionality - should be no concerns here D-Link isn't the only 0x00a8; The AboCom FE2500MX bears 0x13d1 0xab08. Are there any cards that have exactly the same 32-bit PCIID, and different/modified chipsets? I didn't think that something like that is possible... Anyway, the PCM200's PCIID doesn't seem to conflict with any other card's, so I'm sure it won't break anything. 0. More info is _always_ better. In any case, the message will take 2 lines on console, so shortening the description will not gain anything Yes, it does. It gains readability. compare: dc0: Linksys PCM200 EtherFast 10/100 CardBus NIC, v.03 (ADMtek Centaur-C) port 0x1000-0x10ff mem 0x88002000-0x880023ff irq 9 at device 0.0 on cardbus1 and dc0: Linksys PCM200 EtherFast CardBus 10/100 port 0x1000-0x10ff mem 0x88002000 -0x880023ff irq 9 at device 0.0 on cardbus1 Is the latter more readable? I think they're the same. The former is even more readable for me, because the description is on one line, and all the I/O info is on the other. Also, if I will need to send dmesg to somebody (for example, the card could create a problem by conflicting with some other hardware), they will know _exactly_ what card is it (and even if they're not familiar with this card, they'll know the chipset). Long descriptions should generally be reserved for pciconf -lv and driver comments. for this card, `pciconf -lv` outputs not much useful info: [EMAIL PROTECTED]:0:0: class=0x02 card=0xab091737 chip=0xab091737 rev=0x11 hdr=0x00 vendor = 'Linksys' device = 'PCM200 10/100 CardBus Ethernet Adapter' Even the chipID is changed. It also does not state card's version (one will need to figure that out from revID) - and, according to info in the INet, card's versions differ between each other noticeably. 2. when PCI IDs for previous card versions will be added, the description will need to be changed anyway to include the version number Only because D-Link has a 'change everything except the model name' fetish. Unless D-Link pulled the same crap they did with the DWL-520 and DWL-650, personally I don't see any compelling reason to include chipset and revision in the dev's desc. why not? there can never be too much info :) Now, if D-Link pulled the same crap on this as they did with the DWL-520, I'd say just slap Rev.D in there; there's no need for chipset name chipset name makes the dmesg message separate nicely into 2 lines :p Anyway, enough on this. I'd personally prefer to see my long description commited, but seems like the FreeBSD developers know better what to do (as they were able to create such a great OS). I'll test the store-and-fwd patch later today. I thought however, that it has to swith to that mode because my notebook (and CardBus controller) isn't fast enough. Form `man 4 dc`: dc%d: TX underrun -- increasing TX threshold The device generated a transmit underrun error while attempting to DMA and transmit a packet. This happens if the host is not able to DMA the packet data into the NIC's FIFO fast enough. Timestamp: 0x417C1321 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Re: Linksys PCM200
If you have done any testing, that should be sufficent. I've done a little testing under various loads. The driver switches chip to store and forward mode soon during initial use after attaching (I also get few messages about watchdog timeouts together with increasing TX threshold). But it seems to work OK. I haven't done any serious performance testing (maximum speed it could reach was ~ 5Mb/s on 100baseTX/FD) nor attach/detach tests. After all, the hardware didn't work before, right? yes, it wasn't recognized before It did work before that's another issue, but if not, all that matters is that we don't break any other cards. I don't see a way how it could break other cards' functionality - should be no concerns here I suggest that you change the description to: Linksys PCM200 EtherFast 10/100 CardBus NIC, v.03 (ADMtek Centaur-C) Card's versions differ between each other significantly. Also, there will be no easy way to find out card's chipset if it won't be stated in the description. The string will fit on console even better: dc0: Linksys PCM200 EtherFast 10/100 CardBus NIC, v.03 (ADMtek Centaur-C) port 0x1000-0x10ff mem 0x88002000-0x880023ff irq 9 at device 0.0 on cardbus1 I disagree. If you need that level fo detail, you should use pciconf -lv. I don't see a real reson not to use more complete description. There are few resons to use it: 0. More info is _always_ better. In any case, the message will take 2 lines on console, so shortening the description will not gain anything 1. the description in `pciconf -lv` does not show card's version and chipset 2. when PCI IDs for previous card versions will be added, the description will need to be changed anyway to include the version number Timestamp: 0x417A853C [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] Re: Linksys PCM200
Could some people with dc(4) devices please test the following patch? It compiles for me and is trivial, but a quick test is probalby in order before I commit it. It's rather necessary to test it well, because I didn't actually remove the card's case to see the chip; I relied on my own tests and info from the INet, thus some problems may appear if Linksys modified the chipset Linksys PCM200 is the only 32-bit PCMCIA NIC available in Compusmart - I'm sure that soon someone will buy the card, find the patch, and test it. It's better to wait for feedback before committing the patch. This differs from soralx's patch in that it adds comments on the 0xab08 collisions and shortens the description string to something that will fit in one line on the console. I suggest that you change the description to: Linksys PCM200 EtherFast 10/100 CardBus NIC, v.03 (ADMtek Centaur-C) Card's versions differ between each other significantly. Also, there will be no easy way to find out card's chipset if it won't be stated in the description. The string will fit on console even better: dc0: Linksys PCM200 EtherFast 10/100 CardBus NIC, v.03 (ADMtek Centaur-C) port 0x1000-0x10ff mem 0x88002000-0x880023ff irq 9 at device 0.0 on cardbus1 Timestamp: 0x4178A3E1 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] Re: Linksys PCM200
[got no answer on [EMAIL PROTECTED]
I've tested this on 5.3-BETA7 - works OK, no more watchdog timeouts.
So could someone review those patches and add them to the source tree?
It's probably a good idea to update dc(4) and supported hw list also.
/usr/src/sys/pci/if_dc.c udiff:
--- ./if_dc.c Sat Jan 24 22:23:21 2004
+++ /fd0/if_dc.cWed Oct 13 20:56:08 2004
@@ -217,6 +217,10 @@
Microsoft MN-130 10/100 },
{ DC_VENDORID_MICROSOFT, DC_DEVICEID_MSMN130_FAKE,
Microsoft MN-130 10/100 },
+ { DC_VENDORID_LINKSYS, DC_DEVICEID_PCM200_AB08,
+ Linksys PCM200 EtherFast 10/100 CardBus ethernet adapter, v.03 (ADMtek
Centaur-C) },
+ { DC_VENDORID_LINKSYS, DC_DEVICEID_PCM200_AB09,
+ Linksys PCM200 EtherFast 10/100 CardBus ethernet adapter, v.03 (ADMtek
Centaur-C) },
{ 0, 0, NULL }
};
@@ -1978,6 +1982,7 @@
case DC_DEVICEID_3CSOHOB:
case DC_DEVICEID_MSMN120:
case DC_DEVICEID_MSMN130_FAKE: /* XXX avoid collision with PNIC*/
+ case DC_DEVICEID_PCM200_AB09:
sc-dc_type = DC_TYPE_AN985;
sc-dc_flags |= DC_64BIT_HASH;
sc-dc_flags |= DC_TX_USE_TX_INTR;
/usr/src/sys/pci/if_dcreg.h udiff:
--- ./if_dcreg.hFri Jan 9 14:13:56 2004
+++ /fd0/if_dcreg.h Wed Oct 13 20:44:50 2004
@@ -1002,6 +1002,18 @@
#define DC_DEVICEID_MSMN1300x0002
#define DC_DEVICEID_MSMN130_FAKE 0xFFF2
+/*
+ * Linksys vendor ID
+ */
+#define DC_VENDORID_LINKSYS0x1737
+
+/*
+ * Linksys device IDs
+ */
+#define DC_DEVICEID_PCM200_AB080xab08
+#define DC_DEVICEID_PCM200_AB090xab09
+
/*
* PCI low memory base and low I/O base register, and
* other PCI registers.
Timestamp: 0x4172A6A5
[SorAlx] http://cydem.org.ua/
ridin' VN1500-B2
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
We could add a new flag srunlnk, or maybe even srm-r. The rm command will always have to stat() the file it is given (just to see if it is a directory), so it could check to see if this flag is turned on. If it is turned on, then 'rm' could refuse to honor any '-rf' request on that directory. Why not to just add a flag to 'rm'? For example, `rm -rf /` or `cd; rm -rf .././` will fail, but `rm -rF /` will succeed. Timestamp: 0x415F2702 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Geode based PC/104 micro board and FreeBSD
If I install FreeBSD to CF card on other PC and use this CF card to boot this machine, it will lockup 5-15 seconds after I login to it on the console. try booting without ACPI Timestamp: 0x414F3755 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
586Core
Good localtime() I'm starting some small project, and I need to decide what hardware will fit its needs. I'm looking for a small single-board computer that should have minimum: 2 serial ports (RS232 [RS232 | USB(preferable)]), 8-bit databus, FLASH disk, RTC, 486 CPU performance, low power consumption; should be able to run FreeBSD. PCB size does not matter much. One of the applications I plan to run on it is 'gnokii'. I've found this: 'http://www.compulab.co.il/586core.htm', and I'd appreciate to get some opinions on this product. Is anyone using it? How well does it work with FreeBSD (or *BSD)? How well FBSD works with its USB controller (ScanLogic SL811HST)? Maybe someone can suggest a better and possibly less expensive alternative? I'd like to get as many opinions as possible, therefore crossposting. Sorry. Timestamp: 0x41453D16 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The continued remote debugging saga...
| This works SOMETIMES boot() which just takes an int of boot flags (which was the 0 that I shoved into eax for RB_AUTBOOT). are you shure that you don't need to push the 0x0 into stack (`MOV ESP,0x0`)? Timestamp: 0x41367B68 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reboots after OR AL,1 MOV CR0, EAX on some computers.
good free environment for initialization and further running. Shortly: ON SOME COMPUTERS (MAYBE CPUS) I GET REBOOTING JUST ON 'JMP' INSTRUCTION AFTER PE BIT IS ENABLED. I've got no reboots on all i386, i486, i586 computers that I tryed to boot from. I have a Pentium III Celeron (Coppermine) 900MHz - no reboots. Also tested on some Pentium II 400MHz - no reboots. But on other side Pentium IV (don't remember speed) gave me a reboot. And other computer I was not able to see processor model (maybe PentiumIV !?) gave me a reboot too. Using endless loop stop points I figured out that reboot is before any instruction pointed by 'protected' label and that reboot happens after setting the PE bit. I've tested the code on a Dual-CPU P-166 - the system always goes into cold reboot. I first thought that SMP systems need some special procedure to switch to protected mode (the fact that all Pentium IV CPUs have second logical processor helps the idea), but then I tested it on Athlon XP system - reboots also. I'll play with it later. Maybe somebody at freebsd-hackers know the answer? Timestamp: 0x4118F317 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Next Generation kernel configuration?
The debate here is automation vs. simplification. Why we shouldn't simplificate the kernel compile ? Because our user base's average IQ will be lower ? We're not suggesting to have KDE installed by default here. Users would still to have to type the commands to compile the kernel by hand and do a little research about the options they enabled. XFree86 has ncurses/graphic configuration utilities. Why the kernel shouldn't ? Because configuring kernel by editing config files is, IMHO, the fastest and most convenient method. New FreeBSD users should get used to it from the beginning - this will save their time in future. There's nothing hard in editing the files, especially after few kernels for different machines have been created (they can be used as templates). Timestamp: 0x41005EBC [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 1.1.5.1-R cvs repo archive?
I am looking for the source code (if there is somewhere I can find the repository, that would be great) of the last FreeBSD 1.x RELEASE. Is it legal today? And if it is, is it possible for me to obtain a copy over the Internet? I have Google'ed with no luck :-( ftp://ftp.ru.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/1.0-RELEASE (although that's not exactly what you're looking for) Timestamp: 0x409DB426 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel activity
I'm running a pretty busy webserver, and right now I can see it's CPU-bound: %vmstat 1 procs memory pagedisks faults cpu r b w avmfre flt re pi po fr sr da0 ac0 in sy cs us sy id 78 2 0 1135684 144648 93 0 0 0 248 82 14 0 319 235 136 26 35 39 72 2 0 1135668 144060 25 0 0 0 160 0 19 0 1971 141871 1098 41 59 0 84 2 0 1135836 142692 82 0 0 0 405 0 35 0 3144 246325 1739 42 58 0 77 2 0 1135732 142104 168 0 0 0 343 0 20 0 2129 155969 1314 38 62 0 and I'm trying to figure out why so much time is consumed in 'system mode' (to see if I can further tune the box or not). Any idea what kind of structures/utilities I should consult for that? do you already use polling for the NIC? Timestamp: 0x40563F7E [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: off topic - disk crash
With certain directories or files I get READ_DMA timeouts and also the system hangs totally when a certain type of error occurs. ad2: TIMEOUT - READ_DMA retryinmg (2 retries left) LBA=24703729 ad2: WARNING - READ_DMA Interrupt was seen but but timeout fired LBA=24703729 ad2: WARNING - READ_DMA Interrupt was seen but but taskqueue stalled LBA=24703729 ad0: FAILURE - WRITE_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=9825063 What I find strange is that the failing drive on the secondary IDE channel causes the primary channel also to fail. I wonder if this has to happen or could be avoided. I can only reboot from that point on. I used a straightforward approach: copy files with midc, note on which the system freezes, reboot, and skip those files. Eventually I got everything impotant recovered. BTW, one of the few files which could not be read was the Apache log - another reason to keep huge logs on sepatate drives (or slices, at least). :) Timestamp: 0x4054BCAD [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HDD problem research (was HDD questions)
Does any body have Segate drive ST380021A working with FreeBSD? I do. For ~ 1.5 years now. Still running 4.6.2-RELEASE; booted 4.8-RELEASE live-CD (frenzy.org.ua) without any problem. ad0: 76319MB ST380021A [155061/16/63] at ata0-master UDMA100 IDE controller: Intel ICH4 Timestamp: 0x40500478 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SPAM/virii apparently from freeBSD addresses.
Swen and MyDoom are easy to detect and reject at the SMTP stage. The fact that our mail servers don't do this is a PITA, as it forces list subscribers to accept them as well (if you reject list mail because it contains a virus, Mailman disables your subscription) not a problem - those should be silently discarded and not rejected anyway Timestamp: 0x40442CF6 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [call for helpers!] Tuning for the Beaver Challenge
Beaver Challenge 2004 is coming!. Details in http://osuosl.org/benchmarks/bc/ We are preparing the tuning guide. Definitely we need suggestions and comments. does the sysctl 'machdep.cpu_idle_hlt' still have any effect? see: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=36729+40701+/usr/local/www/db/text/2003/freebsd-hackers/20031012.freebsd-hackers Timestamp: 0x40288509 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Update: PR bin/60636 / SPAM
I am getting these MS Update stuff too for 3 month now ... very annoying ! you can setup DrWeb (/usr/ports/security/drweb-mailer-daemon) on the mailserver and tune it to drop all emails with Klez - that _really_ helps Timestamp: 1072746574 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I'm resigning from FreeBSD
Subject: I'm resigning from FreeBSD ;; QUERY SECTION: ;; 104.61.54.202.in-addr.arpa, type = ANY, class = IN inetnum: 202.54.61.96 - 202.54.61.111 [...] 202.54.61.104 is a proxy Timestamp: 1072499268 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adding more ram
The same was true for 10.20 and 11 Versions of HPUX - I believe there once was I very long going debate when the new FreeBSD vm was made on the issue. The fundamental question at the time was what to do when you run out of swap/vm space. The 1-1 backing of swap space was seen as a way to avoid that you have resort to kill random processes in order to free up space and the tradition with the 2-1 swap ratio used to have a performance reason in the initial Unix Swap and paging implementations. I can't seem to recall the actual reason While we're at this topic, can somebody plz briefly explain how does swap performance depend on swap size? From `man 7 tuning` (May 25, 2001): The kernel's VM paging algorithms are tuned to perform best when there is at least 2x swap versus main mem- ory. Configuring too little swap can lead to inefficiencies in the VM page scanning code as well as create issues later on if you add more mem- ory to your machine. Is this still true? For -CURRENT also? 10.12.2003; 18:42:17 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd smp - linux up
sadly, all ktrace shows is ktrace launching vmware (from 'ktrace vmware', shows sh reading and executing, and then ends with the vmware fork). why not to `ktrace` vmware binary '/usr/local/lib/vmware/bin/vmware' instead of the shell-script 'vmware'? 28.11.2003; 23:00:47 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: isapnp vs pci card: device_probe_and_attach
Isn't there a way so that the PCI card will use another irq and initialize correctly ? AFAIK, you should be able to assign(reserve) IRQs to ISA in BIOS. 19.09.2003; 21:29:20 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug FreeBSD 4.8 ATA driver
I am reading FreeBSD ATA drivers because I want to use them as base for
my ATA driver and I found a total nonsence: in ata-dma.c in FreeBSD 4.8,
there is line
if (!((pci_read_config(parent,0x40,4)(ch-unit8))0x4000)) {
if ch-unit is 1, config word is shifted by 256 bytes, which gives
undefined result in C. How was this meant? What should it do?
Hm, it should be (IMHO)
if (!((pci_read_config(parent,0x40,4)(ch-unit5))0x4000))
but I can't verify it as have no access to documentation for PIIX3 nor
acces to the PIIX3 hardware now.
I have PIIX3 contorller on a machine with FreeBSD 4.8-RELEASE; I am willing to
test whatever needed.
26.08.2003; 22:32:58
[SorAlx] http://cydem.org.ua/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
The transfer rates are usually given for the outside of the disk I think. Average transfer rates is what's usually given ([inside+outside]/2) - at least that's what manufacturers say. However, as they usually seem too high, probably the data rate for the first few thousand sectors are given. 01.08.2003; 18:33:47 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Maybe not, but they do give a transferspeed from medium range and that is what can be expected. Hmm, I guess not everyone does that. We have some seagates here at work we were wondering about because they seemed too slow, and we couldn't find anything aside from what we already knew... the tranfer speed of the SCSI interface, which is basically from drive cache to controller. That is unless the manufacturers hide the info somewhere so you really have to dig, which wouldnt' surprise me. Example took me less than 64 seconds to find (for Seagate Barracuda IV): http://www.seagate.com/cda/products/discsales/personal/family/0,1085,559,00.html Look for 'Avg. Sustained Transfer Rate'. AFAIK, every manufacturer I know gives the sustained transfer rate specs (which are sometime a bit too high than in reality). If the specs are not specified, it'd be very suspicious, and I would think 128 time before buying such drives. 31.07.2003; 18:28:06 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network stack cloning / virtualization patches
A third issue on the x86 is a lack of registers: There are only 6 general purpose registers (and each of them actually has a specific purpose). Eating one of these registers to maintain a pointer to a struct vimage will be a noticable performance hit. Why not to store it in memory? If the pointer needs to be read often, there is a high chance that it will be in CPU's data cache. Nowadays with these huge FSB frequencies reading dword from RAM won't be _much_ slower that reading it from a register anyway. IMO, experiment is req'd to see if you will win some performance be freeing a register. Or am I wrong? 03.06.2003; 21:30:43 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: misc/41772: can't disable keybell [PATCH]
Incidentally, using quiet.off doesn't
shut it up either which is very confusing since quiet sets
SC_QUIET_BELL.
it does, actually
the `man kbdcontrol` doesn't say that it also checks to see
if the beeping console is not current:
if (scp != scp-sc-cur_scp (scp-sc-flags SC_QUIET_BELL))
+} else if (duration != 0 pitch != 0) {
why using if (duration != 0 pitch != 0) is
better than if (!(duration pitch))?
Can you verify that this fix works for you?
OK, I'll check it after work
22.03.2003; 09:09:34
[SorAlx] http://cydem.org.ua/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: misc/41772: can't disable keybell [PATCH]
Using kbdcontrol -b off on my laptop running current does
turn off the sound already.
I tested `kbdcontrol -b off` on FreeBSD 5.0-RELEASE, and it
still did not turn off the beeper. I have also checked
'syscons.c', v. 1.399 ([0]), and foud only one change
concerning keybell:
'if (cold || shutdown_in_progress || !enable_bell)' -
('enable_bell' added, which must be hw.syscons.bell
sysctl var), that enables to turn the keybell off globally,
but not for separate vtys.
Incidentally, using quiet.off doesn't
shut it up either which is very confusing since quiet sets
SC_QUIET_BELL.
I tested this again, and it works fine:
`kbdcontrol -b quiet.normal`
`(sleep 2;echo -e \x07;sleep 2)`
When, after executing this command, i quickly switch to
another vty, I hear no bell; when I stay on the same vty,
I can hear the bell.
PCI ID's for the ICH4 controllere were committed prior to 4.7.
good, found my controller's ID in the latest CVSweb ATA-PCI tree
This patch would inadvertently turn off visual bell's if you
set the duration or pitch to zero manually. A better patch
might be:
Index: syscons.c
===
RCS file: /usr/cvs/src/sys/dev/syscons/syscons.c,v
retrieving revision 1.399
diff -u -r1.399 syscons.c
--- syscons.c 3 Mar 2003 16:24:44 - 1.399
+++ syscons.c 22 Mar 2003 14:38:58 -
@@ -3547,7 +3547,7 @@
if (scp != scp-sc-cur_scp)
scp-sc-blink_in_progress += 2;
blink_screen(scp-sc-cur_scp);
-} else {
+} else if (duration != 0 pitch != 0) {
if (scp != scp-sc-cur_scp)
pitch *= 2;
sysbeep(pitch, duration);
Can you verify that this fix works for you?
yes, it does
but, I think, this may produce faster code:
+} else if (duration pitch) {
I also found couple more problems:
00.
`kbdcontrol -b 128.800`
`(sleep 2;echo -e \x07;sleep 2)`
If I stay on the same vty, I hear 800Hz bell, if I switch
to another vty, I hear ~400Hz bell.
`kbdcontrol -b normal`
`(sleep 2;echo -e \x07;sleep 2)`
If I stay on the same vty, I hear normal bell, if I switch
to another vty, I hear a bell with pitch twice as _high_.
01.
`kbdcontrol quiet.115.400` - won't set SC_QUIET_BELL flag
[0]
(http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/root/src \
/src/sys/dev/syscons/syscons.c?rev=1.399content-type=text/plain)
22.03.2003; 23:12:44
[SorAlx] http://cydem.org.ua/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: misc/41772: can't disable keybell [PATCH]
http://www.freebsd.org/cgi/query-pr.cgi?pr=41772
This appears to be _VERY_ old problem (I don't remember
it on 2.2.7-RELEASE, though)
In short: the beeper still produces noises (clicks) when
shut up with `kbdcontrol -b off`
Finally I got some time to look at
'sys/dev/syscons/syscons.c'. However, I only speak
i386 Asm fluently (no C at all yet), so could
someone plz (fix?) this 3-line 'patch' and commit
it? I'd really like to see it MFC'ed in 4.8-RELEASE
(as well a this one:
'http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/44257' -
it works well for my EIDE controller).
FreeBSD 4.6.2-RELEASE:
===8===
--- ./syscons.c.ORIGFri Mar 21 23:10:05 2003
+++ ./syscons.c Fri Mar 21 23:10:37 2003
@@ -3385,6 +3385,9 @@
if (scp != scp-sc-cur_scp (scp-sc-flags SC_QUIET_BELL))
return;
+if (!(duration pitch))
+ return;
+
if (scp-sc-flags SC_VISUAL_BELL) {
if (scp-sc-blink_in_progress)
return;
===8===
21.03.2003; 23:20:26
[SorAlx] http://cydem.org.ua/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
5000 packets transmitted, 94 packets received, 98% packet loss round-trip min/avg/max/stddev = 0.156/0.337/0.605/0.159 ms So I'm not see much difference. are you sure it's not because of this: 'ping: sendto: No buffer space available'? 12.03.2003; 18:56:02 [SorAlx] http://cydem.org.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
| are you sure it's not because of this: | 'ping: sendto: No buffer space available'? No such messages appeared. I forgot that I hooked it up to 10Mbit hub for now, so nevermind 8) are you piping it through 'less'? you won't see this message in 'less' output what's the value of your 'kern.ipc.nmbclusters'? `sysctl kern.ipc.nmbclusters`: kern.ipc.nmbclusters: 4560 (FreeBSD 4.6.2-RELEASE) I'll test 'rl' vs 'xl' later on 100Mbit/s. 12.03.2003; 20:16:35 [SorAlx] http://cydem.org.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kern/40611 linux compatibility fix
I didn't know there're so many people running linux apps under emulation. I've a couple of other linux related patches for -stable, among them backport of linux ptrace from -current, anyone interested? yes, it would be good to have 'ptrace' backport already in 4.8-R, if not too late (good to have breakpoints working in Linux 'gdb') 04.03.2003; 22:56:26 [SorAlx] http://cydem.org.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: where's my pr gone? - supplemental
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/47512 this happens only with the above link, i.e. from the pr summary. searching for the bugid 47512 works (= not empty) works as well with the link 16.02.2003; 03:03:54 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Lower power SMP boxes?
The easiest thing to do is under-clock a very fast processor, if what you want to do is drop power requirements, as you've said. I would _really_ like to watch this process: you underclocking new Xeon 2GHz to 1GHz (minimum speed of VIA Nehemiah), trying to lower Vcc by 0.1V at most and get it working, and finally putting passvie radiator on it :) 50 Amps actually isn't too much, and 55W of heat - it's only 2 medium-power soldering irons... 8) 01.02.2003; 18:49:57 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5400RPM|7200RPM Cable bottleneck?
If by 'cable' you mean a cable modem providing at best a few Mb/s bandwidth, then I doubt the speed of your disk will have any impact whatsoever. Even the crappiest ATA disk will be able to deliver a few MB/s -- in the worst case that's still an order of magnitude more than you can stuff down your cable modem. what if he needs to read lot of small files (few KB) - he'd better get 7200RPM UDMA HDD with big cache... 18.01.2003; 11:11:30 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DDoS attacks, packets captured ... not sure what to do.
Knowing his IP address is useless, if it's a denial of service, unless you have a peering agreement with his NSP/ISP, and/or are within driving distance, and own a shotgun. That is what I'm talking about. :) And I think that the attaker lives not so far from him, since you need to have very good Inet to send thousands pps. BTW, what were the UDP packets for? Scanning? Otherwise, they might have been a Linux NFS over UDP client (same thing, really), or some other attack (e.g. attempted DNS poisoning, etc.). no - he says that the packets are sent to random ports So, watch and try to get the real IP 8) 07.01.2003; 19:42:31 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DDoS attacks, packets captured ... not sure what to do.
1. a ton of TCP SYN, [1658] - [106] 3COM-TSMUX to ports that do not exist on the target. this is not a 'SYN flood'; 'SYN flood'=TCP SYN+FIN seems like someone is continuosly using TCP SYN half-open scan to get your open ports, or just sends random SYN pakets 2. a noticable amount of christmas tree packets aimed at the target: TCP FIN SYN RST PSH ACK, [1400] - [98] TAC-news again, to ports not actually open on the target. Also some of them are not quite as xmas as other: TCP SYN RST PSH ACK, [1230] - [118] SQL-service again, directed at a service that does not exist. try using 'ipfw' option 'tcpflags' to ignore such packets, or dummynet 3. These seem less frequent, but I am seeing: UDP, [21397] - [2284] ^M Source port: [21397] ^M Destination port: [2284] ^M UDP length: 908^M Checksum: 0x (data fragment - not able to check)^M So .. a UDP fragment sent to a port not open on the target. This also seems like bad news. UDP scan? try options ICMP_BANDLIM, if not already enabled 3. will the solutions given to me actually help ? I mean, the packets will still hit my firewall, and given the cpu utilization and config I showed you earlier, will the fixes nullify the effect of these attacks, or Limiting ICMP pps may help. If you configure 'ipfw' to ignore such packets (and also other trash packets that are useless), target will not send RST for closed ports, which may also help. I don't know for certain - you need to experiment. 05.01.2003; 23:25:10 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DDoS attacks, packets captured ... not sure what to do.
Another useful thing to do is limit the number of connections per second from a given source IP address, and to limit the total number of connection in progress from a given IP address. I doubt that all the packets are sent from one real IP. But, I tnink, it may be possible to determine the IP of an attacker, because it's not just a DoS attack. He may use other methods later. I am almost sure he tried to scan ports earlier, probably with `nmap -v -O` to determine the OS, and now he knows what packets to send. BTW, what were the UDP packets for? Scanning? 06.01.2003; 00:14:26 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in -STABLE on P4/2GHz
SoboMax I'm observing very strange memory corruption problems with 2GHz P4 system running 4.7 (security branch as of today). Under the load (make -j20 buildworld) the compiler or make(1) often die with signal 11. I found in mailing lists that there is similarly looking problem with -current, any chances that -stable is affected as well? What CPU core you have? I tested my system several times and found no problems: FreeBSD 4.6.2-RELEASE NO 'options DISABLE_PSE' CPU: Intel P4 2.0A Ghz, NW core, overclocked to 2.5Ghz MBoard: Gigabyte GA-8IHXP, i850E chipset RAM: 512Mb RDRAM 800Mhz Run /usr/ports/sysutils/cpuburn, `burnP6` for a night. If it doesn't coredump, run memtest86 for another night. This is how I tested my overclocked system. With FSB frequency more than 125Mhz (+25Mhz), `burnP6` dies with sig?? after some time, and 'memtest86' reports errors. The same result is when I increase the frequency and don't increase Vcc (CPU core voltage). Seems like the CPU doesn't get enough power (check the 12V 4-pin power connector and the power supply) or the memory is no-brand/overclocked. Robert Withrow [EMAIL PROTECTED] I had similar problems. Terry Lambert reports that there is a bug in the P4. not likely. why? 18.11.2002; 21:42:59 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: GDB Linux binaries.
I'm guessing this is because the linux libc library file is in /usr/compat/linux/lib, how do I get GDB to use it instead? Or is it even possible. That's interesting. I already asked similar question here, on freebsd-hackers@, but was immediately sent to freebsd-questions@, where I didn't get any answer. :) I believe you can install the linux_devtools* port and get gdb for Linux. There is also linux_kdump which groks ktrace output from linux binaries. I tried Linux 'gdb' - it doesn't break on breakpoints; is says that ptrace() syscall is not implemented. Linux RedHAT 7.2 emulation + 'linux_devtools'. 10.11.2002; 19:40:41 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cpu class features
I'm writing an application that needs info on the machine cpu architecture, the cpu class, and the cpu features. Why not just use the 'CPUID' instruction? 07.11.2002; 19:48:41 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: i am looking for a 5 volt signal
:The output signals don't go straight from the chip - do they? :I've seen few KOhms resistors on most boards for each output pin. An external series resistor is there strictly for current limiting purposes. Yep, that's why I asked if manufacturers usually put external resistors. I tried to short all the wires together and on the ground :) from an old ISA paraller port controller card - it didn't blow up. So the message to the author of this thread: check for resistors on your mboard, if it's the old one, in series with the outputs, so that you can be sure that you won't kill the controller during experiments... 28.10.2002; 18:05:15 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
As of a write-protected floppy, why is it allowd to be mounted as writeable? The mount should be degraded to readonly or rejected. This would not be very convenient - a person may want to remove the write protection without remounting the floppy. 28.10.2002; 18:14:52 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: i am looking for a 5 volt signal
In anycase, I can only concur on the danger of ganging the parallel power output bits. A single chip is driving those outputs and is almost certainly not rated to deal with a maximal current draw from all of them at once for long periods of time. It could fry. The output signals don't go straight from the chip - do they? I've seen few KOhms resistors on most boards for each output pin. 27.10.2002; 19:32:00 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware2 and simd instructions
From what I have gathered doing web seaches, the cpuid opcode is *not* trappable. :( What's the problem then? The guest OS should get proper info from the CPUID instruction. Can you test that? What does CPU info program show about the CPU in a guest OS? The problem is in VMWare - it has some weird reaction to P6 instructions. Oct 16 23:44:47: F(140) line=1893 0x10:0xc02660bc fault=13 can you disassemble 0xc02660bc? Seems like there should be a way to trap the fault 13 to not have the guest os panic or blue screen. don't think so Programs with P6 instructions won't start working from this anyway... 21.10.2002; 22:07:56 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware2 and simd instructions
is there anyway to lie to vmware2 about the processor installed? or a patch to vmmon to have it lie to the guest os about the processor installed? yes Please enlighten us. I would like to have more than ancient stuff running in my vmware2 I assume to lie to vmware2 about the processor installed means to force vmware2 to report differents CPU features returned by its CPUID instruction. I guess `vmware` reads CPU info from '/usr/compat/linux/proc/cpuinfo' (that is, linuxprocfs) - confirmed by disassembling `vmware`. You may 'lie' to vmware by modifying 'cpuinfo' (i.e., patch for linuxprocfs), but that will make sense only if you want to force vmware2 not to use some CPU feature. You probably need to be able to execute MMX/SSE/SSE2 instructions, and vmware2 doesn't (?) know about them: =BEGIN==/root/.vmware/vmware-log.root=8= ... Oct 19 00:48:59: Unknown CPUID Feature 0x3c68 Oct 19 00:48:59: cpuFeatures == 0x701 ... =END/root/.vmware/vmware-log.root=8= 0x701 means: FPU, CX8, APIC, b10 - reserved? My CPU Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP, MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,b28,ACC As you can see, I have almost all the available features, and vmware2 understans only 701H - no MMX/SSE/SSE2. Therefore, we need to disassemble the code, find the place where VMWare emulates CPUID instruction, and, if EAX=0x01, return EDX: OR EDX,1101b Also, we can find where (code) `vmware` stores CPU features in the 'cpuFeatures' variable (not far from a place where it puts CPUID features to log file) and patch it to always save our value. Moreover, if you want, you can also patch it for returning another CPU ID and stepping. I'll try to check it after the weekend. I don't think this may work at all, since vmware2 probably doesn't have emulation for the advanced instructions, and may generate 'Invalid OpCode' (#UD) exception. So you better think how to make vmware3 working on FreeBSD (port vmmon3)... :) 18.10.2002; 22:59:26 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware2 and simd instructions
is there anyway to lie to vmware2 about the processor installed? or a patch to vmmon to have it lie to the guest os about the processor installed? yes 17.10.2002; 19:32:37 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ptrace
Is the 'ptrace' syscall implemented in linux emulation? 29.09.2002; 03:48:17 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
gdb + Linux binary + breakpoints
When I try to run `gdb somelinuxprog` with Linux emulation, RedHat7.1, the prog dies with SIG11 after 'run'. I get more luck with `/usr/compat/linux/usr/bin/gdb`, but the debugger doesn't react on breakpoints. Is there any way to make it stopping at breakpoints? What might be causing this behaviour? 11.09.2002; 22:33:56 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
