Current kernel can't execute gzip'ed ELF executables!
Hi All, If seems that 4.0-current (make world kernel as of yesterday) can't execute ELF gzip'ed binaries with following symptoms: sh-2.02# cp /bin/sh ./ sh-2.02# gzip sh sh-2.02# ls -l total 177 -rw-r--r-- 1 root wheel 43 Apr 17 09:58 Report -r-xr-xr-x 1 root wheel 170093 Apr 17 09:58 sh.gz sh-2.02# mv sh.gz sh sh-2.02# ls -l total 177 -rw-r--r-- 1 root wheel 253 Apr 17 09:58 Report -r-xr-xr-x 1 root wheel 170093 Apr 17 09:58 sh sh-2.02# ./sh sh: ./sh: cannot execute binary file In dmesg I have: Output=32 Inflate_error=1 igz.error=8 error2=0 where=180 This misbehavior verified on two machines. Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
Chris Piazza wrote: On 17-Apr-99 Brian Feldman wrote: Both sound drivers are broken with the new-bus code. My SB16, in the old driver, now gets recognized but sbxvi is never looked for. pcm0, the new driver, never initializes with the new code :( device pcm0 at isa? port? tty irq 5 drq 1 flags 0x16 The pcm0 sounddriver works for me. In fact, the only problem I had with new bus was it is now pcm0 instead of pcm1 ;-). es0: AudioPCI ES1370 at device 9.0 on pci0 pcm0: using I/O space register mapping at 0xd800 es0: interrupting at irq 4 device pcm0 On two different systems it works for me using pcm0.. This is an ESS clone card: Probing for PnP devices: CSN 1 Vendor ID: ESS1868 [0x68187316] Serial 0x Comp ID: PNPb02f [0x2fb0 d041] ESS1868 (rev 11) pcm1 (ESS1868 ESS1868 sn 0x) at 0x220-0x22f irq 5 drq 1 on isa This is an on-board Crystal SB-like PnP device: Probing for PnP devices: CSN 1 Vendor ID: CSC0b36 [0x360b630e] Serial 0x Comp ID: @@@ [0x ] mss_attach CS42361 at 0x530 irq 5 dma 1:0 flags 0x10 pcm1 (CS423x/Yamaha/AD1816 CS4236 sn 0x) at 0x530-0x537 irq 5 drq 1 fl ags 0x10 on isa For what it's worth, PnP has for the most part not been changed under new-bus and is using the old mechanisms. The only significant risk is that the attach code doesn't like what I've done with the emulation of isa_device-id_id for unit numbers. I'm sorry, you're going to need to have a bit of a look around and turning on or inserting some debug code to see what's happening. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
successfull SMP / current on duel P-III box. Yahhhh. I've successfully brought -current up in SMP on a duel P-III box.
I have one problem, though. During the kernel boot: isa_dmainit(2, 1024) failed And, of course, any access to something that needs isa dma (e.g. floppy) panics. It's a large-memory machine (1G). I was under the impression that this was supposed to be fixed in the vm/vm_page.c commit: vm/vm_page.c revision 1.128 date: 1999/03/19 05:21:03; author: alc; state: Exp; lines: +8 -2 Construct the free queue(s) in descending order (by physical address) so that the first 16MB of physical memory is allocated last rather than first. On large-memory machines, this avoids the exhaustion of low physical memory before isa_dmainit has run. Anyone have any ideas? -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP!!!! Important instructions for -current users!
According to David E . O'Brien: Is this a change? For pre-POST_NEWBUS When wireing down SCSI disks, the config file has both a da0 device (to get the generic SCSI disk code) and disk (to wire it down). I've never defined da* twice in oldconfig-style config. You're not supposed to do that I think. In LINT, there is only one definition. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP!!!! Important instructions for -current users!
According to Peter Wemm: As a special warning: The APIC_IO interrupt management could be a little wonky on systems that require the special mptable fixups. If you have warnings about broken mptables, or additional interrupts being wired, hold back until it's been checked. Seems to work fine on my 2x PPro/200, Intel Providence MB, 64 MB, SMP. I've built but not yet tested the new fxp.ko module though. Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #15: Sat Apr 17 12:33:10 CEST 1999 robe...@tara:/src/src/sys/compile/TARA_SMP Timecounter i8254 frequency 1193182 Hz CPU: Pentium Pro (686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping=9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 67108864 (65536K bytes) avail memory = 62119936 (60664K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc0307000. Preloaded elf module nfs.ko at 0xc030709c. Preloaded elf module linux.ko at 0xc0307138. Preloaded elf module green_saver.ko at 0xc03071d8. Preloaded elf module procfs.ko at 0xc030727c. Pentium Pro MTRR support enabled, default memory type is uncacheable npx0: math processor on motherboard npx0: INT 16 interface pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Intel 82440FX (Natoma) PCI and memory controller at device 0.0 on pci0 fxp0: Intel EtherExpress Pro 10/100B Ethernet at device 6.0 on pci0 fxp0: interrupting at irq 18 fxp0: Ethernet address 00:a0:c9:49:5a:ef isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 uhci0: Intel 82371SB (PIIX3) USB Host Controller at device 7.2 on pci0 uhci0: interrupting at irq 10 usb0: Intel 82371SB (PIIX3) USB Host Controller on uhci0 uhub0 at usb0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ahc0: Adaptec aic7880 Ultra SCSI adapter at device 9.0 on pci0 ahc0: interrupting at irq 17 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs fdc0: interrupting at irq 6 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive at fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60 on isa0 atkbd0: AT Keyboard on atkbdc0 atkbd0: interrupting at irq 1 psm0: PS/2 Mouse on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 psm0: interrupting at irq 12 vga0: Generic ISA VGA on isa0 sc0: System console on isa0 sc0: VGA color 10 virtual consoles, flags=0x0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: interrupting at irq 4 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: interrupting at irq 3 ppc0 at port 0x378 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppc0: interrupting at irq 7 APIC_IO: routing 8254 via 8259 on pin 0 Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! da0 at ahc0 bus 0 target 6 lun 0 da0: QUANTUM VIKING II 4.5WLS 4110 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Consistent errors making buildworld
On Fri, Apr 16, 1999 at 09:45:29PM -0400, Luoqi Chen wrote: Do you have an empty /usr/X11R6/include? Ah, yes I do. Thanks for that :) The Makefile assumes you have the header files if the directory /usr/X11R6/include is present and tries to build the X version of doscmd. This assumption may not be true though. I'll change the Makefile to check for /usr/X11R6/include/X11/X.h instead. By the way, X headers only take 4M disk space, you might want to consider installing them. Hav done. I'm a little confused as to why they weren't there already, actually, as I was certain I had compiled and installed XFree86 from the port... Ah well :) Whatever. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
Hey!
I've add UNICODE support to the Joliet patch.
It contains few charsets now, but to add other charsets is very easy.
Currently, iso8859-1 and euc-jp is included.
Mixture of Joliet/RockRidge Extension is also available, however untested.
How to use:
1. Pick up the patch from the URL.
http://triaez.kaisei.org/~mzaki/joliet/joliet.unicode.patch.gz
It contains huge table which provides conversion
from unicode character to euc-jp, so that the gzip'ed size is 36k.
So I give up to attach the patch to this mail.
2. Apply the patch to the source tree.
#cd /usr/src
#zcat /tmp/joliet.unicode.patch.gz|patch -p1
3. Make and install new mount_cd9660(8)
#cd /usr/src/sbin/mount_cd9660
#make; make install
4. Reconfig and reinstall your kernel and reboot.
5. Tell your kernel the charset you prefer.
#sysctl -w vfs.charset=iso8859-1
Currently, only 'none', 'iso8859-1' and 'euc-jp' is available.
none : The filenames are assumed to have 8bit character ONLY.
This is not recommended.
iso8859-1 : 8bit characters.
All 16bit characters (include russian, greek, chinese, etc.)
are replaced with numerical ('0'-'9').
euc-jp: Japanese characters.
This corresponds to the userland locale 'ja_JP.EUC'.
All characters unable to express are
replaced with numerical ('0'-'9').
How to use other charsets:
1. Look at the /sys/isofs.
charset and encoding directories are added.
For Europians, to make new charset/*.c is sufficient.
For Asians (Chinese, Korean, Japanese and so on),
to make new encoding/*.c is also required.
charset/*.c should contains Code Conversion Table.
Currently, only 'UNICODE - local charset' conversion is needed.
(in future, reverse conversion may needed for msdosfs and ntfs.)
encoding/*.c should contains multibyte encoding routines.
These are subset of rune(3) at /usr/src/lib/libc/locale/
At least, MSKanji is required for ja_JP.SJIS, BIG5 for zh_TW.BIG5,
also UTF-8 for all UNICODE locale.
2. Add new file entries to /sys/conf/files
3. Reconfig and reinstall your kernel and reboot.
More documents are now scheduled in some days at the URL
http://triaez.kaisei.org/~mzaki/joliet/
--
Motomichi Matsuzaki mz...@e-mail.ne.jp
Dept. of Biological Science, Fuculty of Sciences, Univ. of Tokyo, Japan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Current kernel can't execute gzip'ed ELF executables!
On Sat, 17 Apr 1999, Maxim Sobolev wrote: If seems that 4.0-current (make world kernel as of yesterday) can't execute ELF gzip'ed binaries with following symptoms: I enquired about this a few months ago (but didn't hear anything in reply). As far as I've been able to work out, the facility was never intended to work with ELF executables because no-one's updated it from using a.out executables. It's a shame since that can be quite useful on machines where disk space is tight, but I have no idea how hard it will be to get working again. Kris - The Feynman problem-solving algorithm: 1. Write down the problem 2. Think real hard 3. Write down the solution To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Current kernel can't execute gzip'ed ELF executables!
Maxim Sobolev sobo...@altavista.net writes: If seems that 4.0-current (make world kernel as of yesterday) can't execute ELF gzip'ed binaries with following symptoms: It never could, AFAIK. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Current kernel can't execute gzip'ed ELF executables!
It's a shame since that can be quite useful on machines where disk space is tight, but I have no idea how hard it will be to get working again. Use gzexe - the old fashioned way of doing things. If anyone does actually want it fixed, on a minimum, man send-pr .. I don't see anything related posted there right now. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
Chris Piazza wrote: On 17-Apr-99 Brian Feldman wrote: Both sound drivers are broken with the new-bus code. My SB16, in the old driver, now gets recognized but sbxvi is never looked for. pcm0, the new driver, never initializes with the new code :( device pcm0 at isa? port? tty irq 5 drq 1 flags 0x16 The pcm0 sounddriver works for me. In fact, the only problem I had with new bus was it is now pcm0 instead of pcm1 ;-). es0: AudioPCI ES1370 at device 9.0 on pci0 pcm0: using I/O space register mapping at 0xd800 es0: interrupting at irq 4 device pcm0 On two different systems it works for me using pcm0.. This is an ESS clone card: Probing for PnP devices: CSN 1 Vendor ID: ESS1868 [0x68187316] Serial 0x Comp ID: PNPb02f [0x2f b0 d041] ESS1868 (rev 11) pcm1 (ESS1868 ESS1868 sn 0x) at 0x220-0x22f irq 5 drq 1 on isa This is an on-board Crystal SB-like PnP device: Probing for PnP devices: CSN 1 Vendor ID: CSC0b36 [0x360b630e] Serial 0x Comp ID: @@@ [0x00 00 ] mss_attach CS42361 at 0x530 irq 5 dma 1:0 flags 0x10 pcm1 (CS423x/Yamaha/AD1816 CS4236 sn 0x) at 0x530-0x537 irq 5 drq 1 fl ags 0x10 on isa For what it's worth, PnP has for the most part not been changed under new-bus and is using the old mechanisms. The only significant risk is that the attach code doesn't like what I've done with the emulation of isa_device-id_id for unit numbers. I thought PnP was not even using new-bus yet?! I haven't used PnP in a long time, but the pcm driver is broke for me too. I have used the following successfully with just the plain isa0 for quite some time.. device pcm0 at isa? port? tty irq 5 drq 1 flags 0x10 I'm sorry, you're going to need to have a bit of a look around and turning on or inserting some debug code to see what's happening. Where should I start? It doesn't print out anything upon boot.. Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Lastest ATA/ATAPI driver boots with kernel.debug only.
I've found that I need to disable my secondary IDE controller with the version 5 and 6 of the new ATAPI drivers. It's probably something to do with Ultra DMA support as I have an Ultra DMA 6.48 GB IBM drive on my IDE controller 0 (master) and a Ultra DMA Mitsubishi 32 spin CD-ROM drive as slave on my second IDE controller. By the way, the IBM 6.48 GB drive is working fine in UDMA2... Lovely. Too bad my drive cant do tagged queueing. There must be a problem with the UDMA CDROMs as with my second IDE controller enabled, I never boot it just never gets to the changing root device to bit. dmesg attached with second controller disabled also old boot messages attached for ATAPI driver version 4 when I could have the controller enabled. Natty Rebel wrote: Hello Soren and other -current users, I've used your new ATA/ATAPI driver flawlessly through the 4th version. I was not able to get past the 'changing root device to wd0s1a' message with version 5, so I just went back to the wd driver. Last nigh I tried version 6 and ran into the same problem. I finally decided to do a little investigating. First I found that I could do a 'ctrl-alt-del' to reboot. I then decided to install the debug kernel doing a 'make install.debug' in my kernel build directory. Lo! and behold! to my surprise my box booted flawlessly. The questions I have are 1) Why did the debug kernel boot and not the kernel without debug symbols? 2) What procedures/tools should I use to investigate this further? Of course any help/pointers are appreciated ... Thanxs. #;^) i'khala -- natty rebel harder than the rest ... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Fri Apr 16 23:03:56 CST 1999 m...@localhost:/usr/src/sys/compile/MATTE Timecounter i8254 frequency 1193182 Hz CPU: Celeron (463.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x660 Stepping=0 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 67108864 (65536K bytes) config pnp 1 0 bios enable avail memory = 62177280 (60720K bytes) Preloaded elf kernel kernel at 0xc02eb000. Preloaded userconfig_script /boot/kernel.conf at 0xc02eb09c. Preloaded elf module splash_bmp.ko at 0xc02eb0ec. Pentium Pro MTRR support enabled, default memory type is uncacheable module_register_init: module_register(splash_bmp, c02e760c, 0) error 2 Probing for devices on PCI bus 0: chip0: Intel 82443BX host to PCI bridge rev 0x03 on pci0.0.0 chip1: Intel 82443BX host to AGP bridge rev 0x03 on pci0.1.0 chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.7.0 ata-pci0: Intel PIIX4 IDE controller rev 0x01 on pci0.7.1 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 intpm0: Intel 82371AB Power management controller rev 0x02 on pci0.7.3 intpm0: I/O mapped 5000 ALLOCED IRQ 0 intr IRQ 9 enabled revision 0 intsmb0: Intel PIIX4 SMBUS Interface smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped 4000 vga0: Tseng Labs ET6000 graphics accelerator rev 0x30 int a irq 255 on pci0.11.0 ncr0: ncr 53c810 fast10 scsi rev 0x02 int a irq 11 on pci0.13.0 Probing for devices on PCI bus 1: Probing for PnP devices: CSN 1 Vendor ID: CTL0024 [0x24008c0e] Serial 0x100a1ec0 Comp ID: PNP0600 [0x0006d041] Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 12 virtual consoles, flags=0x0 ed0 at 0x300-0x31f irq 9 on isa ed0: address 00:00:e8:20:33:e8, type NE2000 (16 bit) atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc0 not found vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface apm0 on isa apm: found APM BIOS version 1.2 joy0 at 0x201 on isa joy0: joystick sb0 at 0x220 irq 5 drq 1 on isa snd0: SoundBlaster 16 4.13 sbxvi0 at drq 5 on isa snd0: SoundBlaster 16 4.13 sbmidi0
Re: Lastest ATA/ATAPI driver boots with kernel.debug only.
Matthew Thyer wrote: I've found that I need to disable my secondary IDE controller with the version 5 and 6 of the new ATAPI drivers. Just as a thought.. Is your kernel.debug leftover from an earlier build? Perhaps that's why it works and the current ones do not... Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
Hey! I've add UNICODE support to the Joliet patch. It contains few charsets now, but to add other charsets is very easy. Currently, iso8859-1 and euc-jp is included. Mixture of Joliet/RockRidge Extension is also available, however untested. Cool! I think NTFS and VFATFS could use this code too, is it possible to move the code to place like libkern/unicode? -- Motomichi Matsuzaki mz...@e-mail.ne.jp Dept. of Biological Science, Fuculty of Sciences, Univ. of Tokyo, Japan -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
boot kernel panic with the latest new-bus
Hi, I'm getting kernel panics during boot with the latest kernel built today using new-bus. This broke both my custom kernel and today's GENERIC (with all the needed updates) on my machine. Booting with the old kernel works fine.
Re: HEADS UP!!!! Important instructions for -current users!
As of a few minutes ago, a minimal set of changes to bring the so-called 'new-bus' functionality to the i386 kernel in -current. Is this formal decision of core team ? I feel a huge despair, as a member of newconfig project -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: boot kernel panic with the latest new-bus
Jose Gabriel Marcelino wrote: Hi, I'm getting kernel panics during boot with the latest kernel built today using new-bus. This broke both my custom kernel and today's GENERIC (with all the needed updates) on my machine. Booting with the old kernel works fine. From what I can see (and copied from paper) this is what happens: [..] ncr0: ncr 53c810 fast10 scsi at device 11.0 on pci0 ncr0: interrupting at irq 10 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f3ac1 [..] This sounds a bit like it might be fixed by Bruce: RCS file: /home/ncvs/src/sys/i386/isa/isa_compat.c,v revision 1.2 date: 1999/04/17 09:56:35; author: bde; state: Exp; lines: +2 -2 Allocate space for struct isa_device's, not for pointers thereto. This fixes memory corruption that caused calls to address 0 here. Can you check if you have this update? Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ftp hangs on -current
How many of you are using RealTek network cards ? They are crap in my experience (under any OS). Bret Ford wrote: Wednesday, April 14, 1999, 10:25:11 AM, you wrote: I am getting problems similar to those outlined above. I don't run natd, either, but I do have a firewall enabled. (open rule) I've had to 'put' files rather than 'get' them, since my last build/installworld. (Yesterday's -current source) TP I am not running any firewall but my last cvsup which is also current was the same day as yours. i'm still experiencing this strange problem too. developers, where are you? :) Let's continue this thread in capital letters. We might attract some attention! ;-) I CAN'T FTP OUT FROM MY -CURRENT SYSTEM. I CAN FTP IN. SOMETHING IS PROBABLY WRONG. I CAN LIST DIRECTORIES, USUALLY. 'GET' COMMANDS HANG. I AM RUNNING -CURRENT FROM MORNING APR 13. THANKS! BRET FORD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: boot kernel panic with the latest new-bus
[..] This sounds a bit like it might be fixed by Bruce: RCS file: /home/ncvs/src/sys/i386/isa/isa_compat.c,v revision 1.2 date: 1999/04/17 09:56:35; author: bde; state: Exp; lines: +2 -2 Can you check if you have this update? I have just checked it and I do have it, so that's not the problem :-( Thanks anyway! Regards, Gabriel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP!!!! Important instructions for -current users!
In message 199904170528.oaa05...@chandra.eatell.msr.prug.or.jp, NAKAGAWA Yoshihisa writes: As of a few minutes ago, a minimal set of changes to bring the so-called 'new-bus' functionality to the i386 kernel in -current. Is this formal decision of core team ? I feel a huge despair, as a member of newconfig project Yes, this was a decision by the core team. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
On Sat, 17 Apr 1999, Peter Wemm wrote: Chris Piazza wrote: On 17-Apr-99 Brian Feldman wrote: Both sound drivers are broken with the new-bus code. My SB16, in the old driver, now gets recognized but sbxvi is never looked for. pcm0, the new driver, never initializes with the new code :( device pcm0 at isa? port? tty irq 5 drq 1 flags 0x16 The pcm0 sounddriver works for me. In fact, the only problem I had with new bus was it is now pcm0 instead of pcm1 ;-). es0: AudioPCI ES1370 at device 9.0 on pci0 pcm0: using I/O space register mapping at 0xd800 es0: interrupting at irq 4 device pcm0 On two different systems it works for me using pcm0.. This is an ESS clone card: Probing for PnP devices: CSN 1 Vendor ID: ESS1868 [0x68187316] Serial 0x Comp ID: PNPb02f [0x2fb0 d041] ESS1868 (rev 11) pcm1 (ESS1868 ESS1868 sn 0x) at 0x220-0x22f irq 5 drq 1 on isa This is an on-board Crystal SB-like PnP device: Probing for PnP devices: CSN 1 Vendor ID: CSC0b36 [0x360b630e] Serial 0x Comp ID: @@@ [0x ] mss_attach CS42361 at 0x530 irq 5 dma 1:0 flags 0x10 pcm1 (CS423x/Yamaha/AD1816 CS4236 sn 0x) at 0x530-0x537 irq 5 drq 1 fl ags 0x10 on isa For what it's worth, PnP has for the most part not been changed under new-bus and is using the old mechanisms. The only significant risk is that the attach code doesn't like what I've done with the emulation of isa_device-id_id for unit numbers. I'm sorry, you're going to need to have a bit of a look around and turning on or inserting some debug code to see what's happening. Cheers, -Peter Here's what's going on with the pcm code. I've got an on-board audio device that should probably eventually be supported, is PnP and detected, but not recognized by the pcm driver. However, my SB16 ALSO fails to be attached. My SB16 is a nice pre-PnP one, which used to work fine with either audio driver. I'll paste my current config and dmesg. # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # For more information read the handbook part System Administration - # Configuring the FreeBSD Kernel - The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # URL:http://www.FreeBSD.ORG/ # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.102 1998/01/11 02:16:38 jkh Exp $ machine i386 cpu I586_CPU ident CUSTOM maxusers128 makeoptions DEBUG=-g options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options CD9660#ISO 9660 Filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG#boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options NO_F00F_HACK options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD #enable xparent proxy support options IPDIVERT options IPSTEALTH options DUMMYNET options DDB options DDB_UNATTENDED options VM86 options SOFTUPDATES options PQ_HUGECACHE # color for 1024k cache options ICMP_BANDLIM options MSGBUF_SIZE=16384 options VESA options INVARIANTS options INVARIANT_SUPPORT options CLK_USE_TSC_CALIBRATION #optionsICMP_BANDLIM_SILENT #optionsCPU_WT_ALLOC #optionsNO_MEMORY_HOLE config kernel root on wd0 controller pci0at nexus? controller isa0at nexus? controller pnp0 # Luigi's snd code. # You may also wish to enable the pnp controller with this, for pnp # sound cards. # device pcm0 device pcm1 at isa? port? tty irq 5 drq 1 flags 0x16 #controller snd0 #device sb0 at isa? port 0x220 irq 5 drq 1 #device sbxvi0 at isa? drq 6 #device sbmidi0 at isa? port 0x330 #device opl0 at isa? port 0x388 device joy0at isa? port IO_GAME #controller fdc0at isa? port IO_FD1 bio irq 6 drq 2 #disk fd0 at fdc0 drive 0 #disk fd1 at fdc0 drive 1 # for a PCI only system (most modern machines) #controller ata0 #device atadisk0# ATA disks #device
Re: cvsup
Whats the posibility of having another process for the display ? Naturally this would only be forked if the DISPLAY env is set and the user didnt refuse GUI mode. John Polstra wrote: Thomas Schuerger wrote: cvsup is mostly based on disk (and network) I/O, so there shouldn't be a problem with properly updating the GUI. Someone said it is done in a separate process, so I still wonder why the GUI is updated so slowly on my PII/450. Not a separate process -- a separate thread. It uses user-level threads. If the process blocks in a disk I/O call, all threads stop until the call completes. That's just the way Unix works. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: boot kernel panic with the latest new-bus
On Sat, 17 Apr 1999, Jose Gabriel J Marcelino wrote: [..] This sounds a bit like it might be fixed by Bruce: RCS file: /home/ncvs/src/sys/i386/isa/isa_compat.c,v revision 1.2 date: 1999/04/17 09:56:35; author: bde; state: Exp; lines: +2 -2 Can you check if you have this update? I have just checked it and I do have it, so that's not the problem :-( Thanks anyway! I think we aren't picking up the PCI-ISA bridge chip which means that the isa bus didn't get probed. Could you do a verbose boot (boot -v) of your *old* kernel and post the resulting dmesg. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
On Sat, 17 Apr 1999, Brian Feldman wrote: On Sat, 17 Apr 1999, Peter Wemm wrote: Chris Piazza wrote: On 17-Apr-99 Brian Feldman wrote: Both sound drivers are broken with the new-bus code. My SB16, in the old driver, now gets recognized but sbxvi is never looked for. pcm0, the new driver, never initializes with the new code :( device pcm0 at isa? port? tty irq 5 drq 1 flags 0x16 [bunch of dmesg delete] [here from Peter] For what it's worth, PnP has for the most part not been changed under new-bus and is using the old mechanisms. The only significant risk is that the attach code doesn't like what I've done with the emulation of isa_device-id_id for unit numbers. I'm sorry, you're going to need to have a bit of a look around and turning on or inserting some debug code to see what's happening. Here's what's going on with the pcm code. I've got an on-board audio device that should probably eventually be supported, is PnP and detected, but not recognized by the pcm driver. However, my SB16 ALSO fails to be attached. My SB16 is a nice pre-PnP one, which used to work fine with either audio driver. I'll paste my current config and dmesg. FWIW, using a 2 hour old kernel, my Turtle Beach Malibu PCI PnP card works just fine: [from my config file] device pcm0 at isa? port ? tty irq 15 drq 1 [from my dmesg] Probing for PnP devices: Trying Read_Port at 203 CSN 1 Vendor ID: CSC7537 [0x3775630e] Serial 0x Comp ID: @@@ [0x ] PnP: override config for CSN 1 LDN 0 vend_id 0x3775630e port 0x 0x 0x 0x irq 0:0 drq 4:4 en 0 Called nullpnp_probe with tag 0x0001, type 0x3775630e port 0x0534 0x 0x0220 0x irq 15:0 drq 1:0 en 1 port 0x0534 0x 0x0220 0x irq 15:0 drq 1:0 en 1 mss_attach CS42371 at 0x530 irq 15 dma 1:0 flags 0x10 pcm1 (CS423x/Yamaha/AD1816 CS4237 sn 0x) at 0x530-0x537 irq 15 drq 1 f lags 0x10 on isa Notice that the line beginning port shows twice, which is an odditity. I use a line in my kernel.conf of: pnp 1 0 os enable port0 0x534 port2 0x220 irq0 15 drq0 1 drq1 0 I'm not saying Brian doesn't have a real problem, but I *am* saying that not all PCI PnP sound is broken. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
Brian Feldman wrote:
On Sat, 17 Apr 1999, Peter Wemm wrote:
Chris Piazza wrote:
On 17-Apr-99 Brian Feldman wrote:
Both sound drivers are broken with the new-bus code. My SB16, in the ol
d
driver, now gets recognized but sbxvi is never looked for. pcm0, the ne
w
driver, never initializes with the new code :(
device pcm0 at isa? port? tty irq 5 drq 1 flags 0x16
The pcm0 sounddriver works for me. In fact, the only problem I had with
new
bus was it is now pcm0 instead of pcm1 ;-).
es0: AudioPCI ES1370 at device 9.0 on pci0
pcm0: using I/O space register mapping at 0xd800
es0: interrupting at irq 4
device pcm0
On two different systems it works for me using pcm0..
Here's what's going on with the pcm code. I've got an on-board audio device
that should probably eventually be supported, is PnP and detected, but
not recognized by the pcm driver. However, my SB16 ALSO fails to be attached.
My SB16 is a nice pre-PnP one, which used to work fine with either audio
driver. I'll paste my current config and dmesg.
[..]
# Luigi's snd code.
# You may also wish to enable the pnp controller with this, for pnp
# sound cards.
#
device pcm0
device pcm1 at isa? port? tty irq 5 drq 1 flags 0x16
[..]
Hmm, you might like to try this patch and see what happens, there is
a missing old driver wrapper for the pcm stuff. As a result, it's not
getting run from the isa probe. Regarding the other driver, I'm not
sure what's going on there as the hooks appear to be present.
Index: i386/isa/isa_compat.h
===
RCS file: /home/ncvs/src/sys/i386/isa/isa_compat.h,v
retrieving revision 1.1
diff -u -r1.1 isa_compat.h
--- isa_compat.h1999/04/16 21:22:23 1.1
+++ isa_compat.h1999/04/17 17:30:34
@@ -49,6 +49,7 @@
#include ze.h
#include zp.h
#include oltr.h
+#include pcm.h
#include pas.h
#include sb.h
#include sbxvi.h
@@ -117,6 +118,7 @@
extern struct isa_driver zedriver;
extern struct isa_driver zpdriver;
extern struct isa_driver oltrdriver;
+extern struct isa_driver pcmdriver;
extern struct isa_driver pasdriver;
extern struct isa_driver sbdriver;
extern struct isa_driver sbxvidriver;
@@ -320,6 +322,9 @@
#if NOLTR 0
{ DRIVER_TYPE_MISC, oltrdriver },
+#endif
+#if NPCM 0
+ { DRIVER_TYPE_MISC, pcmdriver },
#endif
#if NPAS 0
{ DRIVER_TYPE_MISC, pasdriver },
Cheers,
-Peter
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP!!!! Important instructions for -current users!
Is this formal decision of core team ? I feel a huge despair, as a member of newconfig project This was a core team decision, but I really do hope we can still figure out some way of working together on a final hybrid of the best ideas from both projects since this honestly wasn't done with the intention of making the newconfig people unhappy, please believe me. This is simply one of those unfortunate situations where two groups of developers have worked in relative isolation from one another and come up with more or less the same thing, the difference with new-bus being that we were working just that much more closely with Doug Rabson (and the others helping him) and had already used the new-bus stuff for FreeBSD/alpha. The core team did not make this decision lightly and there was considerable debate over it until we finally made the decision to take the clearest choice we could see before us and simply synchronize the FreeBSD/alpha and FreeBSD/x86 code bases. I also have to say that this has pointed out, once again, that communication is really lacking between the various groups, especially in situations where a language barrier exists. Most of us didn't even know about the newconfig project until comparatively recently, and I didn't even really know about it until I saw you guys submit a paper for the FREENIX track at USENIX. Doug's new-bus stuff, on the other hand, was a well known factor for at least a year and, as I noted, had already made it to the Alpha platform, getting it to the x86 simply being a project which was delayed by many various factors. It would, in fact, probably have gone into FreeBSD 6 months ago if everyone involved had simply had a bit more free time. However this situation came about, the core team also ultimately had to make a decision one way or another and no matter *which* alternative we picked, somebody was going to be the loser so it wasn't even as if we had that many good alternatives. The discussions on merging the two efforts really didn't seem to be going anywhere and the more we watched the two groups talk the more it seemed like they simply weren't going to converge on their thinking on this. I don't really like the word loser very much, however, and would much rather that everyone focus instead on the best route forward from here since we've made the decision, for better or for worse, and need to figure out some way for everyone's best ideas to still win in some way. With that in mind, I would be more than happy to take you and all the other newconfig project people out to dinner at the upcoming USENIX conference, perhaps with Satoshi serving as translator, along with Doug Rabson and any other new-bus people who'd like to come. Rather than sinking into despair, we really need to start discussing how to fix the communications problems we've had in the past since that will be addressing the *cause* rather than the symptoms of our current problem. I also truly feel that much can still be salvaged in a number of different ways if we're willing to put the well-being of FreeBSD first and foremost in our minds, and I'm more than happy to do anything I can to make that happen. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
On Sat, 17 Apr 1999, Peter Wemm wrote: For what it's worth, PnP has for the most part not been changed under new-bus and is using the old mechanisms. The only significant risk is that the attach code doesn't like what I've done with the emulation of isa_device-id_id for unit numbers. Well, something appears to have changed. My internal PnP modem is no longer detected. I just checked sio.c, and it appears as if the PnP id is still there. I've got: controller pnp0 device sio0at isa? port IO_COM1 flags 0x10 tty irq 4 in my config file. Previously dmesg|grep sio would return: sio1: irq maps: 0x1 0x9 0x1 0x1 sio1: type 16550A sio1 (siopnp Cardinal MVP288IV sn 0x00416288) at 0x3e8-0x3ef irq 3 on isa sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A apm: found APM BIOS version 1.2 Now it returns: apm: found APM BIOS version 1.2 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: interrupting at irq 4 I'm sorry, you're going to need to have a bit of a look around and turning on or inserting some debug code to see what's happening. Cheers, -Peter - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: swap-related problems
There is obviously a problem when all swap is exhausted. The only solution is to allow the additional memory *use* to succeed AND to warn the sysadmin that ALL virtual memory has been exhausted. The only way to do this is to be able to allocate extra virtual memory. I'd vote for a system that would create swap files in the largest mounted read/write filesystem of type UFS or in the filesystem of my choice. There would be a systctl to set the limits on how much space to allocate. Possibly a setting for size and number of emergency swap files. When the time comes for killing processes, you should be able to specify that certain processes (by name) are precious and that processes owned by particular users and/or particular login classes are in the last resort or first resort for killing. I dont think it's worth trying to signal with a different signal because only FreeBSD specific programs will know what to do when signalled in such a manner. I suppose you could signal prior to killing as another layer to my dream system. Warner Losh wrote: In message 199904142340.taa96...@misha.cisco.com Mikhail Teterin writes: : Then, one can write a safe malloc, which will install the signal : handler, and touch every page in the the memory referenced by the : to-be-returned pointer. If the signal handler is invoked in the : progress, the to-be-returned memory must be returned back to the : system and NULL should be returned to the caller. This won't work all the time. FreeBSD overcommits swap space and you may get a SIGKILL even if you've touched all the pages. FreeBSD kills processes when swap space runs out. : However, my (in)ability to propose anything remotely sensible does : not change the facts established in this painful thread. That our : malloc does not conform to standards (for whatever reasons), and : that something should be done about it. That something must start : with documenting the flaw... The behavior is documented: The malloc() and calloc() functions return a pointer to the allocated memory if successful; otherwise a NULL pointer is returned. What the system does when it has resource shortages is beyond the scope of the ANSI-C standard, so I don't see why you say that FreeBSD's malloc isn't standard conforming. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: swap-related problems
Replying to myself... You'd have to be able to specify the absolute maximum memory use for a process to ensure you'd still kill run-aways (These would go first! regardless of the other rules maybe). Matthew Thyer wrote: There is obviously a problem when all swap is exhausted. The only solution is to allow the additional memory *use* to succeed AND to warn the sysadmin that ALL virtual memory has been exhausted. -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: lnc0: broke for us between 3.1 and 4.0?
-Original Message- From: Robert Watson [mailto:rob...@cyrus.watson.org] Sent: 17 April 1999 01:16 To: freebsd-current@freebsd.org Subject: lnc0: broke for us between 3.1 and 4.0? We upgraded a crash machine from 3.1-RELEASE to 4.0-CURRENT from just before the EGCS switch was pulled. The machine is a Pentium 166 MMX overdrive. Prior to the upgrade, it correctly probed the Kensington KNE 2100 (something like that) with the lnc driver as being at 0x300 irq 5 drq 6. The working 3.1-RELEASE GENERIC w/a change in the config editor probe went like: lnc0 at 0x300-0x317 irq 5 drq 6 on isa lnc0: PCnet-ISA address 00:c0:f0:00:81:f4 After upgrading to -current, the probe failed as follows (when config was used on the GENERIC quote): lnc0 at 0x300-0x317 irq 5 drq 6 on isa lnc0: Memory allocated above 16Mb limit It looks like the change to allocate memory from the top rather than the bottom has broken it since on my box, at least, it's getting memory from the end of physical memory now whereas it never used to. Can someone remind what exactly that change was? Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
On Sun, 18 Apr 1999, Peter Wemm wrote:
Brian Feldman wrote:
On Sat, 17 Apr 1999, Peter Wemm wrote:
Chris Piazza wrote:
On 17-Apr-99 Brian Feldman wrote:
Both sound drivers are broken with the new-bus code. My SB16, in the
ol
d
driver, now gets recognized but sbxvi is never looked for. pcm0, the
ne
w
driver, never initializes with the new code :(
device pcm0 at isa? port? tty irq 5 drq 1 flags 0x16
The pcm0 sounddriver works for me. In fact, the only problem I had
with
new
bus was it is now pcm0 instead of pcm1 ;-).
es0: AudioPCI ES1370 at device 9.0 on pci0
pcm0: using I/O space register mapping at 0xd800
es0: interrupting at irq 4
device pcm0
On two different systems it works for me using pcm0..
Here's what's going on with the pcm code. I've got an on-board audio device
that should probably eventually be supported, is PnP and detected, but
not recognized by the pcm driver. However, my SB16 ALSO fails to be
attached.
My SB16 is a nice pre-PnP one, which used to work fine with either audio
driver. I'll paste my current config and dmesg.
[..]
# Luigi's snd code.
# You may also wish to enable the pnp controller with this, for pnp
# sound cards.
#
device pcm0
device pcm1 at isa? port? tty irq 5 drq 1 flags 0x16
[..]
Hmm, you might like to try this patch and see what happens, there is
a missing old driver wrapper for the pcm stuff. As a result, it's not
getting run from the isa probe. Regarding the other driver, I'm not
sure what's going on there as the hooks appear to be present.
Thank you, that did work :) Now if someone could tell me why I need to
keep seeing
sorry, read DMA channel unavailable
let me know. This seems to be something that I do NOT need to see
from sb_dsp.c :P Other than that, everything's nice and peachy.
No, wait, I forgot. IPFW is _not_ being recognized in the kernel, and
the module is getting loaded instead (ipfw not being initialized?).
Index: i386/isa/isa_compat.h
===
RCS file: /home/ncvs/src/sys/i386/isa/isa_compat.h,v
retrieving revision 1.1
diff -u -r1.1 isa_compat.h
--- isa_compat.h 1999/04/16 21:22:23 1.1
+++ isa_compat.h 1999/04/17 17:30:34
@@ -49,6 +49,7 @@
#include ze.h
#include zp.h
#include oltr.h
+#include pcm.h
#include pas.h
#include sb.h
#include sbxvi.h
@@ -117,6 +118,7 @@
extern struct isa_driver zedriver;
extern struct isa_driver zpdriver;
extern struct isa_driver oltrdriver;
+extern struct isa_driver pcmdriver;
extern struct isa_driver pasdriver;
extern struct isa_driver sbdriver;
extern struct isa_driver sbxvidriver;
@@ -320,6 +322,9 @@
#if NOLTR 0
{ DRIVER_TYPE_MISC, oltrdriver },
+#endif
+#if NPCM 0
+ { DRIVER_TYPE_MISC, pcmdriver },
#endif
#if NPAS 0
{ DRIVER_TYPE_MISC, pasdriver },
Cheers,
-Peter
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ __ \ |) |
http://www.freebsd.org _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: cvsup
Matthew Thyer wrote: Whats the posibility of having another process for the display ? To be blunt, the probability is epsilon. I simply am not interested in spending time to make the silly GUI perform better when I could instead work on making the package transfer files faster. BTW, have you tried running the GUI from an X server on a different machine? Maybe the problem is that your X server isn't getting enough resources to update the screen quickly. I really don't see much of a problem with the speed of GUI updates here on my machine. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: boot kernel panic with the latest new-bus
On Sat, 17 Apr 1999, Doug Rabson wrote: I think we aren't picking up the PCI-ISA bridge chip which means that the isa bus didn't get probed. Could you do a verbose boot (boot -v) of your *old* kernel and post the resulting dmesg. Ok. Here it is. This is the biggest I could get. I had some trouble to get it too (I had to turn off most of the SCSI chain and boot single mode :), how can one increase the size of the dmesg buffer btw??) 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 128M bytes Write Allocate 15-16M bytes: Disable Hardware Write Allocate Control: Enable real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002e1000 - 0x07ffdfff, 131190784 bytes (32029 pages) avail memory = 127750144 (124756K bytes) Found BIOS32 Service Directory header at 0xc00f99e0 Entry = 0xf0490 (0xc00f0490) Rev = 0 Len = 1 PCI BIOS entry at 0x4c0 DMI header at 0xc00f51c0 Version 2.0 Table at 0xf51da, 31 entries, 973 bytes Other BIOS signatures found: ACPI: $PnP: 000fced0 Preloaded elf kernel kernel.stable at 0xc02c8000. VESA: information block 56 45 53 41 00 02 31 77 00 c0 01 00 00 00 22 00 00 01 40 00 05 01 46 77 00 c0 4d 77 00 c0 56 77 00 c0 00 01 01 01 02 01 03 01 05 01 07 01 08 01 09 01 0b 01 0c 01 10 01 11 01 12 01 13 01 14 01 VESA: 24 mode(s) found pci_open(1):mode 1 addr port (0x0cf8) is 0x80006000 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=55911039) Probing for devices on PCI bus 0: found- vendor=0x1039, dev=0x5591, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 map[0]: type 1, range 32, base e000, size 26 chip0: Host to PCI bridge (vendor=1039 device=5591) rev 0x02 on pci0.0.0 found- vendor=0x1039, dev=0x5513, revid=0xd0 class=01-01-8a, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=0 map[0]: type 4, range 32, base e400, size 3 map[1]: type 4, range 32, base e000, size 2 map[2]: type 4, range 32, base d800, size 3 map[3]: type 4, range 32, base d400, size 2 map[4]: type 4, range 32, base d000, size 4 ata-pci0: Unknown PCI IDE controller rev 0xd0 int a irq 0 on pci0.0.1 ata-pci0: Busmastering DMA not enabled found- vendor=0x1039, dev=0x0008, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 chip1: SiS 85c503 rev 0x01 on pci0.1.0 found- vendor=0x1039, dev=0x0009, revid=0x00 class=ff-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x1039, dev=0x7001, revid=0x11 class=0c-03-10, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=5 map[0]: type 1, range 32, base df80, size 12 found- vendor=0x1039, dev=0x0001, revid=0x00 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 chip2: PCI to PCI bridge (vendor=1039 device=0001) rev 0x00 on pci0.2.0 found- vendor=0x10ec, dev=0x8029, revid=0x00 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[0]: type 4, range 32, base b800, size 5 ed1: NE2000 PCI Ethernet (RealTek 8029) rev 0x00 int a irq 9 on pci0.10.0 ed1: address 00:00:1c:01:9d:d9, type NE2000 (16 bit) bpf: ed1 attached found- vendor=0x1000, dev=0x0001, revid=0x01 class=00-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[0]: type 4, range 32, base b400, size 8 map[1]: type 1, range 32, base df00, size 8 ncr0: ncr 53c810 fast10 scsi rev 0x01 int a irq 10 on pci0.11.0 ncr0: minsync=25, maxsync=206, maxoffs=8, 16 dwords burst, normal dma fifo ncr0: single-ended, open drain IRQ driver found- vendor=0x102b, dev=0x051a, revid=0x03 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[0]: type 3, range 32, base e700, size 23 map[1]: type 1, range 32, base de80, size 14 map[2]: type 1, range 32, base de00, size 23 vga0: Matrox MGA 1024SG/1064SG/1164SG graphics accelerator rev 0x03 int a irq 11 on pci0.12.0 Probing for devices on PCI bus 1: Initializing PnP override table Probing for PnP devices: Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 No Plug-n-Play devices were found Probing for devices on the ISA bus: atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0 on
Re: new-bus breaks both sound drivers
Hmm, you might like to try this patch and see what happens, there is a missing old driver wrapper for the pcm stuff. As a result, it's not getting run from the isa probe. Regarding the other driver, I'm not sure what's going on there as the hooks appear to be present. Right on, that patch does it for me. pcm0 at port 0x220 irq 5 drq 1 flags 0x15 on isa0 pcm0: interrupting at irq 5 I've got an old SB16 Value, non-pnp. mp3s aren't playing quite right with x11amp though, little skips here and there, they work fine with the old kernel. mpg123 seems fine, as does the sound in FXTV. I'll try making the world again. IPFW works for me...but I'm loading the KLD. my panasonic cdrom is no longer probed, it uses the matcd driver. doesn't show up in dmesg at all, but it does in the visual kernel config thing. It's so old, I'm not surprised :) great work! Jake -- we are but packets in the internet of life To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
Oh, btw, you did break sbxvi. Look carefully at the #if which surrounds it ;) Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
login
When I log in to my -current machine (April 13 sources) it takes a minute or two after the password is entered before the shell prompt comes up: FreeBSD/i386 (andrsn7.stanford.edu) (ttyp0) login: xanne Password: []--cursor just stays here for a while This is on a LAN; it works fine at the console (and it worked when it was 3.1). I can certainly live with this but it puzzles me. Would anyone know why this might be happening? Annelise To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: boot kernel panic with the latest new-bus
On Sat, 17 Apr 1999, Jose Gabriel Marcelino wrote:
On Sat, 17 Apr 1999, Doug Rabson wrote:
I think we aren't picking up the PCI-ISA bridge chip which means that the
isa bus didn't get probed. Could you do a verbose boot (boot -v) of your
*old* kernel and post the resulting dmesg.
Ok. Here it is. This is the biggest I could get.
I had some trouble to get it too (I had to turn off most of the SCSI chain
and boot single mode :), how can one increase the size of the dmesg buffer
btw??)
There is an option for this which is documented in LINT, MSGBUF_SIZE.
Could you try this patch which should make it see your PCI-ISA bridge:
Index: pcisupport.c
===
RCS file: /home/ncvs/src/sys/pci/pcisupport.c,v
retrieving revision 1.96
diff -u -r1.96 pcisupport.c
--- pcisupport.c1999/04/16 21:22:52 1.96
+++ pcisupport.c1999/04/17 19:02:05
@@ -929,6 +929,10 @@
return(AcerLabs M1533 portable PCI-ISA bridge);
case 0x154310b9:
return(AcerLabs M1543 desktop PCI-ISA bridge);
+
+ /* SiS -- vendor 0x1039 */
+ case 0x00081039:
+ return (SiS 85c503 PCI-ISA bridge);
}
if (pci_get_class(dev) == PCIC_BRIDGE
@@ -947,6 +951,7 @@
desc = isab_match(dev);
if (desc) {
device_set_desc_copy(dev, desc);
+
/* Don't bother adding more than one ISA bus */
if (!devclass_get_device(devclass_find(isa), 0))
device_add_child(dev, isa, -1, 0);
@@ -1050,8 +1055,6 @@
return (SiS 85c496);
case 0x04061039:
return (SiS 85c501);
- case 0x00081039:
- return (SiS 85c503);
case 0x06011039:
return (SiS 85c601);
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
On Sat, 17 Apr 1999, Jake Burkholder wrote: Hmm, you might like to try this patch and see what happens, there is a missing old driver wrapper for the pcm stuff. As a result, it's not getting run from the isa probe. Regarding the other driver, I'm not sure what's going on there as the hooks appear to be present. Right on, that patch does it for me. pcm0 at port 0x220 irq 5 drq 1 flags 0x15 on isa0 pcm0: interrupting at irq 5 I've got an old SB16 Value, non-pnp. mp3s aren't playing quite right with x11amp though, little skips here and there, they work fine with the old kernel. mpg123 seems fine, as does the sound in FXTV. I'll try making the world again. I suggest using the old VoxWare with an old SB16, like I do. I was only trying to use pcm temporarily because sbxvi is broken (fix isa_compat.h). IPFW works for me...but I'm loading the KLD. I like having my ipfw rules there BEFORE anything happens, hence before rc(5). my panasonic cdrom is no longer probed, it uses the matcd driver. doesn't show up in dmesg at all, but it does in the visual kernel config thing. It's so old, I'm not surprised :) great work! Jake -- we are but packets in the internet of life To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ __ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP!!!! Important instructions for -current users!
: : Is this formal decision of core team ? I feel a huge despair, as a : member of newconfig project : :This was a core team decision, but I really do hope we can still :figure out some way of working together on a final hybrid of the best :ideas from both projects since this honestly wasn't done with the :... : :I also have to say that this has pointed out, once again, that :communication is really lacking between the various groups, especially :in situations where a language barrier exists. Most of us didn't even :know about the newconfig project until comparatively recently, and I :... : :I don't really like the word loser very much, however, and would :much rather that everyone focus instead on the best route forward from :here since we've made the decision, for better or for worse, and need :... :- Jordan I think Jordan has nailed it on the head, as usual. I would like to address the communications aspect of the problem, because I think it is fairly easy for us to solve it. Simply put, people are not using the 'hackers' mailing list enough. If you notice, whenever I'm working on something that is fairly intrusive to the code base, I post updates to hackers at fairly regular intervals ( or to current if its a patchset for a bug ). I think it is especially important to do this even if there does not appear to be a huge amount of external interest. A week or a month down the line, someone might *become* interested in doing something similar to what you are doing and they aren't going to remember the one message you posted N months ago. As an example of the obviousness of the solution, I would point to CAM. the CAM guys posted updates 'almost' regularly enough. When the time came to shoehorn it into the source tree, there was grumbling but enough people knew it was coming that CAM had no real trouble getting in. I would say that if the CAM group had posted updates more regularly then they did, there would have been even less argument and confusion. If they hadn't posted anything at all, it might not have gotten in at all. Same thing goes here. -- Point #2 : The language barrier. Language is always a barrier, but it is made much worse when people to take a guy to task for his 'bad english'. I would ask people to STOP DOING THIS. Do not harass or ridicule someone for not being fluent in english! Now, it is sorely true that someone will often post to the list a message on the order of my machine crashed, please fix it! without one iota of additional information -- but please, people, be polite! If you don't want to try to help the person, do not answer at all. Else allow other people to lead him through the procedure. Many of these people are trying a hellofalot harder to communicate then us fluent english speakers ( we who tend to not know any language other then english, which is quite sad! ). -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: boot kernel panic with the latest new-bus
OK!
There is an option for this which is documented in LINT, MSGBUF_SIZE.
Thanks for letting me know!
Could you try this patch which should make it see your PCI-ISA bridge:
Well, I'm more than pleased to say IT DID!! Everything is working now!
I'm typing this using the new kernel.
Thank you very much! I'm amazed :-) Great work!
--
Gabriel
+++ pcisupport.c 1999/04/17 19:02:05
Index: pcisupport.c
===
RCS file: /home/ncvs/src/sys/pci/pcisupport.c,v
retrieving revision 1.96
diff -u -r1.96 pcisupport.c
--- pcisupport.c 1999/04/16 21:22:52 1.96
@@ -929,6 +929,10 @@
return(AcerLabs M1533 portable PCI-ISA bridge);
case 0x154310b9:
return(AcerLabs M1543 desktop PCI-ISA bridge);
+
+ /* SiS -- vendor 0x1039 */
+ case 0x00081039:
+ return (SiS 85c503 PCI-ISA bridge);
}
if (pci_get_class(dev) == PCIC_BRIDGE
@@ -947,6 +951,7 @@
desc = isab_match(dev);
if (desc) {
device_set_desc_copy(dev, desc);
+
/* Don't bother adding more than one ISA bus */
if (!devclass_get_device(devclass_find(isa), 0))
device_add_child(dev, isa, -1, 0);
@@ -1050,8 +1055,6 @@
return (SiS 85c496);
case 0x04061039:
return (SiS 85c501);
- case 0x00081039:
- return (SiS 85c503);
case 0x06011039:
return (SiS 85c601);
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: login
It seems Annelise Anderson wrote: When I log in to my -current machine (April 13 sources) it takes a minute or two after the password is entered before the shell prompt comes up: FreeBSD/i386 (andrsn7.stanford.edu) (ttyp0) login: xanne Password: []--cursor just stays here for a while This is on a LAN; it works fine at the console (and it worked when it was 3.1). I can certainly live with this but it puzzles me. Would anyone know why this might be happening? Sounds like a DNS timeout or something like that... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
Luoqi Chen wrote: I've add UNICODE support to the Joliet patch. It contains few charsets now, but to add other charsets is very easy. Currently, iso8859-1 and euc-jp is included. Mixture of Joliet/RockRidge Extension is also available, however untested. Cool! I think NTFS and VFATFS could use this code too, is it possible to move the code to place like libkern/unicode? I'm concerned about the possible size of GENERIC with this code. Remember, it has to fit in the install floppy. (Well, not really, with loader, but I'm not the one who is getting killed because of a three-disks install.) Also, it adds a sysctl node, isn't that so? Directly under vfs, even, so it applies to all filesystems. Ideally, this should apply on a per-mount basis, and not even be in a sysctl. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Well, Windows works, using a loose definition of 'works'... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: login
On Sat, 17 Apr 1999, Soren Schmidt wrote: It seems Annelise Anderson wrote: When I log in to my -current machine (April 13 sources) it takes a minute or two after the password is entered before the shell prompt comes up: FreeBSD/i386 (andrsn7.stanford.edu) (ttyp0) login: xanne Password: []--cursor just stays here for a while This is on a LAN; it works fine at the console (and it worked when it was 3.1). I can certainly live with this but it puzzles me. Would anyone know why this might be happening? Sounds like a DNS timeout or something like that... -Søren I think it was, thanks. I changed the order of the nameservers in resolv.conf and it no longer happens. :) Annelise To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re[2]: ftp hangs on -current
Hello Matthew, Saturday, April 17, 1999, 9:07:51 PM, you wrote: I am getting problems similar to those outlined above. I don't run natd, either, but I do have a firewall enabled. (open rule) I've had to 'put' files rather than 'get' them, since my last build/installworld. (Yesterday's -current source) MT How many of you are using RealTek network cards ? MT They are crap in my experience (under any OS). hmm... i'm really using Realtek 8029 card. i'm in doubt that this network card is real reason of a problem with ftp, but i will try to replace it with 3Com 509 on Monday and report about results. Best regards, Ilyamailto:ca...@avias.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
Brian Feldman wrote: IPFW works for me...but I'm loading the KLD. I like having my ipfw rules there BEFORE anything happens, hence before rc(5). klds can be loaded by the loader. Hence, before /kernel. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Well, Windows works, using a loose definition of 'works'... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: login
Annelise Anderson wrote: When I log in to my -current machine (April 13 sources) it takes a minute or two after the password is entered before the shell prompt comes up: FreeBSD/i386 (andrsn7.stanford.edu) (ttyp0) login: xanne Password: []--cursor just stays here for a while You haven't by any chance added kerberos by mistake, have you? :-) If you're not sure, send the output from ldd /usr/libexec/rlogind. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP!!!! Important instructions for -current users!
I would ask people to STOP DOING THIS. Do not harass or ridicule someone for not being fluent in english! Now, it is sorely true that someone wil Let me just reinforce this statement. It truly does no good at all and, speaking as a former non-speaker-of-the-native-language when I lived in Germany, I can say it's frustrating enough as it is just trying to make yourself understood in a language that's not your mother tongue, especially when you're reasonably intelligent in your own. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
new-bus changes break i4b
After the latest new-bus changes in FreeBSD-current a kernel configured
with ISDN support and PnP does not compile anymore. The following patch
fixed the problem for me, at least the kernel compiles and runs. I don't
have a PnP ISDN card (only a non-PnP one), but I do have PnP enabled in my
kernel config file because my sound card needs it. The patch below is
based on changes between /sys/i386/isa/sio.c and /sys/isa/sio.c and it
could be completely wrong...
*** /sys/i4b/layer1/i4b_isic_pnp.c.orig Sun Mar 7 17:08:16 1999
--- /sys/i4b/layer1/i4b_isic_pnp.c Sun Apr 18 00:48:46 1999
***
*** 219,231
if(dev-id_driver == NULL)
{
dev-id_driver = isicdriver;
!
! isa_devp = find_isadev(isa_devtab_net, isicdriver, 0);
!
! if(isa_devp != NULL)
! {
! dev-id_id = isa_devp-id_id;
! }
}
if((dev-id_alive = isic_pnpprobe(dev, spci.port[1])) != 0)
--- 219,225
if(dev-id_driver == NULL)
{
dev-id_driver = isicdriver;
! dev-id_id = isa_compat_nextid();
}
if((dev-id_alive = isic_pnpprobe(dev, spci.port[1])) != 0)
Blaz Zupan, b...@medinet.si, http://home.amis.net/blaz
Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
On Sun, 18 Apr 1999, Daniel C. Sobral wrote: Brian Feldman wrote: IPFW works for me...but I'm loading the KLD. I like having my ipfw rules there BEFORE anything happens, hence before rc(5). klds can be loaded by the loader. Hence, before /kernel. Thanks for ruining my logic ;) But I really do hate overstuffing Makefile.inc in sys/modules so I can get the options I want. That's why for most things I use the kernel itself and not modules, really. -- Daniel C. Sobral (8-DCS) d...@newsguy.com d...@freebsd.org Well, Windows works, using a loose definition of 'works'... Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ __ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP!!!! Important instructions for -current users!
Let us not forget that much of the newconfig work can be used with newconfig shims in the newbus scheme. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: successfull SMP / current on duel P-III box.Yahhhh. I've successfully brought -current up in SMP on a duel P-III box.
I have one problem, though. During the kernel boot:
isa_dmainit(2, 1024) failed
And, of course, any access to something that needs isa
dma (e.g. floppy) panics. It's a large-memory machine (1G).
I was under the impression that this was supposed to be fixed
in the vm/vm_page.c commit:
[...]
Anyone have any ideas?
Yes.
Using a recent -current GENERIC kernel, I reproduced the problem with
a machine having 512 MB memory.
All physical memory below 16 MB is used.
vm_page_list_find uses TAILQ_LAST when prefer_zero is set, thus
pv_table occupies the physical memory below 640 KB.
The remaining physical memory below 16 MB is allocated to
vm_page_array and vm_page_buckets in vm_page_startup, or was reserved
earlier (e.g. kernel text, data, bss).
IMO, vm_page_array and vm_page_buckets should not use physical memory
below 16 MB on large-memory machines. This can be achieved by
modyfing the contents of phys_avail, causing the largest region to
be above 16 MB.
GENERIC kernel:
(kgdb) print phys_avail
$66 = {4096, 651264, 3624960, 536862720, 0, 0, 0, 0, 0, 0}
The kernel I normally use:
(kgdb) print phys_avail
$1 = {4096, 651264, 3301376, 16777216, 16777216, 536608768, 0, 0, 0, 0}
This works fine for machines with 512 MB and 1 GB memory.
For machines with more than 2 GB memory, the size of pv_table might become
a problem.
Alternating between TAILQ_INSERT_HEAD and TAILQ_INSERT_TAIL in
vm_page_startup might be a workaround for this second problem (causing
the memory below 16 MB not already allocated by vm_page_startup to be
in the middle of the page queues).
- Tor Egge
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: login
On Sat, Apr 17, 1999 at 12:38:25PM -0700, Annelise Anderson wrote:
I think it was, thanks. I changed the order of the nameservers
in resolv.conf and it no longer happens. :)
What about setting up a caching DNS server on your machine ?
You could configure forwarders.
options {
directory /etc/namedb;
forwarders {
aaa.bbb.ccc.ddd;
};
};
in /etc/resolv.conf
domain your.domain
nameserver 127.0.0.1
Had to do many many (~600) DNS requests in a script and had
a lame nameserver over network about 3-4 hops away.
After configuring a local DNS server the script was much (!) faster.
--
Andreas Klemm http://www.FreeBSD.ORG/~andreas
http://www.freebsd.org/~fsmp/SMP/SMP.html
powered by Symmetric MultiProcessor FreeBSD
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
RE: lnc0: broke for us between 3.1 and 4.0?
-Original Message- From: Robert Watson [mailto:rob...@cyrus.watson.org] Sent: 17 April 1999 01:16 To: freebsd-current@freebsd.org Subject: lnc0: broke for us between 3.1 and 4.0? After upgrading to -current, the probe failed as follows (when config was used on the GENERIC quote): lnc0 at 0x300-0x317 irq 5 drq 6 on isa lnc0: Memory allocated above 16Mb limit Any suggestions as to what might done to fix it? If we switch back to the old kernel, it boots fine, so presumably it was some change between 3.1-RELEASE and 4.0-CURRENT, either in the config file or the lnc driver? I've just committed a fix for this. It was caused by the change to the way vm_page.c allocates memory Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Laptop support
Can anyone tell me if I can get freebsd 3.1 running on a compaq pressario 1675 - I'm worried about the pcmcia controller being recognized (and my xircom re-100btx working). Thanks. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
From: Daniel C. Sobral d...@newsguy.com Luoqi Chen wrote: I've add UNICODE support to the Joliet patch. It contains few charsets now, but to add other charsets is very easy. Currently, iso8859-1 and euc-jp is included. Cool! I think NTFS and VFATFS could use this code too, is it possible to move the code to place like libkern/unicode? I'm concerned about the possible size of GENERIC with this code. Remember, it has to fit in the install floppy. (Well, not really, with loader, but I'm not the one who is getting killed because of a three-disks install.) The UNICODE routines consist of these files. charset/charset.c mandatory iso8859-1.c recommended euc-jp.coptional-- BIG! the object file has 53k bytes encoding/encoding.c mandatory euc.c optional The 'mandatory + recommended' object size is no more than 5 kbytes. The GENERIC kernel does not require necessarily the euc-jp support or any other charsets. I think the iso8859-1 support alone is sufficient for GENERIC. The custom kernels can have the euc-jp support through the CHARSET_EUC_JP and ENCODING_EUC kernel configure option. (They are currently defined at the top of the source files.) Also, it adds a sysctl node, isn't that so? Directly under vfs, even, so it applies to all filesystems. Ideally, this should apply on a per-mount basis, and not even be in a sysctl. Yes. sysctl is not the best idea. I think the charset preferences should apply on per-process basis ideally. The operator mounts some disks. The users access the disks in their own preferred charset. The UNICODE is a multiligual codeset, so we shoud not suppose any specific charset on the disk. Therefore, a per-mount basis is not enough. If the routines can refer the users' environment 'LC_CTYPE', it is fine idea. But it can't, I suppose. -- Motomichi Matsuzaki mz...@e-mail.ne.jp Dept. of Biological Science, Fuculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
On Sun, 18 Apr 1999, Motomichi Matsuzaki wrote: From: Daniel C. Sobral d...@newsguy.com I'm concerned about the possible size of GENERIC with this code. Remember, it has to fit in the install floppy. (Well, not really, with loader, but I'm not the one who is getting killed because of a three-disks install.) The UNICODE routines consist of these files. charset/charset.c mandatory iso8859-1.c recommended euc-jp.coptional-- BIG! the object file has 53k bytes encoding/encoding.c mandatory euc.c optional The 'mandatory + recommended' object size is no more than 5 kbytes. The GENERIC kernel does not require necessarily the euc-jp support or any other charsets. I think the iso8859-1 support alone is sufficient for GENERIC. The custom kernels can have the euc-jp support through the CHARSET_EUC_JP and ENCODING_EUC kernel configure option. (They are currently defined at the top of the source files.) couldn't this be done as a KLD? -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
From: Motomichi Matsuzaki mz...@e-mail.ne.jp Subject: Re: kern/5038: FreeBSD can't read MS Joliet CDs. Date: Sun, 18 Apr 1999 13:55:58 +0900 Message-ID: 19990418135558w.mz...@e-mail.ne.jp mzaki If the routines can refer the users' environment 'LC_CTYPE', mzaki it is fine idea. But it can't, I suppose. It may be possible to set the kernel behavior via a call to setlocale(3). That is, change the charset per process within setlocale routine who knows the LC_CTYPE. Another way which have larger impact on the whole system is to change the start up routine to look for LC_CTYPE and change the behavior. The last solution is to make the charset of a process inheritable to child processes. Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
newbus and modem(s)
I'm as excited as anyone to see progress, especially if it means the ability to modularize the kernel and load various drivers on demand. But, alas, it seems this whole thing was rushed horribly. The first thing I noticed was the panic I got, in atkbd_isa_intr, which has since been fixed. But once I got my system booted, I noticed that it didn't detect my PnP modem (a quick check revealed that the PnP code was #if 0'd out). So, I tried my external modem, which worked. But in the process of downloading email, I got about 5 sio overflows. I've left my box up for a few days and rebuilt world while downloading stuff, and only gotten around one or two overflows. I looked at un #ifdef'n the PnP code, but some things seem to have changed substantially. Where is there any documentation on how to un-butcher drivers or even properly fix them? Sure it looks like the pcm driver works and works with the PnP code but it uses the shims. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
