Re: NewCard / pccbb
Ok, now I need your dmesg again, since it's been trimmed and I've lost it. I also need to know what slots you have things in. Please don't cut the $PIR output off this message when you reply. Note that your system is something of a pathalogical worst-case; no PCI recommended interrupts, all the 'major' interrupts available for each slot. It's not improbable that the table is wrong or buggy too. Here we go, the output as requested: $PIR table at 0x2812f7c0 version 1.0 PCI interrupt router at 0:3.8 vendor 0x1106 device 0x686 PCI-only interrupts [ ] entry bus slot device 00: 00 0001 INTA 01 [ 3 4 5 7 9 10 11 1214 15] INTB 02 [ 3 4 5 7 9 10 11 1214 15] INTC 03 [ 3 4 5 7 9 10 11 1214 15] INTD 05 [ 3 4 5 7 9 10 11 1214 15] 01: 00 0007 INTA fe [14 ] INTB ff [ 15] INTC 03 [ 3 4 5 7 9 10 11 1214 15] INTD 05 [ 3 4 5 7 9 10 11 1214 15] 02: 00 0109 INTA 02 [ 3 4 5 7 9 10 11 1214 15] INTB 03 [ 3 4 5 7 9 10 11 1214 15] INTC 05 [ 3 4 5 7 9 10 11 1214 15] INTD 01 [ 3 4 5 7 9 10 11 1214 15] 03: 00 0210 INTA 03 [ 3 4 5 7 9 10 11 1214 15] INTB 05 [ 3 4 5 7 9 10 11 1214 15] INTC 01 [ 3 4 5 7 9 10 11 1214 15] INTD 02 [ 3 4 5 7 9 10 11 1214 15] 04: 00 0311 INTA 05 [ 3 4 5 7 9 10 11 1214 15] INTB 01 [ 3 4 5 7 9 10 11 1214 15] INTC 02 [ 3 4 5 7 9 10 11 1214 15] INTD 03 [ 3 4 5 7 9 10 11 1214 15] 05: 00 0012 INTA 01 [ 3 4 5 7 9 10 11 1214 15] INTB 00 [ ] INTC 00 [ ] INTD 00 [ ] Thanks Andrew On Fri, 3 Aug 2001, Mike Smith wrote: Tried the patch, interesting thing, for some reason or other its always routing the IRQ to the same IRQ as the realtek network card I have in here, and with the patch in (before nothing worked at all on the pccbb), now if the network card is in slot0 it doesnt work, and the wavelan does, if the wavelan comes first on the pcibus it doesnt work and the network card does. For some reason it always seems to be trying to share an IRQ between these 2, any reason for this? Yeah; that seems to be the way your system's interrupt routing is set up. Get http://people.freebsd.org/~msmith/pir.c, build and run it and let's look at the output. -- ... 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 -- ... 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: NewCard / pccbb
Hi Mike, ok my pci-pcmcia bridge is in slot 0, my network card is in slot 3, below are the dmesg outputs from both oldcard and newcard, Thanks Andrew Newcard dmesg: Copyright (c) 1992-2001 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 5.0-CURRENT #16: Sat Aug 4 11:09:22 SAST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VORTEXIA Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 851941527 Hz CPU: Pentium III/Pentium III Xeon/Celeron (851.94-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 125763584 (122816K bytes) avail memory = 116891648 (114152K bytes) Preloaded elf kernel kernel at 0xc046f000. Pentium Pro MTRR support enabled Using $PIR table, 6 entries at 0xc00f77c0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA100 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at 7.2 (no driver attached) pci0: serial bus, USB at 7.3 (no driver attached) pci0: serial bus, SMBus at 7.4 (no driver attached) pci0: multimedia, audio at 7.5 (no driver attached) pccbb0: TI1410 PCI-CardBus Bridge at device 9.0 on pci0 pccbb0: PCI Memory allocated: 4400 pci_cfgintr_virgin: using routable interrupt 3 pci_cfgintr: 0:9 INTA routed to irq 3 cardbus0: Cardbus bus (newcard) on pccbb0 pccard0: 16-bit PCCard bus on pccbb0 rl0: RealTek 8139 10/100BaseTX port 0xc800-0xc8ff mem 0xdf00-0xdfff irq 12 at device 11.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:50:bf:3f:bb:9d miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto orm0: Option ROM at iomem 0xc-0xcbfff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 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 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sn0: ioaddr is 0x300 sn0: test1 failed vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc1: System console on isa0 sc1: MDA 16 virtual consoles, flags=0x0 WARNING: Driver mistake: repeat make_dev(consolectl) vga1: Generic ISA VGA at port 0x3b0-0x3bb iomem 0xb-0xb7fff on isa0 unknown: PNP0303 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0700 can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging disabled IP Filter: v3.4.20 initialized. Default = pass all, Logging = enabled ad0: DMA limited to UDMA33, non-ATA66 compliant cable ad0: 19546MB FUJITSU MPG3204AT E [39714/16/63] at ata0-master UDMA33 acd0: CDROM CD-ROM 52X/AKH at ata0-slave PIO4 Mounting root from ufs:/dev/ad0s1a pccbb0: card inserted: event=0x0006, state=1411 pccard0: chip_socket_enable pccbb_pcic_socket_enable: pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] pccbb0: pccbb_power: CARD_VCC_5V and CARD_VPP_VCC [15] pccbb0: pccbb_pcic_wait_ready: status 0x6f pccbb0: card type is mem pccard0: read_cis pccbb_pcic_mem_map window 0 bus 44001000+400+bbfff000 card addr 0 pccbb_pcic_do_mem_map window 0: 8001 8001 3fff 44 (44001000+0400.1000*bbfff000) pccbb_pcic_do_mem_map window 0: 8001 8001 7fff 44 (44001000+0400.1000*bbfff000) cis mem map d46c5000 pccard0: CIS tuple chain: CISTPL_DEVICE type=null speed=null 01 03 00 00 ff CISTPL_DEVICE_A type=sram speed=ext 17 04 67 5a 08 ff unhandled CISTPL 1d 1d 05 01 67 5a 08 ff CISTPL_VERS_1 15 50 05 00 4c 75 63 65 6e 74 20 54 65 63 68 6e 6f 6c 6f 67 69 65 73 00 57 61 76 65 4c 41 4e 2f 49 45 45 45 00 56 65 72 73 69 6f 6e 20 30 31 2e 30 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff CISTPL_MANFID 20 04 56 01 02
Re: promise ultra 100 tx2 on 4.3
It seems Tim Yardley wrote: anyone have plans or already ported the ata pci/dma work in 5.0 over to 4.3 for the tx2 card? rumor has it soren is swamped... anyone else out there brave enough to take on the ata dev tree? I'll get to it, soon, is the -stable tree in code freeze now or am I totally out of touch on that :) There is even yet another Promise chip out there, I'll get that into -current first so it can get merged also... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyXXXX_r()
On Sat, Aug 04, 2001 at 12:04:02AM -0600, Wes Peters wrote: Alfred Perlstein wrote: * Alexander Litvin [EMAIL PROTECTED] [010803 09:54] wrote: Are there any plans of making gethostbyname_r() and gethostbyaddr_r() available in FreeBSD? May be somebody already has them almost ready to be commited? Or are there any considered wrong way to go? The reason I'm asking is that I actually have a local patch implementing them here (only for DNS for now). Is it good idea to put some effort to finalaze it and submit a PR? Or I'd better not waist time on that? Please complete it, let me know when you submit the PR i'll try to get it integrated. I'll be happy to take a look at it too. I did a lot of the _r routines we have now, in some cases simply documenting ones that were there, but halted when I got to gethostbyX_r and the passwd and group variants, because they were too fugly to tackle at that time. I'll get back to the remainder someday, when I have the time, unless you beat me to it. There are some gethostby_r, getnetby_r, ... etc routines in the linuxthreads port (/usr/ports/devel/linuxthreads/files). These came from the original linuxthreads package, and have no copyright on them. I never researched the copyright status of them, but I don't think they are GPL, though you might want to do further research on their history if you use them. -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Sat, Aug 04, 2001 at 02:38:23AM -0300, Rik van Riel wrote: On Fri, 3 Aug 2001, Terry Lambert wrote: This is a trivial implementation. I'm not very impressed. Personally, I'm not interested in a huge user space, Maybe not you, but I bet the database and scientific computing people will be interested in having 64 GB memory support in this simple way. All I was interested so far was more address space for a single process and more physical memory for kernel use. Both I've found in ALPHA machines and am happy with it. Go and compare prices for ALPHA and i386 systems which support more than 4G of physical memory and don't forget that you put a lot of CPU power in managing the memory with i386. In the unix world there is less reason to stuck with a single architecture as in Windows. If I need more than one process to gain use of the memory I would consider using a second machine. Fully populating both the transmit and receive windows for 1M connections is 32G of RAM, right there... and it better be kernel RAM, or you're screwed. Well, you _could_ store this memory in files, which get mapped and unmapped by the same code the filesystem code uses to access file data in non-kernel-mapped RAM. Consider that you don't need such evilness on existing Machines such as ALPHA. Well AFAIK FreeBSD currently doesn't support ALPHAs with that amount of memory very well - but this can be considered more as a bug than a missing feature and can be fixed. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyXXXX_r()
hi, there! On Sat, 4 Aug 2001, Richard Seaman, Jr. wrote: There are some gethostby_r, getnetby_r, ... etc routines in the linuxthreads port (/usr/ports/devel/linuxthreads/files). These came from the original linuxthreads package, and have no copyright on them. I never researched the copyright status of them, but I don't think they are GPL, though you might want to do further research on their history if you use them. gethostbyxxx_r can be taken from bind 8 /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fwd: Sun Grid Engine 5.2.3 Available. Now Open Source
I am writing a document about porting SGE. Once that's done, you guys can hack! -Ron --- Wes Peters [EMAIL PROTECTED] wrote: Ron Chen wrote: It's weekend, it's time for hacking. I downloaded the SGE 5.3 source code. Played with it for a while, the 50+MB of source does have some goodies, it is not as simple as NQS: 1. Master fail-over: you can set up several shadow masters in one cluster. When the qmaster fails, one of the shadow masters will take over. 2. Project base fairshare: you can have project A using 30% of your cluster resource, project B using the other 30%, and project C using the rest. 3. User base fairshare: same, but users instead of projects. 4. deadline scheduling 5. distributed make: qmake 6. security: krb, dce, ssl, etc 7. NT execution engine 8. Java interface 9. COBRA interface 10. Perl interface 11. preemptive seheduling 12. job scheduler: calender based job scheduler 13. Parallel interface 14. checkpointing interface I am still hacking. There are more interesting features that are in the source. Oooh, sounds good. Will we have a FreeBSD port kit when you're done? qmake sounds quite interesting. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: linking WITH -lstdc++ makes executeables smaller?
On Fri, Aug 03, 2001 at 02:12:25PM +0200, Bernd Walter wrote: I used a library which also needed -lstdc++. Now that I did not need them any more I removed them and was surprised that the resulting FreeBSD binary actually got bigger! On NetBSD the binary is slightly smaller as expected. Is there any logical explanation for this phaenomen? Forget `ls'. Show the output from `size' and `file'. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Finding filesizes in C++ for files greater than 4gb
On Wed, Aug 01, 2001 at 10:29:39PM -0500, Jim Bryant wrote: Kent, my point is that the manual page should specify this. I think that's the point the original poster was trying to make once he was told. Well, either of you two submit a diff to the manpage and I'll commit it. It really isn't that hard to add a sentence or two to a man page you don't think is clear. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: linking WITH -lstdc++ makes executeables smaller?
On Sat, Aug 04, 2001 at 02:58:34PM -0700, David O'Brien wrote: On Fri, Aug 03, 2001 at 02:12:25PM +0200, Bernd Walter wrote: I used a library which also needed -lstdc++. Now that I did not need them any more I removed them and was surprised that the resulting FreeBSD binary actually got bigger! On NetBSD the binary is slightly smaller as expected. Is there any logical explanation for this phaenomen? Forget `ls'. Show the output from `size' and `file'. With -lstdc++: ticso@cicely8 size cbckd textdata bss dec hex filename 4528435725088 53944d2b8 cbckd ticso@cicely8 file cbckd cbckd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped Without -lstdc++: ticso@cicely8 size cbckd textdata bss dec hex filename 6241442085304 71926 118f6 cbckd ticso@cicely8 file cbckd cbckd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped Same on alpha: With -lstdc++: ticso@cicely9 size cbckd textdata bss dec hex filename 6126858769280 76424 12a88 cbckd ticso@cicely9 file cbckd cbckd: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped Without -lstdc++: ticso@cicely9 size cbckd textdata bss dec hex filename 9117780249712 108913 1a971 cbckd ticso@cicely9 file cbckd cbckd: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyXXXX_r()
| Are there any plans of making gethostbyname_r() and gethostbyaddr_r() | available in FreeBSD? May be somebody already has them almost ready | to be commited? Or are there any considered wrong way to go? | | The reason I'm asking is that I actually have a local patch implementing | them here (only for DNS for now). Is it good idea to put some effort to | finalaze it and submit a PR? Or I'd better not waist time on that? | | Please complete it, let me know when you submit the PR i'll try | to get it integrated. I believe BIND9 has a completely thread-safe libresolv now. -Dan -- There is nothing wrong with Southern California that a rise in the ocean level wouldn't cure. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
At 10:57 PM -0700 8/3/01, Terry Lambert wrote: Rik van Riel wrote: This is a trivial implementation. I'm not very impressed. Personally, I'm not interested in a huge user space, Maybe not you, but I bet the database and scientific computing people will be interested in having 64 GB memory support in this simple way. You mean 4G, of course, since the process address space remains limites to 32 bits... For what it's worth, we ran into some similar problem with a mainframe operating system I used to work on. We ended up creating something we called named address spaces for some user processes. Basically, it was just a quick swapping mechanism. In the context of IA-32, you could maybe have the first gigabyte of space as fixed, and the remaining three gigabytes as multiple (named) address spaces. Each named-address space could be between 1 and 3 gig, and you could have several of them. You'd make a system call to switch from one named-address space to a different one. It would not be practical for all user processes, but it would be useful for some of them. One ironic thing about this named-address space idea was that we had talked about it off-and-on for a few years, but we didn't actually *do* it until just as we were getting to the point where we could switch from 24-bit addressing to 31-bit addressing on our OS. We hit something where we just had to have the extra space right away (quicker than we could implement 31-bit addressing in userland processes). Once we decided to do this named-address space idea, it turned out it wasn't all that hard to implement. However, the current situation isn't quite the same as that one, and in the land of freebsd I'd think it would be better to concentrate on good support for the chips which do support 64-bit addresssing. I just thought it was worth pointing out that a process might well be limited to 32-bit addressing, and yet not be limited to 4-gig of usable memory space. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
