IPX, Netware functionality?
Is somebody still working on IPX, Netware functionality? I'm having quite unexpected problems on 4.10-RELEASE when trying to mount netware volumes. In former 4-releases, I could a) add IPX+ef to kernel, b) recompile, c) run IPXrouted and d) make ifconfig iff[0-3] ipx net, then everything worked. Now, I don't see iff[0-3] pseudo-interfaces anymore. ifconfig ipx, however, works. After using it, I can have either one several (aliased) ipx net entries in my ifconfig. And tcpdump confirms there *is* at least SAP traffic from netware servers I'm interested in. Now, everything netware-related fails with protocol not supported diagnostic. I digged a bit in ncplist, and found that the ipx listening socket fails to receive anything with ETIMEDOUT. IPX socket not working?? Could anything be done? Also, there's some peculiar logic in ipx addresses checking in libncp routines, e.g., ipx_nullnet checking of host addrs. For my digging, I had to circumvent it, as without doing so, perfectly reasonable configuration just generated error, without even trying to listen to the network. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPDIVERT option not getting compiled?
Dmitry Morozovsky wrote: DM YT an option to IPFIREWALL, you have to build your kernel with DM YT both IPFIREWALL and IPDIVERT: DM YT ... DM YT I did. See the config contents in originating posting. That was the essence DM YT of the problem -- familiar procedure unexplainably not working. DM DM But you did reference ipfw *module*. This combination will not work. Currently, DM if you need divert you *must* compile ipfw into 4.X kernel. Hmm. Looking at you kernel config file I see you *did* included ipfw into the kernel. Looks strange to me. Well, can you please provide dmesg from the failing boot? Not anymore. I've finally went for reformatting and reinstalling. Then it all worked -- and with this same config file. And I'm reasonably sure I wasn't messing with system in previous installation. What I'd like to know now is what could be the possible cause?? --regards ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPDIVERT option not getting compiled?
Gary Jennejohn wrote: Yury Tarasievich writes: Hello? anybody? So how come IPDIVERT option is outright ignored in system build here?? The system isn't even connected to internet, nor to any other net anyway! And as if I don't know how to compile kernel? And it is stock 4.10-RELEASE, too (and 4-STABLE has same problem). The process is fairly familiar to me. Config is config that worked before (on other machines). Is it something with the machine perhaps?? What could possibly be going on? What should I check? How about explaining in a little more detail what sort of error you're seeing? We're not psychics und I certainly can't see a real error report anywhere in the text of your mail. :) Given the situation, if I'd be able to provide any extra info, I'd be able to solve the problem myself, wouldn't I? I'm adding IPDIVERT option (options IPDIVERT) to config file and config kernel and compile kernel (alternatively -- buildkernel KERNCONF...) and install kernel and all's fine except that after reboot ipfw.ko tells that divert is disabled and it is, indeed, disabled, as natd starts but there are no divert sockets. It happens both with 4.10-RELEASE and with 4-STABLE. But never you mind. This time I had the luxury of being able to just format the partition and install system from scratch, so I did (there wasn't anything big installed yet). Mighty it would help me with populated system. --regards ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPDIVERT option not getting compiled?
Yar Tikhiy wrote: On Tue, Nov 16, 2004 at 03:08:54PM +0200, Yury Tarasievich wrote: I'm adding IPDIVERT option (options IPDIVERT) to config file and ... You seem to be confused by the well-known kernel vs. module configuration issue. Alas, kernel options you specify in your kernel config file affect the kernel binary only, not modules built along with the kernel. If you want IPDIVERT, which is an option to IPFIREWALL, you have to build your kernel with both IPFIREWALL and IPDIVERT: ... I did. See the config contents in originating posting. That was the essence of the problem -- familiar procedure unexplainably not working. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPDIVERT option not getting compiled?
Hello? anybody? So how come IPDIVERT option is outright ignored in system build here?? The system isn't even connected to internet, nor to any other net anyway! And as if I don't know how to compile kernel? And it is stock 4.10-RELEASE, too (and 4-STABLE has same problem). The process is fairly familiar to me. Config is config that worked before (on other machines). Is it something with the machine perhaps?? What could possibly be going on? What should I check? Yury ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPDIVERT option not getting compiled?
Yury Tarasievich wrote: Just recently I've run into this: when compiling kernel in 4.10-RELEASE and in 4-STABLE, options IPDIVERT does not produce enabled divert in firewall code. Previously (meaning other machines and previous 4.* variants) the configuration compiled/worked okay. I've used the attached config for kernel (with commented out SMP and APIC_IO). I've compiled both with and without make.conf including IPFW2=TRUE. Even simple adding options IPDIVERT to GENERIC doesn't work, and not just in firewall, but by having no ipdivert code in kernel whatsoever. I'm at a loss. ,Yury ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
IPDIVERT option not getting compiled?
Hello, Just recently I've run into this: when compiling kernel in 4.10-RELEASE and in 4-STABLE, options IPDIVERT does not produce enabled divert in firewall code. Previously (meaning other machines and previous 4.* variants) the configuration compiled/worked okay. I've used the attached config for kernel (with commented out SMP and APIC_IO). I've compiled both with and without make.conf including IPFW2=TRUE. ,Yury machine i386 ###cpu I386_CPU ###cpu I486_CPU cpu I586_CPU cpu I686_CPU ident SMP-8 options INCLUDE_CONFIG_FILE maxusers0 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking ###options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options KBD_INSTALL_CDEV# install a CDEV entry in /dev ###options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. ###options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # To support HyperThreading, HTT is needed in addition to SMP and APIC_IO ##4.9#options HTT # HyperThreading Technology device isa device eisa device pci # Floppy drives device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # # If you have a Toshiba Libretto with its Y-E Data PCMCIA floppy, # don't use the above line for fdc0 but the following one: #device fdc0 # ATA and ATAPI devices device ata0at isa? port IO_WD1 irq 14 device ata1at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device mpt # LSI-Logic MPT/Fusion device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets) options SYM_SETUP_LP_PROBE_MAP=0x40 # Allow ncr to attach legacy NCR devices when # both sym and ncr are configured device adv0at isa? device adw device bt0 at isa? device aha0at isa? device aic0at isa? device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg
Re: serial ATA support?
Søren Schmidt wrote: Yury Tarasievich wrote: Do I understand right (after looking into sources) that 4-STABLE has no support for serial ATA devices?? Almost none, it works with a few controllers that looks like stock ATA ones (HPT fx). Anyhow you want 5.3 to get real SATA support.. I see. And needing a 5.3 is bad news. ,Yury ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
serial ATA support?
Do I understand right (after looking into sources) that 4-STABLE has no support for serial ATA devices?? regards ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fgdg
I prefer it that way: 1. run freebsd install partition the disk, using multiplies of heads*sectors as base unit make ...s1 slice of type 6 (and possibly make fairly big ad0s2 of type 5) make ...s3 and install freebsd there (I have seen windows at my place occasionally removing primary partitions placed in chain between C: (...s1) and extended partition) 2. setup windows to ...s1 3. when (if) wanting to run linux fdisk (I use it to add logical drives rather than that of windows), switch bios to normal disk translation before and to LBA after (in most cases one-time operation) Is there any freebsd fdisk capable of dealing with logical drives? Roman Kurakin wrote: Hi, Joerg Micheel wrote: On Mon, Mar 17, 2003 at 12:39:22PM +0300, sergej wrote: mozno li ustanovit% odnovremenno na odin disk: unix i windows, i kak jto sdelat%! I think it would be better if you will ask questions in English. Get yourself a copy of the Complete FreeBSD by Greg Lehey, which covers this subject very well. This question also belongs to freebsd-questions, not -hackers. In short, the configuration option is there with FreeBSD as delivered, but you need to take care on making the right steps at the right time. Starting off with BSD first is the better way to proceed, adding Windows later. If you setup at first FreeBSD and then add Windows you will lose FreeBSD's boot loader. And you will have to reinstall bootloader. You also could meet other problems. If your set incorrect (from FreeBSD's point of view) geometry for you hard disk and install freebsd 5.0 after Windows 2000, freebsd will fix windows partition entry and any reinstalletions or fix procedures of Windows will lead to nothing. Probably some last versions from 4.x branch have the same features, but the last 4.x version I worked with at home was 4.3. PS. I don't know if this bug was fixed in current versions. I am almost sure that it is not. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Are there any on-going projects on v4l porting?
At http://freebsddvb.narod.ru, there exists an adequately up-to-date port of linux DVB drivers, seemingly supporting DVB adapters up to rev.1.5. Regarding porting of V4L. I may be utterly wrong, but isn't the whole V4L/V4L2/V4L2-whatever thing rather made ad hoc, not really designed? Could something reincarnating BeOS (or even OS/2) multimedia subsystem be better? Vladimir Kushnir wrote: As subj. said - does anybody work on porting v4l (especially!) drivers for non- bt8x based cards? Specifically saa7134 based (got one and would rather not have to reboot to Linux to watch TV :-) Yes, I know, the simplest answer would be you're interested - you do but that'd be quite beyond my skills. Still I'd happily help with testing/debugging/whatever else. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tyan S4520 GCHE
Brian Buchanan wrote: I'm having problems getting SMP to work on a Tyan S4520 Thunder GCHE motherboard with 4x 1.9GHz Xeon processors: Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 Programming 16 pins in IOAPIC #2 AP #1 (PHY# 2) failed! panic y/n? [y] AP #2 (PHY# 4) failed! panic y/n? [y] AP #3 (PHY# 6) failed! panic y/n? [y] This is under FreeBSD 4.7-RELEASE. I also tried a recent -STABLE build and 5.0-RELEASE, with the same results. I made similar problem known here about middle-January. John Baldwin told me there is standing problem with APICs on 7500SW2 motherboards. Possible solution he suggested was: You can try to change bus_clock from 6600 to 53300 in sys/i386/i386/mpapic.c and see if that helps. This didn't help me (I couldn't even pass panic (y/n) with no). See if it helps you. What really concerns me now is 5.0-RELEASE with all the SMPng can't cope with the problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Making pkg_XXX tools smarter about file types...
clemens fischer wrote: Yury Tarasievich [EMAIL PROTECTED]: ...then, Tim Kientzle wrote: A better approach might be to simply fob it off on the user, i.e., # pkg_install foo-1.5 Warning: foo-1.5 requires bar-2.3, you have bar-1.7 installed. Proceed? [Y/n] i think this is the best approach. I still disagree with that partially (as in quote below). In my opinion, user should be bothered with choices *only* when, like in this example, when dependency isn't *at* *all* satisfied. User definitely should *not* be bothered when differences are irrelevant to the functionality. E.g., ask only when bar-1.7 is installed and 2.3+ required, not when bar-1.7 is installed and say 1.4.1+ is required. but i've seen libraries/interfaces changed dramatically. i faintly remember a package which would not link to Qt-2, but insisted on Qt-1 beeing used. So have dependency list insist on having available qt-1no-higher. Not the most appropriate example, either (I would have thought of dividing line like method changed behaviour over some revision number). QT's have different naming schemes (IIRC) and different functionalities, effectively being 3 different packages. I think dependencies could / should also have *upper* revision limit (library interface change, e.g.). And there could also be functionality of system-wide dependencies updating (isn't there one?) but you cannot possibly know at what version number in the future some API will change. anything like this could only make sense if an API is described in terms of functionality needed, at a much finer grained level than version numbers. I agree with that but then I don't see what is *the* problem? I believe it *is* known what functionality gets changed and how, when package goes through revision change? I've seen interesting concept of version number processing by D.J.Bernstein (called slashpackage, I believe). slashpackage doesn't really solve this problem, it is just a more rigorous framework. but since many of DJBs followers make programs as [...] No, I was thinking about that (citing cr.yp.to/slashpackages/versions.html): Which version is newer? Version numbers are required to start with digits, but they aren't required to follow any particular numbering system. In particular, they aren't required to increase lexicographically. One package might have versions 2, 2.01, ..., 2.09, 2.1, 2.11, ..., 2.89, 2.9, etc., while another package has versions 2.0, 2.1, 2.2, ..., 2.9, 2.10, 2.11, etc.; 2.11 may be before or after 2.9. If you're building a package, you can include a file ./package/versions that lists all the version numbers you've used so far, one per line, in order. Then scripts can compare two versions to see which one is newer. For example, if /package/admin/daemontools-0.80/ package/versions says 0.75 0.76 0.80 while /package/admin/dameontools-0.92/package/versions says 0.75 0.76 0.80 0.81 0.90 0.91 0.92 then 0.92 is newer. This file also makes it possible to reliably handle dependencies such as ``you must have version 0.81 or newer.'' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Making pkg_XXX tools smarter about file types...
...first, clemens fischer wrote: Yury Tarasievich [EMAIL PROTECTED]: I'd like to see in dependencies not only like was built with -1.9_2abc, so wants it, but also something like -1.5+ (obviously 1.5.0 and newer), -* (any version will do). Perhaps something else. At least to have possibility of specifying that, if this can't go into official ports. Does it seem reasonable? this problem has been annoying me for ages, but he who implements this should consider dependencies specified too liberally. sometimes newer versions aren't backwards compatible, which you can't know back in the past. Well, someone *should* pay *some* attention to what he's porting, right? And I've seen some ports even aren't compliant with hier(7), too. ...then, Tim Kientzle wrote: A better approach might be to simply fob it off on the user, i.e., # pkg_install foo-1.5 Warning: foo-1.5 requires bar-2.3, you have bar-1.7 installed. Proceed? [Y/n] In my opinion, user should be bothered with choices *only* when, like in this example, when dependency isn't *at* *all* satisfied. User definitely should *not* be bothered when differences are irrelevant to the functionality. E.g., ask only when bar-1.7 is installed and 2.3+ required, not when bar-1.7 is installed and say 1.4.1+ is required. I think dependencies could / should also have *upper* revision limit (library interface change, e.g.). And there could also be functionality of system-wide dependencies updating (isn't there one?) I've seen interesting concept of version number processing by D.J.Bernstein (called slashpackage, I believe). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Making pkg_XXX tools smarter about file types...
I have yet another suggestion regarding packaging subsystem -- could it be possible to extend pkg_* functionality (and, in fact, ports functionality) to recognize modest set of wildcards in dependencies names? It seems pretty unreasonable to have various subrevisions of, say, libiconv, pulled as packages dependencies ending with libiconv-1.7_5, libiconv-1.8, libiconv-1.8_1 and installed. And still another package would complain about having no -1.8_2. I'd like to see in dependencies not only like was built with -1.9_2abc, so wants it, but also something like -1.5+ (obviously 1.5.0 and newer), -* (any version will do). Perhaps something else. At least to have possibility of specifying that, if this can't go into official ports. Does it seem reasonable? Tim Kientzle wrote: The attached patch modifies the pkg_install tools to inspect the file contents--rather than the [...] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: End-Of-Life announcement for M-Systems DiskOnChip driver(fla).
Nat Lanza wrote: On Mon, 2003-02-03 at 18:06, Terry Lambert wrote: But if that's the argument for removing it, then it's probably time to remove the ability to use non-DMA IDE drives from the ATA driver, and kill all the ethernet drivers that have alignment requirements for their DMA engines, making m_pullup copies necessary, and yanking all drivers that do destructive probes, and getting rid of the F00F workaround, and yanking all support for things hung off the floppy controller, etc. etc.. All that could be justified using exactly the same argument. It's great to hear you volunteering to maintain this driver, Terry. Is the code *broken*? If not, what is The Real Reason to axe it? I'd also add that in existing environment relevance of having FreeBSD support for any brand new hardware is not *that* higher than relevance of maintaining support for existing hardware. Perhaps not higher at all. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: verbose device probing ?
Narvi wrote: If only Joe-Bob or some other very limited set of people have the card, then the severity of the bug in the *FreeBSD* bug database should probably not be 5 - orherwise the database will contain a large amount of bugs that claim to be of high severity but only ever affect neglible amounts of people I'd say there is *no* such thing as negligible amount of people in FreeBSD community. In Windows community, perhaps. Not here. Remember we aren't yet talking millions of installations and must-setup thing. No negligible (discardable) amount of people, then. Please. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Terry Lambert wrote: Yury Tarasievich wrote: [...info and pointers greatly appreciated...] Now: Most of the reasons this stuff is not in FreeBSD is NIH (not being the pet research project of a committer), license, the need to productize the code from research, etc.. For the complaints about scalability... Linux has a project that they are very proud of, in order to obtain 10,000 simultaneous TCP connections. With respect, I personally achieved 1,600,000 simultaneous TCP connections on a modified FreeBSD box with 4G of RAM. During this process, I found a credentials reference count overflow bug (since fixed in FreeBSD), which occurred on close, after opening more than 32,763 connections in one process. No one else reported this bug, so I have to assume that no one else ever ran FreeBSD up to that number of connections, before. So... the primary reason is that no one is using FreeBSD under the loads necessary to cause the problems to exhibit themselves. You have to have a need in order to be interested in a way of satifying a need. 8-). I wasn't explicit with my question, although with your explanations my question(s) seems rather rhetoric -- but I'd like to know your opinion: - what is the *real* *reason* for stuff that good not going into FreeBSD? and - doesn't all that mean that the supposed plentiness of choice turn out to be rather its opposite? has one not belonging to the inner circle *any* chance of influencing things course? You were also saying in same post that: The fixes are mostly simple, but for whatever reason, they never make it into FreeBSD proper (my theory is that the developement focus is heavily skewed to general purpose processing, rather than network processing). And throttling the FlagFeature??? That sort of thing has to be there, for FreeBSD to be interesting as a reasearch OS, so that additional work occurs on the platform; that's pretty much a given. You wouldn't have someone as well-known as Sam Leffler donating code, if that code was unlikely to get in, since it would be a waste of his time and effort (the same reason some people have left the project, actually). That I didn't understand. People left because they couldn't get their code in or because they couldn't stop code of well-known persons getting in? So even if you don't like feature creep or bloat, when it impacts top end performance, top end performance really doesn't matter to most people who are doing the coding (i.e. how many OC3's do you have to your computer? How many would you need to have to saturate even a single gigabit ethernet?). I wasn't precise in wording. Possibly, one cannot even see the real impact of worsening of network processing. I just do not see the good reason for *actually* making network processing capability -- the most praised feature of free *nixes -- worse, not better. And I think it's bad press, too. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD firewall for high profile hosts - waste of time ?
Terry Lambert wrote: FreeBSD is actually adding pointers and other complexity to its stack [...etc.] So you are referring to common features of stacks of both 4.* and 5.*, right? As far as I understand the matter, this all have to be (and I guess actually is) provable. Now, you were saying that 5.* is even worse, I quote: FreeBSD 5.x network performance is really poor, relative to 4.x; I do not recommend using FreeBSD 5.x in a production environment. Then I wonder *what* were the reasons for not working on matters pointed out??? You were also saying in same post that: The fixes are mostly simple, but for whatever reason, they never make it into FreeBSD proper (my theory is that the developement focus is heavily skewed to general purpose processing, rather than network processing). And throttling the FlagFeature??? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.7 on 2 Xeons SMP?
Want to attract your attention once more. At my place double Xeons fails to start (with only SMP and APIC options added to GENERIC) with following diagnostics: I tried both 4.7-RELEASE srs/sys and that of January 14. That's what I get when booting with SMP enabled (copied from screen): Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 AP #1 (PHY# 6) failed panic y/n? mp_lock = 0001; cpuid = 0; lapic_id = I'm also attaching dmesg of successful boot of GENERIC. Now, when I looked into sources for apic initializing (where it seemingly fails), I've thought that with some qualified guidance (by e-mail or likewise) I could possibly try to address the problem myself. Bad news is that machine's going to be in my posession for two weeks only (in case FreeBSD+Oracle 9i combo fails to start) and that I'm practically unacquainted with kernel debugging so coaching should come really low-level, like in recent Dreyfus article about running IRIX binaries on NetBSD. Good news is I have some knowledge of electronics and recognize some concepts in source and understood almost everything in said article. :) So would anybody be willing to spare time and knowledge? Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.7-RELEASE #0: Wed Oct 9 15:08:34 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz CPU: Pentium 4 (1794.19-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 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 real memory = 1073217536 (1048064K bytes) avail memory = 1039351808 (1014992K bytes) Preloaded elf kernel kernel at 0xc050f000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 17 entries at 0xc00fdeb0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pci0: unknown card (vendor=0x8086, dev=0x2541) at 0.1 pcib1: PCI to PCI bridge (vendor=8086 device=2543) at device 2.0 on pci0 pci1: PCI bus on pcib1 pci1: unknown card (vendor=0x8086, dev=0x1461) at 28.0 pcib2: PCI to PCI bridge (vendor=8086 device=1460) at device 29.0 on pci1 pci2: PCI bus on pcib2 pci1: unknown card (vendor=0x8086, dev=0x1461) at 30.0 pcib3: PCI to PCI bridge (vendor=8086 device=1460) at device 31.0 on pci1 pci3: PCI bus on pcib3 uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x7000-0x701f irq 10 at device 29.0 on pci0 usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x7020-0x703f irq 5 at device 29.1 on pci0 usb1: Intel 82801CA/CAM (ICH3) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcib4: Intel 82801BA/BAM (ICH2) Hub to PCI bridge at device 30.0 on pci0 pci4: PCI bus on pcib4 ahc0: Adaptec 29160N Ultra160 SCSI adapter port 0x8000-0x80ff mem 0xfc24-0xfc240fff irq 5 at device 2.0 on pci4 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs pci4: ATI Mach64-GR graphics accelerator at 3.0 irq 11 fxp0: Intel Pro 10/100B/100+ Ethernet port 0x8800-0x883f mem 0xfc20-0xfc21,0xfc242000-0xfc242fff irq 11 at device 4.0 on pci4 fxp0: Ethernet address 00:02:b3:b0:c5:06 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Intel Pro 10/100B/100+ Ethernet port 0x8840-0x887f mem 0xfc22-0xfc23,0xfc243000-0xfc243fff irq 11 at device 5.0 on pci4 fxp1: Ethernet address 00:02:b3:b0:c2:14 inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI to ISA bridge (vendor=8086 device=2480) at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH3 ATA100 controller port 0x7040-0x704f,0-0x3,0-0x7,0-0x3,0-0x7 irq 0 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: unknown card (vendor=0x8086, dev=0x2483) at 31.3 irq 11 orm0: Option ROMs at iomem 0xc-0xc7fff,0xe3800-0xe3fff on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags
4.7 on 2 Xeons SMP?
Hello, Is there any possibility of helping me to get started FreeBSD with SMP option (and no SMP works okay) on modern 2 Xeon procs server? I have about two weeks for accomplishing that, after that machine either goes under Linux, or even under Windows, as there is a complementary (and very nasty) problem -- getting Oracle 9i installed there (that is unsolved yet, although there can be some clues). I tried both 4.7-RELEASE srs/sys and that of January 14. That's what I get when booting with SMP enabled (copied from screen): Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 AP #1 (PHY# 6) failed panic y/n? mp_lock = 0001; cpuid = 0; lapic_id = (sorry, forgot to save dmesg from non-SMP boot) Does the 5.0 solve the problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Restoring superblock backup?
Andreas Klemm wrote: On Fri, Dec 13, 2002 at 02:28:00PM -0800, Nate Lawson wrote: I've successfully repaired a fs with the superblock backup at 32. Now how do I copy that backup to the default superblock location? fsck_ffs does NOT automatically do this. It does. With fsck -b 32 you use the alternate super block to repair the filesystem just in case the superblock in at the usual place is damaged. After that the filesystem is completely repaired ... Of course the previously damages superblock ... fsck does the same things only that you choosed the first copy of the superblock, that is always on block 32. The next copy depends on the size and geometry of the filesystem and is not so easy predictable like the 32 which is always present If FS boundaries are right, one can always try newfs -N, then fsck with -b. I tried this once and succeeded using superblock copy being really more distant from FS start. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
unnaturally slow booting
Wanted to ask about it for quite some time. I've got two 20G disks installed with basically same geometry. They were partitioned (by linux fdisk) approx. similarly (+/- 10 cylinders): part. 1: ~1-250 part. 2 (Extended): ~751-everything that remains part. 3: ~251-500 part. 4: ~501-750 There's FreeBSD (4.7-RELEASE) installed on ad0s3 and ad1s3. There's FreeBSD bootmanager installed. Instance from ad1s3 boots without any problems. Now, booting instance on ad0s3, beginning with kernel loading and through modules from loader.conf loading, takes unnaturally long time, spinning bar ticks happen at rate about 1 per sec. When kernel and modules are loaded, things progress as usual. In fact, I installed the instance on ad1s3 just to avoid this weirdness. I believe this behaviour started somewhere about 4.6-RELEASE. I somehow do not recall seeing this on 4.3-4.5, and I surely was using this scheme of partitioning then. I'm in no way expert, so looking through bootloader source didn't reveal anything to me. Any thoughts on what happens? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: documentation on kernel locks, mutexes?
On Sat, Nov 30, 2002 at 10:27:27PM -0800, Terry Lambert wrote: Robert Watson wrote: On Mon, 25 Nov 2002, Terry Lambert wrote: Yury Tarasievich wrote: I need to port some driver from linux to freebsd and, somehow, I can't find documentation on kernel locks and mutexes. There are no man pages, links from handbook are broken, and search on freebsd site gives nothing (besides the handbook itself). [...] I was thinking more in terms of device driver information. All of the how to write a driver for newbus, how to write a CAM driver, how to use devfs from the kernel, what XXX to do in FreeBSD, given YYY in Linux, how to port a driver from Linux to FreeBSD, etc., are missing. Well, perhaps not THAT generic information... :) While it's true that kernel locks and mutexes are documented for SMPng, he posted to -hackers, not -current, and so he's probably not interested in -current primitives that aren't available in the 4.x -RELEASE and -STABLE branches. Exactly my point, thanks! And I'll point again that: - links in handbook DO NOT work (freebsd.org does not have these pages (specifically lockmgr(9), mutex(9)) - and there are no man pages for them in distribution I've even checked this with 4.4-RELEASE at hand -- seen same. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
vnconfig
Hi, Regarding vn subsystem: since about 4.6-RELEASE vnconfig -d no longer disables /dev/vn entry. That means that... vnconfig -e /dev/vnsomething file vnconfig -d /dev/vnsomething vnconfig -e /dev/vnsomething anotherfile ...gives vnconfig: VNIOCATTACH: Devise busy... and only kldunload vn helps. Yury To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vnconfig
On Fri, Nov 29, 2002 at 09:20:52AM +0300, Fred Souza wrote: Regarding vn subsystem: since about 4.6-RELEASE vnconfig -d no longer disables /dev/vn entry. [] Actually, it does disable it (or at least, using the same words from the manpage, if it's possible). Your problem most likely is that -d only disables the device, but does not unconfigure it. Try using the -u flag instead of -d, it'll do both things for you. That's right, thank you! But why this simple detail isn't in the manpage?? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
documentation on kernel locks, mutexes?
Hello, I need to port some driver from linux to freebsd and, somehow, I can't find documentation on kernel locks and mutexes. There are no man pages, links from handbook are broken, and search on freebsd site gives nothing (besides the handbook itself). Where can I find some docs? ,Yury. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
