Re: AMD System Management driver and Newbus
On Thu, Dec 28, 2000 at 02:57:33PM -0500, Andrew Gallatin wrote: Nicolas Souchu writes: Gasp! This is part of my fault. I shouldn't have left this old style driver in the tree :( You should have contacted me, I would have adviced you. Takanori is right, you should look at intpm to get info about how to cleanly newbusify your driver. This is what I'm currently doing for alpm ;) By the way, is someone working on the VIA SMBus support? Or do I start it? FWIW, I've just newbus'ified the alpm driver. See http://people.freebsd.org/~gallatin/alpm.diff Good. Seems ok for commit. Somebody with an x86 AMD should probably test it.This seems to "sorta" work on my API UP1000 (which is an alpha). Eg: FreeBSD 5.0-CURRENT #23: Thu Dec 28 11:24:33 EST 2000 [EMAIL PROTECTED]:/.amd_mnt/muffin/export/ari_scratch2/gallatin/c urrent/sys/compile/UP1000 UP1000 API UP1000 598 MHz, 598MHz 8192 byte page size, 1 processor. CPU: major=11 minor=8 extensions=0x307BWX,FIX,CIX,MVI,PRECISE OSF PAL rev: 0x100010002013e ... alpm0: AcerLabs M15x3 Power Management Unit port 0x1040-0x105f,0x1000-0x103f at device 17.0 on pci0 smbus0: System Management Bus on alsmb0 smb0: SMBus general purpose I/O on smbus0 We should remove all these useless reports of general purpose driver and just keep the controller detection prints. ... # ./smb_detect 58 found. 74 found. 78 found. 90 found. a0 found. a8 found. If I beat on lm.c from http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/lm.c enough and use 0x90 as cmd.slave, I can get the CPU temp of 41 C. This is the same as firmware gives me, which is encouraging. As you can probably tell, I don't know enough about smb to fight my way out of a wet paper bag. Is there an SMB savy person out there who can take me by the hand and help me figure out where the fan speed and voltage is lurking and how to read it? Maybe not over SMBus :( Some boards are designed such a way that SMBus is only used for SDRAM detection not monitoring. The lm75/78 can also be controlled over both ISA... But this seems not to be the case for you since you found many chip on the SMBus. Grab the linux lm_sensor documentation and see if these I2C addresses are listed and which chips they are potentially assigned to. At this point, it is not SMBus dependent, but chip/vendor dependent. The only problem you can have with smbus/iicbus is now timings, but with alpm, these are handled by the controller. By the way, there's a port (lmmon) that accesses the lm75/78 over ISA, if you have such a monitoring chip... Nicholas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AMD System Management driver and Newbus
Grab the linux lm_sensor documentation and see if these I2C addresses are listed and which chips they are potentially assigned to. At this point, it is not SMBus dependent, but chip/vendor dependent. FWIW, Ralf Brown's interrupt list contains a fairly extensive set of I2C address assignments... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Allocating I/O port space
Hi again all, Well, despite the reception I'm still here, desperately trying to allocate an I/O port range! Still can't get bus_alloc_resource to work, despite doing everything by the book. I have a question. My kernel prints this: amdpm0: AMD 756 Power Management Controller at device 7.3 on pci0 ...before amdpm_attach complains it can't map any I/O space. Where does the resource info printed here come from? Does the fact that nothing is printed about ports mean that as far as the system is concerned, it doesn't have any? Is this why bus_alloc_resource fails? Sorry if the answers seem obvious, but I'm learning, so please be patient! If all this is the case, then how could I allocate the I/O space I need? Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SecureBSD
Hello! Some pretty good time ago, I accidentally found SecureBSD (www.securebsd.org), which is a security patch for 3.4-REL and 4.0-REL. I kept a note about this site, and that's about it. Recently, reviewing my ~/cool.lynx file, I've found this site again. Interested, I dloaded it (4.0 version) and tried to apply it to my pretty recent 4.2-STABLE. Not surprisingly, it didn't apply, there were lots of rejects. I looked at rejected code, and it seems that it can be fixed easily. I've already wrote a perl script that would help me fixing all the patches :) The point of this letter is, whether SecureBSD worth trying or not? Maybe, even if I manage to correctly apply all the patches, it still would not work? It seems like really useful and cool thing, but I've hardly seen anyone using or even mentioning it. Will it help me make more secure server than using standard FreeBSD methods? Of course, I speak from 4.2-STABLE user/hacker position. Opinions? Thought? Everything will be appreciated :) Thanks. \\danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
Warner Losh wrote: In message [EMAIL PROTECTED] Wes Peters writes: : We have several NIC's around here (the New Internet Computer, see : http://www.thinknic.com/ for details) and will be adding a couple of these : so we can boot FreeBSD or NetBSD on them in the next little while. A NIC : running FreeBSD on a silent CF disk strikes me as an ideal bedroom computer; : you can leave it on all the time and just let the screen sleep when you're : not using it. The ideal bedroom computer wouldn't have a monitor either because that makes a lot of noise. The I-Opener looks very promising here, but only if you have one of the cheap units. I'd hate to buy one now at full price given how hard they are to hack. We're working on that, give us time. ;^) What's a good price point for a bedroom/kitchen "thin" computer with an 800x600 LCD panel? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread DIES [Re: ssh - are you nuts?!? ]
Bill Fumerola wrote: On Wed, Dec 27, 2000 at 04:04:36PM -0800, [EMAIL PROTECTED] wrote: Bill Fumerola, who states that security policy information is un-available. However, I might refer his comment to the Security Officer instead, if Bill feels this appropriate. for the public record: Its unavailable in a "I don't know of any place that it is currently stored publicly, so I have no idea how JmJr was making references to it"-way as opposed to a "It's super-secret-elite and you can't have it"-way. This is exactly what I meant when I wrote "we need to solve this problem." I.e., we need a published procedure for disseminating ssh keys for FreeBSD machines to those who need them. Simply publishing what is currently done, perhaps in the committer section of the Handbook or even in the committers instructions, would meet this need just fine. Boy, am I glad this is over. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
: Still, I personally believe, that "core" or general "freebsd community" : should explicitly state, that support for binary drivers and support for : easier inclusion of binary driver or just third party driver is eagerly : encouraged. And as much as possible, easy inclusion of binary drivers : sould be kept in mind whether makeing changes to /usr/src/Makefile or : kernel interfaces or even discussions on the freebsd lists. Core has stated in the past a strong desire for developers not to break kernel interfaces within minor releases. 4.1 broke that "policy" rather badly. Perhaps its time to get rid of the mbuf macros, as any change to that structure breaks binary compatibility in the worst way possible. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AMD System Management driver and Newbus
Nicolas Souchu writes: If I beat on lm.c from http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/lm.c enough and use 0x90 as cmd.slave, I can get the CPU temp of 41 C. This is the same as firmware gives me, which is encouraging. As you can probably tell, I don't know enough about smb to fight my way out of a wet paper bag. Is there an SMB savy person out there who can take me by the hand and help me figure out where the fan speed and voltage is lurking and how to read it? Maybe not over SMBus :( Some boards are designed such a way that SMBus is only used for SDRAM detection not monitoring. The lm75/78 can also be controlled over both ISA... But this seems not to be the case for you since you found many chip on the SMBus. Grab the linux lm_sensor documentation and see if these I2C addresses are listed and which chips they are potentially assigned to. At this point, it is not SMBus dependent, but chip/vendor dependent. The only problem you can have with smbus/iicbus is now timings, but with alpm, these are handled by the controller. By the way, there's a port (lmmon) that accesses the lm75/78 over ISA, if you have such a monitoring chip... I know what chips they are (From the UP1000 Tech. Ref. Manual): The UP1000 has one main SM bus and two sub-SM busses. Acces to the sub-SM bus is controlled by a multiplexer (MUX) which sits on the main SM bus. The SM bus from the Alpha Slot B Module [processor module, akin to a Slot A Athlon] connects the first sub-SM bus; the DIMM EEPROMs are connected to the second sub-SM bus. SM bus addresses for all UP1000 devices are provided in Table 4-3. Table 4-3: SM Bus Address of Each Device: Device Address ----- ADM 9240 (system mgmnt unit) 0101 100X ICS9179-06 (Zero delay clock buffer) 1011 001X PCF8574AT (LED Controller)1010 001X PCF8574AT (I2C bus MUX Controller)1010 010X PCF8582 (MB revision EEPROM) 1010 001X Revision EEPROM on Alpha Slot B 1010 000X Module LM79 (Thermal Detector on Alpha 0101 111X Slot B Module) Dimm0 1010 000X Dimm1 1010 001X Dimm2 1010 010X This knowledge doesn't seem to help me much.. Is the I2C bus MUX controller common? Could that be why the "detect" program shows device addresses which are different than those given in the table? What software would you suggest for dealing with the mux and accessing the lm79? BTW, do I need the iic stuff? All I've got for smb in my config file is: device smbus # Bus support, required for smb below. device alpm1 device smb Thanks again, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
In message [EMAIL PROTECTED] Dennis writes: : 4.1 broke that "policy" rather badly. Perhaps its time to get rid of the : mbuf macros, as any change to that structure breaks binary compatibility in : the worst way possible. Agreed. There are too many things that have been MFC'd that change the interface and too little oversight of them. FreeBSD is better about not breaking things than many others, but we're far from perfect. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
In message [EMAIL PROTECTED] Wes Peters writes: : What's a good price point for a bedroom/kitchen "thin" computer with an : 800x600 LCD panel? If it had builtin ethernet, then I'd go up to $400-$500. If not, then I'd go $50-$100 less. Especially if there were no slots at all in it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Dennis wrote: : Still, I personally believe, that "core" or general "freebsd community" : should explicitly state, that support for binary drivers and support for : easier inclusion of binary driver or just third party driver is eagerly : encouraged. And as much as possible, easy inclusion of binary drivers : sould be kept in mind whether makeing changes to /usr/src/Makefile or : kernel interfaces or even discussions on the freebsd lists. Core has stated in the past a strong desire for developers not to break kernel interfaces within minor releases. 4.1 broke that "policy" rather badly. Perhaps its time to get rid of the mbuf macros, as any change to that structure breaks binary compatibility in the worst way possible. DB The "problem" was not with the macros themselves, but with the fact that your outdated binary was compiled with old definitions of some structures which were later changed (mbstat structure). The changes that happened there were relatively minor. I'm sure you would know all this had you debugged the problem yourself, but it turns out that all you provided in terms of "support" was whining and directing blame at the FreeBSD team. I disagree with not merging in fixes to -STABLE that help maintain code in general, for the entire project; In this case, the change helped userland code such as netstat(1) deal with mbtypes. This wasn't a "big interface change" by any means. Plus, it was discussed on -net and since -net directly concerns you and your driver, perhaps you should read it every once in a while. Had we not merged this change to -STABLE, I'm sure we would have had just as many, if not more requests: "MFC MFC, you guys are ignoring -STABLE!" as we have now with you complaining about the change being made. A wise man once said something along the lines: "you can never win with tire-kickers," and now I see how he was right. Regards, Bosko. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ñ ÍÎÂÛÌ ÃÎÄÎÌ
Title: Æóðíàë "Íîâûé Àêðîïîëü" Äîðîãèå äðóçüÿ! Ðåäàêöèÿ æóðíàëà "Íîâûé Àêðîïîëü" îò âñåé äóøè ïîçäðàâëÿåò âàñ ñ Íîâûì ãîäîì è íàñòóïëåíèåì íîâîãî òûñÿ÷åëåòèÿ! Ïðåäñòàâëÿåì Âàì æóðíàë "Íîâûé Àêðîïîëü". Êîíå÷íî, ó Âàñ âîçíèêíóò âîïðîñû: "À ÷òî ýòî çà æóðíàë? ×åì îí îòëè÷àåòñÿ îò äðóãèõ? Íàéäó ëè ÿ â íåì ÷òî-íèáóäü èíòåðåñíîå äëÿ ñåáÿ?.." Ìû íàäååìñÿ, ÷òî íà ÷àñòü ýòèõ âîïðîñîâ îòâåòèò ñàì æóðíàë è åãî ìàòåðèàëû, íî íà íåêîòîðûå èç íèõ ñòîèò îòâåòèòü ñåé÷àñ. Íàø æóðíàë - ýòî íå ïîïûòêà âûãîâîðèòüñÿ, ýòî äîðîãà, êîòîðàÿ ïðîõîäèò ïî ìåñòàì, ãäå òâîðèëàñü èñòîðèÿ ÷åëîâå÷åñòâà, ãäå ðàáîòàëè âûäàþùèåñÿ ëþäè, ãäå ñîâåðøàëèñü ïîðàçèòåëüíûå îòêðûòèÿ. Ýòî âîçìîæíîñòü âìåñòå ïîðàçìûøëÿòü, çàíÿòüñÿ íàó÷íûì ïîèñêîì, óçíàòü ìíîãî íîâîãî è ïðîñòî ïîáîëòàòü. Íàì áû î÷åíü õîòåëîñü, ÷òîáû ìû ñòàëè íå ñëó÷àéíûìè ïîïóò÷èêàìè, à äîáðûìè äðóçüÿìè, ãîòîâûìè äåëèòü ðàäîñòü îòêðûòèé è òðóä ïîèñêà, à ñàìîå ãëàâíîå - ëþáîâü ê ìóäðîñòè, êîòîðàÿ ñîãðååò íàøè ñåðäöà. È òîãäà ìàòåðèàëû ýòîãî æóðíàëà íå áóäóò ïðîñòî èñòî÷íèêîì èíôîðìàöèè, à ïîçâîëÿò îòêðûòü çàãàäî÷íûé ìèð, æèâóùèé â êàæäîì èç íàñ, - ìèð íàøåé äóøè. Ïåðåä âàìè íåêîòîðûå òåìû íàøåãî æóðíàëà (æóðíàë èçäàåòñÿ ñ 1997 ã.): Áóäåì ëè ìû æèòü ñíîâà? Ïî÷åìó ìû, ëþäè, îáìàíûâàåì? Çàãàäî÷íûå öèêëû â æèçíè ÷åëîâåêà Êòî íàéäåò ñîêðîâèùà òàìïëèåðîâ? Íåôåðòèòè: ñòðàíñòâèå ÷åðåç ïåñêè âå÷íîñòè Èñêóññòâî: àëõèìèÿ òâîð÷åñòâà Áîåâûå èñêóññòâà è ðûöàðñêèå îðäåíû Òàèíñòâåííûé ìèð êåëüòîâ  ïîèñêàõ Ãðààëÿ "Íåâîçìîæíûå" ìå÷òû Èñòîðèÿ ìàãèè Âå÷íàÿ òàéíà ëþáâè Ïîäïèñíîé èíäåêñ æóðíàëà â Îáúåäèíåííîì êàòàëîãå (çåëåíîì) - 39052 Öåíà çà ïîëóãîäèå - 96,42 ðóá. Àäðåñ â Èíòåðíåòå: http://www.newacropol.ru
Re: Boot process robustness
On 28-Dec-00 Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], "Walter W. Ho p" writes: Hi all, I was wondering how to increase the robustness of the booting process, so that a box would be able to keep itself on its feet without intervention of the console. I think this would be of great value to the many people who administer colocated boxes. I'm not much of a coder so all I can do is mailing this (at the risk of wasting your time with total useless crap ofcourse, in which case I apologize.) 1. Old kernel recovery When 'make install'ing a new kernel, a flag is raised (say, 'revert_on_fail') which is only cleared after a successful system initialisation. When the new kernel boots, a panic in this state or an unexpected reboot (reset after a system hang) would cause /kernel.old to be loaded on the next boot instead (maybe the same could work for /etc/rc.conf.old) This is actually more a question of where to store the flag than anything else. /boot/loader.conf perhaps, but how does the loader know that the previous boot failed so that it knows to fall back? This is much harder, as a failed kernel boot usually results in a hang or an instant CPU reset. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
Greetings, On a fairly recent -STABLE I am getting this failure: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033 I assume I'm doing something stupid, however the same code works on Linux gcc-2.95.2, so I'm looking for what the difference might be. The program is an ACE/TAO C++ program that dlsym()s an object, uses it happily, and then gets the assertion when dlclose()ing from the containing object's dtor. The assertion is that the refcount != 0. What should I do to fix that? Thanks! Russell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Easy way to recover disk
OK. I have a disk drive that is failing in random ways. Today blocks 123 456 and 293 might be unreadable. Tomorrow, it might be these and 27 or it might just be 27. It is an IDE drive. I was wondering if anybody had a program that would read the entire disk and keep a list/bitmap of the bad blocks and try them again next time the program is run. Operating on a slice or partition level would be ideal (I have a 20G disk that is failing, but only about 18G of free space). Ideas? Warner P.S. Basically what I want at the end of the day, disk willing, is what dd if=/dev/ad8s2a of=/huge/big-honkin-file ... would give me. I want this so I can then dump it to tape. I can't run dump directly since it hits those bad blocks and whines. P.P.S. Yes, I know I should have backups. P.P.P.S. Yes, I know that I may be SOL. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Easy way to recover disk
Isn't this what the Linux badblocks program is for? Why don't you take that and find a way to feed this into badsect(8)... OK. I have a disk drive that is failing in random ways. Today blocks 123 456 and 293 might be unreadable. Tomorrow, it might be these and 27 or it might just be 27. It is an IDE drive. I was wondering if anybody had a program that would read the entire disk and keep a list/bitmap of the bad blocks and try them again next time the program is run. Operating on a slice or partition level would be ideal (I have a 20G disk that is failing, but only about 18G of free space). Ideas? Warner P.S. Basically what I want at the end of the day, disk willing, is what dd if=/dev/ad8s2a of=/huge/big-honkin-file ... would give me. I want this so I can then dump it to tape. I can't run dump directly since it hits those bad blocks and whines. P.P.S. Yes, I know I should have backups. P.P.P.S. Yes, I know that I may be SOL. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Easy way to recover disk
In message [EMAIL PROTECTED] Matthew Jacob writes: : Isn't this what the Linux badblocks program is for? Why don't you take that : and find a way to feed this into badsect(8)... I thought the linux badblocks program found bad blocks and keep the user from using them. I want to read the entire disk and the parts that don't read I want to try again later to see if I can maybe get lucky. The disk has too many bad sectors to really use... So far the brute force approach seems to be going quickly. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SecureBSD
Alexey Dokuchaev wrote: Hello! Some pretty good time ago, I accidentally found SecureBSD (www.securebsd.org), which is a security patch for 3.4-REL and 4.0-REL. I kept a note about this site, and that's about it. Recently, reviewing my ~/cool.lynx file, I've found this site again. Interested, I dloaded it (4.0 version) and tried to apply it to my pretty recent 4.2-STABLE. Not surprisingly, it didn't apply, there were lots of rejects. I looked at rejected code, and it seems that it can be fixed easily. I've already wrote a perl script that would help me fixing all the patches :) The point of this letter is, whether SecureBSD worth trying or not? Maybe, even if I manage to correctly apply all the patches, it still would not work? It seems like really useful and cool thing, but I've hardly seen anyone using or even mentioning it. Will it help me make more secure server than using standard FreeBSD methods? If I recall, the license on SecureBSD doesn't allow you to distribute the patches to anyone else. You can contribute them back to SecureBSD, they can then do with them as they please, which may or may not include giving them to other SecureBSD users. This is the primary reason why the interest in SecureBSD remains so low around here. You may want to look at http://www.trustedbsd.org/ as well. It is provided under the Berkeley license, and much of what is developed there will be folded into FreeBSD as time permits. The primary author of TrustedBSD is Robert Watson, who is now a FreeBSD Core Team member as well. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Easy way to recover disk
On Fri, 29 Dec 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Matthew Jacob writes: : Isn't this what the Linux badblocks program is for? Why don't you take that : and find a way to feed this into badsect(8)... I thought the linux badblocks program found bad blocks and keep the user from using them. I want to read the entire disk and the parts that don't read I want to try again later to see if I can maybe get lucky. No, badblocks always reads the whole disk- it emits a list of badblocks. It's e2fsck that is then used to tell the filesystem that these blocks are unavailable. The newer IBM ATA drives do auto reallocate. It was that and the fact that they now do tagged multiple commands that has convinced me that parallel SCSI is now almost pointless for workstations (and even for RAID units). And with SCSI over IP coming along nicely, fibre channel SCSI is also dead. I gotta get init a new line of work.. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ñ ÍÎÂÛÌ ÃÎÄÎÌ
Title: Æóðíàë "Íîâûé Àêðîïîëü" Äîðîãèå äðóçüÿ! Ðåäàêöèÿ æóðíàëà "Íîâûé Àêðîïîëü" îò âñåé äóøè ïîçäðàâëÿåò âàñ ñ Íîâûì ãîäîì è íàñòóïëåíèåì íîâîãî òûñÿ÷åëåòèÿ! Ïðåäñòàâëÿåì Âàì æóðíàë "Íîâûé Àêðîïîëü". Êîíå÷íî, ó Âàñ âîçíèêíóò âîïðîñû: "À ÷òî ýòî çà æóðíàë? ×åì îí îòëè÷àåòñÿ îò äðóãèõ? Íàéäó ëè ÿ â íåì ÷òî-íèáóäü èíòåðåñíîå äëÿ ñåáÿ?.." Ìû íàäååìñÿ, ÷òî íà ÷àñòü ýòèõ âîïðîñîâ îòâåòèò ñàì æóðíàë è åãî ìàòåðèàëû, íî íà íåêîòîðûå èç íèõ ñòîèò îòâåòèòü ñåé÷àñ. Íàø æóðíàë - ýòî íå ïîïûòêà âûãîâîðèòüñÿ, ýòî äîðîãà, êîòîðàÿ ïðîõîäèò ïî ìåñòàì, ãäå òâîðèëàñü èñòîðèÿ ÷åëîâå÷åñòâà, ãäå ðàáîòàëè âûäàþùèåñÿ ëþäè, ãäå ñîâåðøàëèñü ïîðàçèòåëüíûå îòêðûòèÿ. Ýòî âîçìîæíîñòü âìåñòå ïîðàçìûøëÿòü, çàíÿòüñÿ íàó÷íûì ïîèñêîì, óçíàòü ìíîãî íîâîãî è ïðîñòî ïîáîëòàòü. Íàì áû î÷åíü õîòåëîñü, ÷òîáû ìû ñòàëè íå ñëó÷àéíûìè ïîïóò÷èêàìè, à äîáðûìè äðóçüÿìè, ãîòîâûìè äåëèòü ðàäîñòü îòêðûòèé è òðóä ïîèñêà, à ñàìîå ãëàâíîå - ëþáîâü ê ìóäðîñòè, êîòîðàÿ ñîãðååò íàøè ñåðäöà. È òîãäà ìàòåðèàëû ýòîãî æóðíàëà íå áóäóò ïðîñòî èñòî÷íèêîì èíôîðìàöèè, à ïîçâîëÿò îòêðûòü çàãàäî÷íûé ìèð, æèâóùèé â êàæäîì èç íàñ, - ìèð íàøåé äóøè. Ïåðåä âàìè íåêîòîðûå òåìû íàøåãî æóðíàëà (æóðíàë èçäàåòñÿ ñ 1997 ã.): Áóäåì ëè ìû æèòü ñíîâà? Ïî÷åìó ìû, ëþäè, îáìàíûâàåì? Çàãàäî÷íûå öèêëû â æèçíè ÷åëîâåêà Êòî íàéäåò ñîêðîâèùà òàìïëèåðîâ? Íåôåðòèòè: ñòðàíñòâèå ÷åðåç ïåñêè âå÷íîñòè Èñêóññòâî: àëõèìèÿ òâîð÷åñòâà Áîåâûå èñêóññòâà è ðûöàðñêèå îðäåíû Òàèíñòâåííûé ìèð êåëüòîâ  ïîèñêàõ Ãðààëÿ "Íåâîçìîæíûå" ìå÷òû Èñòîðèÿ ìàãèè Âå÷íàÿ òàéíà ëþáâè Ïîäïèñíîé èíäåêñ æóðíàëà â Îáúåäèíåííîì êàòàëîãå (çåëåíîì) - 39052 Öåíà çà ïîëóãîäèå - 96,42 ðóá. Àäðåñ â Èíòåðíåòå: http://www.newacropol.ru
Re: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
In article [EMAIL PROTECTED], Russell L. Carter [EMAIL PROTECTED] wrote: On a fairly recent -STABLE I am getting this failure: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033 I assume I'm doing something stupid, however the same code works on Linux gcc-2.95.2, so I'm looking for what the difference might be. The program is an ACE/TAO C++ program that dlsym()s an object, uses it happily, and then gets the assertion when dlclose()ing from the containing object's dtor. The assertion is that the refcount != 0. What should I do to fix that? There is a bug in the dynamic linker in connection with calling dlopen or dlclose from a static constructor or destructor, and this sounds like it's related to that. I came up with a fix for it which Peter Wemm was testing at Yahoo. That was a few months ago, and I'll have to dig it out again after the holiday madness has subsided. If you haven't heard from me by Saturday Jan. 6, I'd appreciate a gentle reminder to [EMAIL PROTECTED]. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
linux_ioctl_disk problems..
While trying to get the linux mke2fs to create linux filesystems on
slices,
I have come across a problem with one of the disk ioctls. I am having
trouble tracking it down further, but I think I am close.
After creating a partition table, I am attempting to execute:
mke2fs /dev/ad0s1
Sometimes, it works, and creates the file system, and other times it
fails.
If I create the filesystem on /dev/ad0, it always seems to work. It is
quite
odd. Anyways, the problem is, that sometimes this ioctl fails:
linux_open("/dev/ad0s1",0,00)= 3 (0x3)
linux_ioctl(0x3,0x1260,0xbfbff9cc) ERR#22 'Invalid
argument'
Which is the LINUX_BLKGETSIZE case in linux_ioctl.c:113 on 4.2-STABLE.
Needless to say, accessing the device with the wrong block size then
makes
things more unhappy, as indicated by a bunch of dscheck messages:
dscheck(#ad/0x20002): b_bcount 1 is not on a sector boundary (ssize 512)
Any ideas?
Chris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: Easy way to recover disk
What do you mean, you can have multiple outstanding reads like in SCSI? I thought the IDE protocol was fundamentally unable to handle the concept. I also thought that IDE drives have been transparently remapping bad blocks (and failing only when they run out of spares) for quite a few years now. -- Jonathan Graehl email: [EMAIL PROTECTED] web: http://jonathan.graehl.org/ phone: 858-642-7562 The newer IBM ATA drives do auto reallocate. It was that and the fact that they now do tagged multiple commands that has convinced me that parallel SCSI is now almost pointless for workstations (and even for RAID units). And with SCSI over IP coming along nicely, fibre channel SCSI is also dead. I gotta get init a new line of work.. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot process robustness
This is actually more a question of where to store the flag than anything else. /boot/loader.conf perhaps, but how does the loader know that the previous boot failed so that it knows to fall back? This is much harder, as a failed kernel boot usually results in a hang or an instant CPU reset. I had always planned to write a fixed-size file to disk (probably 512 bytes) and then implement "overwrite only" write support in the various filesystems to allow us to use it as a "persistent" environment store, eg. have a 'save foo' keyword which would update the persistent store with the 'foo' variable. This would avoid the bloat that block allocation, directory creation etc. would entail with "real" write support, whilst allowing us most of the desirable features. All of the primary boot filesystems (ffs, nfs, tftp, fat, ext2) could handle this with trivial modifications. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Easy way to recover disk
On Fri, 29 Dec 2000, Jonathan Graehl wrote: What do you mean, you can have multiple outstanding reads like in SCSI? I thought the IDE protocol was fundamentally unable to handle the concept. I dunno- check out Soren's work. I also thought that IDE drives have been transparently remapping bad blocks (and failing only when they run out of spares) for quite a few years now. It was news to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Easy way to recover disk
In message [EMAIL PROTECTED] Matthew Jacob writes: : No, badblocks always reads the whole disk- it emits a list of badblocks. : It's e2fsck that is then used to tell the filesystem that these blocks are : unavailable. Ah. Yes. I see now. It would be useful. Before I discovered this I hacked togheter something that seemed to work. It basically read all the blocks that it could and save them to a file and note in an easy to parse format the bad blocks. I only had 3 after the first go round (the 512 byte reads did the bulk of the trick, 8k reads died a horrible death, fsck couldn't cope). I don't know why 512 byte reads did it, and I noticed my simple progress meter ran faster or slower depending on which part of the disk it was on. Also, PIO mode seemed to be better at reading the blocks. I turned the drive off and let it set for a few hours and was able to recover the last 3 blocks at that time by hand. Interestingly enough, once I was able to read an entire partition with 512 byte reads, mount, fsck and some light disk activity seemed to work with the 8k and 16k read/writes that implied. This is a stupid 20G toshiba laptop disk that I wouldn't have thought did bad block remapping. So I'm now running dump on the resulting file :-) The only thing I couldn't figure out how to do was to mount the file. Since I grabbed the disk partition, I wasn't sure I could just use vnconfig since there was no FreeBSD label on that partition. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
