Kernel panic (with uipc_domain.c, rev 1.33)
Hi, latest kernel causes a panic early during boot: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x68 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02667cf stack pointer = 0x10:0xc0641cf8 frame pointer = 0x10:0xc0641d08 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at _mtx_lock_sleep+0x18f: movl0x68(%ecx),%edx db where _mtx_lock_sleep(c050fbe0,0,0,0) at _mtx_lock_sleep+0x18f net_add_domain(c04bd500) at net_add_domain+0x34 ngs_mod_event(c09e8c80,0,c04bd300,0,c09e8c80) at ngs_mod_event+0x26 ng_mod_event(c09e8c80,0,c04bd300,c050c500,0) at ng_mod_event+0x52 module_register_init(c04bd33c,63ec00,63e000,0,c013d015) at module_register_init+ 0x4b mi_startup() at mi_startup+0x96 begin() at begin+0x2c db backing out rev. 1.33 of kern/uipc_domain.c solved the problem for me. Additional side notice: netgraph is compiled statically into the kernel, no separate module. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng probe updated please test
Soren Schmidt schrieb: I've gone over the probe code once again. Please test, and in case it fails to detect or misdetects anything, mail me the output of dmesg from a verbose boot, and state what devices actually are there. Hi, again no luck. Same problem persists, the devices got probed correctly (two disks, each on its own channel), but cannot be accessed. Daniel SMAP type=01 base= len=0009fc00 SMAP type=01 base=0009fc00 len=0400 SMAP type=02 base=000f len=0001 SMAP type=02 base= len=0001 SMAP type=01 base=0010 len=03ef SMAP type=03 base=03ff3000 len=d000 SMAP type=04 base=03ff len=3000 Copyright (c) 1992-2003 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.1-CURRENT #784: Tue Sep 2 17:32:45 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROCK Preloaded elf kernel /boot/kernel/kernel at 0xc061f000. Calibrating clock(s) ... i8254 clock: 1193178 Hz Timecounter i8254 frequency 1193178 Hz quality 0 Calibrating TSC clock ... TSC clock: 300681454 Hz CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x580 Stepping = 0 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX AMD Features=0x8800SYSCALL,3DNow! Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 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: 64M bytes Write Allocate 15-16M bytes: Enable Hardware Write Allocate Control: Disable real memory = 67043328 (63 MB) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x00646000 - 0x03ea7fff, 59121664 bytes (14434 pages) avail memory = 58634240 (55 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb040 bios32: Entry = 0xfb4c0 (c00fb4c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb4f0 pnpbios: Found PnP BIOS data at 0xc00fc130 pnpbios: Entry = f:c158 Rev = 1.0 Other BIOS signatures found: null: null device, zero device mem: memory I/O VESA: information block 56 45 53 41 00 02 00 01 00 01 00 00 00 00 22 00 00 01 40 00 00 01 0b 01 00 01 21 01 00 01 2a 01 00 01 00 01 01 01 10 01 11 01 12 01 03 01 13 01 14 01 15 01 05 01 16 01 17 01 18 01 07 01 19 01 VESA: 40 mode(s) found VESA: v2.0, 4096k memory, flags:0x0, mode table:0xc05540c2 (122) VESA: ATI MACH64 VESA: ATI Technologies Inc. MACH64GT 01.00 random: entropy source acpi0: GBTAWRDACPI on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=154110b9) pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdef0 PCI-Only Interrupts: 9 10 12 Location Bus Device Pin Link IRQs slot 1 08A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 08B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 08C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 08D 0x04 3 4 5 7 9 10 11 12 14 15 slot 2 09A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 09B 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 09C 0x04 3 4 5 7 9 10 11 12 14 15 slot 2 09D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10A 0x03 3 4 5 7 9 10 11 12 14 15 slot 3 0 10B 0x04 3 4 5 7 9 10 11 12 14 15 slot 3 0 10C 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10D 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11A 0x04 3 4 5 7 9 10 11 12 14 15 slot 4 0 11B 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 11C 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11D 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 12A 0x01 3 4 5 7 9 10 11 12 14 15 slot 5 0 12B 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 12C 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 12D 0x04 3 4 5 7 9 10 11 12 14 15 embedded0 15A 0x05 3 4 5 7 9 10 11 12 14 15 embedded0 15B 0x06 3 4 5 7 9 10 11 12 14 15 embedded01A 0x01 3 4 5 7 9 10 11 12 14 15 embedded01B 0x02 3 4 5 7 9 10 11 12 14 15 embedded01C 0x03 3 4 5 7 9 10 11 12 14 15 embedded01D 0x04 3 4 5 7 9 10 11 12 14 15 embedded02A 0x59 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 15 func
Re: ATA-ng
Soren Schmidt schrieb: It seems Chris Petrik wrote: Think it would be a wise thing to do is to make a kernel option to use ATAng and one to use the old ATAold or something you commited a important part of the system without throughly testing it and most people dont use SMP i would think to do it this way then when its proven that ATAng is stable and working remove the ATAold stuff and make ATAng default but thats just a sugestion as im having problems too. It sounds to me as if you should not run -current :) Anyhow please upgrade to the latest that should fix the problems with the probe missing some devices. Hi, I just upgraded -CURRENT to the latest (cvsup'd this morning). With ATAng I (like some others too) get the message: ad0: 9671MB IBM-DTTA-351010 [20960/15/63] at ata0-master UDMA33 ad1: 1221MB Seagate Technology 1275MB - ST31276A [2482/16/63] at ata1-master WDMA2 ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt Mounting root from ufs:/dev/ad0a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Attached are dmesg output from a failed boot and a good one with a kernel from Jul, 26th More info on request. Daniel Copyright (c) 1992-2003 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.1-CURRENT #778: Sun Aug 31 12:37:14 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROCK Preloaded elf kernel /boot/kernel/kernel at 0xc061e000. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x580 Stepping = 0 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX AMD Features=0x8800SYSCALL,3DNow! real memory = 67043328 (63 MB) avail memory = 58638336 (55 MB) VESA: v2.0, 4096k memory, flags:0x0, mode table:0xc0552dc2 (122) VESA: ATI MACH64 acpi0: GBTAWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdef0 acpi0: power button is handled as a fixed feature programming model. acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x4d6,0x40b,0x480-0x48f,0x5000-0x501f,0x4000-0x403f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 2 INTA is routed to irq 11 pcib0: slot 8 INTA is routed to irq 10 pcib0: slot 9 INTA is routed to irq 12 pcib0: slot 10 INTA is routed to irq 9 pcib0: slot 11 INTA is routed to irq 9 agp0: Ali M1541 host to AGP bridge mem 0xd000-0xdfff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 10 pcib1: slot 0 INTA is routed to irq 10 pci1: display, VGA at device 0.0 (no driver attached) ohci0: AcerLabs M5237 (Aladdin-V) USB controller mem 0xe9103000-0xe9103fff irq 11 at device 2.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: AcerLabs M5237 (Aladdin-V) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 fxp0: Intel 82558 Pro/100 Ethernet port 0xe000-0xe01f mem 0xe900-0xe90f,0xe910-0xe9100fff irq 10 at device 8.0 on pci0 fxp0: Ethernet address 00:a0:c9:ef:69:8d miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: RealTek 8139 10/100BaseTX, rev. B port 0xe400-0xe4ff mem 0xe9101000-0xe91010ff irq 12 at device 9.0 on pci0 rl0: Ethernet address: 00:e0:7d:75:fd:fb miibus1: MII bus on rl0 rlphy0: RealTek internal media interface on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: Adaptec 2940 Ultra SCSI adapter port 0xe800-0xe8ff mem 0xe9102000-0xe9102fff irq 9 at device 10.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs pcm0: AudioPCI ES1370 port 0xec00-0xec3f irq 9 at device 11.0 on pci0 atapci0: AcerLabs Aladdin UDMA33 controller port 0xf000-0xf00f at device 15.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/1 bytes threshold
Re: Performance problems with 5.0-RELEASE
Dan Nelson schrieb: In the last episode (Jan 23), Rahul Siddharthan said: Kenneth Culver wrote: Did you by any chance build your own kernel? If so did you leave things like this in: options INVARIANTS #Enable calls of extra sanity options INVARIANT_SUPPORT #Extra sanity checks of internal options WITNESS #Enable checks to detect deadlocks options WITNESS_SKIPSPIN#Don't run witness on spinlocks I'd like to add that even with these removed, I was experiencing terrible performance in building ports, etc (anything involving heavy filesystem activity or memory usage). Setting up an /etc/malloc.conf fixed this (this is also briefly noted in UPDATING). Specifically I use (don't know whether it's optimal, but it works): # ls -l /etc/malloc.conf lrwxr-xr-x 1 root wheel 4 Jan 23 11:52 /etc/malloc.conf - HR H and should only make a difference if you are low on memory. R is on by default in 5.0 anyway, due to A and J being on by default. Setting malloc.conf to aj makes it work like it does in 4.*. Ahh, thanks for the info. Just a notice. With malloc.conf pointing to aj I got a speedup of over 85% for a specific test program for Perl 5.8.0: To reproduce: cd /usr/ports/lang/perl make cd work/perl-5.8.0 time ./perl t/op/pat.t Results: no /etc/malloc.conf 125 seconds user time /etc/malloc.conf - aj 18 seconds user time on an AMD K6-2 300. I'd say this is a significant difference... Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fsck cannot find superblock
Hi, with 'uncommon' block sizes fsck seems to have problems finding the superblock: # newfs -i 10240 -b 4096 -f 512 /dev/ad1d Reduced frags per cylinder group from 26208 to 26200 to enlarge last cyl group /dev/ad1d: 409.6MB (838860 sectors) block size 4096, fragment size 512 using 33 cylinder groups of 12.79MB, 3275 blks, 1312 inodes. super-block backups (for fsck -b #) at: 32, 26232, 52432, 78632, 104832, 131032, 157232, 183432, 209632, 235832, 262032, 288232, 314432, 340632, 366832, 393032, 419232, 445432, 471632, 497832, 524032, 550232, 576432, 602632, 628832, 655032, 681232, 707432, 733632, 759832, 786032, 812232, 838432 # fsck /dev/ad1d ** /dev/ad1d Cannot find file system superblock LOOK FOR ALTERNATE SUPERBLOCKS? [yn] n If I type 'y' fsck will find an alternate superblock at 16 (not 32, as printed during newfs). The number of inodes, fragment size don't seem to have an impact, only block size. No problems with block size of 8192 though. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CURRENT unstable during heavy file system I/O
Hi, since some months now my -CURRENT is very unstable during heavy file system activity (parallel accesses while deleting large subdirectories). Today, I ran the following command for simple cleanup of /usr/ports: # find /usr/ports -type d -name work -print | xargs rm -rf [Yes, I should have added an option -maxdepth 3]. During this cleanup the machine panic'd twice. I don't have a crash dump, only console output: Fatal double fault: eip = 0xc04304c8 esp = 0xd85e8fb8 ebp = 0xd85e980c panic: double fault Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db c syncing disks... panic: bwrite: buffer is not busy??? Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db c Uptime: 26m29s Dumping 127 MB ata0: resetting devices .. panic: bremfree: removing a buffer not on a queue Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db c Uptime: 26m29s Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort gdb at address 0xc04304c8: Dump of assembler code for function bus_dmamap_load: 0xc0430340 bus_dmamap_load: push %ebp [...] 0xc04304b8 bus_dmamap_load+376: mov%eax,0xfff0(%ebp) 0xc04304bb bus_dmamap_load+379: mov0xffe4(%ebp),%edx 0xc04304be bus_dmamap_load+382: mov%edx,0xffe0(%ebp) 0xc04304c1 bus_dmamap_load+385: movl $0x1,0xffdc(%ebp) 0xc04304c8 bus_dmamap_load+392: movl $0x0,0x4(%edx) 0xc04304cf bus_dmamap_load+399: movl $0x0,0xffd4(%ebp) 0xc04304d6 bus_dmamap_load+406: lea0x0(%esi),%esi 0xc04304d9 bus_dmamap_load+409: lea0x0(%edi,1),%edi 0xc04304e0 bus_dmamap_load+416: mov0xfff0(%ebp),%ecx 0xc04304e3 bus_dmamap_load+419: mov%ecx,%eax 0xc04304e5 bus_dmamap_load+421: shr$0x16,%eax The panic bwrite: buffer is not busy??? is always the same. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Resource allocation error in new pnp code
Hi, I already mentioned this bug a few months ago but didn't got a reply. Maybe I'm the only one who is affected by this bug. I have several PnP cards in my system (see attached output of pnpinfo). Especially one card requests a resource: I/O Range 0x100 .. 0x3ff, alignment 0x1, len 0x1 [16-bit addr] My ISDN controller also requests a resource from this range: I/O Range 0x100 .. 0x3f0, alignment 0x8, len 0x8 [not 16-bit addr] Now the following happens: first card gets assigned: Mar 28 21:12:00 gate /kernel: unknown10: EEPROM at port 0x100 on isa0 and the ISDN card gets assigned: Mar 28 21:12:00 gate /kernel: isic0: Sedlbauer WinSpeed at port 0x101-0x108 irq 11 on isa0 which is wrong since it requests an alignment of 8. The code in /sys/isa/isa_common.c, which should prevent this is useless, since most work is done in /sys/kern/subr_rman.c which automatically tries to find an alternate region, but without honouring any alignment. Also attached is my (ugly) hack for this problem, but I think the problem should be addressed elsewhere (in the resource manager), since it may affect any type of resource allocation which requires different alignment. -- Daniel Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID AZT3002 (0x02305407), Serial Number 0x PnP Version 1.0, Vendor Version 1 Device Description: AZT3002 PnP SOUND DEVICE Logical Device ID: AZT0500 0x00055407 #0 Device supports I/O Range Check Device Description: IDE CDROM DISABLED TAG Start DF Good Configuration I/O Range 0x0 .. 0x0, alignment 0x8, len 0x0 [16-bit addr] I/O Range 0x0 .. 0x0, alignment 0x2, len 0x0 [16-bit addr] IRQ: IRQ: High true edge sensitive TAG End DF Logical Device ID: AZT1004 0x04105407 #1 Device supports I/O Range Check Device Description: AUDIO TAG Start DF Good Configuration I/O Range 0x220 .. 0x220, alignment 0x10, len 0x10 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0x534 .. 0x534, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 IRQ: High true edge sensitive DMA: channel(s) 1 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 3 8-bit, not a bus master, count by byte, , Compatibility mode TAG Start DF I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0x534 .. 0x608, alignment 0xd4, len 0x4 [16-bit addr] IRQ: 5 9 10 IRQ: High true edge sensitive DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode TAG Start DF I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0xe84 .. 0xf44, alignment 0xc0, len 0x4 [16-bit addr] IRQ: 5 9 10 IRQ: High true edge sensitive DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode TAG Start DF I/O Range 0x100 .. 0x3f0, alignment 0x10, len 0x10 [16-bit addr] I/O Range 0x100 .. 0x3f8, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0x100 .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 9 10 11 15 IRQ: High true edge sensitive DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode TAG Start DF I/O Range 0x100 .. 0x3f0, alignment 0x10, len 0x10 [16-bit addr] I/O Range 0x100 .. 0x3f8, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0x100 .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 9 10 11 15 IRQ: High true edge sensitive DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode TAG End DF Logical Device ID: AZT2001 0x01205407 #2 Device supports I/O Range Check Device Description: MPU401 MIDI TAG Start DF Good Configuration I/O Range 0x330 .. 0x330, alignment 0x2, len 0x2 [16-bit addr] IRQ: 9 IRQ: High true edge sensitive TAG Start DF I/O Range 0x300 .. 0x330, alignment 0x30, len 0x2 [16-bit addr] IRQ: 5 9 10 11 15 IRQ: High true edge sensitive TAG Start DF I/O Range 0x100 .. 0x3fe, alignment 0x2, len 0x2 [16-bit addr] IRQ: 5 9 10 11 15 IRQ: High true edge sensitive TAG End DF Logical Device ID: AZT3001 0x01305407 #3 Device supports I/O Range Check Device Description: GAME PORT TAG Start DF Good Configuration I/O Range 0x200 .. 0x200, alignment 0x8, len 0x8 [16-bit addr] TAG Start DF I/O Range 0x208 .. 0x208,
ata: panic with new sysctl variable
Hi, just noticed the new sysctl variable for ata. I just wanted to use the new way for disabling DMA on my disk (has some strange problems, even under windows). Previously I just commented out the ata_dmainit() lines in ata_disk.c, now I wanted to set it with sysctl: sysctl -w hw.atamodes="pio,dma,dma,dma" but this paniced my machine. I later discovered that there is no sanity check during setting the new modes: The machine in question didn't have a secondary IDE controller, but the variables were set without a range check. My solution was simple. Just use sysctl -w hw.atamodes="pio,dma" but I think, the ata driver should range check the settings. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: isa_dmastart: bad bounce buffer
Nick Hibma wrote: Starting mpg123 with a random mpg3 file produces the following panic within half a second. The kernel is current as of this morning. THe panic is reproducable (as in, I cannot play the mpg3 file). kernel plus core available if needed. Dec 15 14:55:25 henny /kernel: ESS1879: adding io range 0x220-0x22f, size=0x10, align=0 Dec 15 14:55:25 henny /kernel: ESS1879: adding io range 0x388-0x38b, size=0x4, align=0 Dec 15 14:55:25 henny /kernel: ESS1879: adding irq mask 0x20 Dec 15 14:55:25 henny /kernel: ESS1879: adding dma mask 0x2 Dec 15 14:55:25 henny /kernel: ESS1879: adding dma mask 0x20 Dec 15 14:55:25 henny /kernel: ESS1879: start dependant Dec 15 14:55:25 henny /kernel: pnpbios: handle 1 device ID ESS1879 (79187316) Dec 19 17:10:48 henny /kernel: sbc0: ESS ES1879 at port 0x220-0x22f,0x388-0x38b irq 5 drq 1,5 on isa0 Dec 19 17:10:48 henny /kernel: pcm0: SB DSP 3.01 on sbc0 Same here. If I change the call to esschan_init() back to sbchan_init() [in /sys/dev/sound/isa/sb.c], these messages and the panic disappear again. (Alternatively I can turn down ESS_BUFFSIZE to 8192, larger values [tried (16384 and 32768) -256] also don't work] Sound still doesn't work yet. Just noise - probably played at a fraction of the normal speed (5%). sbc: ESS ES1869 at port 0x220-0x22f, 0x388-0x38b, 0x330-0x331 irq 5 drq 1,0 on isa0 pcm0: SB DSP 3.01 (ESS mode) on sbc0 Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors and AUTO_EOI
Oliver Fromme schrieb: Doug White wrote in list.freebsd-current: On Tue, 21 Dec 1999, Soren Schmidt wrote: It seems Dieter Rothacker wrote: The solution for me was to recompile the kernel without AUTO_EOI1 and AUTO_EOI2. Those options newer worked (for me at least) reliably with anything, could those that are seeing the hangs please check this ?? Although this isn't immediately related to ATA, I've found that Intel L440GX+ boards *hate* AUTO_EOI_2 when running SMP. They freeze going into multiuser mode. Took me quite a while to figure that out. I have always been using AUTO_EOI_1, but _not_ AUTO_EOI_2, and it has always worked very well. The comment in LINT about AUTO_EOI_2 sounds pretty suspicous, so I never even tried it: "it works for some clones and some integrated versions." That sounds to me like "it works on a very limited set of hardware (and if you're lucky)." AUTO_EOI_1 seems to be fine, though. Same for me. Except for my laptop, which didn't even like AUTO_EOI_1 (which is also mentioned in LINT, but noticed it only at 3rd read). Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problems with new pnp code
Hi, just noticed a bug in the new pnp code. The resource allocator seems to ignore the align flag for port addresses. dmesg output: [...] AZT5001: start dependant AZT5001: adding io range 0x100-0x3ff, size=0x1, align=0x1 AZT5001: end dependant [...] SAG0001: start dependant SAG0001: adding io range 0x100-0x3f7, size=0x8, align=0x8 SAG0001: adding irq mask 0xbcb8 SAG0001: start dependant SAG0001: adding io range 0x100-0x3f7, size=0x8, align=0x8 SAG0001: adding irq mask 0x20 SAG0001: start dependant SAG0001: adding io range 0x100-0x3f7, size=0x8, align=0x8 SAG0001: adding irq mask 0x80 SAG0001: end dependant [...] unknown11: EEPROM at port 0x100 on isa0 isic0: Sedlbauer WinSpeed at port 0x101-0x108 irq 10 on isa0 isic0: HSCX VSTR test failed for SWS PnP isic0: HSC0: VSTR: 0xee isic0: HSC1: VSTR: 0xee device_probe_and_attach: isic0 attach returned 6 [...] Shouldn't the port for isic0 be chosen as 0x108-10f? This used to be the assignment by the BIOS with the old code. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATA problem
Hi, The ata driver tries to enable UDMA for my controller, but fails (this is no disk problem. The disks can do UDMA, as tested in another machine). Perhaps UDMA should be disabled for all VIA 82C586 chips: dmesg output: [...] found- vendor=0x1106, dev=0x0571, revid=0x02 class=01-01-8a, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base 6000, size 4 map[24]: type 1, range 32, base e110, size 13 [...] ata-pci0: VIA 82C586 ATA controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0: iobase=0x01f0 altiobase=0x03f6 ata0: mask=03 status0=50 status1=50 ata0: mask=03 status0=50 status1=50 ata0: devices = 0x3 ata0 at 0x01f0 irq 14 on ata-pci0 ata1: iobase=0x0170 altiobase=0x0376 ata1: mask=03 status0=50 status1=00 ata1: mask=03 status0=50 status1=00 ata1: devices = 0x1 ata1 at 0x0170 irq 15 on ata-pci0 [...] ata0: master: success setting up WDMA2 mode on VIA chip ad0: piomode=4 dmamode=2 udmamode=2 cblid=0 ad0: ST34321A/3.29 ATA-4 disk at ata0 as master ad0: 4103MB (8404830 sectors), 8894 cyls, 15 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, DMA Creating DISK ad0 Creating DISK wd0 ata0: slave: success setting up WDMA2 mode on VIA chip ad1: piomode=4 dmamode=2 udmamode=-1 cblid=0 ad1: Seagate Technology 1275MB - ST31276A/1.37 ATA-2 disk at ata0 as slave ad1: 1221MB (2501856 sectors), 2482 cyls, 16 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 1 depth queue, DMA Creating DISK ad1 Creating DISK wd1 ata1: master: success setting up WDMA2 mode on VIA chip ad2: piomode=4 dmamode=2 udmamode=2 cblid=0 ad2: IBM-DTTA-351010/T56OA73A ATA-4 disk at ata1 as master ad2: 9671MB (19807200 sectors), 19650 cyls, 16 heads, 63 S/T, 512 B/S ad2: 16 secs/int, 32 depth queue, DMA This already with a small patch with only uses WDMA modes, otherwise I will get "lost disk contact" messages. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm driver breakage
[Followup to myself] With the latest changes to the pcm driver, a downgrade of channel.c to 1.8 doesn't help any more: I cannot hear anything while playing something (in my case with mpg123). A verbose output of mpg123 shows me that the application seems to hang after a few write()'s to the sound device (with no sound output). There also doesn't seem to be any interrupt activity on the pcm interrupt. Two days before (but with rev 1.8 of channel.c) I could play any pcm file I have with only some noise at the end if I interrupt mpg123 with ^C. Here the latest configuration information (I can post full output if requested). Kernel config: [...] device pcm0 device sbc0 options PNPBIOS [also without PNPBIOS but with device sbc0at isa? port 0x220 irq 5 drq 1 flags 0x10 no difference] dmesg output from a verbose boot: sbc0: ESS ES1869 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 pcm0: SB DSP 3.01 on sbc0 pcm: setmap 3, ff00; 0xcd4b5000 - 3 pcm: setmap 4, ff00; 0xcd4c5000 - 4 Daniel "D. Rock" wrote: Hi, something broke between rev 1.8 and 1.9 of /sys/dev/sound/pcm/channel.c The driver probes as a: pcm0: ESS1869 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 The relevant kernel config entries are device pcm0 options PNPBIOS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pccard sio problems (Re: HEADSUP: wd driver will be retired!)
Zitiere Daniel Eischen [EMAIL PROTECTED]: In message [EMAIL PROTECTED] Christopher Masto writes: : Right now, I have no sound (not detected), no USB (panic on removal), : can\\\'t use my sio pccard, can\\\'t eject my ed pccard, my IDE drives are : taking hours to dump and fsck, and my TV card is missing every other : line if I try to use the (not working anyway) closed caption decoder. I have some patches for the can\'t eject the network cards from a user that I\'m trying out and would then need to get committed to the network layer to properly support if_detach(). What\'s wrong with your sio pccard? Mine works well enough... Mine hasn\'t worked since a kernel built from Nov 23 sources. It broke sometime between then and December 4th. Just built a new kernel from todays sources, and still no go. pccardd[47]: driver allocation failed for Motorola (MONTANA 33.6 FAX/MODEM): Device not configured I also had problems with latest -current. After a little debugging I noticed that sio.c doesn\'t include \"card.h\" which defines NCARD, so the pccard stuff isn\'t compiled in. I added that line to sio.c, recompiled, and sio for pccard was at least again partially functional. I have two pccard sio devices, one seems to work, the other one freezes the machine during a simple \"stty -a /dev/cuaaX\". I have attached the CIS information of these cards with my pccard.conf. Ejecting sio also doesn\'t seem to work. The machine is freezed afterwards. I can eject my DLink ed card, but after a re-insertion the driver isn\'t attached any more. Daniel Configuration data for card in slot 0 Tuple #1, code = 0x1 (Common memory descriptor), length = 2 000: 00 ff Common memory device information: Device number 1, type No device, WPS = OFF Speed = No speed, Memory block size = reserved, 32 units Tuple #2, code = 0x15 (Version 1 info), length = 32 000: 04 01 49 6e 74 65 6c 6c 69 67 65 6e 74 00 50 43 010: 4d 43 49 41 20 46 41 58 2b 4d 4f 44 45 4d 00 ff Version = 4.1, Manuf = [Intelligent],card vers = [PCMCIA FAX+MODEM] Tuple #3, code = 0x20 (Manufacturer ID), length = 4 000: 00 02 01 00 PCMCIA ID = 0x200, OEM ID = 0x1 Tuple #4, code = 0x21 (Functional ID), length = 2 000: 02 00 Serial port/modem Tuple #5, code = 0x22 (Functional EXT), length = 4 000: 00 02 0f 5c Serial interface extension: 16550 UART, Parity - Space,Mark,Odd,Even, Tuple #6, code = 0x22 (Functional EXT), length = 9 000: 05 1f 1f 00 04 00 00 04 00 Modem interface capabilities: Tuple #7, code = 0x22 (Functional EXT), length = 9 000: 06 1f 1f 00 04 00 00 04 00 Modem interface capabilities: Tuple #8, code = 0x22 (Functional EXT), length = 12 000: 02 06 00 3f 1c 03 03 0f 07 00 01 b5 Data modem services available: Tuple #9, code = 0x22 (Functional EXT), length = 8 000: 13 06 00 1f 00 02 00 b5 Tuple #10, code = 0x22 (Functional EXT), length = 8 000: 23 06 00 1f 00 02 00 b5 Tuple #11, code = 0x1a (Configuration map), length = 5 000: 01 27 80 ff 67 Reg len = 2, config register addr = 0xff80, last config = 0x27 Registers: XXX--XX- Tuple #12, code = 0x1b (Configuration entry), length = 19 000: cf 41 99 79 55 3d 86 46 26 4c aa 60 f8 03 07 f0 010: bc 86 28 Config index = 0xf(default) Interface byte = 0x41 (I/O) +RDY/-BSY active Vcc pwr: Nominal operating supply voltage: 5 x 1V Continuous supply current: 3.5 x 10mA Max current average over 1 second: 1 x 100mA, ext = 0x46 Max current average over 10 ms: 2 x 100mA Power down supply current: 4.5 x 1mA Card decodes 10 address lines, 8 Bit I/O only I/O address # 1: block start = 0x3f8 block length = 0x8 IRQ modes: Level, Pulse, Shared IRQs: 4 5 6 7 10 11 12 13 15 Max twin cards = 0 Misc attr: (Audio-BVD2) (Power down supported) Tuple #13, code = 0x1b (Configuration entry), length = 7 000: 17 08 aa 60 f8 02 07 Config index = 0x17 Card decodes 10 address lines, 8 Bit I/O only I/O address # 1: block start = 0x2f8 block length = 0x8 Tuple #14, code = 0x1b (Configuration entry), length = 7 000: 1f 08 aa 60 e8 03 07 Config index = 0x1f Card decodes 10 address lines, 8 Bit I/O only I/O address # 1: block start = 0x3e8 block length = 0x8 Tuple #15, code = 0x1b (Configuration entry), length = 7 000: 27 08 aa 60 e8 02 07 Config index = 0x27 Card decodes 10 address lines, 8 Bit I/O only I/O address # 1: block start = 0x2e8 block length = 0x8 Tuple #16, code = 0xff (Terminator), length = 0 Configuration data for card in slot 0 Tuple #1, code = 0x1 (Common memory descriptor), length = 2
Re: ATA driver as the default
Doug Ambrisko schrieb: D. Rock writes: | I just re-enabled the ATA driver again after reading the change log | of better error handling and automatic falldown DMA-PIO under specific | circumstances. | But a few days later, while making world (with the ata driver), the | system | crashed quite heavily. The file system was totally screwed up afterwards | (I found my /usr/local after some heavy searching: It magically | moved to /usr/obj/usr/src/tmp/usr/share/zoneinfo (!) and got tons of | fsck | messages). The file system had softupdates enabled. I don't know the | last kernel messages before the crash (was running X at that time). You might want to look at ata-disk.c and the timeout value around line 438: /* start timeout for this transfer */ if (panicstr) request-timeout_handle.callout = NULL; else request-timeout_handle = timeout((timeout_t*)ad_timeout, request, 5*hz); Originally it was 3s and recently increased to 5s. Personally I switched it to 30s after it trashed my filesystem when it was 3s. The issue was that 3s, is that it is to short to wait for my laptop's drive to spin back up. Sometimes I would get a corrupted read sometimes on a write it would trash things. I noticed in the old wd driver that it tried 10s first then a couple 3s timeouts. After making this change my system has been rock solid when the drive spins down. Note I haven't tried to tune this value since trashing a 14G filesystem is pain full. I don't think I have the same problem. My drive definitely doesn't spin down. It sometimes occurs during heavy usage, so the drive should still be very alive. With PIO mode I also don't have any timeout problems. I also had the same DMA problems with the old wd driver and under Windows. The problem is, that the new driver doesn't allow to selectively turn off DMA for problematic devices. I now had commented out the DMA activation code in ata-disk.c (DMA is still activited on the CD-ROM drive though) and I will see how the system behaves. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver as the default
David O'Brien schrieb: Since the ATA driver is destined to be the default in 4.0-R, and we hare hitting the feature freeze date; can we make the switch now? I think it is very important to get ATA into more hands to see where it breaks. It certainly has problems on my Vaio 505 laptop; and I wonder where else it will have problems. Better to find them now than right before release. I occasionaly tested the new ATA driver on my laptop but decided to go back to the old wd driver: There seems to be a problem if I enable DMA for the hard disk. With DMA turned on the disk sometimes hung for a few seconds, then got resetted and worked again. No data corruption occured. This happened under FreeBSD and Windows. I therefor disabled DMA transfer for the disk. The CD-ROM works just happily with DMA turned on though. Disk and CD-ROM are connected to the same IDE controller (Intel standard). I just want a flag to selectively disable DMA transfer for certain files, just like I could for the old wd driver. I just re-enabled the ATA driver again after reading the change log of better error handling and automatic falldown DMA-PIO under specific circumstances. But a few days later, while making world (with the ata driver), the system crashed quite heavily. The file system was totally screwed up afterwards (I found my /usr/local after some heavy searching: It magically moved to /usr/obj/usr/src/tmp/usr/share/zoneinfo (!) and got tons of fsck messages). The file system had softupdates enabled. I don't know the last kernel messages before the crash (was running X at that time). Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rm error code on FAT
Maxim Sobolev wrote: "Matthew D. Fuller" wrote: On Tue, Nov 09, 1999 at 02:18:44AM +0200, a little birdie told me that Maxim Sobolev remarked If your logic is right, then attempt to remove existent files from FAT using '*' should yield absolutely the same result (i.e. EINVAL). But in fact files being removed from FAT w/o any problems (touch /fat/1.exist /fat/2.exist ; rm /*.exist). IMHO it is clear bug in unlink error codes on FAT f/s. I think you'll find that the '*' in that case is expanded by your shell long before rm ever gets to it. *sigh* (seems it is time for me to go into the bed ;). You are probably right - it seems I forgot to take into account shell role. So it is pure and unavoidable "feature" of FAT Wildcards only get expanded by the shell if there is something to expand. Just write an "echo" instead of "rm" for your command and see by yourself. csh would show the error message "no match", but sh compatible shells just display: # mkdir empty # cd empty # echo *xtra *xtra So in fact, if you try to remove something, the '*' is indeed part of the filename for the unlink() command. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ESS 1868 driver, again
Peter Wemm wrote: As to why the 1869 isn't working for you, that's anybody's guess. You might try posting the 'dmesg' output (not from syslog) and your complete config file, as well as any other pertinant information you can think of. Ok here is the (hopefully) complete information. -current cvsupped ~2 hours ago. If seems there will no interrupts be generated. If I try to play something, nothing happens, if I run "vmstat -i" then, there are 0 interrupts for irq 5 (pcm0). Daniel kernel config file: machine i386 ident LAPTOP maxusers6 options PQ_LARGECACHE cpu I686_CPU options COMPAT_43 options SYSVSHM options SYSVSEM options SYSVMSG options MD5 options DDB options KTRACE options PERFMON options UCONSOLE options INET pseudo-device ether pseudo-device loop pseudo-device bpf pseudo-device tun options ICMP_BANDLIM options FFS options NFS options NFS_NOSERVER options CD9660 options MSDOSFS options PROCFS options FFS_ROOT options SOFTUPDATES options QUOTA options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L controller scbus0 device da0 device pass0 pseudo-device pty options MSGBUF_SIZE=20480 controller isa0 controller pnp0 options PNPBIOS controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 options ATKBD_DFLT_KEYMAP makeoptions ATKBD_DFLT_KEYMAP="german.iso" device psm0at atkbdc? irq 12 options PSM_HOOKAPM options PSM_RESETAFTERSUSPEND device vga0at isa? port ? conflicts options VGA_WIDTH90 options VESA pseudo-device splash device sc0 at isa? options MAXCONS=6 options SC_DFLT_FONT makeoptions SC_DFLT_FONT=iso options SC_PIXEL_MODE device npx0at nexus? port IO_NPX flags 0x0 irq 13 controller ata0 device atadisk0 device atapicd0 options ATA_ENABLE_ATAPI_DMA controller fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 device ed0 device pcm0 device apm0at nexus? device joy0at isa? port IO_GAME controller pci0 controller pcic0 at isa? irq 10 controller pcic1 at isa? irq 10 controller card0 options PCIC_RESUME_RESET controller ppbus0 controller vpo0at ppbus? device lpt0at ppbus? device ppi0at ppbus? device ppc0at isa? port? irq 7 drq 3 controller uhci0 controller usb0 device ugen0 options HZ=500 dmesg output of verbose boot: 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 #241: Sun Nov 7 13:48:17 CET 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/ROCK Calibrating clock(s) ... TSC clock: 232125177 Hz, i8254 clock: 1193284 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II/Xeon/Celeron (232.11-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 67108864 (65536K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002ef000 - 0x03ffafff, 64012288 bytes (15628 pages) avail memory = 62169088 (60712K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f66a0 bios32: Entry = 0xfd7e0 (c00fd7e0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x203 pnpbios: Found PnP BIOS data at 0xc00f66d0 pnpbios: Entry = f:a62f Rev = 1.0 Other BIOS signatures found: ACPI: VESA: information block 56 45 53 41 00 02 6b 00 00 c0 00 00 00 00 f6 8c 00 c0 10 00 00 00 b4 27 00 c0 b5 27 00 c0 b6 27 00 c0 b7 27 00 c0 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 VESA: 11 mode(s) found VESA: v2.0, 1024k memory, flags:0x0, mode table:0xc00c8cf6 (c0008cf6) VESA: Copyright 1994 TRIDENT MICROSYSTEMS INC. VESA: Pentium Pro MTRR support enabled pci_open(1):mode 1 addr port (0x0cf8) is 0x80001010 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71928086) npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2
Re: sio working
Warner Losh wrote: In message [EMAIL PROTECTED] "D. Rock" writes: : device sio0at isa? port IO_COM1 flags 0x10 irq 4 : device sio1at isa? port IO_COM2 irq 3 These look good. IIRC, the kernel I tested with also had: device sio2at isa? port IO_COM3 irq 5 disabled or device sio2 in it, but I may be misremembering. Just make sure that you use the config entry that gives you a port at 0x3e8, since most laptops have COM1 and COM2 which really cannot be disabled (well, the BIOS says you can disable them, but I've seen a few where the BIOS disabling is broken). Already did that. I used a config entry for 0x3e8 and one for 0x2e8. Windows 98 configured the card for IRQ 11 I/O 0x3e8 BTW. Just some more pccard questions: When will removing cards (and therefor also suspend/resume) work again? If I remove the netcard or suspend the machine, the system will freeze. I also get a NMI if I insert my netcard (DLink DE-660). If DDB is compiled in I can just continue. Interesting the NMI wasn't generated during initial configuration (via DHCP), but when I tried some ping tests: pccard: card inserted, slot 0 sio2: irq maps: 0x105 0x105 0x105 0x105 sio2: probe failed test(s): 0 1 4 6 7 9 sio2: irq maps: 0x105 0x105 0x105 0x105 sio2: probe failed test(s): 0 1 4 6 7 9 pccard: card inserted, slot 1 ed0 at port 0x240-0x25f irq 15 slot 1 on pccard0 ed0: address 00:80:c8:8b:66:e9, type NE2000 (16 bit) bpf: ed0 attached NMI ... going to debugger ( [the first two sio2 lines were with config index for port 0x3e8, the other ones with config index for 0x2e8] Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ESS 1868 driver, again
Peter Wemm wrote: "D. Rock" wrote: I read the last mails regarding problems with their ESS 1868 boards. Well, at least it is partially working for them. I didn't have any luck with the driver for some time now. I couldn't get a single tone. With the old voxware driver, sound worked at least partially (44.1 kHz, 8 Bit, mono), but with the new driver I didn't have any luck at all. Here my configuration: device pcm0at isa? port 0x220 irq 5 drq 1 flags 0x15 Err, the ESS1868 is a PNP device. You should only have "device pcm0" and nothing more. You might also try "options PNPBIOS". You are running -current, right? What does "options PNPBIOS" do. I didn't find it in LINT? This one doesn't seem to be a PNP device. I set all the resources manually via BIOS. If it was a PNP device, it shouldn't be detected any longer by the old voxware driver. # pnpinfo Checking for Plug-n-Play devices... No Plug-n-Play devices were found Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sio working
Warner Losh wrote: In message [EMAIL PROTECTED] "D. Rock" writes: : I tried many different combinations. I disabled the onboard serial devices : in the BIOS and kernel, so config index 0xf could grap io port 0x3f8 with : irq 4 but the only thing I get is : sio2: configured irq -1071415680 not in bitmap of probed irqs 0 That is very odd... Do you have sio2 in your config file? If so just take it out and see if that helps or hurts (or replace what is there with "devicesio2" As always when you see odd problems like this, try a make clean make depend make in the compile directory (after reconfiguring). I don't think it will help the current situation, but it won't hurt. Had tried it all before. No sio2 in kernel. Below is the complete config file Daniel --- machine i386 ident LAPTOP maxusers6 options PQ_LARGECACHE cpu I686_CPU options COMPAT_43 #optionsUSER_LDT options SYSVSHM options SYSVSEM options SYSVMSG options MD5 #optionsDDB #optionsDDB_UNATTENDED options KTRACE options PERFMON options UCONSOLE #optionsUSERCONFIG #optionsVISUAL_USERCONFIG options INET pseudo-device ether #pseudo-device sppp pseudo-device loop pseudo-device bpf pseudo-device tun #optionsMROUTING #optionsIPFIREWALL #optionsIPFIREWALL_VERBOSE #optionsIPFIREWALL_FORWARD #optionsIPFIREWALL_DEFAULT_TO_ACCEPT #optionsIPDIVERT #optionsIPSTEALTH options ICMP_BANDLIM #optionsDUMMYNET options FFS options NFS options NFS_NOSERVER options CD9660 options MSDOSFS options PROCFS options FFS_ROOT options SOFTUPDATES options QUOTA options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L #controller scbus0 #device ch0 #device da0 #device sa0 #device cd0 #device pass0 #optionsSCSI_REPORT_GEOMETRY pseudo-device pty #pseudo-device speaker #pseudo-device gzip #pseudo-device vn #pseudo-device snp 3 options MSGBUF_SIZE=20480 controller isa0 #optionsAUTO_EOI_1 #controller pnp0 controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 options ATKBD_DFLT_KEYMAP makeoptions ATKBD_DFLT_KEYMAP="german.iso" device psm0at atkbdc? irq 12 #optionsPSM_HOOKAPM #optionsPSM_RESETAFTERSUSPEND device vga0at isa? port ? conflicts options VGA_WIDTH90 options VESA pseudo-device splash device sc0 at isa? options MAXCONS=6 options SC_DFLT_FONT makeoptions SC_DFLT_FONT=iso options SC_PIXEL_MODE device npx0at nexus? port IO_NPX flags 0x0 irq 13 #controller ata0 #device atadisk0 #device atapicd0 controller wdc0at isa? port IO_WD1 flags 0xe0ffc0ff irq 14 device wd0 at wdc0 drive 0 options IDE_DELAY=2000 device wcd0 controller fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 #optionsEXTRA_SIO=1 device ed0 #device xe0 #controller snd0 #device sb0 at isa? port 0x220 irq 5 drq 1 #device sbxvi0 at isa? port 0x220 irq 5 drq 5 conflicts #device sbmidi0 at isa? port 0x330 #device opl0at isa? port 0x388 #device mpu0at isa? port 0x330 device pcm0at isa? port 0x220 irq 5 drq 1 flags 0x15 #device pca0at isa? port IO_TIMER1 device apm0at nexus? device joy0at isa? port IO_GAME #controller miibus0 controller pci0 controller card0 controller pcic0 at isa? irq 10 controller pcic1 at isa? irq 10 #options PCIC_RESUME_RESET #controller smbus0 #controller intpm0 #device smb0at smbus? #controller iicbus0 #controller iicbb0 #device ic0 at iicbus? #device iic0at iicbus? #device iicsmb0 at iicbus? #options AVM_A1_PCMCIA #device isic0 #pseudo-device "i4bq921" #pseudo-device "i4bq931" #pseudo-device "i4b" #pseudo-device "i4btrc" 4 #pseudo-device "i4bctl" #pseudo-device "i4brbch" 4 #pseudo-device "i4btel"2 #pseudo-device "i4bipr" 4 #optionsIPR_VJ #pseudo-device "i4bisppp" 4 controller ppbus0 #controller vpo0at ppbus? device lpt0at ppbus? device ppi0at ppbus? device ppc0at isa? port? irq 7 drq 3 controller uhci0 controller usb
Re: ESS 1868 driver, again
"D. Rock" wrote: Here my configuration: device pcm0at isa? port 0x220 irq 5 drq 1 flags 0x15 Err, the ESS1868 is a PNP device. You should only have "device pcm0" and nothing more. You might also try "options PNPBIOS". You are running -current, right? What does "options PNPBIOS" do. I didn't find it in LINT? This one doesn't seem to be a PNP device. I set all the resources manually via BIOS. If it was a PNP device, it shouldn't be detected any longer by the old voxware driver. # pnpinfo Checking for Plug-n-Play devices... No Plug-n-Play devices were found Uups, forget my previous post. I added "options PNPBIOS" to my configuration and also only a line "device pcm0", but the problem remains: Probe message: Nov 7 03:34:45 /kernel.new: pcm0: ESS1869 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,5 on isa0 And then later, if I try to play something: Nov 7 03:34:45 /kernel.new: sb_dspwr(0xd0) timed out. Nov 7 03:34:45 /kernel.new: sb_dspwr(0xc0) timed out. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sio working
Warner Losh wrote: In message [EMAIL PROTECTED] "D. Rock" writes: : I tried many different combinations. I disabled the onboard serial devices : in the BIOS and kernel, so config index 0xf could grap io port 0x3f8 with : irq 4 but the only thing I get is : sio2: configured irq -1071415680 not in bitmap of probed irqs 0 That is very odd... Do you have sio2 in your config file? If so just take it out and see if that helps or hurts (or replace what is there with "devicesio2" As always when you see odd problems like this, try a make clean make depend make in the compile directory (after reconfiguring). I don't think it will help the current situation, but it won't hurt. With the latest -current I get a slightly different output: Nov 7 03:34:47 /kernel.new: pccard: card inserted, slot 0 Nov 7 03:34:57 /kernel.new: sio2: irq maps: 0x105 0x105 0x105 0x105 Nov 7 03:34:57 /kernel.new: sio2: probe failed test(s): 0 1 4 6 7 9 Nov 7 03:34:57 pccardd[15]: driver allocation failed for Intelligent(PCMCIA FAX+MODEM): Device not configured How intelligent is pccardd? This card has several config entries, but only the first one contains also possible IRQs, the additional entries only contain I/O ports. So I also tried to use the first one (and disabling the conflicting sio0 in BIOS + kernel config) Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world, attempt 5
Greg Lehey schrieb: I've been trying for the last 24 hours solid to make a new world. The latest problem is: === libwrap cc -nostdinc -O -pipe -DFACILITY=LOG_AUTH -DHOSTS_ACCESS -DNETGROUP -DDAEMON_UMASK=022 -DREAL_DAEMON_DIR=\"/usr/libexec\" -DPROCESS_OPTIONS -DSEVERITY=LOG_INFO -DRFC931_TIMEOUT=10 -DHOSTS_DENY=\"/etc/hosts.deny\" -DHOSTS_ALLOW=\"/etc/hosts.allow\" -DSYS_ERRLIST_DEFINED -DALWAYS_HOSTNAME -I/usr/obj/src/PANIC/src/tmp/usr/include -c /src/PANIC/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c -o hosts_access.o /src/PANIC/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:245: syntax error before `' /src/PANIC/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:84: warning: `host_match' declared `static' but never defined /src/PANIC/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:85: warning: `string_match' declared `static' but never defined I know these errors. Mostly they are caused by local modifications of the source. If you then "cvs update" your tree, and there is a conflict, the offending lines are surrounded by Your Code === New Code I also have overseen cvs conflicts dozens of time. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
"Donald J . Maddox" schrieb: Is the new PnP code really so smart that it has no use for user intervention ever? My experience indicates that it is not. It would be very nice if the architects of the new PnP code would add back this lost functionality. My (QD) solution for this problem: Get rid of controller pnp0 in your config-file. Write down the Port/IRQ/DMA of all your PnP cards, then configure them the hard way (they normally don't change between reboots). This was my solution to get my PnP ISDN card working again (i4b isn't yet converted to newPnP). As a side effect I also had to manually configure my NE2000 compatible PnP card manually. Before --- controller pnp0 device ed0 device isic0 -- ed0: NE2000 Compatible at port 0x220-0x23f irq 3 on isa0 ed0: address 00:40:05:38:7b:a4, type NE2000 (16 bit) unknown3: speed win SEDLBAUER AG at port 0x108-0x10f irq 11 on isa0 After --- device ed0 at isa? port 0x220 irq 3 device isic0 at isa? port 0x108 irq 11 flags 9 -- ed0 at port 0x220-0x23f irq 3 on isa0 ed0: address 00:40:05:38:7b:a4, type NE2000 (16 bit) isic0 at port 0x108 irq 11 flags 0x9 on isa0 isic0: Sedlbauer WinSpeed isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0x10a) isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x10b, AddrB=0x10d) The ISDN card needed some additional tweaking, since it a PnP only card and isn't expected to run as a non-PnP card, but the sound driver should be just like the ed driver. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealTek 8139 problems
Bruce Evans schrieb: Under normal Circumstances, the communication is Ok between all three machines, but sometimes the ethernet interface in the main machine (the 8139) wedges up. I cannot ping any other host. The only solution is taking the interface down and up again: It hangs when it gets an rx fifo overrun. The chance of an overrun can be modified by tweaking the fifo threshold and rx maxdma as in if_rlreg.h rev.1.9. Thanks, this seems to fix my problem. I set #define RL_RX_MAXDMA RL_RXDMA_UNLIMITED #define RL_TX_MAXDMA RL_TXDMA_2048BYTES and now at least my simple "ping torture tests" doesn't impress the driver any more. Do such high values have any negative impact on the performance/stability/ memory usage of the system? If not, couldn't these values be the default? Or the other way: Since recovery seems to be very easy, how difficult is it for the driver to detect this condition and do an auto-recovery? Yes, I know the RealTek are very ugly chips. Normally this card is installed into my Windows PC, but I had to swap the card with an I-EEPro in order to dualboot Solaris on this PC. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
dev_t and system accounting
Hi, the new dev_t stuff in the kernel keeps system accounting showing up the tty properly. After taking a look at the fix for the swap device, I propose the following equivalent fix: Index: kern/kern_acct.c === RCS file: /data/cvs/src/sys/kern/kern_acct.c,v retrieving revision 1.20 diff -u -r1.20 kern_acct.c --- kern_acct.c 1999/04/27 11:15:53 1.20 +++ kern_acct.c 1999/07/09 19:57:38 @@ -221,7 +221,7 @@ /* (7) The terminal from which the process was started */ if ((p-p_flag P_CONTROLT) p-p_pgrp-pg_session-s_ttyp) - acct.ac_tty = p-p_pgrp-pg_session-s_ttyp-t_dev; + acct.ac_tty = dev2udev(p-p_pgrp-pg_session-s_ttyp-t_dev); else - acct.ac_tty = NODEV; + acct.ac_tty = dev2udev(NODEV); Index: sys/acct.h === RCS file: /data/cvs/src/sys/sys/acct.h,v retrieving revision 1.9 diff -u -r1.9 acct.h --- acct.h 1998/02/01 20:08:35 1.9 +++ acct.h 1999/07/09 19:57:15 @@ -60,7 +60,7 @@ gid_t ac_gid; /* group id */ u_int16_t ac_mem; /* average memory usage */ comp_tac_io;/* count of IO blocks */ - dev_t ac_tty; /* controlling tty */ + udev_tac_tty; /* controlling tty */ #defineAFORK 0x01/* forked but not exec'ed */ #defineASU 0x02/* used super-user permissions */ Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dev_t and system accounting
Hi, the new dev_t stuff in the kernel keeps system accounting showing up the tty properly. After taking a look at the fix for the swap device, I propose the following equivalent fix: Looks good, could you try this version for me ? [patch deleted] I recompiled a "make world" and also rebuild the kernel with this patch. No problems. lastcomm now again works as expected. I already ran with the modified kernel from my patch. But I didn't rebuilt world, so I didn't notice the userland problems for dev_t/udev_t Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config is broken?
This option is in /sys/conf/options and /sys/i386/conf/options.i386 According to the cvs log, the floppy driver has moved out of the i386 architecture directory. It seems the options.i386 has been forgotten (options.pc98 has been corrected). Daniel Alex Zepeda schrieb: redwood201:/usr/src/sys/i386/conf#config -g DUSTER options.i386: Duplicate option FDC_DEBUG. redwood201:/usr/src/sys/i386/conf#grep FDC_DEBUG * LINT:# FDC_DEBUG enables floppy debugging. Since the debug output is huge, you LINT:optionsFDC_DEBUG options.i386:FDC_DEBUG opt_fdc.h redwood201:/usr/src/sys/i386/conf# To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
New ata driver gets intr statistics wrong
Interrupts don't get accounted right. Instead of adding them to irq14/irq15 they always seem to be added to irq0. Here is a sample output of systat (I have options HZ=1000 in my kernel config, so 1000 should be normal) 3 usersLoad 1.21 1.05 1.01 Do 4 Mär 02:04 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 10308206020764 38568408 count5 All 587962792 1127196 5784 pages 31 688 zfod Interrupts Proc:r p d s wCsw Trp Sys Int Sof Flt195 cow1333 total 1 4 11 459 973 5233 1333 252 920 23068 wire 1125 clk0 irq0 13528 act 128 rtc0 irq8 24.5%Sys 1.6%Intr 46.7%User 0.0%Nice 27.3%Idl16524 inact pci irq11 |||||||||| 5456 cache24 pci irq15 + 2952 freepci irq9 daefr fdc0 irq6 Namei Name-cacheDir-cache prcfr24 atkbd0 irq Calls hits% hits% 2 react32 psm0 irq12 8739 8440 97 310 pdwak sio0 irq4 pdpgs sio1 irq3 Discs ad0 da0 da1 da2 cd0 fd0 pass0 intrn ppc0 irq7 KB/t 8.09 0.00 9.29 0.00 0.00 0.00 0.00 5518 buf isic0 irq1 tps 124 023 0 0 0 0 4039 desir esb0 irq5 MB/s 0.98 0.00 0.21 0.00 0.00 0.00 0.00 11444 numvnodes 7994 freevnodes During probe I also noticed this message: ata-pci0: Acer Aladdin IV/V IDE controller rev 0xc1 int a irq 0 on pci0.15.0 ^ ata0 at 0x01f0 irq 14 on ata-pci0 On another machine with VIA chipset I don't see any int a irq X, but the interrupts get still accounted for irq0 instead of irq14 This isn't a big deal for me, PCMCIA interrupts do have the same problem. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ata1: unwanted interrupt
After having CVSupped to the latest 4.0-CURRENT tree (just now), I noticed the amazing speed of the new ATA driver. The amazing speed of the new ATA driver? Were you using 32 bit transfers and multi-sector IO with the older driver? I assumed from the benchmarks posted that I had no reason to feel alarmed about the fact that the new driver offered no tangible performance increase. My understanding was that we'd feel it when DMA transfers were enabled for those drives that support them. I also tried the new ata code and wasn't impressed by the speed: With the old driver I achieved 12 MB/s with almost no CPU load on my ST34321A drive. The new driver works flawless in my configuration (I only have a single IDE drive attached, the rest is SCSI. Chipset is Ali Aladdin), but I only get about 7MB/s from the drive while having 70% irq load. (I have done the tests with dd from the raw device and a block size of 1MB) So I didn't notice any problems with the new code, but we'll have to wait until DMA is supported to get a really decent performance. Just to be complete. Here are the relevant portions of dmesg output for just another working configuration: ata-pci0: Acer Aladdin IV/V IDE controller rev 0xc1 int a irq 0 on pci0.15.0 ata0 at 0x01f0 irq 14 on ata-pci0 [...] ad0: ST34321A/3.29 ATA-4 disk at ata0 as master ad0: 4103MB (8404830 sectors), 8894 cyls, 15 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ata1: unwanted interrupt
Am I confused (yet again)? Yes ;-) I mean the time it takes to actually detect the drive. I recently added options IDE_DELAY=2000 on all IDE kernels I managed. The only problem with this short delay so far was an undetected drive in an unusual configuration: The jumper block was defective and the drive could only be jumpered as slave. A 2s delay was too short to detect this drive without a master drive attached at the same bus. So in my case, there isn't even a speed improvement during boot. But I will soon test the new code on my laptop: The drive has problem if DMA is enabled. I hope the new code will give me some speed improvement in this case. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to power off an ATX power supply machine on shutdown ?
Is a delay needed between the final sync's and the actual power off? Apparently so. There is/was a recently added sysctl for this purpose. Poke around in the archives. Was that sysctl added to the -STABLE branch? I am running 3.1-BETA and I cannot find it. No, they were added after the split and weren't backported to the 3.x branch. But if you are impatient, you could just grab a copy of sys/kern/kern_shutdown.c from a 4.0 branch and copy it to your tree. The added sysctl is for now the only difference in this file. Then you can specify somewhere in your rc files sysctl -w kern.shutdown.poweroff_delay = x with x measured in ms. I have only seen one machine so far which suffers this problem of powering off the machine too fast. On all other machines I know of either the mainboard or the power supply (don't know which) have a small delay before powering off the machine, which seems to be long enough for the drives to flush their buffers. On this particular machine, I set the delay to 1.5 seconds, and I never got unclean filesystems again. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr
This doesn't fix my problem (my isn't even rename or delete related) As I writed some time before, I always get the wrong results if I generate the termcap.db in an NFSv3 mounted directory. It doesn't matter which machine is the NFS server (tried Solaris 7 and the NFS client machine itself). The generated file has *always* the wrong size (always the same: 1077760 Bytes, instead of 1245184 Bytes, which it should have). With NFSv2 the output is OK. Can anyone please test this if they have the same problem. It is quite easy: mkdir /NFS/termcap; cp /usr/src/share/termcap/* /NFS/termcap cd /NFS/termcap; make redo this with NFSv2 and v3 and compare the results. If someone else has the same problem it would be nice if he can drop me a note, so I know I'm not alone... Anyone with /usr/obj NFS mounted should have the same problems. I don't even dare to do a make release on an NFSv3 mounted chroot directory. Even if the make succeeded I wouldn't trust the results. NFSv2 seems quite stable now. Daniel Matthew Dillon schrieb: Index: nfs_vnops.c === RCS file: /home/ncvs/src/sys/nfs/nfs_vnops.c,v retrieving revision 1.119 diff -u -r1.119 nfs_vnops.c --- nfs_vnops.c 1999/01/27 22:45:49 1.119 +++ nfs_vnops.c 1999/02/06 01:56:23 @@ -1567,6 +1567,19 @@ } /* +* We have to flush B_DELWRI data prior to renaming +* the file. If we don't, the delayed-write buffers +* can be flushed out later after the file has gone stale +* under NFSV3. NFSV2 does not have this problem because +* ( as far as I can tell ) it flushes dirty buffers more +* often. +*/ + + VOP_FSYNC(fvp, fcnp-cn_cred, MNT_WAIT, fcnp-cn_proc); + if (tvp) + VOP_FSYNC(tvp, tcnp-cn_cred, MNT_WAIT, tcnp-cn_proc); + + /* * If the tvp exists and is in use, sillyrename it before doing the * rename of the new file over it. * XXX Can't sillyrename a directory. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr
As I writed some time before, I always get the wrong results if I generate the termcap.db in an NFSv3 mounted directory. It doesn't matter which machine is the NFS server (tried Solaris 7 and the NFS client machine itself). The generated file has *always* the wrong size (always the same: 1077760 Bytes, instead of 1245184 Bytes, which it should have). With NFSv2 the output is OK. 1077760 seems to be correct. The different sizes are caused by the db library believing that statbuf.st_blksize actually gives the optimal blocksize for I/O. For nfsv3, st_blksize is 512, and this gives a smaller database, but for nfsv2 st_blksize seems to be determined by the server. I get the following results after hacking the db library to use a fixed blocksize: blocksize 8192: ufs db file size = nfs db file size = 1245184, and files same blocksize 512: ufs db file size = nfs db file size = 1077760, but files differ The differences seem to be mostly for randomly sized bunches of \0's appearing at different places in the files. cap_mkdb is incredibly slow (140 seconds on a P5/133 for an nfs output file). Ahh, this sounds reasonable. I should have noticed earlier by myself. On my home machine I recently installed another 1GB (actually 997MB) drive. In order to be able to make a release on this disk I created the filesystem with a 4096/512 block size. This saves approx. 50MB for the whole installation. With this block size, my termcap.db is only 765952 Bytes in size. It is interesting that a 4k block size generates a much smaller file than a block size of 512 Bytes... Does this have something to do that 4k is also the page size? NFSv3 doesn't seem to have a st_blksize field. Thus it is set to 512. For v2 it should be the same as for the corresponding local filesystem on the other end. The difference in the \0 Bytes is related by reading the source file: cap_mkdb uses the stdio functions to read in the source file. This again uses fstat() to obtain the optimal block size. Now more comfortable with NFSv3, I will give it another try. I hope my release builds will speed up a little. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: locale errors
I think I have found a solution. The problem with the current definition is, that ss is folded into one character, while ß should be expanded to ss and sorted accordingly. I read the manual pages of colldef and found a solution, which sorted my test patterns right. ndex: data/de_DE.ISO_8859-1.src === RCS file: /data/cvs/src/usr.bin/colldef/data/de_DE.ISO_8859-1.src,v retrieving revision 1.4 diff -c -r1.4 de_DE.ISO_8859-1.src *** de_DE.ISO_8859-1.src1997/03/10 21:59:53 1.4 --- de_DE.ISO_8859-1.src1999/02/10 14:52:52 *** *** 3,8 --- 3,9 # $Id: de_DE.ISO_8859-1.src,v 1.4 1997/03/10 21:59:53 ache Exp $ # charmap map.ISO_8859-1 + substitute \xdf with ss order \ # controls NU;...;US;PA;...;AC;\ *** *** 29,35 b;(c,c,);d;(e,e',e!,e/,e:);\ f;g;h;(i,i',i!,i/,i:);\ j;...;m;(n,n?);(o,o',o!,o/,o:,o?,o//);\ ! p;...;r;s;(ss,ss);t;(u,u',u!,u/,u:);\ v;w;x;(y,y',y:);z;\ d-;th;\ # --- 30,36 b;(c,c,);d;(e,e',e!,e/,e:);\ f;g;h;(i,i',i!,i/,i:);\ j;...;m;(n,n?);(o,o',o!,o/,o:,o?,o//);\ ! p;...;r;s;ss;t;(u,u',u!,u/,u:);\ v;w;x;(y,y',y:);z;\ d-;th;\ # This patch now sorts successfully my test words: ausarbeiten aussagen außer aussuchen austragen auszahlen Any negative side effects by this patch? [Why does ss have to be somewhere in the order statement although it has been substituted by some other characters? If I remove the ss in the order statement, colldef won't compile the file. The position of ss doesn't even matter...] BTW It is ugly you cannot use symbols on the LHS of substitute. Daniel Andrey A. Chernov schrieb: On Thu, Feb 04, 1999 at 07:38:12AM +0100, J Wunsch wrote: Well, not completely. :) For testing, i've restored the file from before my change, and it missorts similarly. I'm probably too stupid to understand all of this collate stuff. So far, i haven't been able to come up with any locale definition that does the right thing for every input. I mean no particular commit but whole idea how to sort doubled letters - it comes from you, I can't invent this. Collating scheme is very simple - we have two sorting orders - primary and secondary (f.e. Posix have four levels for Unicode). If two strings are the same by primary order, they compare using secondary one. That's all. I will apreciate your any decision regarding to DE locale, fixing, backing out etc. since I even can't display characters you use in your example, nor have strong desire to dig in DE language area starting from zero background. -- Andrey A. Chernov a...@null.net MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: locale errors
My locale is set do de_DE.ISO_8859-1, not de_DE.ASCII If I type 2 characters ss, I mean 2 characters ss. If I type ß I mean the single character ß. This sorting behaviour is just wrong. Not every apperence of ss even in pure ASCII does mean ß. I suggest you set LC_COLLATE to C, then it sorts in the good old fashioned way its meant to be. (like this on Solaris 7: Assel aSS asen ass asse assel assen aß aßen ) The locales were introduced to be used. I want words with umlauts to be sorted the right way, not somewhere at the end of the section/file. Solaris isn't the problem. FreeBSD treats two character strings special, which is wrong IMHO. I want FreeBSD to sort the same way as Solaris: No special interpretation of ss, which would be right on some cases, wrong on other (wrong on all cases if we use phone book sorting) The only LC_ variable which is not set to de (de_DE.ISO_8859-1 on FreeBSD) is LC_NUMERIC. I don't want to convert all awk scripts... Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr
Matt wrote: This is very odd. This is the approximate backtrace that I get when I throw my test machine into DDB: [..] What is happening is that I am doing a 'make installworld' on my test machine with / and /usr NFS V3 mounted R+W. I also have come to the conclusion that NFSv3 is badly broken. I switched all my R/W mounts back to NFSv2 and I am happy again. I can do a full make relase with an NFS mounted chroot directory with no problems, while I have seen many problems with v3 mounts. One thing to lock up the system (probably only the filesystem code, I can still switch virtual screens with Alt+Fx, but getty cannot start /usr/bin/login) if I mount NFSv3 with the -l flag. I tried to track down some of the problems doing a network snoop and noticed something interesting: NFSv3 seems to produce more than twice the packets during file write than NFSv2 Is this true. There are many more getattr() calls with NFSv3 than with NFSv2. Since my NFS server exports one filesystem exclusively to one FreeBSD machine (which is a little short on disk space), I also tried some tricks for speedup. I just mounted one big file, vnconfig'd, newfs'd it and mounted it via UFS. But unfortunately the machine panic'd really fast during filesystem activity. My tests on this are 3-4 months old though, I will give it another try. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: locale errors
J Wunsch schrieb: As Andrey A. Chernov wrote: I suggest removing any multi character definition out of the collate files. It was Joerg initiative, I don't know DE enough to judge here. Please resolve this problem with him (CC'ed). Well, not completely. :) For testing, i've restored the file from before my change, and it missorts similarly. I'm probably too stupid to understand all of this collate stuff. So far, i haven't been able to come up with any locale definition that does the right thing for every input. To make matters worse, German doesn't even have a single collate defintion at all. There are at least two dissenting definitions: one is the phonebook sorting order, and the other one (certainly more widely accepted and thus should be the base of our collate definition) the `Duden' (German dictionary). According to my Duden, the following words Maße Maßeinheit Masse Massaua Massel should be sorted like: Massaua Maße Masse Maßeinheit Massel If anybody could come up with a set of collate definition files that does this, it probably would be the right thing. ;) Maybe it's simply impossible to express using the current collate stuff? It is impossible. The collate couldn't detect concatenated words, which sould sort the usual way: aussetzen austreiben (just a simple example) I noticed the difference while looking into the /R/dist/src directory during a make release. ssys.XX was sorted behind susrbin.XX in ls output. I suggest just backing out the stuff with multi character locale settings because it is bogus. We should just use the simple phonebook sorting, because it is easier to implement, and the people are more familiar with it. Duden isn't always right (very true since last year for some parts in northern Germany) Daniel P.S. Solaris does sorting the easy way (at least for LC_COLLATE=de.ISO8859-15 and LC_COLLATE=de) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: locale errors
Ladavac Marino schrieb: -Original Message- From: D. Rock [SMTP:r...@cs.uni-sb.de] Sent: Thursday, February 04, 1999 10:36 AM To: Joerg Wunsch Cc: Andrey A. Chernov; curr...@freebsd.org Subject: Re: locale errors It is impossible. The collate couldn't detect concatenated words, which sould sort the usual way: aussetzen austreiben (just a simple example) [ML] Shouldn't ß (scharfes-s, sz) be collated as SZ which it really is? /Marino You will still get into the same problem (Auszeit) Also Duden explicitly states, sz should be only used as a last resort, to avoid misinterpretation. But the original example shows that Duden suggests treating ss and ß equal in sorting. Introducing sz just produces additional confusion. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
locale errors
While browsing through some directories I noticed an annoying error in locale based sorting. My LANG is set to de_DE.ISO_8859-1 Sorting treats ss as a single character instead of two. This leads to some interesting (at least) errors in displaying sorted output. My locale is set do de_DE.ISO_8859-1, not de_DE.ASCII If I type 2 characters ss, I mean 2 characters ss. If I type ß I mean the single character ß. This sorting behaviour is just wrong. Not every apperence of ss even in pure ASCII does mean ß. I suggest removing any multi character definition out of the collate files. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
No CD-ROM support in boot.flp?
jkh 1999/01/26 07:14:11 PST Modified files: release/scripts doFS.sh dokern.sh Log: 1. Adjust fs sizes to get floppies back under control. 2. Viciously slash all CD support out of boot.flp. It's basically just a net boot floppy now. Revision ChangesPath 1.22 +1 -1 src/release/scripts/doFS.sh 1.10 +13 -4 src/release/scripts/dokern.sh Does this mean, it is now pointless to use boot.flp as a boot image for CD-ROMs: I can boot from the CD, but not install... Are there any plans to create another boot disk (cdrom.flp?), 2.88MB in size especially for CD-ROM boots? Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
dirty fs after apm power off
I have noticed this behaviour on at least one machine. If I shutdown the machine with apm power off, the filesystem is dirty and has to been checked on the next reboot. It seems, the power is cut too fast. I don't have any problems with reboots. It seems the drive doesn't have the time to write the superblock back to disk. I simply put a DELAY(400) in the apm_power_off() routine and the problem fades away. Any thoughts on doing this a configurable option? It doesn't break anything, it only takes a few seconds longer for the machine to power off. The drive is a Maxtor Diamond Max (90432D2) 4GB IDE drive in an Asus SP98 board. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: dirty fs after apm power off
This is what I also thought. But how do I turn off write caching on IDE disks. I know how to do on SCSI bit (mode page 8 byte 2 bit 2 clear), but I have absolutely no clue how this can be achieved on IDE disks. I normally turn off write caching on all drives I install. The drive shouldn't shuffle the carefully sorted file system blocks. Daniel probably the drive needs write-caching turned off... On Sat, 23 Jan 1999, D. Rock wrote: I have noticed this behaviour on at least one machine. If I shutdown the machine with apm power off, the filesystem is dirty and has to been checked on the next reboot. It seems, the power is cut too fast. I don't have any problems with reboots. It seems the drive doesn't have the time to write the superblock back to disk. I simply put a DELAY(400) in the apm_power_off() routine and the problem fades away. Any thoughts on doing this a configurable option? It doesn't break anything, it only takes a few seconds longer for the machine to power off. The drive is a Maxtor Diamond Max (90432D2) 4GB IDE drive in an Asus SP98 board. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS v3 issue
Matthew Dillon schrieb: :With NFS v3 there seem still to be some open issues. :Im running the latest (4.0)-current with the new vm/NFS changes. :While I haven't found any problems with NFSv2 so far, v3 still seems to make :trouble. : :I noticed the error some months ago, while my /usr/obj was NFS mounted, and :a build failed while making termcap.db. Today, I gave it another try. :I copied /usr/src/share/termcap into an NFS mounted directory and did :a make. I compared the output of termcap.db with the one build on the local :drive. :While the NFS mounted one was only 1077760 bytes in size, the correct :size (from the local build) should be 1245184 bytes. I did the build :several times, everytime I got the same values. I then remounted the :direcory NFSv2. Now the build produced the right file (in size and content). : :The NFS Server is a Solaris 7 machine. : :Can anyone else confirm this error? : :Daniel I can't help you here, but I want to make sure: The problems you are having are the same problems you were having a few months ago? ( I want to make sure I haven't introduced new problems in -4.x, and if I have to fix them ASAP! ). I am not sure if they are the same, but it seems so: A make world with /usr/obj NFS mounted worked up to the point where the termcap was built. Now only the error is slightly different: A few months ago, cap_mkdb exited with SIG 11, now it succeeds but generates the wrong file. I think it's the same bug. The SEGV maybe have gone away because of some library reordering over the months. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
NFS v3 issue
With NFS v3 there seem still to be some open issues. Im running the latest (4.0)-current with the new vm/NFS changes. While I haven't found any problems with NFSv2 so far, v3 still seems to make trouble. I noticed the error some months ago, while my /usr/obj was NFS mounted, and a build failed while making termcap.db. Today, I gave it another try. I copied /usr/src/share/termcap into an NFS mounted directory and did a make. I compared the output of termcap.db with the one build on the local drive. While the NFS mounted one was only 1077760 bytes in size, the correct size (from the local build) should be 1245184 bytes. I did the build several times, everytime I got the same values. I then remounted the direcory NFSv2. Now the build produced the right file (in size and content). The NFS Server is a Solaris 7 machine. Can anyone else confirm this error? Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
libexpcrypt?
Hi, after todays build I wasn't able to login: Instead of installing libdescrypt.* and linking libcrypt.* to libdescrypt.* I suddenly got libexpcrypt.* files, with no DES code in. It seems the international secure distribution isn't in sync any more. I am missing /usr/src/secure/lib/libcrypt/crypt-des.c I have also noticed the major number in the library bump. Is it safe for the transition period still link libcrypt.so.3 to libdescrypt.so.2? Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS problem found - pleaes try this patch.
This patch seems to fix my NFS problems. I started a make release yesterday and it is still running (It's a slow machine). No problems so far. The chroot dir is NFSv2/UDP mounted. Thanks, Daniel Luoqi Chen schrieb: The check is correct and should be there, the B_CACHE bit was cleared because I made a mistake when setting the valid bit in the vm page. Index: vfs_bio.c === RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.192 diff -u -r1.192 vfs_bio.c --- vfs_bio.c 1999/01/12 11:59:34 1.192 +++ vfs_bio.c 1999/01/18 14:45:33 @@ -2171,7 +2171,7 @@ (vm_offset_t) (soff PAGE_MASK), (vm_offset_t) (eoff - soff)); sv = (bp-b_offset + bp-b_validoff + DEV_BSIZE - 1) ~(DEV_BSIZE - 1); - ev = (bp-b_offset + bp-b_validend) ~(DEV_BSIZE - 1); + ev = (bp-b_offset + bp-b_validend + DEV_BSIZE - 1) ~(DEV_BSIZE - 1); soff = qmax(sv, soff); eoff = qmin(ev, eoff); } Note the calculation of ev, the original code was a round-up and I changed it to round-down in my -r1.188 commit (I thought it was a bug in the original code, but it was actually me who didn't understand the nfs code well enough). -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS woes: getting worse?
I have similar experiences. I sometimes do a make release with an NFS mounted chroot environment. My latest successful build is dated from Dec 21. All of the later builds (starting Jan 6th) failed. The error seems to be very deterministic though. I have at least a lot of garbage in chroot/usr/include, with the usual 0-Bytes starting on page boundary (but never the first page) up to the end of the file. I looked at the cvs log, but the only NFS/vfs/vm change I discovered (I'm using only NFSv2/UDP, so the one for NFSv3 on Solaris 7 doesn't apply) were the removal of waslocked paramter on Jan 5th. I don't know if this is related, though. Daniel Matthew Dillon schrieb: :Forgot to mention, this happens with a read-only NFS tree too. I was :running builds on the client with a shared /usr/ports and WRKDIRPREFIX :pointing to a local directory, and the build will topple over in the :middle unable to find a Makefile on the server or something. : :That is the problem that went away with the server load. : :Satoshi I am running a Dec 24th CVS tree while working on the first set of VM commits. I've been using read-only NFS mounts of /usr/src on diskless workstations in order to do make -j6 buildworld runs on them ( /usr/obj being a big 300 MB MFS filesystem on the same workstation, swap-backed, where swap itself is BOOTP NFS based swap). I have not experienced any NFS corruption at all, so whatever blew NFS up must have been committed after Dec 24th. Note that I *AM* using luoqi's VFS/BIO patches, which fixed the msdosfs mount-after-ufs-mount-attempt crash. I'll have time to help track down the NFS problems after the tree splits and I can commit the new swapper, but I can't update my tree until then. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ESS 1868 driver, again
I read the last mails regarding problems with their ESS 1868 boards. Well, at least it is partially working for them. I didn't have any luck with the driver for some time now. I couldn't get a single tone. With the old voxware driver, sound worked at least partially (44.1 kHz, 8 Bit, mono), but with the new driver I didn't have any luck at all. Here my configuration: device pcm0at isa? port 0x220 irq 5 drq 1 flags 0x15 and during boot: pcm0: ESS1868 rev 11 at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0 If I try to play something, I only get the following error from the driver: sb_dspwr(0xc0) timed out. The old voxware driver: controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 device sbxvi0 at isa? port 0x220 irq 5 drq 5 conflicts device sbmidi0 at isa? port 0x330 device opl0at isa? port 0x388 device mpu0at isa? port 0x330 sb0 at port 0x220 irq 5 drq 1 on isa0 Hmm... Could this be an ESS688 based card (rev 11) snd0: SoundBlaster Pro 3.1 isa_compat: didn't get ports for sbxvi sbxvi0 at port 0x220 irq 5 drq 5 on isa0 isa_compat: didn't get ports for sbxvi snd0: SoundBlaster 16 3.1 WARNING: "snd" is usurping "snd"'s cdevsw[] opl0 at port 0x388 on isa0 snd0: Yamaha OPL3 FM WARNING: "snd" is usurping "snd"'s cdevsw[] Any hints are welcome. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
