Re: ATAng no PIO fallback?
On Tuesday 26 August 2003 10:27 pm, Anish Mistry wrote: After removing atapicam from my kernel, so no panics on boot I decided to see it DMA was fixed for my CD/DVD combo drive. I changed the hw.ata.atapi_dma=0 to hw.ata.atapi_dma=1 in my /boot/loader.conf. After a reboot I tried to access my cdrom drive, and got the following error messages, which is very similar to the messages when trying to dma before ATAng: Aug 26 22:09:34 littleguy kernel: acd0: WARNING - READ_CD recovered from missing interrupt Aug 26 22:09:34 littleguy kernel: acd0: WARNING - READ_CD UDMA ICRC error (retrying request) The problem is that before with DMA enabled it would try dma a few times fail, and then fall back to PIO, whcih though annoying still left the drive in a useable condition. Where as now the drive just stays stuck and unusable. . Anyone thinking about looking into this? I'll just submit a PR, in a day or 2 if there is no resposne. Thanks, -- Anish Mistry pgp0.pgp Description: signature
[current tinderbox] failure on ia64/ia64
TB --- 2003-08-27 21:49:15 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-08-27 21:49:15 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-08-27 21:52:30 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-08-27 22:58:09 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Aug 27 22:58:09 GMT 2003 Kernel build for GENERIC completed on Wed Aug 27 23:13:45 GMT 2003 TB --- 2003-08-27 23:13:45 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-08-27 23:13:45 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Aug 27 23:13:45 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/fs/smbfs/smbfs_node.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/fs/smbfs/smbfs_smb.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/fs/smbfs/smbfs_subr.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127
Recent sound change still broken?
My patch http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/54810 ever worked well for my old Creative sound card, the device is probed, but now no sound at all. :-( dmesg: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Thu Aug 28 06:44:25 CST 2003 [EMAIL PROTECTED]:/home/davidxu/src/sys/i386/compile/mpnw Preloaded elf kernel /boot/kernel/kernel at 0xc04a7000. Preloaded elf module /boot/kernel/snd_es137x.ko at 0xc04a71f4. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04a72a4. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (999.67-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 805240832 (767 MB) avail memory = 776982528 (740 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdda0 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 IOAPIC #0 intpin 11 - irq 2 IOAPIC #0 intpin 10 - irq 5 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xf000-0xf3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686B UDMA100 controller port 0xa000-0xa00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xa400-0xa41f irq 2 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: OmniVision OV511+ Camera, rev 1.00/1.00, addr 2 uhci1: VIA 83C572 USB controller port 0xa800-0xa81f irq 2 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 7.4 (no driver attached) fxp0: Intel 82557 Pro/100 Ethernet port 0xb800-0xb81f mem 0xf700-0xf70f,0xf710-0xf7100fff irq 2 at device 11.0 on pci0 fxp0: Ethernet address 00:a0:c9:5a:41:98 miibus0: MII bus on fxp0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative SB AudioPCI CT4730 port 0xc000-0xc01f,0xbc00-0xbc3f irq 5 at device 12.0 on pci0 pcm0: Creative EV1938 AC97 Codec orm0: Option ROM at iomem 0xc-0xc8fff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) unknown: PNP0700 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0400 can't assign resources (port) APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec ad0: 57241MB ST360021A [116301/16/63] at ata0-master UDMA100 ata1-slave: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED acd0: CDROM ATAPI-CD ROM-DRIVE-52MAX at ata1-master PIO4 SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad0s3a drm0: ATI Radeon QM R200 9100 port 0x9000-0x90ff mem 0xf500-0xf500,0xe800-0xefff irq 2 at device 0.0 on pci1 info: [drm] AGP at 0xf000 64MB info: [drm] Initialized radeon 1.9.0 20020828 on minor 0 info: [drm] Loading R200 Microcode -- David Xu ___ [EMAIL
Re: Recent sound change still broken?
I use es137x module: [EMAIL PROTECTED]:/home/davidxu kldstat Id Refs AddressSize Name 15 0xc010 37fc28 kernel 21 0xc048 6964 snd_es137x.ko 32 0xc0487000 1e554snd_pcm.ko 41 0xc5f0e000 16000radeon.ko David Xu On Thursday 28 August 2003 07:37, David Xu wrote: My patch http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/54810 ever worked well for my old Creative sound card, the device is probed, but now no sound at all. :-( dmesg: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent 5.1-CURRENT kernel panics on acd0 probe/attach, IBM T30
Le 2003-08-27, Lee Damon écrivait : Removing atapicam from my kernel configuration fixed the problem for me as well. Please try the patch I posted on -current under HEADS UP! ATAng committed. Thanks, Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IDE DVD playback on 5.1-CURRENT
On Tue, Aug 26, 2003 at 09:31:45PM -0400, Adam K Kirchhoff wrote: I've asked this same question on freebsd-questions an on #freebsd (freenode), but haven't gotten any answer, so I thought I'd ask on here. ... Is DVD playback just not supported on IDE drives on FreeBSD -CURRENT? This is dated impressions, but ~2 years ago SCSI definitely had better support than IDE. My impression was that SCSI had more standardization and was easier for people to write code for. IMHO, *BSD is doing the right thing by making things look like SCSI (like my USB keyfob-drive, DVD drive over Firewire, etc) and it gets better support by presenting them as SCSI. Take that support away by going native IDE and then you're at the mercy of a specialized device driver that gets a lot less eyeballing. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA-ng
I upgraded to -CURRENT from around 6:00 PM EST (10:00 PM GMT, iirc), a few hours after your message, Soren, and gave it a shot... With the atapicam device. Unfortunately, it doesn't see my IDE cd drive as either an IDE cd drive or a SCSI drive. It's completely missing :-) But, on the + side, at least I'm not getting a kernel panic any more :-) On Wed, 27 Aug 2003, Soren Schmidt wrote: It seems Chris Petrik wrote: Think it would be a wise thing to do is to make a kernel option to use ATAng and one to use the old ATAold or something you commited a important part of the system without throughly testing it and most people dont use SMP i would think to do it this way then when its proven that ATAng is stable and working remove the ATAold stuff and make ATAng default but thats just a sugestion as im having problems too. It sounds to me as if you should not run -current :) Anyhow please upgrade to the latest that should fix the problems with the probe missing some devices. -Søren ___ [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: recent 5.1-CURRENT kernel panics on acd0 probe/attach, IBM T30
Thomas, I tried your patch. Though I know longer get kernel panics, I also don't get FreeBSD to see my IDE CD/DVD drive :-) (as either an IDE or SCSI drive). Adam On Thu, 28 Aug 2003, Thomas Quinot wrote: Le 2003-08-27, Lee Damon écrivait : Removing atapicam from my kernel configuration fixed the problem for me as well. Please try the patch I posted on -current under HEADS UP! ATAng committed. Thanks, Thomas. -- [EMAIL PROTECTED] ___ [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: cvsup failing with ASSERT failed
Ummm, well, when you have a hidden ELF who keeps multiplying all of those ridiculus numbers by 10, of course! ;) It should have been 2GB - oh well. On 27 Aug, Peter Jeremy wrote: On Tue, Aug 26, 2003 at 11:02:08PM -0500, [EMAIL PROTECTED] wrote: A couple of times, now, on both FBSD-5.1-CURRENT and FBSD-4.8-STABLE whilst running with 2MB of RAM, cvsup has croaked with the following error: Out of interest, how do you get either 4.x or 5.x to run in 2MB? I found running 2.x in 4MB was painful and my 4.x kernel is more than 2MB. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IDE DVD playback on 5.1-CURRENT
You might also want/need to change/define a local mplayer configuration ala: /home/.../.mplayer/gui.conf where you can change the runtime configuration paramaters such as: ao_driver = oss:/dev/dsp1 ao_volnorm = no ao_surround = no ao_extra_stereo = no ao_extra_stereo_coefficient = 1.00 ao_oss_mixer = /dev/mixer ao_oss_device = /dev/dsp1 dvd_device = /dev/acd0c cdrom_device = /dev/cdrom using/choosing a different dvd_device and/or ao_oss_device/ao_driver. I have had to change these variables going from 4.8 to 5.1 as different IDE hardware was or was not recognized. On 27 Aug, Daniel C. Sobral wrote: Ian Freislich wrote: Adam K Kirchhoff wrote: I've asked this same question on freebsd-questions an on #freebsd (freenode), but haven't gotten any answer, so I thought I'd ask on here. I'm hoping someone can help me out here. I recently moved a firewire card and DVD drive that had been in my FreeBSD box to another computer. I replaced it with an IDE DVD drive. The probelm is that now I can't get mplayer or vlc to play any DVDs that had previously worked with the firewire drive. I have, of course, made sure that /dev/dvd is a symbolic link to /dev/acd0 instead of /dev/cd0 (as it used to be). The only difference that I can think of is that FreeBSD sees the firewire drive as a scsi drive and sees the ide drive as an ide drive. Have you tried (from mplayer's man page): -dvd-device path to device Override default DVD device name /dev/dvd. Actually, I recall some player on which you just had to mount the dvd, and them point them at the path where the dvd was mounted. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCMCIA trouble with Xircom, CIS is too long -- truncating
In message: [EMAIL PROTECTED] Andreas Klemm [EMAIL PROTECTED] writes: : Hi, : : good and bad news. Good news is that -current installation : CD-Rom (JPSNAP of yesterday) doesn't panic during boot : anymore, which was the case previously (or when inserting : the card). Thanks a lot, this is a very good progress, I'm : very pleased ! : : But the fix opened another problem. The card isn't recognized : by the FreeBSD anymore: yup. like I said before, this just papers over the problem... : What more infos do you need ? How do I fix it? I have a few fixes in my queue, but they don't seem to fix my problem child Home and Away card just yet. I'm likely missing something trivially obvious :-( Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCMCIA trouble with Xircom, CIS is too long -- truncating
In message: [EMAIL PROTECTED] Sergey A. Osokin [EMAIL PROTECTED] writes: : Please comment this lines and add : devicepcic : devicecard 1 : : and recompile your kernel. Let me know does it help you. This uses oldcard rather than newcard. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[no subject]
OK, after checking out Soren's version 1.6 ata-lowlevel.c, rebuilding the kernel, and rebooting I got the following kernel boot message (attached). The output of atacontrol list is about the same as before as well. My last build (using 1.4 ata-lowlevel) booted up ok and at least my slave DVDROM on the secondary channel probed ok. Now both the master CDRW device and the DVDROM no longer probe ok. My last good kernel (pre-ATAng with atapicam enabled) boot is also attached. Good pre-ATAng kernel with atapicam: cam: using minimum scsi_delay (100ms) Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #16: Wed Aug 20 00:06:46 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL Preloaded elf kernel /boot/kernel.good/kernel at 0xc046e000. Preloaded elf module /boot/kernel/acpi.ko at 0xc046e230. Calibrating clock(s) ... i8254 clock: 1193155 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 737022840 Hz CPU: Intel Pentium III (737.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 535736320 (510 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00495000 - 0x1f5c9fff, 521359360 bytes (127285 pages) avail memory = 515514368 (491 MB) bios32: Found BIOS32 Service Directory header at 0xc00f1430 bios32: Entry = 0xf0bf0 (c00f0bf0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdf0 pnpbios: Found PnP BIOS data at 0xc00fc070 pnpbios: Entry = f:c0a0 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS CUSL2on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=11308086) pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00f1360 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 72540A 0x60 3 4 5 7 9 10 11 12 slot 72540B 0x61 3 4 5 7 9 10 11 12 embedded02A 0x60 3 4 5 7 9 10 11 12 embedded0 31A 0x60 3 4 5 7 9 10 11 12 embedded0 31B 0x61 3 4 5 7 9 10 11 12 embedded0 31C 0x6b 3 4 5 7 9 10 11 12 embedded0 31D 0x63 3 4 5 7 9 10 11 12 slot 1 19A 0x69 3 4 5 7 9 10 11 12 slot 1 19B 0x6a 3 4 5 7 9 10 11 12 slot 1 19C 0x6b 3 4 5 7 9 10 11 12 slot 1 19D 0x68 3 4 5 7 9 10 11 12 slot 2 1 10A 0x6a 3 4 5 7 9 10 11 12 slot 2 1 10B 0x6b 3 4 5 7 9 10 11 12 slot 2 1 10C 0x68 3 4 5 7 9 10 11 12 slot 2 1 10D 0x69 3 4 5 7 9 10 11 12 slot 3 1 11A 0x6b 3 4 5 7 9 10 11 12 slot 3 1 11B 0x68 3 4 5 7 9 10 11 12 slot 3 1 11C 0x69 3 4 5 7 9 10 11 12 slot 3 1 11D 0x6a 3 4 5 7 9 10 11 12 slot 4 1 12A 0x68 3 4 5 7 9 10 11 12 slot 4 1 12B 0x69 3 4 5 7 9 10 11 12 slot 4 1 12C 0x6a 3 4 5 7 9 10 11 12 slot 4 1 12D 0x6b 3 4 5 7 9 10 11 12 slot 5 1 13A 0x69 3 4 5 7 9 10 11 12 slot 5 1 13B 0x6a 3 4 5 7 9 10 11 12 slot 5 1 13C 0x6b 3 4 5 7 9 10 11 12 slot 5 1 13D 0x68 3 4 5 7 9 10 11 12 slot 6 1 14A 0x62 3 4 5 7 9 10 11 12 slot 6 1 14B 0x63 3 4 5 7 9 10 11 12 slot 6 1 14C 0x60 3 4 5 7 9 10 11 12 slot 6 1 14D 0x61 3 4 5 7 9 10 11 12 embedded18A 0x68 3 4 5 7 9 10 11 12 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks BAD min = 3, max = 786, width = 783 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks BAD min = 3, max = 795, width = 792 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks BAD min = 3, max = 785, width = 782 ACPI timer looks BAD min = 3, max = 784, width = 781 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks BAD min = 3, max = 812, width = 809 Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
Re: nfs tranfers hang in state getblck or nfsread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In this configuration I see a lot of nfs server ...: is not responding and nfs server ...: is alive again when I copy large files (e.g. a CD image). All of them happen in the same second. I haven't looked at the state or priority of the cp process when this happens. I'm also seeing a similar problem - I have a cluster of high-volume mailservers delivering mail over nfs to maildirs on a netapp. The cluster was all 4-stable, but I decided to mix a couple of 5.1 boxes in to see how they would do. The 5.1 boxes accepted and queued mail as well as the 4-stable boxes, but delivering the mail into the maildirs over nfs, I kept seeing those short-lived hangs, and so the queues started to back up as the boxes were accepting mail faster than they could deliver it. My mounts are all nfsv3 over udp. -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE/TYRhswXMWWtptckRAl7XAKDqAe2Z3HnT7bb+J6gPchMfxGo2fQCaA8u0 8wKNDwTh8NIFkLUNdi2HV2Q= =g19M -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Someone help me understand this...?
On Wed, 27 Aug 2003, Joe Greco wrote:
I've got a weirdness with kill(2).
This code is out of Diablo, the news package, and has been working fine for
some years. It apparently works fine on other OS's.
In the Diablo model, the parent process may choose to tell its children to
update status via a signal. The loop basically consists of going through
and issuing a SIGALRM.
This stopped working a while ago, don't know precisely when. I was in the
process of debugging it today and ran into this.
The specific OS below is 5.1-RELEASE but apparently this happens on 4.8 as
well.
Perhaps the children are setuid, the parent doesn't have appropriate
privelege and you are mistaken about this happening under 4.8 as well.
In 5.x since at least rev.1.80 of kern_prot.c, only certain signals
not including SIGALRM can be sent from unprivileged processes to setuid
processes.
This is very UN-unixlike although it is permitted as an-implementation-
defined restriction in at least POSIX.1-2001. It breaks^Wexposes bugs
in some old POSIX test programs and I don't have many security concerns
so I just disable it locally:
%%%
Index: kern_prot.c
===
RCS file: /home/ncvs/src/sys/kern/kern_prot.c,v
retrieving revision 1.175
diff -u -2 -r1.175 kern_prot.c
--- kern_prot.c 13 Jul 2003 01:22:20 - 1.175
+++ kern_prot.c 17 Aug 2003 04:26:00 -
@@ -1395,4 +1387,5 @@
return (error);
+#if 0
/*
* UNIX signal semantics depend on the status of the P_SUGID
@@ -1425,4 +1418,5 @@
}
}
+#endif
/*
%%%
Wot? Why can't I send it a signal?
I've read kill(2) rather carefully and cannot find the reason. It says,
For a process to have permission to send a signal to a process designated
by pid, the real or effective user ID of the receiving process must match
that of the sending process or the user must have appropriate privileges
(such as given by a set-user-ID program or the user is the super-user).
The implementation-defined restrictions are not documented, of course ;-).
Well, the sending and receiving processes both clearly have equal uid/euid.
We're not running in a jail, so I don't expect any issues there.
The parent process did actually start as root and then shed privilege with
struct passwd *pw = getpwnam(news);
struct group *gr = getgrnam(news);
gid_t gid;
if (pw == NULL) {
perror(getpwnam('news'));
exit(1);
}
if (gr == NULL) {
perror(getgrnam('news'));
exit(1);
}
gid = gr-gr_gid;
setgroups(1, gid);
setgid(gr-gr_gid);
setuid(pw-pw_uid);
so that looks all well and fine... so why can't it kill its own children,
and why can't I kill one of its children from a shell with equivalent
uid/euid?
Changing the ids is one way to make the process setuid (setuid-on-exec is
another but that doesn't seem to be the problem here). The relevant setuid
bit (P_SUGID) is normally cleared on exec, but perhaps it isn't here,
either because the children don't exec or the effective ids don't match
the real ids at the time of the exec.
I know there's been some paranoia about signal delivery and all that, but
my searching hasn't turned up anything that would explain this. Certainly
the manual page ought to be updated if this is a new expected behaviour or
something... at least some clue as to why it might fail would be helpful.
Certainly. It is incomplete even not counting complications for jails
or other implementation-defined restrictions related to appropriate
privilege.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Someone help me understand this...?
On Wed, 27 Aug 2003, Joe Greco wrote:
I've got a weirdness with kill(2).
This code is out of Diablo, the news package, and has been working fine for
some years. It apparently works fine on other OS's.
In the Diablo model, the parent process may choose to tell its children to
update status via a signal. The loop basically consists of going through
and issuing a SIGALRM.
This stopped working a while ago, don't know precisely when. I was in the
process of debugging it today and ran into this.
The specific OS below is 5.1-RELEASE but apparently this happens on 4.8 as
well.
Perhaps the children are setuid, the parent doesn't have appropriate
privelege and you are mistaken about this happening under 4.8 as well.
Well, the parent process does the code I listed below early on in the
initialization process - it pretty much does a little initialization,
opens its socket (119), sheds privilege, and begins accepting conns.
It then forks off processes for each connection.
The program itself is not a suid executable, but rather relies on being
launched by a root user.
I'm not sure what appropriate privilege would be. If both the uid/euid
of the parent match both the uid/euid of the child, I would expect to be
able to kill the process...
Client complains about the resulting problems also happening under 4.8
servers. Dunno. Could possibly be a separate issue.
In 5.x since at least rev.1.80 of kern_prot.c, only certain signals
not including SIGALRM can be sent from unprivileged processes to setuid
processes.
This is very UN-unixlike although it is permitted as an-implementation-
defined restriction in at least POSIX.1-2001. It breaks^Wexposes bugs
in some old POSIX test programs and I don't have many security concerns
so I just disable it locally:
%%%
Index: kern_prot.c
===
RCS file: /home/ncvs/src/sys/kern/kern_prot.c,v
retrieving revision 1.175
diff -u -2 -r1.175 kern_prot.c
--- kern_prot.c 13 Jul 2003 01:22:20 - 1.175
+++ kern_prot.c 17 Aug 2003 04:26:00 -
@@ -1395,4 +1387,5 @@
return (error);
+#if 0
/*
* UNIX signal semantics depend on the status of the P_SUGID
@@ -1425,4 +1418,5 @@
}
}
+#endif
/*
%%%
Wot? Why can't I send it a signal?
I've read kill(2) rather carefully and cannot find the reason. It says,
For a process to have permission to send a signal to a process designated
by pid, the real or effective user ID of the receiving process must match
that of the sending process or the user must have appropriate privileges
(such as given by a set-user-ID program or the user is the super-user).
The implementation-defined restrictions are not documented, of course ;-).
Well, the sending and receiving processes both clearly have equal uid/euid.
We're not running in a jail, so I don't expect any issues there.
The parent process did actually start as root and then shed privilege with
struct passwd *pw = getpwnam(news);
struct group *gr = getgrnam(news);
gid_t gid;
if (pw == NULL) {
perror(getpwnam('news'));
exit(1);
}
if (gr == NULL) {
perror(getgrnam('news'));
exit(1);
}
gid = gr-gr_gid;
setgroups(1, gid);
setgid(gr-gr_gid);
setuid(pw-pw_uid);
so that looks all well and fine... so why can't it kill its own children,
and why can't I kill one of its children from a shell with equivalent
uid/euid?
Changing the ids is one way to make the process setuid (setuid-on-exec is
another but that doesn't seem to be the problem here). The relevant setuid
bit (P_SUGID) is normally cleared on exec, but perhaps it isn't here,
either because the children don't exec or the effective ids don't match
the real ids at the time of the exec.
The children aren't spawned via exec, but clearly they have equal
uid/euid's.
So what you're saying, I guess, is it's not supposed to work.
I guess I'm a bit confused by the logic of this. I've seen numerous
forking daemons over the years that do this sort of thing (not to mention
I've written a number). I've always viewed shedding root privs as being a
good thing... Was it really intended to break things in this manner?
I know there's been some paranoia about signal delivery and all that, but
my searching hasn't turned up anything that would explain this. Certainly
the manual page ought to be updated if this is a new expected behaviour or
something... at least some clue as to why it might fail would be helpful.
Certainly. It is incomplete even not counting complications for jails
or other implementation-defined restrictions related to appropriate
privilege.
Sigh.
Thanks for the note,
... JG
--
Joe Greco - sol.net Network
[patch] usb ohci suspend/resume
If you have trouble with suspend/resume killing your usb devices try out the
attached patch (ohci only, unless someone want to adapt to uhci). I think I
finally got it working, at least it works with my mouse and no panics if you
leave devices plugged during a suspend/resume cycle.
Same as attached in case it gets stripped.
http://am-productions.biz/docs/ohci-usb-suspend.patch
--
Anish Mistry
diff -u usb.orig/ohci.c usb/ohci.c
--- usb.orig/ohci.c Thu Aug 28 00:54:09 2003
+++ usb/ohci.c Thu Aug 28 01:04:43 2003
@@ -1020,7 +1020,7 @@
DPRINTF((ohci_shutdown: stopping the HC\n));
OWRITE4(sc, OHCI_CONTROL, OHCI_HCFS_RESET);
}
-
+#endif
/*
* Handle suspend/resume.
*
@@ -1028,6 +1028,86 @@
* called from an intterupt context. This is all right since we
* are almost suspended anyway.
*/
+usbd_status ohci_resume(struct ohci_softc *sc)
+{
+/* return ohci_init(sc);*/
+ int s;
+ u_int32_t ctl, ival, hcr, fm, per, rev, desca;
+ s = splusb();
+ DPRINTF((ohci_resume: start\n));
+#if defined(__OpenBSD__)
+ printf(,);
+#else
+ printf(%s:, USBDEVNAME(sc-sc_bus.bdev));
+#endif
+ rev = OREAD4(sc, OHCI_REVISION);
+ printf( OHCI version %d.%d%s\n, OHCI_REV_HI(rev), OHCI_REV_LO(rev),
+ OHCI_REV_LEGACY(rev) ? , legacy support : );
+ /* Some broken BIOSes do not recover these values */
+ OWRITE4(sc, OHCI_HCCA, DMAADDR(sc-sc_hccadma, 0));
+ OWRITE4(sc, OHCI_CONTROL_HEAD_ED, sc-sc_ctrl_head-physaddr);
+ OWRITE4(sc, OHCI_BULK_HEAD_ED, sc-sc_bulk_head-physaddr);
+ if (sc-sc_intre)
+ OWRITE4(sc, OHCI_INTERRUPT_ENABLE,
+ sc-sc_intre (OHCI_ALL_INTRS | OHCI_MIE));
+ if (sc-sc_control)
+ ctl = sc-sc_control;
+ else
+ ctl = OREAD4(sc, OHCI_CONTROL);
+ ctl |= OHCI_HCFS_RESUME;
+ OWRITE4(sc, OHCI_CONTROL, ctl);
+ usb_delay_ms(sc-sc_bus, USB_RESUME_DELAY);
+ ctl = (ctl ~OHCI_HCFS_MASK) | OHCI_HCFS_OPERATIONAL;
+ OWRITE4(sc, OHCI_CONTROL, ctl);
+ usb_delay_ms(sc-sc_bus, USB_RESUME_RECOVERY);
+ sc-sc_control = sc-sc_intre = 0;
+ /* disable all interrupts and then switch on all desired interrupts */
+ OWRITE4(sc, OHCI_INTERRUPT_DISABLE, OHCI_ALL_INTRS);
+ OWRITE4(sc, OHCI_INTERRUPT_ENABLE, sc-sc_eintrs | OHCI_MIE);
+ /* switch on desired functional features */
+ ctl = OREAD4(sc, OHCI_CONTROL);
+ ctl = ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR);
+ ctl |= OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE |
+ OHCI_RATIO_1_4 | OHCI_HCFS_OPERATIONAL;
+ /* And finally start it! */
+ OWRITE4(sc, OHCI_CONTROL, ctl);
+
+ /*
+ * The controller is now OPERATIONAL. Set a some final
+ * registers that should be set earlier, but that the
+ * controller ignores when in the SUSPEND state.
+ */
+ fm = (OREAD4(sc, OHCI_FM_INTERVAL) OHCI_FIT) ^ OHCI_FIT;
+ fm |= OHCI_FSMPS(ival) | ival;
+ OWRITE4(sc, OHCI_FM_INTERVAL, fm);
+ per = OHCI_PERIODIC(ival); /* 90% periodic */
+ OWRITE4(sc, OHCI_PERIODIC_START, per);
+
+ /* Fiddle the No OverCurrent Protection bit to avoid chip bug. */
+ desca = OREAD4(sc, OHCI_RH_DESCRIPTOR_A);
+ OWRITE4(sc, OHCI_RH_DESCRIPTOR_A, desca | OHCI_NOCP);
+ OWRITE4(sc, OHCI_RH_STATUS, OHCI_LPSC); /* Enable port power */
+ usb_delay_ms(sc-sc_bus, OHCI_ENABLE_POWER_DELAY);
+ OWRITE4(sc, OHCI_RH_DESCRIPTOR_A, desca);
+ splx(s);
+ return (USBD_NORMAL_COMPLETION);
+}
+
+usbd_status ohci_suspend(struct ohci_softc *sc)
+{
+ u_int32_t ctl,i;
+ int s;
+
+ s = splhardusb();
+ ctl = OREAD4(sc, OHCI_CONTROL) ~OHCI_HCFS_MASK;
+ ctl |= OHCI_HCFS_SUSPEND;
+ OWRITE4(sc, OHCI_CONTROL, ctl);
+ splx(s);
+
+return (USBD_NORMAL_COMPLETION);
+}
+
+#if defined(__NetBSD__) || defined(__OpenBSD__)
void
ohci_power(int why, void *v)
{
diff -u usb.orig/ohci_pci.c usb/ohci_pci.c
--- usb.orig/ohci_pci.c Thu Aug 28 00:54:09 2003
+++ usb/ohci_pci.c Thu Aug 28 01:16:47 2003
@@ -295,11 +295,43 @@
return 0;
}
+/* implement suspend and resume */
+static int
+ohci_pci_suspend(device_t self)
+{
+ int err;
+ ohci_softc_t *sc = device_get_softc(self);
+ device_printf(self, ohci_pci_suspend: power_state = 0x%08x\n,
+ pci_get_powerstate(self));
+ err = bus_generic_suspend(self);
+ if (err)
+ return err;
+ ohci_suspend(sc);
+ /*usb_delay_ms(sc-sc_bus, USB_RESUME_WAIT);*/
+ return 0;
+}
+
+static int
+ohci_pci_resume(device_t self)
+{
+ ohci_softc_t *sc = device_get_softc(self);
+ device_printf(self, ohci_pci_resume: power_state = 0x%08x\n,
+ pci_get_powerstate(self));
+ ohci_resume(sc);
+ usb_delay_ms(sc-sc_bus, USB_RESUME_DELAY);
+ usb_delay_ms(sc-sc_bus, USB_RESUME_RECOVERY);
+ bus_generic_resume(self);
+
+ return 0;
+}
+
static device_method_t ohci_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, ohci_pci_probe),
DEVMETHOD(device_attach, ohci_pci_attach),
- DEVMETHOD(device_shutdown, bus_generic_shutdown),
+ DEVMETHOD(device_suspend, ohci_pci_suspend),
+ DEVMETHOD(device_resume, ohci_pci_resume),
+
Re: ATAng no PIO fallback?
It seems Anish Mistry wrote: -- Start of PGP signed section. On Tuesday 26 August 2003 10:27 pm, Anish Mistry wrote: After removing atapicam from my kernel, so no panics on boot I decided to see it DMA was fixed for my CD/DVD combo drive. I changed the hw.ata.atapi_dma=0 to hw.ata.atapi_dma=1 in my /boot/loader.conf. After a reboot I tried to access my cdrom drive, and got the following error messages, which is very similar to the messages when trying to dma before ATAng: Aug 26 22:09:34 littleguy kernel: acd0: WARNING - READ_CD recovered from missing interrupt Aug 26 22:09:34 littleguy kernel: acd0: WARNING - READ_CD UDMA ICRC error (retrying request) The problem is that before with DMA enabled it would try dma a few times fail, and then fall back to PIO, whcih though annoying still left the drive in a useable condition. Where as now the drive just stays stuck and unusable. . Anyone thinking about looking into this? I'll just submit a PR, in a day or 2 if there is no resposne. Thanks, There is no PIO fallback in ATAng (so far), if you know that your ATAPI device doesn't do DMA why on earth do you enable it ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HTT on current
Bruce Evans wrote: On Tue, 26 Aug 2003, John Baldwin wrote: On 26-Aug-2003 Yamada Ken Takeshi wrote: [...] One test is not sufficient. -current is also not the best place to test. :) When I first implemented HTT in -current The above times seem slow enough to be partly the result of debugging options in -current. I get buildworld times ranging from 1401 seconds (2002/09/01) to 2427 seconds (2003/05/06) on Athlon XP1600 x 1 depending on configuration and tuning (but never with any expensive debugging options). A Xeon 2.8GHz x 2 should be a bit faster than an old Athlon. Hm, IFAIK I shouldn't have any debug options enabled, but who knows - didn't have time to check more than kernel and malloc. By the way, attached times shows that using HTT speeds up buildworld by 10 (compare HTT/no-HTT) and this is IMHO a real improvement. Many people buy much more expensive processor to get 10% more speed. ... I did 16 trials (first one was throwaway) of back-to-back buildworlds of the same version of -stable using make, make -j2, and make -j4 for the following configurations: UP, HTT, HTT with smp_idle_hlt, and HTT with pause instructions added to stable and smp_idle_hlt. The fastest build time belonged to UP without any -j option. All benchmarks using -j are invalid because of a pessimization in make(1). It sleeps for up to SEL_USEC = 10 usec after completion of every job (average 50 msec). With -j2 this increases !SMP buildworld times of approx. 2000 seconds by approx. 15%. I think it has a smaller effect for larger -j values and for SMP but haven't benchmarked it. This is fixed in NetBSD. I think fixing it was more urgent in NetBSD because NetBSD never changed SEL_USEC from its 4.4Lite default of 50. 50 was large enough to be noticeable even in 1997 when it was reduced in FreeBSD. That would explain the small slow down from -j8 to -j20. But the results seems to me to be schoolbook like: 4 processes per processor as I learned produces best results. Okay, that's so far. Best regards Jens Jens 1) HTT + PAT (-j4) - 4736.474u 569.157s 52:19.56 168.9% 4041+2517k 16977+153222io 5761pf+0w - 4737.875u 571.889s 51:07.10 173.1% 4039+2516k 1519+153172io 450pf+0w - 4734.651u 570.591s 51:51.69 170.4% 4039+2519k 12822+153198io 3264pf+0w 2) HTT + PAT (-j20) - 4754.903u 604.875s 51:10.69 174.5% -3981+2500k 3503+153256io 2952pf+0w - 4770.237u 613.092s 50:46.67 176.6% -3948+2501k 3132+153183io 3143pf+0w - 4772.232u 614.315s 50:45.60 176.8% -3942+2501k 2861+153184io 2963pf+0w 3) no-HTT, PAT, -j4 - 2843.366u 431.189s 57:54.23 94.2% 3981+2475k 1549+153171io 1276pf+0w - 2843.791u 430.378s 58:22.65 93.4% 3983+2476k 1293+153166io 450pf+0w - 2842.366u 432.233s 57:42.22 94.5% 3981+2473k 1277+153170io 450pf+0w 4) HTT, PAT, -j8 - 4761.587u 592.745s 50:40.74 176.0% -3986+2509k 1280+153185io 450pf+0w - 4756.575u 593.777s 50:49.25 175.4% -3991+2509k 1277+153198io 450pf+0w - 4766.158u 595.531s 50:36.81 176.5% -3975+2510k 1284+153182io 450pf+0w 5) Single-User-Mode, HTT, PAT, -j4 - 4732.941u 578.183s 51:08.25 173.0% 4035+2515k 1274+153164io 450pf+0w - 4720.249u 573.533s 51:16.59 172.3% 4034+2515k 1276+153165io 450pf+0w - 4737.491u 575.077s 51:07:71 173.1% 4035+2517k 1273+153173io 450pf+0w 5) Single-User-Mode, HTT, PAT, -j8 - 4756.060u 604.684s 50:33.13 176.7% -3978+2509k 1284+153173io 450pf+0w - 4803.037u 604.068s 52:26.76 171.8% -3904+2511k 17043+153163io 5763pf+0w Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Tue Aug 26 13:39:29 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STATLER Preloaded elf kernel /boot/kernel/kernel at 0xc05b. Preloaded elf module /boot/kernel/acpi.ko at 0xc05b021c. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.86-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 = 1036087296 (988 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 Pentium Pro MTRR support enabled VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc00c52cd (c00052cd) VESA: Matrox Graphics Inc. npx0: math processor on motherboard npx0: INT 16 interface acpi0: A M I OEMXSDT on motherboard pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00f5410 acpi0: power button is handled as a
Re: nfs tranfers hang in state getblck or nfsread
On Wed, 27 Aug 2003 09:06:41 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: I have a very similar configuration, but it sounds like I'm not bumping into the same problem. Are you using NFSv2 or v3, and how many file systems are you mounting? Are you generally using UFS1 or UFS2? Right now, I'm mounting a single UFS2 file system was the root, and I believe right now we always mount NFS roots at NFSv2, which could by why I'm not seeing the same problem... /dev/ad0s2e /big ufs rw1 2 Andro-Beta:/big/mp3 /big/mp3 nfs rw,soft,intr,tcp -b,-w=32768,-r=32768 0 0 Andro-Beta:/big/pics/big/picsnfs rw,soft,intr,tcp -b,-w=32768,-r=32768 0 0 Andro-Beta:/big/Windows /big/Windows nfs rw,soft,intr,tcp -b,-w=32768,-r=32768 0 0 Andro-Beta is a 4.8 system. Bye, Alexander. -- Failure is not an option. It comes bundled with your Microsoft product. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCMCIA trouble with Xircom, CIS is too long -- truncating
On Wed, Aug 27, 2003 at 08:26:21PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Sergey A. Osokin [EMAIL PROTECTED] writes: : Please comment this lines and add : device pcic : device card 1 : : and recompile your kernel. Let me know does it help you. This uses oldcard rather than newcard. Yes, I know. But newcard anyway don't work for me. -- Rgdz,/\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IDE DVD playback on 5.1-CURRENT
Adam K Kirchhoff wrote: Again, no luck. From vlc: [0141] main input: playlist item `dvdold:///dev/[EMAIL PROTECTED],1' [0141] dvd input error: dvdcss cannot open device libdvdread: Using libdvdcss version 1.2.5 for DVD access libdvdread: Could not open /dev/acd0 with libdvdcss. libdvdread: Can't open /dev/acd0 for reading [0141] dvdread input error: libdvdcss cannot open source [0141] vcd input error: no movie tracks found [0141] main input error: no suitable access module for `/://dvdold:///dev/[EMAIL PROTECTED],1 From mplayer: Playing DVD title 1 libdvdread: Could not open device with libdvdcss. libdvdread: Can't open /dev/acd0 for reading Couldn't open DVD device: /dev/acd0 From ogle: libdvdread: Using libdvdcss version 1.2.5 for DVD access libdvdread: Could not open /dev/acd0c with libdvdcss. libdvdread: Can't open /dev/acd0c for reading ERROR[ogle_nav]: faild to open/read the DVD What about: 1) dd if=/dev/acd0 count=1 of=/dev/null 2) dd if=/dev/acd0c count=1 of=/dev/null 3) dd if=/dev/acd0a count=1 of=/dev/null If any of these works, then try that device, and if it still doesn't work, then it's your libdvdcss not having support for the drive. Yet the same DVD in the firewire drive works just fine. The easiest thing to suggest: Continue using the firewire drive; something about the IDE one sucks. 8-). You might also want to make sure the drive is jumpered right (master vs. slave), that it works on regular CDROMs, that it's I can certainly try recompiling the applications but, frankly, I'm really doubtful that will solve the problem :-( Try the dd's and regular CD access. If that works, it's your software; if it doesn't, then it's probably the drive. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
Robert Watson wrote: I have a very similar configuration, but it sounds like I'm not bumping into the same problem. Are you using NFSv2 or v3, and how many file systems are you mounting? Are you generally using UFS1 or UFS2? Right now, I'm mounting a single UFS2 file system was the root, and I believe right now we always mount NFS roots at NFSv2, which could by why I'm not seeing the same problem... You're probably not using UDP; he might be... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ftpd on -CURRENT ?
Hi! I wanted to install an anonymous ftp server on my -CURRENT machine, but ftpd isn't installed. Is there any reason for that or did I mess up my system somehow? Regards, Uli. +---+ |Peter Ulrich Kruppa| | Wuppertal | | Germany | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
Pawel Worach wrote: [ ... subject ... ] This only seem to happen for nfs over tcp. That's strange; most of the problems I've ever seen are from using UDP, large read/write sizes, and then droping one packet out of a bunch of frags caused by the MTU being much smaller than the read/write size (misguided attempt to emulate a fixed window size and get more packets in flight, without using TCP to do it). fstab on the client (/conf/default/etc/fstab) looks like: server:/export/root / nfs ro 0 0 procfs /proc procfs rw 0 0 server:/usr /usrnfs ro,nfsv3,tcp0 0 server:/usr/home /home nfs rw,nfsv3,tcp0 0 /export nfs ro,nfsv3,tcp0 0 server:/export/data/swap /swap nfs rw,nfsv3,tcp0 0 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /etc/exports on the server looks like: /export -alldirs -maproot=root -network 192.168.1.0 -mask 255.255.255.0 /export/root -ro -maproot=0 client /export/data/swap -mapall=nobody -network 192.168.1.0 -mask 255.255.255.0 /usr/home client /usr -ro -network 192.168.1.0 -mask 255.255.255.0 filesystems on the server: /magic 11954 (UFS1)timeWed Aug 27 17:34:13 2003 /usr magic 19540119 (UFS2) timeWed Aug 27 17:33:38 2003 /export magic 11954 (UFS1)timeSat Aug 23 23:51:20 2003 /export/data magic 19540119 (UFS2) timeTue Aug 26 07:48:01 2003 What's magic? Make it go away; the word usually means it's so complicated, I can't explain it to you, and I implemented the thing, so you should have szero faith in it, because if the person who implemented it can't explain it, then it's going to be impossible to verify correct operation. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
Jason Stone wrote: I'm also seeing a similar problem - I have a cluster of high-volume mailservers delivering mail over nfs to maildirs on a netapp. The cluster was all 4-stable, but I decided to mix a couple of 5.1 boxes in to see how they would do. The 5.1 boxes accepted and queued mail as well as the 4-stable boxes, but delivering the mail into the maildirs over nfs, I kept seeing those short-lived hangs, and so the queues started to back up as the boxes were accepting mail faster than they could deliver it. My mounts are all nfsv3 over udp. UDP has problems, if you lose any packets at all. The problem is that the packet reassembly buffer stays full until you retry, and the retry is out of band, for packets larger than the MTU size. What happens when you drop the read and write size low enough that the data and headers fit in a single UDP packet (e.g. according to tcpdump)? Does it suddenly become more reliable? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IDE DVD playback on 5.1-CURRENT
Hi
I had a similar problem when running mplayer with recent kernels. My
problem was that although I was executing mplayer with -dvd-device
/dev/acd0, the program was trying to open /dev/racd0. I modified
main/libmpdvdkit2/dvd_reader.c and sure enough everything is OK. I hope
the following helps:
#if defined(SYS_BSD)
/* FreeBSD /dev/(r)(a)cd0c (a is for atapi), recomended to _not_ use r
OpenBSD /dev/rcd0c, it needs to be the raw device
NetBSD /dev/rcd0[d|c|..] d for x86, c (for non x86), perhaps others
Darwin /dev/rdisk0, it needs to be the raw device
BSD/OS /dev/sr0c (if not mounted) or /dev/rsr0c ('c' any letter will
do) */
static char *bsd_block2char( const char *path )
{
char *new_path;
#if 0
/* If it doesn't start with /dev/ or does start with /dev/r exit */
if( strncmp( path, /dev/, 5 ) || !strncmp( path, /dev/r, 6 ) )
return (char *) strdup( path );
/* Replace /dev/ with /dev/r */
new_path = malloc( strlen(path) + 2 );
strcpy( new_path, /dev/r );
strcat( new_path, path + strlen( /dev/ ) );
#endif
new_path = strdup(path);
return new_path;
}
#endif
Adam K Kirchhoff wrote:
Again, no luck. From vlc:
[0141] main input: playlist item `dvdold:///dev/[EMAIL PROTECTED],1'
[0141] dvd input error: dvdcss cannot open device
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Could not open /dev/acd0 with libdvdcss.
libdvdread: Can't open /dev/acd0 for reading
[0141] dvdread input error: libdvdcss cannot open source
[0141] vcd input error: no movie tracks found
[0141] main input error: no suitable access module for `/://dvdold:///dev/[EMAIL
PROTECTED],1
From mplayer:
Playing DVD title 1
libdvdread: Could not open device with libdvdcss.
libdvdread: Can't open /dev/acd0 for reading
Couldn't open DVD device: /dev/acd0
From ogle:
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Could not open /dev/acd0c with libdvdcss.
libdvdread: Can't open /dev/acd0c for reading
ERROR[ogle_nav]: faild to open/read the DVD
Yet the same DVD in the firewire drive works just fine.
I can certainly try recompiling the applications but, frankly, I'm really
doubtful that will solve the problem :-(
Adam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Regards
Peter
As always the organisation disavows knowledge of this email
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IDE DVD playback on 5.1-CURRENT
Hmmm... I'll give that a shot, thanks :-) Did you ever submit your patch
to the port maintainer?
Adam
On Thu, 28 Aug 2003, Peter Kostouros wrote:
Hi
I had a similar problem when running mplayer with recent kernels. My
problem was that although I was executing mplayer with -dvd-device
/dev/acd0, the program was trying to open /dev/racd0. I modified
main/libmpdvdkit2/dvd_reader.c and sure enough everything is OK. I hope
the following helps:
#if defined(SYS_BSD)
/* FreeBSD /dev/(r)(a)cd0c (a is for atapi), recomended to _not_ use r
OpenBSD /dev/rcd0c, it needs to be the raw device
NetBSD /dev/rcd0[d|c|..] d for x86, c (for non x86), perhaps others
Darwin /dev/rdisk0, it needs to be the raw device
BSD/OS /dev/sr0c (if not mounted) or /dev/rsr0c ('c' any letter will
do) */
static char *bsd_block2char( const char *path )
{
char *new_path;
#if 0
/* If it doesn't start with /dev/ or does start with /dev/r exit */
if( strncmp( path, /dev/, 5 ) || !strncmp( path, /dev/r, 6 ) )
return (char *) strdup( path );
/* Replace /dev/ with /dev/r */
new_path = malloc( strlen(path) + 2 );
strcpy( new_path, /dev/r );
strcat( new_path, path + strlen( /dev/ ) );
#endif
new_path = strdup(path);
return new_path;
}
#endif
Adam K Kirchhoff wrote:
Again, no luck. From vlc:
[0141] main input: playlist item `dvdold:///dev/[EMAIL PROTECTED],1'
[0141] dvd input error: dvdcss cannot open device
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Could not open /dev/acd0 with libdvdcss.
libdvdread: Can't open /dev/acd0 for reading
[0141] dvdread input error: libdvdcss cannot open source
[0141] vcd input error: no movie tracks found
[0141] main input error: no suitable access module for
`/://dvdold:///dev/[EMAIL PROTECTED],1
From mplayer:
Playing DVD title 1
libdvdread: Could not open device with libdvdcss.
libdvdread: Can't open /dev/acd0 for reading
Couldn't open DVD device: /dev/acd0
From ogle:
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Could not open /dev/acd0c with libdvdcss.
libdvdread: Can't open /dev/acd0c for reading
ERROR[ogle_nav]: faild to open/read the DVD
Yet the same DVD in the firewire drive works just fine.
I can certainly try recompiling the applications but, frankly, I'm really
doubtful that will solve the problem :-(
Adam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Regards
Peter
As always the organisation disavows knowledge of this email
___
[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]
Sil3112 dma errors
Hi all, recently I upgraded my kernel to the last version ( Aug 28 now, before was runing Aug 5 version ), and I startet to get error like this: Aug 27 17:03:23 pilkishome kernel: ad4: WARNING - WRITE_DMA recovered from missing interrupt Aug 27 17:03:23 pilkishome kernel: ad4: WARNING - WRITE_DMA soft error (ECC corrected)ad4: FAILURE - WRITE_DMA status=ffBUSY,READY,DMA_READY,DSC,DRQ,CORRECTABLE,INDEX,ERROR error=0... here ends syslogd ad4: WARNING - WRITE_DMA recovery from missing interupt ad4: timeout sending command=ca ad4: error issuing DMA command after where is coming dma timeout, but in the syslog already nothing, system becomes unresponsible here is my uname and dmesg FreeBSD pilkishome.spo-tripoli.local 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Aug 28 14:37:53 EEST 2003 root@:/usr/obj/usr/src/sys/GENERIC i386 upport enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P4G8Xon motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=255d8086) pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00f2320 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 6 10A 0x60 3 4 5 7 9 10 11 12 slot 6 10B 0x61 3 4 5 7 9 10 11 12 embedded0 29A 0x60 3 4 5 7 9 10 11 12 embedded0 29B 0x63 3 4 5 7 9 10 11 12 embedded0 29C 0x62 3 4 5 7 9 10 11 12 embedded0 29D 0x6b 3 4 5 7 9 10 11 12 embedded0 31A 0x62 3 4 5 7 9 10 11 12 embedded0 31B 0x61 3 4 5 7 9 10 11 12 slot 1 20A 0x69 3 4 5 7 9 10 11 12 slot 1 20B 0x6a 3 4 5 7 9 10 11 12 slot 1 20C 0x6b 3 4 5 7 9 10 11 12 slot 1 20D 0x68 3 4 5 7 9 10 11 12 slot 2 21A 0x6a 3 4 5 7 9 10 11 12 slot 2 21B 0x6b 3 4 5 7 9 10 11 12 slot 2 21C 0x68 3 4 5 7 9 10 11 12 slot 2 21D 0x69 3 4 5 7 9 10 11 12 slot 3 22A 0x6b 3 4 5 7 9 10 11 12 slot 3 22B 0x68 3 4 5 7 9 10 11 12 slot 3 22C 0x69 3 4 5 7 9 10 11 12 slot 3 22D 0x6a 3 4 5 7 9 10 11 12 slot 4 26A 0x68 3 4 5 7 9 10 11 12 slot 4 26B 0x69 3 4 5 7 9 10 11 12 slot 4 26C 0x6a 3 4 5 7 9 10 11 12 slot 4 26D 0x6b 3 4 5 7 9 10 11 12 slot 5 27A 0x62 3 4 5 7 9 10 11 12 slot 5 27B 0x63 3 4 5 7 9 10 11 12 slot 5 27C 0x60 3 4 5 7 9 10 11 12 slot 5 27D 0x61 3 4 5 7 9 10 11 12 embedded25A 0x62 3 4 5 7 9 10 11 12 embedded23A 0x61 3 4 5 7 9 10 11 12 embedded24A 0x69 3 4 5 7 9 10 11 12 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks BAD min = 3, max = 1060, width = 1057 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks BAD min = 3, max = 1055, width = 1052 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks BAD min = 3, max = 1055, width = 1052 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks BAD min = 3, max = 1055, width = 1052 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks BAD min = 3, max = 1052, width = 1049 Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.29.0 \\_SB_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.29.1 \\_SB_.LNKC irq 5: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.29.2 \\_SB_.LNKH irq 9: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.29.3 \\_SB_.LNKC irq 5: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.31.0 \\_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.31.1 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.29.0 \\_SB_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.29.1 \\_SB_.LNKC irq 5: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.29.2 \\_SB_.LNKH irq 9: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.29.3 \\_SB_.LNKC irq 5: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.31.0 \\_SB_.LNKB irq 10: [ 3 4 5 6 7 9
[current tinderbox] failure on ia64/ia64
TB --- 2003-08-28 10:06:05 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-08-28 10:06:05 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-08-28 10:09:21 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-08-28 11:14:56 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Thu Aug 28 11:14:56 GMT 2003 Kernel build for GENERIC completed on Thu Aug 28 11:30:35 GMT 2003 TB --- 2003-08-28 11:30:35 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-08-28 11:30:35 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Aug 28 11:30:35 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/kern/uipc_socket2.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/kern/uipc_syscalls.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/kern/uipc_usrreq.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127
Re: Sil3112 dma errors
It seems Putinas wrote: Hi all, recently I upgraded my kernel to the last version ( Aug 28 now, before was runing Aug 5 version ), and I startet to get error like this: Aug 27 17:03:23 pilkishome kernel: ad4: WARNING - WRITE_DMA recovered from missing interrupt Aug 27 17:03:23 pilkishome kernel: ad4: WARNING - WRITE_DMA soft error (ECC corrected)ad4: FAILURE - WRITE_DMA status=ffBUSY,READY,DMA_READY,DSC,DRQ,CORRECTABLE,INDEX,ERROR error=0... here ends syslogd ad4: WARNING - WRITE_DMA recovery from missing interupt ad4: timeout sending command=ca ad4: error issuing DMA command after where is coming dma timeout, but in the syslog already nothing, system becomes unresponsible Hmm two things: what kind of SATA-PATA dongles are you using ? Do you have any significant traffic on the gigE interface ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IDE DVD playback on 5.1-CURRENT
And a quick FYI: After making the changes below, mplayer still refuses to
play back any DVDs. :-) I'll probably just wait till ATAnp and atapicam
are working together nicely again before I continue fighting with it.
Adam
On Thu, 28 Aug 2003, Adam K Kirchhoff wrote:
Hmmm... I'll give that a shot, thanks :-) Did you ever submit your patch
to the port maintainer?
Adam
On Thu, 28 Aug 2003, Peter Kostouros wrote:
Hi
I had a similar problem when running mplayer with recent kernels. My
problem was that although I was executing mplayer with -dvd-device
/dev/acd0, the program was trying to open /dev/racd0. I modified
main/libmpdvdkit2/dvd_reader.c and sure enough everything is OK. I hope
the following helps:
#if defined(SYS_BSD)
/* FreeBSD /dev/(r)(a)cd0c (a is for atapi), recomended to _not_ use r
OpenBSD /dev/rcd0c, it needs to be the raw device
NetBSD /dev/rcd0[d|c|..] d for x86, c (for non x86), perhaps others
Darwin /dev/rdisk0, it needs to be the raw device
BSD/OS /dev/sr0c (if not mounted) or /dev/rsr0c ('c' any letter will
do) */
static char *bsd_block2char( const char *path )
{
char *new_path;
#if 0
/* If it doesn't start with /dev/ or does start with /dev/r exit */
if( strncmp( path, /dev/, 5 ) || !strncmp( path, /dev/r, 6 ) )
return (char *) strdup( path );
/* Replace /dev/ with /dev/r */
new_path = malloc( strlen(path) + 2 );
strcpy( new_path, /dev/r );
strcat( new_path, path + strlen( /dev/ ) );
#endif
new_path = strdup(path);
return new_path;
}
#endif
Adam K Kirchhoff wrote:
Again, no luck. From vlc:
[0141] main input: playlist item `dvdold:///dev/[EMAIL PROTECTED],1'
[0141] dvd input error: dvdcss cannot open device
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Could not open /dev/acd0 with libdvdcss.
libdvdread: Can't open /dev/acd0 for reading
[0141] dvdread input error: libdvdcss cannot open source
[0141] vcd input error: no movie tracks found
[0141] main input error: no suitable access module for
`/://dvdold:///dev/[EMAIL PROTECTED],1
From mplayer:
Playing DVD title 1
libdvdread: Could not open device with libdvdcss.
libdvdread: Can't open /dev/acd0 for reading
Couldn't open DVD device: /dev/acd0
From ogle:
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Could not open /dev/acd0c with libdvdcss.
libdvdread: Can't open /dev/acd0c for reading
ERROR[ogle_nav]: faild to open/read the DVD
Yet the same DVD in the firewire drive works just fine.
I can certainly try recompiling the applications but, frankly, I'm really
doubtful that will solve the problem :-(
Adam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Regards
Peter
As always the organisation disavows knowledge of this email
___
[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: Sil3112 dma errors
1. It's written only Advance Peripherals , looks like this http://www7.alternate.de/prodpic/200x200/f/fpba03.jpg 2. Nope , network is connected only to 100 mbit switch, and most often the problem occurs when there is higher i/o with disk ( like kernel compiling or make buildworld ) which I usually do over ssh remotely, but same thing happened via console and even when booting on the starting up services. - Original Message - From: Soren Schmidt To: Putinas Cc: [EMAIL PROTECTED] Sent: Thursday, August 28, 2003 13:43 PM Subject: Re: Sil3112 dma errors It seems Putinas wrote: Hi all, recently I upgraded my kernel to the last version ( Aug 28 now, before was runing Aug 5 version ), and I startet to get error like this: Aug 27 17:03:23 pilkishome kernel: ad4: WARNING - WRITE_DMA recovered from missing interrupt Aug 27 17:03:23 pilkishome kernel: ad4: WARNING - WRITE_DMA soft error (ECC corrected)ad4: FAILURE - WRITE_DMA status=ffBUSY,READY,DMA_READY,DSC,DRQ,CORRECTABLE,INDEX,ERROR error=0... here ends syslogd ad4: WARNING - WRITE_DMA recovery from missing interupt ad4: timeout sending command=ca ad4: error issuing DMA command after where is coming dma timeout, but in the syslog already nothing, system becomes unresponsible Hmm two things: what kind of SATA-PATA dongles are you using ? Do you have any significant traffic on the gigE interface ? -Søren ___ [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]
IBM HS20 blade and 5.1 release problems (USB)
I have come across the following issues with 5.1 and the IBM blades. They are likely to apply to 4.x too. The HS20 has a serial port, but it is only available as a header on board. The HS20 also has an AT keyboard controller but that seems not to be physically available anywhere. IBMs BladeCenter Chasis has two usb hubs which are switched bettween the blades by the managment module in the chassis. One hub has a CD and Floppy drive, this works fine. The other hub has a mouse and two usb keyboards. One usb keyboard is the PS2 keyboard connected to the managment module, the other is the keyboard element of the integrated IP KVM switch. These two usb keyboards are only ever attached to one of the fourteen blades at a time. However these two keyboards are the only input devices available to the console. IBM rely on all keyboard input ending up in the same place, as is the case in windows and presumably Linux. Is there a way to get syscons to listen to multiiple keyboards at the same time? I have been using usbd to detect the connection of the keyboards and configure syscons, however because multiple devices connect in the same event (ukbd1, umouse0) I discovered I was unable to trigger any action on the connection of the keyboard, only the mouse, so now when a mouse is attached usbd forces syscons to use kbd2. Is this a bug or feature of usbd? Finaly the loader uses the bios for keyboard interaction. However when booting single user you intialise syscons, but not usbd, is there some otherway to figure out if a usb keyboard is attached (remebering most of the time it will not be) and notify syscons? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IDE DVD playback on 5.1-CURRENT
On Thu, 28 Aug 2003 07:46:52 -0400 (EDT) Adam K Kirchhoff [EMAIL PROTECTED] wrote: And a quick FYI: After making the changes below, mplayer still refuses to play back any DVDs. :-) I'll probably just wait till ATAnp and atapicam are working together nicely again before I continue fighting with it. According to the commit log they do now (at least there's no panic)... Bye, Alexander. -- Press every key to continue. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
On Wed, 27 Aug 2003, Pawel Worach wrote: I get the errors every time the nfs mounts are not unmounted cleanly, if the client (which is a laptop and i often forget to plug in the power so the battery dies) dies and the server is rebooted the client boots fine, i.e. no nfs server not responding errors. So it looks like there is some kind of state mismatch in the nfs server code. Ok, so let me see if I have the sequence of events straight: (1) Boot a 4.8-RELEASE/STABLE NFS server (2) Boot a 5.1-RELEASE/CURRENT NFS client (3) Mount a file system using TCP NFSv3 (4) Reboot the client system, reboot, and remount (5) Thrash the file system a bit with large reads/writes, and it hangs Is this correct? I'd like to work out the minimum sequence of events necessary to cause the problem. Is (4) necessary to reproduce the hang, or can you cause it without (4) if you wait long enough? You mention a server reboot here, also, so I want to make sure I'm not confused about the steps to hit the problem. Also, could you try enabling the all.log entry in syslogd, and looking for messages that read something like nfs send error in it after this has happened? Once the hang is occuring on the client, can you drop into DDB and do a ps, and in particular, paste into an e-mail any lines about nfsiod threads, and any threads that are blocked in nfs? Likewise, on the server, could you drop into DDB and do a ps, and paste in the state of any nfsd threads? rc.conf parameters look like this: server: rpcbind_enable=YES nfs_server_enable=YES mountd_enable=YES nfs_reserved_port_only=YES rpc_lockd_enable=YES rpc_statd_enable=YES client: rpcbind_enable=YES nfs_client_enable=YES rpc_lockd_enable=YES rpc_statd_enable=YES For kicks, try disabling rpc.lockd on all sides, as well as rpc.statd. I don't think they're involved here, but it's worth disabling them to be sure. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm also seeing a similar problem - I have a cluster of high-volume mailservers delivering mail over nfs to maildirs on a netapp. The cluster was all 4-stable, but I decided to mix a couple of 5.1 boxes in to see how they would do. [...] My mounts are all nfsv3 over udp. UDP has problems, if you lose any packets at all. The problem is that the packet reassembly buffer stays full until you retry, and the retry is out of band, for packets larger than the MTU size. What happens when you drop the read and write size low enough that the data and headers fit in a single UDP packet (e.g. according to tcpdump)? Does it suddenly become more reliable? I'll try to play around with it and see. We actually had this discussion already over on -performance (and I get what you're saying), but the interesting question here is, why is 5.1 behaving so differently from 4-stable on identical hardware under identical load. -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE/TfwcswXMWWtptckRAoZIAKCA6doHe3VXrwFj/xX/HkfV18emYACfW1GK Yw5ZniWoHqHQg/ez8sj4Svc= =hFfm -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sil3112 dma errors
It seems Putinas wrote: 1. It's written only Advance Peripherals , looks like this http://www7.alternate.de/prodpic/200x200/f/fpba03.jpg OKies, not much to say about those, probably marvell based.. 2. Nope , network is connected only to 100 mbit switch, and most often the problem occurs when there is higher i/o with disk ( like kernel compiling or make buildworld ) which I usually do over ssh remotely, but same thing happened via console and even when booting on the starting up services. Hmm, I cant reproduce anything like this here, could you try to exchange the gigE card with something else ? (I've seen a fair amount of problems with bge based cards lately)... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftpd on -CURRENT ?
On Thu, Aug 28, 2003 at 10:36:24AM +0200, Peter Ulrich Kruppa [EMAIL PROTECTED] wrote: Hi! I wanted to install an anonymous ftp server on my -CURRENT machine, but ftpd isn't installed. Is there any reason for that or did I mess up my system somehow? It should be installed, it's just not in the usual place (/bin,/usr/bin) - it's in /usr/libexec. Have you tried running 'whereis ftpd'? It's part of the base install, so if it's not there then something's wrong with your system. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
On Thu, 28 Aug 2003, Terry Lambert wrote: Pawel Worach wrote: [ ... subject ... ] This only seem to happen for nfs over tcp. That's strange; most of the problems I've ever seen are from using UDP, large read/write sizes, and then droping one packet out of a bunch of frags caused by the MTU being much smaller than the read/write size (misguided attempt to emulate a fixed window size and get more packets in flight, without using TCP to do it). I'm wondering if large block sizes are causing the TCP socket buffer to fill, resulting in some bad behavior on the client or server. Most probably the server, given that the scenarios in question seem to involve reading. Another intereseting test case might be to use dd with various block sizes to read from a file on the server and see whether a particular size triggers the problem, or if it's less deterministic (and more likely a race condition of some sort). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Someone help me understand this...?
On Wed, 27 Aug 2003, Joe Greco wrote:
The specific OS below is 5.1-RELEASE but apparently this happens on 4.8
as well.
Could you confim this happens with 4.8? The access control checks there
are substantially different, and I wouldn't expect the behavior you're
seeing on 4.8...
...
Well, the sending and receiving processes both clearly have equal uid/euid.
We're not running in a jail, so I don't expect any issues there.
...
The parent process did actually start as root and then shed privilege with
struct passwd *pw = getpwnam(news);
struct group *gr = getgrnam(news);
gid_t gid;
if (pw == NULL) {
perror(getpwnam('news'));
exit(1);
}
if (gr == NULL) {
perror(getgrnam('news'));
exit(1);
}
gid = gr-gr_gid;
setgroups(1, gid);
setgid(gr-gr_gid);
setuid(pw-pw_uid);
so that looks all well and fine... so why can't it kill its own children,
and why can't I kill one of its children from a shell with equivalent
uid/euid?
I know there's been some paranoia about signal delivery and all that, but
my searching hasn't turned up anything that would explain this. Certainly
the manual page ought to be updated if this is a new expected behaviour or
something... at least some clue as to why it might fail would be helpful.
The man page definitely needs to be updated, but I think it's worth having
a conversation about whether the current behavior is too conservative
first...
These changes come in response to a class of application vulnerabilities
relating to the delivery of unexpected signals. The reason the process
in question is being treated as special from an access control perspective
is that it has undergone a credential change, resulting in the setting of
the process P_SUGID bit. This bit remains set even if the remaining
credentials of the process appear normal -- i.e., even if ruid==euid,
rgid==egid, and can only be reset by calling execve() on a normal
binary, which is considered sufficient to flush the state of the process.
These processes are given special protection properties because they
almost always have cached access to memory or resources acquired using the
original credential. For example, the process accesses the password file
while holding root privilege, which means that the process may well have
password hashes in memory from its reading the shadow password file -- in
fact, it likely even have a file descriptor to the shadow password file
still open. The same P_SUGID flag is used to prevent against unprivileged
debugging of applications that have changed credentials and now appear
normal. P_SUGID is also used to determine the results of the
issetugid() system call, which is used by many libraries to see if they
are running with (or have run with) privilege and need to behave in a
more conservative manner.
I don't remember the details, but there have been at least a couple of
demonstrated exploits of vulnerable applications using signals in which
setuid applications rely on certain signals (such as SIGALRM, SIGIO,
SIGURG) only being delivered as a result of system calls that set up
timers, IO, etc. I seem to recall it might have involved a setuid
application such as sendmail on OpenBSD, but I'll have to do some googling
and get back to you. These protections probably fall into the same class
of conservative behavior as our preventing setuid programs from being
started with closed stdin/stdout/stderr descriptors.
Giving up privilege without performing an exec() is very difficult in
UNIX, unfortunately, since the trappings of privilege may be maintained by
libraries, etc, without the knowledge of application writers. Right now,
signal delivery in 5.x is pretty conservative if a process has changed
credentials, to protect against tampering with a class of applications
that has, historically, been vulnerable to a broad variety of exploits.
I've attached an (untested) patch that makes this behavior run-time
configuration using a sysctl -- when the sysctl is disabled, special-case
handling for P_SUGID processes is disabled. I believe that this will
cause the problem you're experiencing in 5.x to go away -- please let me
know.
Clearly, unbreaking applications like Diablo by default is desirable. At
least OpenBSD has similar protections to these turned on by default, and
possibly other systems as well. As 5.x sees more broad use, we may well
bump into other cases where applications have similar behavior: they rely
on no special protections once they've given up privilege. I wonder if
Diablo can run unmodified on OpenBSD; it could be they don't include
SIGALRM on the list of protect against signals, or it could be that they
modify Diablo for their environment to use an alternative signaling
mechanism. Another alternative to this patch would simply be to add
SIGARLM to the list of acceptable signals to deliver
Re: Recent sound change still broken?
On Thursday 28 August 2003 07:37, David Xu wrote: My patch http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/54810 ever worked well for my old Creative sound card, the device is probed, but now no sound at all. :-( I tried to backout ac97.c revision 1.43, now my sound card works again, If someone wants more information, please tell me. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Someone help me understand this...?
On Wed, 27 Aug 2003, Joe Greco wrote: The specific OS below is 5.1-RELEASE but apparently this happens on 4.8 as well. Could you confim this happens with 4.8? The access control checks there are substantially different, and I wouldn't expect the behavior you're seeing on 4.8... Rather difficult. I'll see if the client will let me trash a production system, but usually people don't like $40K servers handing out a few hundred megabits of traffic going out of service. We were trying to fix it on the scratch box (which happens to have 5.1R on it) and then were going to see how it fared on the production systems. The man page definitely needs to be updated, but I think it's worth having a conversation about whether the current behavior is too conservative first... These changes come in response to a class of application vulnerabilities relating to the delivery of unexpected signals. The reason the process in question is being treated as special from an access control perspective is that it has undergone a credential change, resulting in the setting of the process P_SUGID bit. This bit remains set even if the remaining credentials of the process appear normal -- i.e., even if ruid==euid, rgid==egid, and can only be reset by calling execve() on a normal binary, which is considered sufficient to flush the state of the process. These processes are given special protection properties because they almost always have cached access to memory or resources acquired using the original credential. For example, the process accesses the password file while holding root privilege, which means that the process may well have password hashes in memory from its reading the shadow password file -- in fact, it likely even have a file descriptor to the shadow password file still open. The same P_SUGID flag is used to prevent against unprivileged debugging of applications that have changed credentials and now appear normal. P_SUGID is also used to determine the results of the issetugid() system call, which is used by many libraries to see if they are running with (or have run with) privilege and need to behave in a more conservative manner. Okay, well, that makes good sense. I don't remember the details, but there have been at least a couple of demonstrated exploits of vulnerable applications using signals in which setuid applications rely on certain signals (such as SIGALRM, SIGIO, SIGURG) only being delivered as a result of system calls that set up timers, IO, etc. I seem to recall it might have involved a setuid application such as sendmail on OpenBSD, but I'll have to do some googling and get back to you. These protections probably fall into the same class of conservative behavior as our preventing setuid programs from being started with closed stdin/stdout/stderr descriptors. Giving up privilege without performing an exec() is very difficult in UNIX, unfortunately, since the trappings of privilege may be maintained by libraries, etc, without the knowledge of application writers. Right now, signal delivery in 5.x is pretty conservative if a process has changed credentials, to protect against tampering with a class of applications that has, historically, been vulnerable to a broad variety of exploits. I've attached an (untested) patch that makes this behavior run-time configuration using a sysctl -- when the sysctl is disabled, special-case handling for P_SUGID processes is disabled. I believe that this will cause the problem you're experiencing in 5.x to go away -- please let me know. Well, I'm hoping more for a general fix for Diablo, rather than a special patch for the OS. Clearly, unbreaking applications like Diablo by default is desirable. At least OpenBSD has similar protections to these turned on by default, and possibly other systems as well. As 5.x sees more broad use, we may well bump into other cases where applications have similar behavior: they rely on no special protections once they've given up privilege. I wonder if Diablo can run unmodified on OpenBSD; it could be they don't include SIGALRM on the list of protect against signals, or it could be that they modify Diablo for their environment to use an alternative signaling mechanism. Another alternative to this patch would simply be to add SIGARLM to the list of acceptable signals to deliver in the privilege-change case. I wonder if it would be reasonable to have some sort of interface that allowed a program to tell FreeBSD not to set this flag... if not, at least if there was a sysctl, code could be added so that the daemon checked the flag when starting and errored out if it wasn't set. BTW, it's worth noting that the mechanism Diablo is using to give up privilege actually does retain some privileges -- it doesn't, for example, synchronize its resource limits with those of the user it is switching to, so it retains the starting resource limits (likely those of
Failure making buildworld (cvsup at Thu Aug 28 10:34:49 EDT 2003)
=== lib/libpam/modules/pam_echo cc -O2 -pipe -march=pentium4 -I/usr/src/lib/libpam/modules/pam_echo/../../.. /../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_echo/../../lib pam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes - Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-string s -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/modules/pam_echo/pam_echo.c /usr/src/lib/libpam/modules/pam_echo/pam_echo.c: In function `_pam_echo': /usr/src/lib/libpam/modules/pam_echo/pam_echo.c:92: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /usr/src/lib/libpam/modules/pam_echo. *** Error code 1 Stop in /usr/src/lib/libpam/modules. *** Error code 1 Stop in /usr/src/lib/libpam. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no PIO fallback?
On Thursday 28 August 2003 02:24 am, you wrote: It seems Anish Mistry wrote: -- Start of PGP signed section. On Tuesday 26 August 2003 10:27 pm, Anish Mistry wrote: After removing atapicam from my kernel, so no panics on boot I decided to see it DMA was fixed for my CD/DVD combo drive. I changed the hw.ata.atapi_dma=0 to hw.ata.atapi_dma=1 in my /boot/loader.conf. After a reboot I tried to access my cdrom drive, and got the following error messages, which is very similar to the messages when trying to dma before ATAng: Aug 26 22:09:34 littleguy kernel: acd0: WARNING - READ_CD recovered from missing interrupt Aug 26 22:09:34 littleguy kernel: acd0: WARNING - READ_CD UDMA ICRC error (retrying request) The problem is that before with DMA enabled it would try dma a few times fail, and then fall back to PIO, whcih though annoying still left the drive in a useable condition. Where as now the drive just stays stuck and unusable. . Anyone thinking about looking into this? I'll just submit a PR, in a day or 2 if there is no resposne. Thanks, There is no PIO fallback in ATAng (so far), if you know that your ATAPI device doesn't do DMA why on earth do you enable it ? Because the drive does support DMA. I've tested to see it DMA actually works in windows, PIO vs DMA while playing a DVD, and there is a big difference, and I can only assume that it works. -Søren -- Anish Mistry pgp0.pgp Description: signature
Re: ATAng no PIO fallback?
It seems Anish Mistry wrote: it DMA was fixed for my CD/DVD combo drive. I changed the hw.ata.atapi_dma=0 to hw.ata.atapi_dma=1 in my /boot/loader.conf. After a reboot I tried There is no PIO fallback in ATAng (so far), if you know that your ATAPI device doesn't do DMA why on earth do you enable it ? Because the drive does support DMA. I've tested to see it DMA actually works in windows, PIO vs DMA while playing a DVD, and there is a big difference, and I can only assume that it works. Hmm, I didn't hear the works in windows bit :) Could you mail me a dmesg from the system, that might uncover some usefull info on if/how/why DMA can work on your HW.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAng hang
My first try with ATAng on -CURRENT as of 18 hours ago ended up dying around reboot. Other than this, it seems to work as expected. I don't have WITNESS or INVARIANTS on this box, but I can recompile kernel with them if it helps. # reboot Aug 28 09:24:35 rms21 reboot: rebooted by root boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped *** HANGS HERE***, I go over and powercycle... àCopyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #6: Thu Aug 28 08:31:37 EEST 2003 CPU: Intel Pentium III (568.59-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 536805376 (511 MB) avail memory = 515559424 (491 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 atapci0: VIA 82C686B UDMA100 controller port 0xc000-0xc00f at device 7.1 on pc i0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci1: HighPoint HPT370 UDMA100 controller port 0xe400-0xe4ff,0xe000-0xe003, 0xdc00-0xdc07,0xd800-0xd803,0xd400-0xd407 irq 11 at device 14.0 on pci0 ata2: at 0xd400 on atapci1 ata3: at 0xdc00 on atapci1 ad0: 9541MB Maxtor 31024H2 [19386/16/63] at ata0-master UDMA100 ad3: 117800MB IC35L120AVVA07-0 [239340/16/63] at ata1-slave UDMA100 Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Someone help me understand this...?
On Thu, 28 Aug 2003, Joe Greco wrote: On Wed, 27 Aug 2003, Joe Greco wrote: The specific OS below is 5.1-RELEASE but apparently this happens on 4.8 as well. Could you confim this happens with 4.8? The access control checks there are substantially different, and I wouldn't expect the behavior you're seeing on 4.8... Rather difficult. I'll see if the client will let me trash a production system, but usually people don't like $40K servers handing out a few hundred megabits of traffic going out of service. We were trying to fix it on the scratch box (which happens to have 5.1R on it) and then were going to see how it fared on the production systems. I think it's safe to assume that if you're seeing a similar failure, there's a different source given my reading of the code, but I'm willing to be proven wrong. It's probably not worth the investment if you're talking about large quantities of money, though. Clearly, unbreaking applications like Diablo by default is desirable. At least OpenBSD has similar protections to these turned on by default, and possibly other systems as well. As 5.x sees more broad use, we may well bump into other cases where applications have similar behavior: they rely on no special protections once they've given up privilege. I wonder if Diablo can run unmodified on OpenBSD; it could be they don't include SIGALRM on the list of protect against signals, or it could be that they modify Diablo for their environment to use an alternative signaling mechanism. Another alternative to this patch would simply be to add SIGARLM to the list of acceptable signals to deliver in the privilege-change case. I wonder if it would be reasonable to have some sort of interface that allowed a program to tell FreeBSD not to set this flag... if not, at least if there was a sysctl, code could be added so that the daemon checked the flag when starting and errored out if it wasn't set. We actually have such an interface, but it's only enabled for the purposes of regression testing. If you compile options REGRESSION into the kernel configuration, a new system call __setsugid(), is exposed to applications. It's used by src/tools/regression/security/proc_to_proc to make it easier to set up process pairs for regression testing of inter-process access control. When I added it, there was some interest in just making it setsugid() and exposing it to all processes. Maybe we should just go this route for 5.2-RELEASE. Invoking it with a (0) argument would mean the application writer accepted the inherrent risks. However, this would open the application to the risks of debugging attachment, which are probably greater than the signal risks in most cases. It's not clear what the best way to express I want to accept these risks but not those risks would be... So far, it sounds like we have three work-arounds in the pot, perhaps we can think of something better: (1) Remove SIGALRM from the list of prohibited signals in the P_SUGID case. Not clear what the risks are here based on common application use, but this is an easy change to make. (2) Add setsugid() to allow applications to give up implicit protections associated with credential changes. This comes with greater risks, I suspect, since it opens up applications to more explicit vulnerabilities: signal attacks require more sophistication and luck, but debugging attacks are easy. (3) Allow administrators to selectively disable the more restrictive signal checks at a system scope using a sysctl. This is easy, and comes with no risks as long as the setting is unchanged (the default in the patch I sent out earlier). I'm tempted to commit (1) immediately to allow a workaround if we get nothing else figured out, and to think some more about (2) and (3). Another possibility would be to encourage application writers to avoid overloading signals that already have meanings, and rely on the USR signals. I assume the reason Diablo uses ALRM is that the USR signals already have assigned semantics? BTW, it's worth noting that the mechanism Diablo is using to give up privilege actually does retain some privileges -- it doesn't, for example, synchronize its resource limits with those of the user it is switching to, so it retains the starting resource limits (likely those of the root account). That's actually preferred in most cases. News servers almost always eat far more resources than whatever limits you might set by default, which just turns into telling people to remove the limits or use root's limits. Generally if a news package bumps limits bad things happen. Right now, most applications in the base system make use of the setusercontext() call to modify their protections as part of a switch of users. They often pass in the flag LOGIN_SETALL and then remove the bits they don't need, such as LOGIN_SETRESOURCES. This also has the side effect
nvidia.ko freezes system in -current
I cvsuped world and kernel today, built world, installed world, did a reinstall (with compilation) of the nvidia module 1.0-4365 and the kernel module loads fine but when I startx I get a few screen flashes and the reboot. I have agp_load=YES in loader.conf (as I had before). I did not choose WITH_FREBSD_AGP as the port makefile gives as option. Need urgent help since I did this (boo boo) on a production server Well the server runs (httpd) but I have no X at the moment and I cannot afford frequent compiles and reboots at the moment. -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAng panic with large file transfer to HighPoint RAID
I think I have reported this two days ago, but look like it wasn't gone through.
Here's my problem
that I still suffer with build world/kernel about three hours ago (i.e. Aug 28 12:00
UTC)
With the new world/kernel, I tried to pax a subdirectory to the RAID1 drive (two IBM
DLTA-307030
attached to the two UDMA-100 interface of a HighPoint 370 controller) with the
following command
and immediately with a DMA transfer error followed by a kernel panic.
shizuka# pax -pe -r -w public /raid/
ad6: FAILURE - oversized DMA transfer attempted 131072 65536
ad6: Setting up DMA failed
ar0: WARNING - mirror lost
ad4: FAILURE - oversized DMA transfer attempted 131072 65536
ad4: Setting up DMA failed
ar0: ERROR - array broken
panic: initiate_write_inodeblock_ufs2: already started
Here's the backtrace from gdb
panic: initiate_write_inodeblock_ufs2: already started
panic: from debugger
Uptime: 2m45s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416
432 448 464 480 496
---
Reading symbols from
/usr/obj/usr/src/sys/SHIZUKA/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHIZUKA/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /boot/kernel/logo_saver.ko...done.
Loaded symbols for /boot/kernel/logo_saver.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0254380 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0254768 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc014ba82 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc014b9e2 in db_command (last_cmdp=0xc046c120, cmd_table=0x0,
aux_cmd_tablep=0xc0422284, aux_cmd_tablep_end=0xc0422288)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc014bb25 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc014eb45 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc03b5d4c in kdb_trap (type=3, code=0, regs=0xdc39ea3c)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc03c75aa in trap (frame=
{tf_fs = -831782888, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1069454141,
tf_ebp =
-600184184, tf_isp = -600184216, tf_ebx = 0, tf_edx = 0, tf_ecx = -1068875680, tf_eax
= 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1069850620, tf_cs = 8, tf_eflags = 642, tf_esp =
-1069434333,
tf_ss = -1069505986})
at /usr/src/sys/i386/i386/trap.c:577
#9 0xc03b76f8 in calltrap () at {standard input}:102
#10 0xc02546a5 in panic (
fmt=0xc0416cc3 initiate_write_inodeblock_ufs2: already started)
at /usr/src/sys/kern/kern_shutdown.c:534
#11 0xc035e2e6 in initiate_write_inodeblock_ufs2 (inodedep=0xc42b6800, bp=0x0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3893
---Type return to continue, or q return to quit---
#12 0xc035d46d in softdep_disk_io_initiation (bp=0xce641830)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3459
#13 0xc0214954 in spec_xstrategy (vp=0xc41dfdb0, bp=0xce641830)
at /usr/src/sys/sys/buf.h:413
#14 0xc0214aab in spec_specstrategy (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:529
#15 0xc0213c18 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:122
#16 0xc029da9b in bwrite (bp=0xce641830) at vnode_if.h:1141
#17 0xc029ffd9 in vfs_bio_awrite (bp=0xce641830)
at /usr/src/sys/kern/vfs_bio.c:1709
#18 0xc02a0e16 in flushbufqueues (flushdeps=0)
at /usr/src/sys/kern/vfs_bio.c:2171
#19 0xc02a097c in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:2072
#20 0xc023d091 in fork_exit (callout=0xc02a0840 buf_daemon, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
Is anyone found the same error
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftpd on -CURRENT ?
Sorry, I forgot to repost to the list. On Thu, 28 Aug 2003, Peter Ulrich Kruppa [EMAIL PROTECTED] wrote: On Thu, 28 Aug 2003, David Wolfskill wrote: I think perhaps you may be overlooking its location: g1-13(5.1-C)[1] grep ftpd /etc/inetd.conf #ftpstream tcp nowait root/usr/libexec/ftpd ftpd -l #ftpstream tcp6nowait root/usr/libexec/ftpd ftpd -l #tftp dgram udp waitroot/usr/libexec/tftpd tftpd -s /tftpboot #tftp dgram udp6waitroot/usr/libexec/tftpd tftpd -s /tftpboot You (and everybody else who replied) are absolutely right, which makes things worse: I uncommented the first ftp line and rebooted, typing # ftp localhost results in ftp: connect: Connection refused ftp When I start ftpd manually # /usr/libexec/ftpd -lD everything works fine - I think I can start it with a /usr/local/etc/rc.d script. But this looks as if my inetd.conf isn't read on bootup. Regards, Uli. +---+ |Peter Ulrich Kruppa| | Wuppertal | | Germany | +---+ +---+ |Peter Ulrich Kruppa| | Wuppertal | | Germany | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no PIO fallback?
On Thu, Aug 28, 2003 at 04:47:56PM +0200, Soren Schmidt wrote: It seems Anish Mistry wrote: it DMA was fixed for my CD/DVD combo drive. I changed the hw.ata.atapi_dma=0 to hw.ata.atapi_dma=1 in my /boot/loader.conf. After a reboot I tried There is no PIO fallback in ATAng (so far), if you know that your ATAPI device doesn't do DMA why on earth do you enable it ? Because the drive does support DMA. I've tested to see it DMA actually works in windows, PIO vs DMA while playing a DVD, and there is a big difference, and I can only assume that it works. Hmm, I didn't hear the works in windows bit :) Could you mail me a dmesg from the system, that might uncover some usefull info on if/how/why DMA can work on your HW.. For the kernel before ATAng: see dmesg.beforeATAng For a small list of DMA according to Windows XP see dmesg.windows I'm still looking how I can get it to boot with a kernel after ATAng. It fails with ad0: WARNING: READ_DMA ICRC warning or something like that. Mark -- Nice testing in little China... Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #2: Sat Aug 16 20:51:43 CEST 2003 [EMAIL PROTECTED]:/usr/obj/sources/src/sys/piglet Preloaded elf kernel /boot/kernel.old/kernel at 0xc080b000. Preloaded elf module /boot/kernel.old/acpi.ko at 0xc080b220. Timecounter i8254 frequency 1193182 Hz CPU: AMD Athlon(TM) XP1700+ (1477.36-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 536788992 (511 MB) avail memory = 512696320 (488 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7V266-E on motherboard pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00f1480 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 13 INTA is routed to irq 11 pcib0: slot 15 INTA is routed to irq 10 pcib0: slot 17 INTD is routed to irq 5 pcib0: slot 17 INTD is routed to irq 5 pcib0: slot 17 INTD is routed to irq 5 agp0: VIA Generic host to PCI bridge mem 0xfc00-0xfdff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 11 pci1: display, VGA at device 0.0 (no driver attached) fxp0: Intel 82550 Pro/100 Ethernet port 0xd800-0xd83f mem 0xed00-0xed01,0xed80-0xed800fff irq 11 at device 13.0 on pci0 fxp0: Ethernet address 00:02:b3:48:51:43 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: CMedia CMI8738 port 0xd400-0xd4ff irq 10 at device 15.0 on pci0 isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 8233 UDMA100 controller port 0xd000-0xd00f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xb800-0xb81f irq 5 at device 17.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 ulpt0: Hewlett-Packard DeskJet 3816, rev 1.10/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 ums0: Cypress Sem PS2/USB Browser Combo Mouse, rev 1.00/0.10, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. uhci1: VIA 83C572 USB controller port 0xb400-0xb41f irq 5 at device 17.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 uhub2: Texas Instruments TUSB2046 hub, class 9/0, rev 1.10/1.25, addr 2 uhub2: 4 ports with 4 removable, self powered ugen0: Hewlett-Packard HP Scanjet 5400C Series, rev 1.10/0.00, addr 3 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 uhci2: VIA 83C572 USB controller port 0xb000-0xb01f irq 5 at device 17.4 on pci0 usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered uhub3: port error, restarting port 1 uhub3: port error, giving up port 1 uhub3: port error, restarting port 2
Re: IDE DVD playback on 5.1-CURRENT
On Thu, Aug 28, 2003 at 01:29:22AM -0700, Terry Lambert wrote: 1)dd if=/dev/acd0 count=1 of=/dev/null 2)dd if=/dev/acd0c count=1 of=/dev/null 3)dd if=/dev/acd0a count=1 of=/dev/null bs=2k ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no PIO fallback?
For the kernel before ATAng: see dmesg.beforeATAng For a small list of DMA according to Windows XP see dmesg.windows I'm still looking how I can get it to boot with a kernel after ATAng. It fails with ad0: WARNING: READ_DMA ICRC warning or something like that. With ata_dma and atapi_dma set to zero I can boot the box (hey, that's as expected :-). acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% ad0: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata0-master PIO4 ata1-slave: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED acd0: CDRW PHILIPS CDRW4012P at ata1-master PIO4 Mounting root from ufs:/dev/ad0s2a So the DVDROM drive is missing. Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng panic with large file transfer to HighPoint RAID
To further test if this issue was really caused by ATAng, I have cvsupped
src/sys/dev/ata,
src/sys/conf/files, src/sys/sys/ata.h back to the time just before ATAng committed.
I then
built/installed kernel and found that with this non-ATAng kernel, the pax command
can run
successfully on a directory of around 2.2GB.
Hope that this additional data would help...
Thanks.
--- Shizuka Kudo [EMAIL PROTECTED] wrote:
I think I have reported this two days ago, but look like it wasn't gone through.
Here's my
problem
that I still suffer with build world/kernel about three hours ago (i.e. Aug 28 12:00
UTC)
With the new world/kernel, I tried to pax a subdirectory to the RAID1 drive (two
IBM
DLTA-307030
attached to the two UDMA-100 interface of a HighPoint 370 controller) with the
following command
and immediately with a DMA transfer error followed by a kernel panic.
shizuka# pax -pe -r -w public /raid/
ad6: FAILURE - oversized DMA transfer attempted 131072 65536
ad6: Setting up DMA failed
ar0: WARNING - mirror lost
ad4: FAILURE - oversized DMA transfer attempted 131072 65536
ad4: Setting up DMA failed
ar0: ERROR - array broken
panic: initiate_write_inodeblock_ufs2: already started
Here's the backtrace from gdb
panic: initiate_write_inodeblock_ufs2: already started
panic: from debugger
Uptime: 2m45s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352
368 384 400
416
432 448 464 480 496
---
Reading symbols from
/usr/obj/usr/src/sys/SHIZUKA/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHIZUKA/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /boot/kernel/logo_saver.ko...done.
Loaded symbols for /boot/kernel/logo_saver.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0254380 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0254768 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc014ba82 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc014b9e2 in db_command (last_cmdp=0xc046c120, cmd_table=0x0,
aux_cmd_tablep=0xc0422284, aux_cmd_tablep_end=0xc0422288)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc014bb25 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc014eb45 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc03b5d4c in kdb_trap (type=3, code=0, regs=0xdc39ea3c)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc03c75aa in trap (frame=
{tf_fs = -831782888, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1069454141,
tf_ebp =
-600184184, tf_isp = -600184216, tf_ebx = 0, tf_edx = 0, tf_ecx = -1068875680,
tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1069850620, tf_cs = 8, tf_eflags = 642, tf_esp =
-1069434333,
tf_ss = -1069505986})
at /usr/src/sys/i386/i386/trap.c:577
#9 0xc03b76f8 in calltrap () at {standard input}:102
#10 0xc02546a5 in panic (
fmt=0xc0416cc3 initiate_write_inodeblock_ufs2: already started)
at /usr/src/sys/kern/kern_shutdown.c:534
#11 0xc035e2e6 in initiate_write_inodeblock_ufs2 (inodedep=0xc42b6800, bp=0x0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3893
---Type return to continue, or q return to quit---
#12 0xc035d46d in softdep_disk_io_initiation (bp=0xce641830)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3459
#13 0xc0214954 in spec_xstrategy (vp=0xc41dfdb0, bp=0xce641830)
at /usr/src/sys/sys/buf.h:413
#14 0xc0214aab in spec_specstrategy (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:529
#15 0xc0213c18 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:122
#16 0xc029da9b in bwrite (bp=0xce641830) at vnode_if.h:1141
#17 0xc029ffd9 in vfs_bio_awrite (bp=0xce641830)
at /usr/src/sys/kern/vfs_bio.c:1709
#18 0xc02a0e16 in flushbufqueues (flushdeps=0)
at /usr/src/sys/kern/vfs_bio.c:2171
#19 0xc02a097c in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:2072
#20 0xc023d091 in fork_exit (callout=0xc02a0840 buf_daemon, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
Is anyone found the same error
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftpd on -CURRENT ?
On Thu, Aug 28, 2003 at 06:31:58PM +0200, Peter Ulrich Kruppa [EMAIL PROTECTED] wrote: But this looks as if my inetd.conf isn't read on bootup. Read this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/inetd.html -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
Robert Watson wrote: On Wed, 27 Aug 2003, Pawel Worach wrote: Ok, so let me see if I have the sequence of events straight: (1) Boot a 4.8-RELEASE/STABLE NFS server (2) Boot a 5.1-RELEASE/CURRENT NFS client (3) Mount a file system using TCP NFSv3 (4) Reboot the client system, reboot, and remount (5) Thrash the file system a bit with large reads/writes, and it hangs Not quite, more like this: 1) Boot the 5.1-CURRENT nfs server 2) Boot the 5.1-CURRENT diskless client (i'm using PXE/DHCP) 3) Login and run find(1) for a while on every filesystem. (e.g. find / ^C ; find /usr ^C ; find /export ^C and so on to generate some getattr(), read() and c/o calls) 4) Shut down the client in a _non-clean_ way, pull the power or enter DDB and 'reset'. 5) Boot the diskless client again. Now here are the messages i get while booting the client (step 5). (darkstar is the server, corona is the client. the one about mounttab is present at every boot and is not related to this problem) Mounting root from nfs: NFS ROOT: 192.168.1.11:/export/root start_init: trying /sbin/init Interface fxp0 IP-Address 192.168.1.20 Broadcast 192.168.1.255 Loading configuration files. Entropy harversting: interrupts ethernet point_to_point Starting file system checks: nfs: can't update /var/db/mounttab for darkstar:/export/root +++ mount_md of /var nfs server darkstar:/usr: not responding insert about a 10 second delay here nfs server darkstar:/usr: is alive again nfs server darkstar:/usr/home: not responding insert about a 20 second delay here nfs server darkstar:/usr/home: is alive again insert about a 20 second delay here [tcp] darkstar:/export: nfsd: RPCPROG_NFS: RPC: Remote system error - Operation timed out insert about a 80 second delay here nfs server darkstar:/export: not responding insert about a 40 second delay here nfs server darkstar:/export: is alive again From here on the boot continues normally and the system works fine. I'm going to set different mount options for every filesystem now and do this again so maybe i can nail down what is causing this. Ths only filesystem that doesn't have problems is / and that is also the only one using udp. Hope this is not as confusing as my previus mail :) And whoever commented about the magic stuff, that was a cut-and-paste from the 'dumpfs fs | grep UFS' command. - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
On Thu, 28 Aug 2003 08:54:07 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: Ok, so let me see if I have the sequence of events straight: (1) Boot a 4.8-RELEASE/STABLE NFS server (2) Boot a 5.1-RELEASE/CURRENT NFS client (3) Mount a file system using TCP NFSv3 (4) Reboot the client system, reboot, and remount (5) Thrash the file system a bit with large reads/writes, and it hangs Is this correct? I'd like to work out the minimum sequence of events necessary to cause the problem. Is (4) necessary to reproduce the hang, or can you cause it without (4) if you wait long enough? You mention a As my server never shuts down and the 5-current client is switched off in the night, I don't know about (4), but I don't think it's necessary (on a shutdown the filesystems get umounted and /var/db/mountdtab only show one mount for the client). server reboot here, also, so I want to make sure I'm not confused about the steps to hit the problem. In my case there's no server reboot. Once the hang is occuring on the client, can you drop into DDB and do a ps, and in particular, paste into an e-mail any lines about nfsiod threads, and any threads that are blocked in nfs? Normally I don't notice that it is blocked, as you see in the following, it may also be the case, that the server is alive again in the same second: ---snip--- /var/log/messages.0.bz2:Aug 24 11:52:05 Magelan kernel: nfs server Andro-Beta:/big/Windows: not responding /var/log/messages.0.bz2:Aug 24 11:52:27 Magelan kernel: nfs server Andro-Beta:/big/Windows: is alive again /var/log/messages.0.bz2:Aug 24 11:52:28 Magelan kernel: nfs server Andro-Beta:/big/Windows: not responding /var/log/messages.0.bz2:Aug 24 11:52:36 Magelan kernel: nfs server Andro-Beta:/big/Windows: is alive again /var/log/messages.0.bz2:Aug 24 11:52:46 Magelan kernel: nfs server Andro-Beta:/big/Windows: not responding /var/log/messages.0.bz2:Aug 24 11:52:46 Magelan kernel: nfs server Andro-Beta:/big/Windows: not responding /var/log/messages.0.bz2:Aug 24 11:52:46 Magelan kernel: nfs server Andro-Beta:/big/Windows: is alive again /var/log/messages.0.bz2:Aug 24 11:52:46 Magelan kernel: nfs server Andro-Beta:/big/Windows: is alive again /var/log/messages.0.bz2:Aug 24 11:53:13 Magelan kernel: nfs server Andro-Beta:/big/Windows: not responding /var/log/messages.0.bz2:Aug 24 11:53:58 Magelan kernel: nfs server Andro-Beta:/big/Windows: is alive again ---snip--- For kicks, try disabling rpc.lockd on all sides, as well as rpc.statd. I don't think they're involved here, but it's worth disabling them to be sure. There's no lockd running, only the statd on the server, so we already can rule out the lockd. BTW.: Robert, mwlucas CCed you in a mail regarding the use of the FreeBSD Foundation address for the commercial icc license, can you please confirm that you got the mail? Bye, Alexander. -- There's no place like ~ http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftpd on -CURRENT ?
On Thu, 28 Aug 2003, Craig Rodrigues wrote: On Thu, Aug 28, 2003 at 06:31:58PM +0200, Peter Ulrich Kruppa [EMAIL PROTECTED] wrote: But this looks as if my inetd.conf isn't read on bootup. Read this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/inetd.html Thanks, so one has to inetd_enable=YES in rc.conf Regards, Uli. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] +---+ |Peter Ulrich Kruppa| | Wuppertal | | Germany | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
No mouse on Dell Inspirion 1100?
I just configured a Dell Inspirion 1100 laptop for a friend ... and this laptop has a built in touch pad ... much like my dell. It's running -CURRENT cvsup'd as of Monday. When it probes the mouse (full -v boot below), it get's this error (boot -v'd) pci0: simple comms at device 31.6 (no driver attached) unknown: not probed (disabled) psmcpnp0 irq 12 on acpi0 atkbdc0: Keyboard controller (i8042) port 0x66,0x62,0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d psm0: current command byte:0065 psm0: the aux port is not functioning (-1). unknown: not probed (disabled) I'm somewhat at a loss ... as I really don't know how to proceed. Help? full boot -v follows: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Tue Aug 26 18:37:07 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LUTE Preloaded elf kernel /boot/kernel/kernel at 0xc0616000. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc06161f4. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc06162a0. Preloaded acpi_dsdt /boot/Dell.aml at 0xc061634c. Preloaded elf module /boot/kernel/if_bcm.ko at 0xc0616390. Preloaded elf module /boot/kernel/acpi.ko at 0xc061643c. Calibrating clock(s) ... i8254 clock: 1193205 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2192893472 Hz CPU: Intel(R) Celeron(R) CPU 2.20GHz (2192.89-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 535597056 (510 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0063d000 - 0x1f5a7fff, 519483392 bytes (126827 pages) avail memory = 513597440 (489 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xcfae pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: 802.11 Link Layer null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled ACPI: DSDT was overridden. ACPI-0375: *** Info: Table [DSDT] replaced by host OS npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL CPi R on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x8050 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=25608086) pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00fcbb0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded0 29A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded0 29B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded0 29C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded0 29D 0x6b 3 4 5 6 7 9 10 11 12 14 15 embedded0 30A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded0 30B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded0 30C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded0 30D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded0 31A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded0 31B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded02A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded10A 0x65 3 4 5 6 7 9 10 11 12 14 15 embedded21A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded24A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded24B 0x60 none embedded22A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded22B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded80A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded80B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded81A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded81B 0x63 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1
Re: nvidia.ko freezes system in -current
On Thu, 2003-08-28 at 15:40, Christoph Kukulies wrote: I cvsuped world and kernel today, built world, installed world, did a reinstall (with compilation) of the nvidia module 1.0-4365 and the kernel module loads fine but when I startx I get a few screen flashes and the reboot. I have agp_load=YES in loader.conf (as I had before). I did not choose WITH_FREBSD_AGP as the port makefile gives as option. I had this effect earlier. XFree was trying to change to graphics mode a few times and then fell back to text-mode. I could only see some weird characters on my display. Then the PC was in an unusable state, but if I holded down Ctrl+Alt+Del long enough it rebooted, so it was not frozen. I wanted to confirm your problem today, because I recognized the symptoms, but I failed :) I have: FreeBSD xxx.local 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Jul 30 20:38:47 CEST XFree-ports: XFree86-4.3.0,1 XFree86-FontServer-4.3.0_1 XFree86-Server-4.3.0_8 XFree86-clients-4.3.0_2 XFree86-documents-4.3.0 XFree86-font100dpi-4.3.0 XFree86-font75dpi-4.3.0 XFree86-fontCyrillic-4.3.0 XFree86-fontDefaultBitmaps-4.3.0 XFree86-fontEncodings-4.3.0 XFree86-fontScalable-4.3.0 XFree86-libraries-4.3.0_5 nvidia-driver-1.0.4365 was compiled today with: make install WITH_FREEBSD_AGP=yes My /boot/loader.conf is: agp_load=YES nvidia_load=YES linux_load=YES linprocfs_load=YES It works again! :) Perhaps I could help. Martin PS.: Don't set option RenderAccel in the device section it has weird effects on rendering smaller images. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Please test: USB floppies
On Tue, 26 Aug 2003, Harald Schmalzbauer wrote: On Monday 25 August 2003 23:19, Nate Lawson wrote: If anyone has a USB floppy drive that is giving them problems, please let me know. Hello, this one needs NO_SYNC I think. Played a bit some time ago but had no luck (I'm no programmer) port 1 addr 2: full speed, power 500 mA, config 1, NEC USB UF000x(0x0040), NEC(0x0409), rev 1.23 ___ Here's some log: umass0: NEC NEC USB UF000x, rev 1.10/1.23, addr 2 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 (probe0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) da0 at umass-sim0 bus 0 target 0 lun 0 da0: NEC USB UF000x 1.23 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 Have you tried it again since early August? Also, what is the exact behavior when you try to mount or read it? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Please test: USB floppies
On Wed, 28 Aug 2003, Larry Baird wrote: Nate, When umount-ing I get the following: umass: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 And this is repeated twice. This message is harmless in the absence of other problems. But no problems like the drive hanging after multiple mount/umounts or writing problems or anything? Here is a report on another USB floppy drive. On my Sony VAIO using SOny's Y-E DATA USB-FDU 1.28 floppy I am also seeing the same message as above. But I see it everytime I access the floppy. Repeated mounts/ unmounts and I/O to the floppy appear to work fine. No hangs, nothing odd other than the above message. I think I have some other USB floppy drives at work. I'll try and give them a test drive as well in the next few days. I re-enabled some floppy quirks that I'm unsure are needed but I had to do it for the upcoming 4.9R just in case. So your results don't help at this point. Could you put an #if 0 and #endif around the section marked: /* USB floppy devices supported by umass(4) */ Alternatively, cvsup sys/cam/scsi/scsi_da.c to rev 1.42.2.42 and test the floppy again. Thanks, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Generating PPro instructions with CPUTYPE=i586?
While trying to build a -CURRENT release for my aging Pentium 150 router box on my substantially faster Athlon XP box, I ran into the following problem. I'm using CPUTYPE=i586 in /etc/make.conf, since the target box is not even capable of doing MMX. However, when the build is complete and I try to installkernel on the target box, the install tools all bomb out with SIGILLs. For example, % gdb infokey 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... (no debugging symbols found)... (gdb) run Starting program: /usr/obj/usr/src/i386/legacy/usr/bin/infokey Program received signal SIGILL, Illegal instruction. 0x080556d4 in malloc_bytes () (gdb) disassemble Dump of assembler code for function malloc_bytes: 0x80556c0 malloc_bytes: push %ebp 0x80556c1 malloc_bytes+1: mov%esp,%ebp 0x80556c3 malloc_bytes+3: push %edi 0x80556c4 malloc_bytes+4: push %esi 0x80556c5 malloc_bytes+5: push %ebx 0x80556c6 malloc_bytes+6: sub$0x1c,%esp 0x80556c9 malloc_bytes+9: mov0x8(%ebp),%eax 0x80556cc malloc_bytes+12:cmp$0xf,%eax 0x80556cf malloc_bytes+15:mov$0x10,%edx 0x80556d4 malloc_bytes+20:cmovbe %edx,%eax As you see, it seems to have generated a cmovbe instruction, which is only supported for Pentium Pro and higher. Is this normal? From the buildlog it seems that all tools under .../i386/legacy were built *without* any CPU specific flags, i.e. just -O -pipe. Only from stage 4: building libraries I see the options change to -O -pipe -march=pentium. Note that the Athlon XP box I'm building on has been completely built using CPUTYPE=athlon-xp, maybe this influences the default instruction set that gcc uses, even without -march flags? pgp0.pgp Description: PGP signature
Re: Please test: USB floppies
On Thursday 28 August 2003 21:35, Nate Lawson wrote: On Tue, 26 Aug 2003, Harald Schmalzbauer wrote: On Monday 25 August 2003 23:19, Nate Lawson wrote: If anyone has a USB floppy drive that is giving them problems, please let me know. Hello, this one needs NO_SYNC I think. Played a bit some time ago but had no luck (I'm no programmer) port 1 addr 2: full speed, power 500 mA, config 1, NEC USB UF000x(0x0040), NEC(0x0409), rev 1.23 *SNIP* Have you tried it again since early August? Also, what is the exact behavior when you try to mount or read it? Mounting, reading writing and umounting is working without errors, just these warnings. Here are the one from today's world: umass0: NEC NEC USB UF000x, rev 1.10/1.23, addr 4 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 (probe0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) da0 at umass-sim0 bus 0 target 0 lun 0 da0: NEC USB UF000x 1.23 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 1MB (2880 512 byte sectors: 64H 32S/T 1C) umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 cale:/mnt# Thanks, -Harry -Nate pgp0.pgp Description: signature
Re: Generating PPro instructions with CPUTYPE=i586?
On Thu, Aug 28, 2003 at 09:55:13PM +0200, Dimitry Andric wrote: While trying to build a -CURRENT release for my aging Pentium 150 router box on my substantially faster Athlon XP box, I ran into the following problem. I'm using CPUTYPE=i586 in /etc/make.conf, since the target box is not even capable of doing MMX. However, when the build is complete and I try to installkernel on the target box, the install tools all bomb out with SIGILLs. For example, Host tools (used for the installworld ) are linked against the existing host libraries, which in your case are compiled for an athlon. If you want to install on another system, you need to build world (or at least the static libraries) on your athlon without optimizations. Kris pgp0.pgp Description: PGP signature
Re: nvidia.ko freezes system in -current
On Thu, 28 Aug 2003, Christoph Kukulies wrote: I cvsuped world and kernel today, built world, installed world, did a reinstall (with compilation) of the nvidia module 1.0-4365 and the kernel module loads fine but when I startx I get a few screen flashes and the reboot. I have agp_load=YES in loader.conf (as I had before). I did not choose WITH_FREBSD_AGP as the port makefile gives as option. Need urgent help since I did this (boo boo) on a production server Well the server runs (httpd) but I have no X at the moment and I cannot afford frequent compiles and reboots at the moment. You should try either: A) comment out agp_load=YES compile nvidia-driver without WITH_FREEBSD_AGP or B) leave agp_loadYES compile nvidia-driver with WITH_FREEBSD_AGP I used to run WITH_FREEBSD_AGP / agp_load=YES (because it was unstable otherwise), but recently cvsuped to -CURRENT, and discovered that the opposite was now more stable (WITH_FREEBSD_AGP/agp_load=YES now causes my computer to lockup regularly when in X). I suggest you try the opposite setting and see if that helps. Also keep WITH_FREEBSD_AGP and agp_load in 'sync'. -- David Taylor [EMAIL PROTECTED] The future just ain't what it used to be ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
On Thu, 28 Aug 2003, Alexander Leidinger wrote: There's no lockd running, only the statd on the server, so we already can rule out the lockd. You probably want to shut down statd on the server as well. Since statd is only used to recover locks on reboots, it is of no use without lockd, and it can only get it the way. -a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent 5.1-CURRENT kernel panics on acd0 probe/attach, IBM T30
Removing atapicam from my kernel configuration fixed the problem for me as well. Please try the patch I posted on -current under HEADS UP! ATAng committed. I just finished a new CVSup and kernel/world compile, rebooted and everything is happy, including reading CDs and data DVDs. I haven't tried a movie yet because I don't have any in my office. nomad --- - Lee nomad Damon - \ play: [EMAIL PROTECTED]or castle!nomad \ work: [EMAIL PROTECTED] \ /\ Seneschal, Castle PAUS./ \ Celebrate Diversity /\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
Pawel Worach wrote: Robert Watson wrote: On Wed, 27 Aug 2003, Pawel Worach wrote: Ok, so let me see if I have the sequence of events straight: Hope this is not as confusing as my previus mail :) Here is some more information. I realized that i had tcp and udp blackholing enabled on the server so i disabled that, still no dice. disabled rpc.statd and rpc.lockd, still no dice. I escaped to DDB between the not responding and the ok messages and came up with this: [SLP]nfscon address] mount_nfs [SLP]- address] nfsiod 3 [SLP]- address] nfsiod 2 [SLP]- address] nfsiod 1 [SLP]- address] nfsiod 0 I have also played with the mount options, here is the result of that: ro,nfsv3,tcp,rdirplus - broken ro,nfsv3,tcp - broken ro,tcp - broken ro - ok (defaults to nfsv2,udp according to my research) ro,nfsv3 - ok (defaults to udp) So it looks like what i said before, only tcp seems to cause this. As this is the first time i'm seriusly investigating this i also noted that a restart of the NFS daemons (or reboot) of the server is not needed, just doing a _clean_ reboot (init 6, shutdown -r now) of the client will make the server recover. (sometimes is takes two clean reboots). - Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Someone help me understand this...?
On Thu, 28 Aug 2003, Joe Greco wrote: On Wed, 27 Aug 2003, Joe Greco wrote: The specific OS below is 5.1-RELEASE but apparently this happens on 4.8 as well. Could you confim this happens with 4.8? The access control checks there are substantially different, and I wouldn't expect the behavior you're seeing on 4.8... Rather difficult. I'll see if the client will let me trash a production system, but usually people don't like $40K servers handing out a few hundred megabits of traffic going out of service. We were trying to fix it on the scratch box (which happens to have 5.1R on it) and then were going to see how it fared on the production systems. I think it's safe to assume that if you're seeing a similar failure, there's a different source given my reading of the code, but I'm willing to be proven wrong. It's probably not worth the investment if you're talking about large quantities of money, though. It's more like large quantities of annoyance and work. Can you describe the case you're envisioning? If I can easily poke at it, I can at least get some clues. Clearly, unbreaking applications like Diablo by default is desirable. At least OpenBSD has similar protections to these turned on by default, and possibly other systems as well. As 5.x sees more broad use, we may well bump into other cases where applications have similar behavior: they rely on no special protections once they've given up privilege. I wonder if Diablo can run unmodified on OpenBSD; it could be they don't include SIGALRM on the list of protect against signals, or it could be that they modify Diablo for their environment to use an alternative signaling mechanism. Another alternative to this patch would simply be to add SIGARLM to the list of acceptable signals to deliver in the privilege-change case. I wonder if it would be reasonable to have some sort of interface that allowed a program to tell FreeBSD not to set this flag... if not, at least if there was a sysctl, code could be added so that the daemon checked the flag when starting and errored out if it wasn't set. We actually have such an interface, but it's only enabled for the purposes of regression testing. If you compile options REGRESSION into the kernel configuration, a new system call __setsugid(), is exposed to applications. It's used by src/tools/regression/security/proc_to_proc to make it easier to set up process pairs for regression testing of inter-process access control. When I added it, there was some interest in just making it setsugid() and exposing it to all processes. Maybe we should just go this route for 5.2-RELEASE. Invoking it with a (0) argument would mean the application writer accepted the inherrent risks. However, this would open the application to the risks of debugging attachment, which are probably greater than the signal risks in most cases. It's not clear what the best way to express I want to accept these risks but not those risks would be... So far, it sounds like we have three work-arounds in the pot, perhaps we can think of something better: (1) Remove SIGALRM from the list of prohibited signals in the P_SUGID case. Not clear what the risks are here based on common application use, but this is an easy change to make. (2) Add setsugid() to allow applications to give up implicit protections associated with credential changes. This comes with greater risks, I suspect, since it opens up applications to more explicit vulnerabilities: signal attacks require more sophistication and luck, but debugging attacks are easy. (3) Allow administrators to selectively disable the more restrictive signal checks at a system scope using a sysctl. This is easy, and comes with no risks as long as the setting is unchanged (the default in the patch I sent out earlier). I'm tempted to commit (1) immediately to allow a workaround if we get nothing else figured out, and to think some more about (2) and (3). Another possibility would be to encourage application writers to avoid overloading signals that already have meanings, and rely on the USR signals. I assume the reason Diablo uses ALRM is that the USR signals already have assigned semantics? Correct. The USR signals control debug levels. If it was a signal that was only used internally, it could be changed, of course, but changing a signal used by humans (and one used in the same manner as other programs) is probably a bad idea. BTW, it's worth noting that the mechanism Diablo is using to give up privilege actually does retain some privileges -- it doesn't, for example, synchronize its resource limits with those of the user it is switching to, so it retains the starting resource limits (likely those of the root account). That's actually preferred in most cases. News servers almost always eat far more
atheros (ath) driver, hostAP?
Howdy list, I'm running FreeBSD 5.1-RELEASE, and I'm considering messing around with some Soekris boards and making some embedded routers with built-in wireless access points and VPN stuff. I know I can do that with the Prism chipsets, but can I run in hostAP mode with the ath driver on an Atheros chipset? Seeing as how I don't run -CURRENT, I can't just run 'man ath'. Any info appreciated! Thanks! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver, hostAP?
On Thu, Aug 28, 2003 at 05:21:30PM -0400, Jesse Guardiani wrote: Howdy list, I'm running FreeBSD 5.1-RELEASE, and I'm considering messing around with some Soekris boards and making some embedded routers with built-in wireless access points and VPN stuff. I know I can do that with the Prism chipsets, but can I run in hostAP mode with the ath driver on an Atheros chipset? From the manpage: The ath driver provides support for wireless network adapters based on the Atheros AR5210, AR5211, and AR5212 chips. Chip-specific support is provided by the Atheros Hardware Access Layer (HAL), that is packaged separately. Supported features include 802.11 and 802.3 frames, power management, BSS, IBSS, and host-based access point operation modes. All host/device interaction is via DMA. Seeing as how I don't run -CURRENT, I can't just run 'man ath'. http://www.freebsd.org/cgi/man.cgi?query=athapropos=0sektion=0manpath=FreeBSD+5.1-currentformat=html -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
natd fw punch rule leak found (and fix)
On a busy ftp site it was noticed that natd stopped punching ftp data session after some time, it was leaking the fw rule numbers allocated for punching. This happens if the ftp clients or ftp servers TCP layer was retransmitting the PORT/EPRT or the passive replies or as a DoS from a malicious client, then natd will allocated a new fw rule number for the punch overwriting the old allocated number, this happens even if the punch would not occur due to one of the port numbers being zero. The fix is simple, in libalias/alias_db.c in PunchFWHole add the following after the initial packetAliasMode test: /* FK, fix fw rule slots leak */ /* PROBLEM: we get double allocation for a link if there is a retransmission of a packet with session information (ftp PORT command etc) or a DoS client that keeps sending such commands, this double allocation will overwrite the previous allocated rule slot number. FIX: If one of the ports for the FW rule is zero then no rule is punched so don't do the punch stuff. */ if (GetOriginalPort(link) == 0 || GetDestPort(link) == 0) return; ClearFWHole(link); /* FK, fix fw rule slots leak ends */ /FK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: natd fw punch rule leak found (and fix)
Ups, there you go when not testing your last optimization, it is required that a fw rule number is allocated for partial connections so the fix is just: in libalias/alias_db.c in PunchFWHole add the following after the initial packetAliasMode test: ClearFWHole(link); /FK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
