Re: amdtemp need help with testing
On 2013-10-07 3:24, rozhuk...@gmail.com wrote: I updated amdtemp and now I need your help with testing. Now the driver should support all AMD processors. For a family of 15h and 16h, not all sensors are available - for my system does not find drivers for ati SMBus, and other systems based on the AMD I have not. CPU: AMD Phenom(tm) II X6 1075T Processor (3013.83-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100fa0 Family = 0x10 Model = 0xa Stepping = 0 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant, performance statistics L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully associative L1 4KB data TLB: 48 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 128 entries, 2-way associative L2 2MB instruction TLB: 0 entries, 2-way associative This is what I get with the 10.0-ALPHA4 driver. sysctl -a | grep amd machine amd64 hw.machine: amd64 hw.machine_arch: amd64 hw.snd.version: 2009061500/amd64 hw.mca.amd10h_L1TP: 1 dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 58.0C This is what I get when I try to compile the new module: freetest# cd /usr/src/sys/modules/amdtemp/ freetest# make Warning: Object directory not changed from original /usr/src/sys/modules/amdtemp cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/amdtemp/../../dev/amdtemp/amdtemp.c /usr/src/sys/modules/amdtemp/../../dev/amdtemp/amdtemp.c:453:9: error: implicit declaration of function 'pci_cfgregread' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if ((pci_cfgregread(pci_get_bus(dev), pci_get_slot(dev), 2, ^ 1 error generated. *** Error code 1 Stop. make: stopped in /usr/src/sys/modules/amdtemp FreeBSD freetest.digiware.nl 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1 r256062: Tue Oct 8 11:05:54 CEST 2013 r...@freetest.digiware.nl:/usr/obj/usr/src/sys/FREETEST amd64 --WjW ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amdtemp need help with testing
On 2013-10-09 13:34, Willem Jan Withagen wrote: On 2013-10-07 3:24, rozhuk...@gmail.com wrote: I updated amdtemp and now I need your help with testing. Now the driver should support all AMD processors. For a family of 15h and 16h, not all sensors are available - for my system does not find drivers for ati SMBus, and other systems based on the AMD I have not. CPU: AMD Phenom(tm) II X6 1075T Processor (3013.83-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100fa0 Family = 0x10 Model = 0xa Stepping = 0 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant, performance statistics L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully associative L1 4KB data TLB: 48 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 128 entries, 2-way associative L2 2MB instruction TLB: 0 entries, 2-way associative This is what I get with the 10.0-ALPHA4 driver. sysctl -a | grep amd machine amd64 hw.machine: amd64 hw.machine_arch: amd64 hw.snd.version: 2009061500/amd64 hw.mca.amd10h_L1TP: 1 dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 58.0C After bruteforce fixing the compile error by deleting the #ifdef around the definition... --WjW freetest# sysctl -a | grep amd machine amd64 Giant,amdtemp hw.machine: amd64 hw.machine_arch: amd64 hw.snd.version: 2009061500/amd64 hw.mca.amd10h_L1TP: 1 dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.rtc.CurTmp: 36.6C dev.amdtemp.0.rtc.CurTmpTjSel: -12.5C dev.amdtemp.0.rtc.TmpSlewDnEn: 1 dev.amdtemp.0.rtc.TmpMaxDiffUp: 3 dev.amdtemp.0.rtc.PerStepTimeDn: 15 dev.amdtemp.0.rtc.PerStepTimeUp: 15 dev.amdtemp.0.rtc.sensor_offset: 0 dev.amdtemp.0.tsi.sensor0.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor0.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor0.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor0.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor0.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor0.status: 0 dev.amdtemp.0.tsi.sensor0.cfg3: 0 dev.amdtemp.0.tsi.sensor0.cfg9: 0 dev.amdtemp.0.tsi.sensor0.upd_rate: 8 dev.amdtemp.0.tsi.sensor0.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor0.alert_threshold: 0 dev.amdtemp.0.tsi.sensor0.alert_cfg: 0 dev.amdtemp.0.tsi.sensor0.manufacture_id: 0 dev.amdtemp.0.tsi.sensor0.revision: 1 dev.amdtemp.0.tsi.sensor0.sensor_offset: 0 dev.amdtemp.0.tsi.sensor1.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor1.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor1.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor1.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor1.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor1.status: 0 dev.amdtemp.0.tsi.sensor1.cfg3: 0 dev.amdtemp.0.tsi.sensor1.cfg9: 0 dev.amdtemp.0.tsi.sensor1.upd_rate: 8 dev.amdtemp.0.tsi.sensor1.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor1.alert_threshold: 0 dev.amdtemp.0.tsi.sensor1.alert_cfg: 0 dev.amdtemp.0.tsi.sensor1.manufacture_id: 0 dev.amdtemp.0.tsi.sensor1.revision: 1 dev.amdtemp.0.tsi.sensor1.sensor_offset: 0 dev.amdtemp.0.tsi.sensor2.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor2.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor2.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor2.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor2.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor2.status: 0 dev.amdtemp.0.tsi.sensor2.cfg3: 0 dev.amdtemp.0.tsi.sensor2.cfg9: 0 dev.amdtemp.0.tsi.sensor2.upd_rate: 8 dev.amdtemp.0.tsi.sensor2.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor2.alert_threshold: 0 dev.amdtemp.0.tsi.sensor2.alert_cfg: 0 dev.amdtemp.0.tsi.sensor2.manufacture_id: 0 dev.amdtemp.0.tsi.sensor2.revision: 1 dev.amdtemp.0.tsi.sensor2.sensor_offset: 0 dev.amdtemp.0.tsi.sensor3.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor3.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor3.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor3.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor3.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor3.status: 0 dev.amdtemp.0.tsi.sensor3.cfg3: 0 dev.amdtemp.0.tsi.sensor3.cfg9: 0 dev.amdtemp.0.tsi.sensor3.upd_rate: 8 dev.amdtemp.0.tsi.sensor3.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor3.alert_threshold: 0 dev.amdtemp.0.tsi.sensor3.alert_cfg: 0 dev.amdtemp.0.tsi.sensor3.manufacture_id: 0 dev.amdtemp.0.tsi.sensor3.revision: 1 dev.amdtemp.0.tsi.sensor3
Re: Failsafe on kernel panic
On 17-1-2013 4:18, Ian Lepore wrote: On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: Thank you for your response, very helpful. one question - how do i configure auto-reboot once kernel panic occurs? Sami From src/sys/conf/NOTES, this may be what you're looking for... # # Don't enter the debugger for a panic. Intended for unattended operation # where you may want to enter the debugger from the console, but still want # the machine to recover from a panic. # options KDB_UNATTENDED But I think it only has meaning if you have option KDB in effect, otherwise it should just reboot itself after a 15 second pause. Well it is not the magical fix-all solution. Last night I had to drive to the colo (lucky for me a 5 min drive.) because I could not get a system to reboot/recover from a crash. Upon arrival the system was crashed and halted on the message: rebooting in 15 sec. Which but those 15 secs are would have gone by for about 10-20 minutes. fysically rebooting or resetting ended up in the same position: rebooting in 15 sec. Without ever getting to actually rebooting. So if I (you) have servers 2 hours away, I usually try to work on upgrading/rebooting during business hours. And remote hands can get me out of trouble IPMI is another nice way of getting at the server in these cases. But that requires a lot more infra and tinkering. --WjW ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Very low disk performance Highpoint 1820a
Steven Hartland wrote: If that where the case it would have been it wouldn't have been 46Mb/s it would have been 543Mb/s, just tested it for you :P I've just finished putting together a new server box spec: Dual AMD 244, 2GB ram, 5 * Seagate SATA 400GB on a Highpoint 1820a RAID 5 array. 5.4-STABLE Highpoint 1820a RAID 5 ( 5 disk ) 65536 bytes transferred in 13.348032 secs (49097875 bytes/sec) You're only transfering 640M in 2GB of RAM, big chance that you're testing memory/buffercode-speed in stead of testing diskspeed. Still I would argue that if you do not use a write size larger than what you have as real memory, that buffering in real memory is going to play a role Other than that I find 50Mb/s is IMHO reasonable high value for a RAID5 in writting. But it would require substantial more organised testing. DD is nothing more than a very crude indication of what to expect in real life. --WjW ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very low disk performance Highpoint 1820a
Steven Hartland wrote: Still I would argue that if you do not use a write size larger than what you have as real memory, that buffering in real memory is going to play a role I think you miss read all the details here Willem. Sorry about that, if that is the case. Original values: Write: 150Mb/s Read: 50Mb/s Current value after tweeking, RAID stripe size, vfs.read_max and MAXPHYS ( needs more testing now due to scotts warning ) Write: 150Mb/s Read: 200Mb/s Note: The test size was upped to 10Gb to avoid caching issues. That would certainly negate my assumption 10G is enough to regularly flush the buffer. Other than that I find 50Mb/s is IMHO reasonable high value for a RAID5 in writting. But it would require substantial more organised testing. DD is nothing more than a very crude indication of what to expect in real life. dd was uses as it is a good quick indication of baseline sequential file access speed and as such highlighted a serious issue with the original performance. That is well phrased English for what I was trying to say. I'm glad to see that it worked for you. And I'm certainly impressed by the numbers... This is on a 4 disk RAID5 with one hot spare??? --WjW ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very low disk performance Highpoint 1820a
Steven Hartland wrote: I've just finished putting together a new server box spec: Dual AMD 244, 2GB ram, 5 * Seagate SATA 400GB on a Highpoint 1820a RAID 5 array. 5.4-STABLE Highpoint 1820a RAID 5 ( 5 disk ) . 65536 bytes transferred in 13.348032 secs (49097875 bytes/sec) You're only transfering 640M in 2GB of RAM, big chance that you're testing memory/buffercode-speed in stead of testing diskspeed. --WjW ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum vs. DPT smartcacheIV raid
Peter C. Lai wrote: I have a box with DPT PM2044 SmartCacheIV UW-SCSI PCI cards which can do RAID-5 in hardware, but I'd have to use the DOS volume manager to set up the array. I have heard reports that vinum woudl be faster than using the native card. Is this true? Should I not bother with doing the hardware raid and just go with vinum? The rest of the system is a k6-2 400mhz with 256mb ram (amount might change). I will also have moderate network i/o on the pci bus (obviously). I still have one here lingering around somewhere on a shelf. It ran a 4*1Gb diskarray RAID-5 when 1GB disk where still sort of big. So that is how old this card is. With that I did have some unplesant experiences with this card: - First and most major it seems that you need to have the right version firmware in it. Otherwise things might get seriously hossed at unexpected times. Just buffers timing out in the middle of the night. - The other issue was that my disk where in an external cabinet and once the cable came loose. It killed the raid as expected, but it took me a long time to find some tools to force the disk up the brute way. Just to see if I could recover some of the data. And like you say: Al these tools are DOS based. Currently I'm running a 4*60Gb ATA RAID5 with old vinum on a 233 MHZ P2, 256Mb with FBSD 5.1. This ATA just because ATA disk are so much cheaper per MB, and I do not need utmost dependability for my 6 PC office. I've ordered 4*250Gb ATA disks this week to build a new RAID5, and I'll go again for vinum. --WjW ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Devilator - performance monitoring for FreeBSD
Harti Brandt wrote: On Wed, 2 Feb 2005, Robert Watson wrote: RW RWOn Wed, 2 Feb 2005, Borja Marcos wrote: RW RW I'm not sure about the correct values in the process description RW to get a picture as accurate as possible of the cpu usage of different RW processes. I've seen that top uses p_runtime (FreeBSD 5 and FreeBSD 4), RW but I'm not sure if the value would be really useful. RW RWThis is very cool. :-) How are you currently extracting the information? RWOne of the things I've wanted to do for a while is make sure all this sort RWof thing is exposed via snmpd so that the information can be gathered RWeasily across a large number of hosts (say, 10,000). That could be a nice JUH (junior userspace hacker's) task to add a module to bsnmp. net-snmp is able to run arbitrary external code to obtain values to be monitored, and it seem to be able to use modules (haven't used them yet). I've been using net-snmp/mrtg already for as long as I can remember to monitor load and diskspace. Processes and other things with MRTG are IMHO sort of troublesome since sample period is 5 minutes. And most processes that outlive that timespan are kernel/daemon processes. What I like about Borja's stuff is that he is able to plot more that just 2 params in 1 graph. --WjW ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Devilator - performance monitoring for FreeBSD
Andrew J Caines wrote: I'd also vouch for collecting orcallator data using rsync over ssh from the client systems to the cruching and report generating server. Wait until you would like to do a larger server park. Then you start running into performance issues because you nee to setup a full ssh/tcp connection. Whereas SNMP-v3 over UDP is a lot faster and simpler. And it is not like you are transporting majore security type data I'm still using a large number of hosts with v1 and IP-number locking as security. --WjW ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dumps with more than 4gig.
David Gilbert wrote: Did someone submit a patch that fixes dumps in excess of 4 Gig on arches like amd64? About half a year ago I had some discussion on am64 when I was not able to dump th kernel when having 2GB of memory... That got fixed, and after some talks a different solution was chosen because that would be more universal. From your question I conclude that it did not solve the whole problem I I remember correctly I suggested taking a size_t len for the action to write the core. But it was fixed in one layer up by writing multiple blocks and calling the routine more times. Now if I could only remember where that was But I started searching from amd64/amd64/dump_machdep.c I guess that you'd have to start there also, after which you'll end up with the disk io-specific module dumpers: cam/scsi/scsi_da.c:static dumper_tdadump; dev/aac/aac_disk.c:static dumper_taac_disk_dump; dev/amr/amr_disk.c:sc-amrd_disk-d_dump = (dumper_t *)amrd_dump; dev/ata/ata-disk.c:static dumper_t addump; dev/ata/ata-raid.c:static dumper_t ardump; dev/ida/ida_disk.c:static dumper_tidad_dump; dev/null/null.c:return (set_dumper(NULL)); dev/twe/twe_freebsd.c:sc-twed_disk-d_dump = (dumper_t *)twed_dump; For the specific details. I perhaps it even depends on what kind of storage you're using --WjW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple Bootable FreeBSD partitions?
From: Stephen Hocking [EMAIL PROTECTED] I'm looking at creating multiple versions of FreeBSD on the one disk - sharing perhaps one or two filesystems, but with totally separate /, /usr and /var. Does anyone have a quick way to do this from a clean install? I've done this under a number of OS's, but can't think how to do it with FreeBSD. FreeBSD itsell come with a selector in the bootsectors. Nothing really fancy, but it works. Not shure if the default is now to use LARGE disks, otherwise readup on boot0cfg and the -o packet option. My system also has w2K and WinXP/amd64, and I wanted a serial bootselector. So I used Grub for this. It is in the ports. --WjW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple Bootable FreeBSD partitions?
Not to blow my own horn, but: http://www.onlamp.com/pub/a/bsd/2002/05/09/Big_Scary_Daemons.html If you have a time and you would like to run current, release, stable and extra a few OS, Install *Linux and use extended partition(slice for BSD guys) and Grub, and you can run at most 8 OS on your single HDD. Grub would boot from Linux extended partition( not dos extended partition). I have GRUB boot from the i386-FreeBSD partition which is the first on the disk. Makes it very easy to get the repair-CD and find the first / to repair the bootsector when MS has again threaded over it. Getting it to boot 8 OS-es is not as far as I got, because I've not started experimenting with extended partition. I've got 3 primaries, 1 extended. --WjW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gdb 6.1.1: File format not recognized
Use gdb6 from the ports. gdb6 -k . --WjW - Original Message - From: Matthias Schuendehuette [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 10, 2004 8:36 PM Subject: gdb 6.1.1: File format not recognized Hello, I tried to look into a core dump from a -current kernel with 'gdb' but all i get is: --8- [EMAIL PROTECTED] - /var/crash 504 # gdb kernel.debug vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... /var/crash/vmcore.0 is not a core dump: File format not recognized (gdb) quit --8- I looked at the man-pages of gdb(1), savecore(8) and into the 'Developers Handbook' but I didn't find anything about the correct file format of a core dump. If I look at /var/crash/info.0, there's: --8- Good dump found on device /dev/da0s1b Architecture: i386 Architecture version: 1 Dump length: 268369920B (255 MB) Blocksize: 512 Dumptime: Sat Jul 10 19:40:30 2004 Hostname: current.best-eng.de Versionstring: FreeBSD 5.2-CURRENT #5: Sat Jul 10 12:37:27 CEST 2004 [EMAIL PROTECTED]:/raid/obj/usr/src/sys/CURRENT Panicstring: unmount: dangling vnode Bounds: 0 --8- Did I overlook something? Has someone a pointer or hint for me? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: magic symbolic links (ideas/patches?)
Well I once did try to get this working, and eventually got it working without ouzing
malloc's in the kernel... That was somewhere around may 1997 and FBSD 2.2.8??
In essence the change in the FILE system is realtively minor, not counting the means
of getting the replacement info there. All that needed changes was vfs_lookup.c. The
netbsd article has a lot more files changed, but they have to do with honouring a
MAGIC mout option telling the kernel to replace or not.
But then the next step was to get usefull info in the replacement.
The way I was used to this on Domain Apollo stations was that changes in the
environment would work per process for the magic symlinks. They called then
variant-links
So then I was stuppid enough to ask what other thought that would be required. So I
got this whole flamefest that it was a security risk, blah, blah, blah.
Much like the discussion in link you have from netbsd.
In the end my conclusion was to get in sysctl as far as to create a namespace
varlink osli. This would restrict heavy tricks to root.
And that is where I got stuck:
The company I was working in was growing real fast.
Sysctl wasn't in a too great a state
Now you are complicating things even more by having things react to changes in the
user process. I knew I did not know enough about FBSD to even start trying that. So I
cannot help you there.
--WjW
PS: I still have src lying around under a VL directory.
- Original Message -
From: Guido van Rooij [EMAIL PROTECTED]
To: John [EMAIL PROTECTED]
Cc: Hackers List [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, March 13, 2003 11:55 AM
Subject: Re: magic symbolic links (ideas/patches?)
IIRC Willem-Jan Withagen has done this years ago.
I Cc ed him.
-Guido
On Wed, Mar 12, 2003 at 07:39:52PM -0500, John wrote:
Hi Folks,
I have a need to implement a highly specific variant usage of
what are commonly referred to as magic symlinks, ie:
/src - /.src/$ARCH/src
where $ARCH needs to come from the user environment.
A related patchset from NetBSD (1995) can be seen here:
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=1781
In my specific implementation, the value of $ARCH will ALWAYS
be 3 characters (Not having implemented anything yet, and to
avoid possibly playing the userland game, I was thinking of
adding a field to the proc structure and having the setenv/putenv
functions place the value there via a sysctl, thus allowing a
very simple interface... short sighted?).
If anyone has any comments, or patches hanging around for
this type of implementation, I would appreciate a pointer to them.
Many, Many Thanks,
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Guido van Rooij | Phone: ++31 653 994 773
Madison Gurkha, Technology Think-Tank |
[EMAIL PROTECTED] | FreeBSD committer
èR{.nÇ+·¬zwfj)m¢f£¢·hkyàRàÂ+aº{.nÇ+·ç±ØZrG«²)í
æèw* ¶¦zË
Re: Bad memory suspected
Good hints,
Well actually it is a Cyrix 266 (aka 200Mhz CPU) on an ASUS board.
(I'm not sure about the numbers since it is at home, but it does SCSI, no network)
And I did upgrade the bios, and looked for support, and it seems suported, since the
BIOS recognises the CPU and speed. I'll again check the voltages
--WjW
Perhaps we should "merge" this thread to [EMAIL PROTECTED] ?
- Oorspronkelijk bericht -
Van: Matthew D. Fuller [EMAIL PROTECTED]
Aan: Chris Dillon [EMAIL PROTECTED]
CC: Willem Jan Withagen [EMAIL PROTECTED]; [EMAIL PROTECTED]
Verzonden: woensdag 2 februari 2000 0:08
Onderwerp: Re: Bad memory suspected
On Tue, Feb 01, 2000 at 05:01:55PM -0600, a little birdie told me
that Chris Dillon remarked
The last time I had a problem like this, it was because I put a P54C
(Pentium-MMX) into a board only designed for the P53C (a.k.a standard
ITYM P55C on a P54C board.
--
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
"The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet"
N
'²æìr¸{û Ù[h¨èÚ£ñkyàRú+û§²æìr¸yúÞy» þêìþ)í
æèw* ¶¦zË
Re: Bad memory suspected
In article [EMAIL PROTECTED] you write: Hoi Jan Willem, I would tend to agree with Doug White about a "make world" being a good memory test. However, I suspect Doug has the kind of system that will do a make world in a minute or two. I too agree with Doug. It is what causes me to ask this question. ;-) make -j 4 buildworld keeps me getting crashes. Even during making the temp-tools. Now I've already replaced the memory once: 4*16M out, in 4*32M, but the crashingis still there. I've even set the timing to it's lowest, but still no go. I could go out an buy more new parts, but this is one of the cases to get to know FreeBSD again a little better. Memory testing skills are a leftover from a previous life. Heck, i've even help design a state-machine to test embeded RAM on VLSI ;-) You should run "make world" to verify your test results, but if you've just plopped in a new SIMM, making the world is just too heavy. Any pointers to nightly reading material?? Since FreeBSD systems will start pumping out random signal 11's in the face of bad memory, try searching the -hardware and -questions list for that. I believe that someone actually wrote a signal 11 FAQ, but I don't have a pointer. I'll go and see if I can find something like that. There is a (Linux) program named memtest that will do just what you suggest. You can dd(1) the binary onto an unused 1 meg partition and have booteasy drop you in without even touching an OS. That's a nice idea a well, I think a module would learn me something more/new to do. But I'll also try and digout this program. Thanx, --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Bad memory suspected
Hi, Being probably bitten again by some bad memory, I'm considering applying some of my old (VLSI) testingskills to this. However. I'm in dire need of some hints, some because I haven't kept up with the intimate details of Intel hardware, nor do I know how to get a lineair memory space for all the fysical memory available in the system. The starting problems are: 1) I'd like to do this als a loadable kernel module, so one would load this module on the boot-prompt and let it eat away CPU time until it is rebooted. Now is there a module example which I can use to get me an easy setup for plugging inthe memory-test modules. Starting with simple things like "walking 0 and 1's", but ending up with O(n^2) tests to check for dependancies on surrounding values 2) Cache is a friend and a fiend in this: It helps fast execution of the code, but prevents data really getting to the silicon. So all experience in this is welcomed. Bluntly I can disable all caching (which would be nice for starters), but once we get to the more complex testingpatterns CPU-cycles do start to count. 3) PC memory layouts used to be a major art just by itself in the old days when we still used DIP 4116's, how is that in the current time with SIMM, DIMM, RAMBUS, PCI-bridges, ECC, . Any pointers to nightly reading material?? Thanx, --Willem Jan I once had a TRS-80 test run for 3 days, before it gave in, but then the error was reproducable and pinpointed the actual chip to be replaced. Which did fix the problem. -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
In article [EMAIL PROTECTED] you write: On Saturday, 3 July 1999 at 17:28:51 -0700, John Polstra wrote: I put a handful of pictures from this year's USENIX conference at http://www.freebsd.org/~jdp/usenix1999/. Hey, they're some of the best I've seen of USENIX. Proves my statement that it is unwise to assume the looks of people from their E-mail. :-) All of the pictures supprised me very mucho. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: devices in sysctl MIB?
Something like below? That is what you get available when running ucd-snmp. So I guess that a lot of the data is already available. Just not in sysctl (yet) -_WjW interfaces.ifNumber.0 = 6 interfaces.ifTable.ifEntry.ifIndex.1 = 1 interfaces.ifTable.ifEntry.ifIndex.2 = 2 interfaces.ifTable.ifEntry.ifIndex.3 = 3 interfaces.ifTable.ifEntry.ifIndex.4 = 4 interfaces.ifTable.ifEntry.ifIndex.5 = 5 interfaces.ifTable.ifEntry.ifIndex.6 = 6 interfaces.ifTable.ifEntry.ifDescr.1 = "de0" Hex: 64 65 30 interfaces.ifTable.ifEntry.ifDescr.2 = "tun0" Hex: 74 75 6E 30 interfaces.ifTable.ifEntry.ifDescr.3 = "tun1" Hex: 74 75 6E 31 interfaces.ifTable.ifEntry.ifDescr.4 = "ppp0" Hex: 70 70 70 30 interfaces.ifTable.ifEntry.ifDescr.5 = "ppp1" Hex: 70 70 70 31 interfaces.ifTable.ifEntry.ifDescr.6 = "lo0" Hex: 6C 6F 30 interfaces.ifTable.ifEntry.ifType.1 = ethernet-csmacd(6) interfaces.ifTable.ifEntry.ifType.2 = 0 interfaces.ifTable.ifEntry.ifType.3 = 0 interfaces.ifTable.ifEntry.ifType.4 = ppp(23) interfaces.ifTable.ifEntry.ifType.5 = ppp(23) interfaces.ifTable.ifEntry.ifType.6 = softwareLoopback(24) interfaces.ifTable.ifEntry.ifMtu.1 = 1500 interfaces.ifTable.ifEntry.ifMtu.2 = 1500 interfaces.ifTable.ifEntry.ifMtu.3 = 1500 interfaces.ifTable.ifEntry.ifMtu.4 = 1500 interfaces.ifTable.ifEntry.ifMtu.5 = 1500 interfaces.ifTable.ifEntry.ifMtu.6 = 16384 interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 1000 interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.3 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.4 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.5 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.6 = Gauge: 0 interfaces.ifTable.ifEntry.ifPhysAddress.1 = Hex: 00 80 48 EA 6C 8B interfaces.ifTable.ifEntry.ifPhysAddress.2 = "" interfaces.ifTable.ifEntry.ifPhysAddress.3 = "" interfaces.ifTable.ifEntry.ifPhysAddress.4 = "" interfaces.ifTable.ifEntry.ifPhysAddress.5 = "" interfaces.ifTable.ifEntry.ifPhysAddress.6 = "" interfaces.ifTable.ifEntry.ifAdminStatus.1 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.2 = down(2) In article [EMAIL PROTECTED] you write: Just a suggestion, perhaps there should be a dev tree in sysctl with nodes for each device type then device. interesting applications for this: reporting on packets dropped/sent and such displaying connection status (duplex/100mb/10mb... etc) enabling/disabling power saving features dev.iface.fxp0.ipkts = 432523 dev.iface.fxp0.opkts = 432523 dev.iface.fxp0.linkspeed = 100 dev.iface.fxp0.linkmode = full-duplex dev.dsk.da0.tags = 32 sysctl -w dev.iface.fxp0.linkmode=half-duplex ? -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
In article 19990704112426.j...@freebie.lemis.com you write: On Saturday, 3 July 1999 at 17:28:51 -0700, John Polstra wrote: I put a handful of pictures from this year's USENIX conference at http://www.freebsd.org/~jdp/usenix1999/. Hey, they're some of the best I've seen of USENIX. Proves my statement that it is unwise to assume the looks of people from their E-mail. :-) All of the pictures supprised me very mucho. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: devices in sysctl MIB?
Something like below? That is what you get available when running ucd-snmp. So I guess that a lot of the data is already available. Just not in sysctl (yet) -_WjW interfaces.ifNumber.0 = 6 interfaces.ifTable.ifEntry.ifIndex.1 = 1 interfaces.ifTable.ifEntry.ifIndex.2 = 2 interfaces.ifTable.ifEntry.ifIndex.3 = 3 interfaces.ifTable.ifEntry.ifIndex.4 = 4 interfaces.ifTable.ifEntry.ifIndex.5 = 5 interfaces.ifTable.ifEntry.ifIndex.6 = 6 interfaces.ifTable.ifEntry.ifDescr.1 = de0 Hex: 64 65 30 interfaces.ifTable.ifEntry.ifDescr.2 = tun0 Hex: 74 75 6E 30 interfaces.ifTable.ifEntry.ifDescr.3 = tun1 Hex: 74 75 6E 31 interfaces.ifTable.ifEntry.ifDescr.4 = ppp0 Hex: 70 70 70 30 interfaces.ifTable.ifEntry.ifDescr.5 = ppp1 Hex: 70 70 70 31 interfaces.ifTable.ifEntry.ifDescr.6 = lo0 Hex: 6C 6F 30 interfaces.ifTable.ifEntry.ifType.1 = ethernet-csmacd(6) interfaces.ifTable.ifEntry.ifType.2 = 0 interfaces.ifTable.ifEntry.ifType.3 = 0 interfaces.ifTable.ifEntry.ifType.4 = ppp(23) interfaces.ifTable.ifEntry.ifType.5 = ppp(23) interfaces.ifTable.ifEntry.ifType.6 = softwareLoopback(24) interfaces.ifTable.ifEntry.ifMtu.1 = 1500 interfaces.ifTable.ifEntry.ifMtu.2 = 1500 interfaces.ifTable.ifEntry.ifMtu.3 = 1500 interfaces.ifTable.ifEntry.ifMtu.4 = 1500 interfaces.ifTable.ifEntry.ifMtu.5 = 1500 interfaces.ifTable.ifEntry.ifMtu.6 = 16384 interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 1000 interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.3 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.4 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.5 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.6 = Gauge: 0 interfaces.ifTable.ifEntry.ifPhysAddress.1 = Hex: 00 80 48 EA 6C 8B interfaces.ifTable.ifEntry.ifPhysAddress.2 = interfaces.ifTable.ifEntry.ifPhysAddress.3 = interfaces.ifTable.ifEntry.ifPhysAddress.4 = interfaces.ifTable.ifEntry.ifPhysAddress.5 = interfaces.ifTable.ifEntry.ifPhysAddress.6 = interfaces.ifTable.ifEntry.ifAdminStatus.1 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.2 = down(2) In article pine.bsf.3.96.990703182338.14320k-100...@cygnus.rush.net you write: Just a suggestion, perhaps there should be a dev tree in sysctl with nodes for each device type then device. interesting applications for this: reporting on packets dropped/sent and such displaying connection status (duplex/100mb/10mb... etc) enabling/disabling power saving features dev.iface.fxp0.ipkts = 432523 dev.iface.fxp0.opkts = 432523 dev.iface.fxp0.linkspeed = 100 dev.iface.fxp0.linkmode = full-duplex dev.dsk.da0.tags = 32 sysctl -w dev.iface.fxp0.linkmode=half-duplex ? -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Variant symlinks [was Re: symlink question]
In article 53425.929320...@zippy.cdrom.com you write: And have /usr/bin point to /binaries/i386/bin or /binaries/mips/bin And before people jump on me, let me just clarify in advance that I was not meaning to imply that Apollo ever used the x86 architecture. They didn't. It was just an example. :) Well sort of. :-) It could do windoze emulation on their poor 68K boxes. But you'd have to be a very patient (or desperate) person to use that. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
In article pine.bsf.3.96.990613141052.366b-100...@server.ghostgbtb.com you write: Sorry if I'm bothering you busy folk unnecessarily... If I wanted to add variant symlinks, would that just require modifications to namei, or is that way too simplistic? I've done that part with help of Mike Smith and others. I still have the changes around somewhere. it was the simpeler part of the job. The harder part is to get something to be usable to replace the variable part with. There has been some discussion on how to get information to the kernel on the variant part. And what kind of problems would go with that. I started on an excursion into sysctl to make it much more dynamic. And use the information stored in there as subsitute values for the variant-links. But since I ran out of holyday time, it has been shelved. The discussions should still be in the archives. Most probably under variant links. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
