questions on S-ATA and ICH5 (now owns hardware :)
Hi all, a few weeks back I had asked whether -current supported ICH5's S-ATA
and Søren stated that he'd put code in to detect it and it "should work" but
there wasn't a lot of feedback yet from users. Well, I have some feedback. I
just got a new spiffy 120Gb Seagate S-ATA drive today and I can say that
-current (as of 7/22/2003) does at least see the drive plugged into the
controller and I can build filesystems, copy/delete files to my heart's
content. However, I'm not sure if everything is entirely correct. I'm attaching
a verbose dmesg (somewhat trimmed). The first thing I notice is that I see the
following bits:
atapci1: port
0xd000-0xd00f,0xcc00-0xcc03,0xc800-0xc807,0xc400-0xc403,0xc000-0xc007 irq 9 at device
31.2 on pci0
...
ata2: at 0xc000 on atapci1
ad4: success setting UDMA133 on Intel ICH5 chip
ad4: ATA-6 disk at ata2-master
ad4: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B
ad4: 16 secs/int, 1 depth queue, UDMA133
ad4: piomode=12 dmamode=34 udmamode=70 cblid=1
Shouldn't this drive be found as a SATA150 device?
pciconf -lv shows both of the devices in ata-chipset.c
{ ATA_I82801EB, 0, 0, 0x00, ATA_UDMA5, "Intel ICH5" },
{ ATA_I82801EB_1, 0, 0, 0x00, ATA_SA150, "Intel ICH5" },
[EMAIL PROTECTED]:31:1: class=0x01018a card=0x1022147b chip=0x24db8086 rev=0x02
hdr=0x00
vendor = 'Intel Corporation'
class= mass storage
subclass = ATA
[EMAIL PROTECTED]:31:2: class=0x01018f card=0x1022147b chip=0x24d18086 rev=0x02
hdr=0x00
vendor = 'Intel Corporation'
class= mass storage
subclass = ATA
The drive is plugged into the "SATA1" port on the MB (not "SATA2"). Does this
information help? What other information can I provide. Is there something
"wrong" here?
Thanks
-
pci0: on pcib0
pci0: physical bus=0
map[10]: type 3, range 32, base e800, size 27, enabled
found-> vendor=0x8086, dev=0x2578, revid=0x02
bus=0, slot=0, func=0
class=06-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found-> vendor=0x8086, dev=0x2579, revid=0x02
bus=0, slot=1, func=0
class=06-04-00, hdrtype=0x01, mfdev=0
cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords)
lattimer=0x40 (1920 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns)
IOAPIC #0 intpin 16 -> irq 2
Freeing (NOT implemented) redirected PCI irq 5.
map[20]: type 4, range 32, base bc00, size 5, enabled
found-> vendor=0x8086, dev=0x24d2, revid=0x02
bus=0, slot=29, func=0
class=0c-03-00, hdrtype=0x00, mfdev=1
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=2
IOAPIC #0 intpin 19 -> irq 5
Freeing (NOT implemented) redirected PCI irq 10.
map[20]: type 4, range 32, base b000, size 5, enabled
found-> vendor=0x8086, dev=0x24d4, revid=0x02
bus=0, slot=29, func=1
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=5
IOAPIC #0 intpin 18 -> irq 9
Freeing (NOT implemented) redirected PCI irq 11.
map[20]: type 4, range 32, base b400, size 5, enabled
found-> vendor=0x8086, dev=0x24d7, revid=0x02
bus=0, slot=29, func=2
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=c, irq=9
Freeing (NOT implemented) redirected PCI irq 5.
map[20]: type 4, range 32, base b800, size 5, enabled
found-> vendor=0x8086, dev=0x24de, revid=0x02
bus=0, slot=29, func=3
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=2
IOAPIC #0 intpin 23 -> irq 10
Freeing (NOT implemented) redirected PCI irq 11.
map[10]: type 1, range 32, base f6101000, size 10, enabled
found-> vendor=0x8086, dev=0x24dd, revid=0x02
bus=0, slot=29, func=7
class=0c-03-20, hdrtype=0x00, mfdev=0
cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=d, irq=10
powerspec 2 supports D0 D3 current D0
found-> vendor=0x8086, dev=0x244e, revid=0xc2
bus=0, slot=30, func=0
class=06-04-00, hdrtype=0x01, mfdev=0
cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns)
found-> vendor=0x8086, dev=0x24d0, revid=0x02
bus=0, slot=31, func=0
class=06-01-00, hdrtype=0x00, mfdev=1
cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords)
lattime
Re: Buildworld /rescue failures in 5.1
On Wed, Jul 23, 2003 at 10:13:20PM -0400, Garance A Drosihn wrote: > At 8:14 PM -0400 7/23/03, Garance A Drosihn wrote: > > > >So indeed, that 'make depend' had not finished before > >the 'make' for the object had started. > > I was going to do some debugging of what 'make' is doing, but > it looks like crunchgen gets confused if make has any kind of > debugging flags turned on. However, I have to get back to my > real-job work before my manager clobbers me, so this is > probably as far as I'm going to take this for now. I just committed 1.14 of src/rescue/rescue/Makefile that should fix the -j build with rescue. Please let me know if it doesn't work. Otherwise, I'm heading to bed. Night. -gordon pgp0.pgp Description: PGP signature
Re: fuword(), suword(), etc.
On Wed, Jul 23, 2003 at 02:48:41PM -0700, Julian Elischer wrote:
+> I'd like to have a "suptr and fuptr" to be able to save and read
+> user pointers in a "machine independent" manner..
+> at the moment ia need to know the size of a pointer and select the
+> appropriate 32 or 64 version.. It would jus tbe another ENTRY files in
+> support.[sS] alongside teh appropriate sized entry
+> for each architecture so it wouldn't 'cost' anything..
+>
+> for i386 it would be an alternate name for fuword32() and suword32()
+> I'm not sure what it would be on other architectures
+>
+> comments?
Yes, good idea. I'm using for now something like this:
static __inline void *
fuptr(void *uaddr)
{
void *ptr;
if (copyin(uaddr, &ptr, sizeof(void *)) != 0)
return ((void *)-1);
return (ptr);
}
For numbers is always better to use copyin(9)/copyout(9). Functions
like fubyte(9), etc. make no sens for me. -1 is returned on error or
if there is really -1, so one isn't able to find out if there is an
error or not.
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
pgp0.pgp
Description: PGP signature
Re: fuword(), suword(), etc.
Julian Elischer wrote:
> I'd like to have a "suptr and fuptr" to be able to save and read
> user pointers in a "machine independent" manner..
> at the moment ia need to know the size of a pointer and select the
> appropriate 32 or 64 version.. It would jus tbe another ENTRY files in
> support.[sS] alongside teh appropriate sized entry
> for each architecture so it wouldn't 'cost' anything..
>
> for i386 it would be an alternate name for fuword32() and suword32()
> I'm not sure what it would be on other architectures
>
> comments?
You cannot be certain that specific user space pointers are 64
bits on a 32 bit kernel or 32 bits on on a 64 bit kernel, etc..
The reason for this is that you may wish to operate in a hybrid
or backward compatability mode, or you may wish to operate the
kernel in a smaller virtual address space than user space, or
vice versa, as a developement decision.
For example the PPC 970 ("G5") processor has specific support for
backward binary compatability, as does the AMD "Hammer", the Intel
"Opteron" (IA64), and the SPARC64.
Probably it will be a long time before many commercial 32 bit
applications are ported to 64 bit kernels, and you're going to
want to be able to run the 32 bit applications.
The point is that you will probably end up needing at least 4
macros each, if you have sized types on both ends, and two each,
if you assume that the kernel pointer size is fixed on every
architecture.
Personally, I would call this a "kernel is aware of the ABI for
each of the applications it is currently running", and make it a
flag in the system call table, if you insist on using a single
name for the thing.
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fuword(), suword(), etc.
Marcel Moolenaar wrote: > > for i386 it would be an alternate name for fuword32() and suword32() > > I'm not sure what it would be on other architectures > > fuword64 and suword64. PowerPC is like i386. PPC 970 explicitly supports mixed mode programming between user and kernel, as do most other 64 bit processors, in order to support legacy applications. It's actually unlikely that IBM will ever release enough documentation to get a full 64 bit Linux running on a PPC 970, let alone FreeBSD, and that you will be stuck with a 32 bit kernel that runs 64 bit apps, and which talks to IBM's internal undocumented glue on the bottom end while running in a virtual environment, such that the interfaces to that glue are not exposed in the source code they publish. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
Hi Bosko, Well I went to go change my /boot/loader.conf options to reflect the following: kern.vm.kmem.size="35" kern.ipc.nmbclusters="8192" and enabled "options DDB" in my kernel. Unfortunately, I ran into a problem on the reboot, the SMP kernel would fail to load due to some of my /boot/loader.conf changes perhaps I miss-understood something in your instructions... anyhow, this is what was displayed on the console when I set those above settings in the /boot/loader.conf... and since I had the debugger running, I did a trace and included in the paste below... is that the kind of stuff you will want if the box crashes again as originally mentioned in this thread. --- /boot/kernel/acpi.ko text=0x39b54 data=0x1638+0xf68 syms=[0x4+0x6200+0x4+0x7b62] 2097152K of memory above 4GB ignored 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-RELEASE #0: Thu Jul 24 00:19:10 MDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP Preloaded elf kernel "/boot/kernel/kernel" at 0xc0702000. Preloaded elf module "/boot/kernel/ipfw.ko" at 0xc07022e4. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0702390. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2399328136 Hz CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 4160225280 (3967 MB) avail memory = 4045996032 (3858 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 6, version: 0x00050014, at 0xfee0 cpu2 (AP): apic id: 1, version: 0x00050014, at 0xfee0 cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 io1 (APIC): apic id: 3, version: 0x00178020, at 0xfec8 io2 (APIC): apic id: 4, version: 0x00178020, at 0xfec80400 Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x8 fault code = supervisor write, page not present instruction pointer = 0x8:0xc034678e stack pointer = 0x10:0xc0724d60 frame pointer = 0x10:0xc0724d80 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at sf_buf_init+0xce: movl%eax,0x8(%ebx,%edx,1) db> trace sf_buf_init(0,721000,721c00,721000,0) at sf_buf_init+0xce mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db> --- Thanks, Stephane. - Original Message - From: "Bosko Milekic" <[EMAIL PROTECTED]> Newsgroups: mailing.freebsd.current Sent: Wednesday, July 23, 2003 10:14 Subject: Re: FreeBSD 5.1-R kernel panic > > On Wed, Jul 23, 2003 at 09:56:32AM -0600, Stephane Raimbault wrote: > > Hi Bosko, > > > > Looking at netstat -m, the value I'd probably be interested in is the > > following: > > > > 3% of cluster map consumed > > > > knowing that the Maximum possible is 25600 I can deduce that ~768 are being > > used? Is that correct. I'm not much of a programmer, but I did recognize > > the printf(); statements from a C class I didn't do well in half a decade > > ago... as you can tell, I'm not much of a programmer :). If it's not the 3% > > I should be paying attention too... then let me know :) > > Look at the "in pool" values for all the pcpu and GEN caches and add > them up. Do this for clusters (since there are fewer). Compare to > the "Maximum Possible" value. With a machine that goes into > spike-load periods, you may want to have the Maximum Possible stay > about 4-6 times what you have as your average "in pool" value > (remember to sum the "in pool" values for the pcpu and GEN caches). > > The 3% is not what you think it is. It's the percentage of the > allocated wired-down memory that is NOT in any of the caches but is > allocated and circulating in the system. If you have a high number of > cached items but the percentage is relatively low for most of the > time, it's a sign that you were probably in a heavy-usage scenario > some time ago, but that your current usage is relatively low. > > > As for using the option DDB in my kernel, I do have one question. I do have > > remote console access that I use to go into single user mode on the box > > remotely. I'm suspecting I could use the debugger mode over the > > comconsole... I just want to make sure there is some kind of reboot command > > from the debugger so that I can tell the box to reboot once I've cap
Re: FreeBSD 5.1-R kernel panic
Thanks for getting back to me regarding that point Scott. I recently realized that I was miss-understanding how much free memory I had on the system, and I doubt I even need the full 4Gig's. Perhaps I can re-confirm how to check how much free real memory is available on the system. Looking at the top command, add the Inact and Free memory? Mem: 180M Active, 499M Inact, 213M Wired, 76K Cache, 112M Buf, 2999M Free so in this case, 3498 actual free memory? Or is there a more accurate way in determining how much memory is left in the system to be used... basically I'm trying to find the indicator I should be monitoring that should tell me if I need to add more ram to the system then I currently have. Thanks, Stephane. - Original Message - From: "Scott Long" <[EMAIL PROTECTED]> Newsgroups: mailing.freebsd.current Sent: Wednesday, July 23, 2003 14:09 Subject: Re: FreeBSD 5.1-R kernel panic > Stephane Raimbault wrote: > > Hi Thanks for your response, > > > > I do not have PAE enabled... I've been hesitant of turning it on, I'm not > > sure if it's too stable, I noticed that the asr driver is in the nodriver > > list in the PAE kernel config file and I use the asr driver for my Adaptec > > 2015S raid card. If you think its safe to enable PAE with my current setup, > > please let me know, I do have 2 more gig's of ram in this particular box > > that I'd like to enable if it doesn't compromise system stability. > > > > The asr(4) driver will likely not operate correctly in a PAE > environment. There is no estimated time frame for fixing this either. > > Scott > > ___ > [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: questions on S-ATA and ICH5 (now owns hardware :)
It seems John Reynolds wrote: > Hi all, a few weeks back I had asked whether -current supported ICH5's S-ATA > and Søren stated that he'd put code in to detect it and it "should work" but > there wasn't a lot of feedback yet from users. Well, I have some feedback. I > just got a new spiffy 120Gb Seagate S-ATA drive today and I can say that > -current (as of 7/22/2003) does at least see the drive plugged into the > controller and I can build filesystems, copy/delete files to my heart's > content. However, I'm not sure if everything is entirely correct. I'm attaching > a verbose dmesg (somewhat trimmed). The first thing I notice is that I see the > following bits: > > atapci1: port > 0xd000-0xd00f,0xcc00-0xcc03,0xc800-0xc807,0xc400-0xc403,0xc000-0xc007 irq 9 at > device 31.2 on pci0 > ... > ata2: at 0xc000 on atapci1 > ad4: success setting UDMA133 on Intel ICH5 chip > ad4: ATA-6 disk at ata2-master > ad4: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B > ad4: 16 secs/int, 1 depth queue, UDMA133 > ad4: piomode=12 dmamode=34 udmamode=70 cblid=1 > > Shouldn't this drive be found as a SATA150 device? Well, technically yes, but in practice the modes the drives reports back as supported are the old UDMA ones, however the interface will run at SATA150 speed no matter what. I've not found a surefire way to tell this apart yet that also gives resonable results if you use a SATA->PATA dongle and other wierd comboes now possible... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NOCRYPT and exists(src/crypto) check
Hi there!
There's currently an inconsistency in how various makefiles
(that use crypto bits) check if these bits are available.
All of them check for the NOCRYPT knob, and some of them
also check if src/crypto/ exists, and some not. None of
them also check if src/secure/ exists, which is the where
the crypto libraries get actually built. Here's the current
summary of these makefiles:
makefiles that don't check if src/crypto/ exists:
gnu/usr.bin/cvs/cvs/Makefile
lib/libfetch/Makefile
lib/libtelnet/Makefile
libexec/telnetd/Makefile
usr.bin/fetch/Makefile
usr.bin/telnet/Makefile
usr.sbin/pkg_install/Makefile
usr.sbin/pkg_install/add/Makefile
usr.sbin/pkg_install/create/Makefile
usr.sbin/pkg_install/delete/Makefile
usr.sbin/pkg_install/info/Makefile
usr.sbin/pkg_install/version/Makefile
makefiles that check if src/crypto/ exists:
bin/ed/Makefile
games/factor/Makefile
lib/Makefile
rescue/rescue/Makefile
usr.bin/Makefile
usr.sbin/Makefile
usr.sbin/ppp/Makefile
usr.sbin/pppd/Makefile
usr.sbin/sendmail/Makefile
usr.sbin/tcpdump/tcpdump/Makefile
Since the "exists(${.CURDIR}/.../crypto) && !defined(NOCRYPT)" check
is weak (it lacks the exists(${.CURDIR}/.../secure) check), I suggest
to simplify these makefiles and remove these obscure exists() checks.
Users that don't fetch crypto sources (src/crypto/ and src/secure/)
will then just have to specify that in their /etc/make.conf. Not
fetching crypto sources and not specifying NOCRYPT currently gives
a broken build, so this change shouldn't surprise a lot of people.
Also, a similar change for src/kerberos5/ is proposed.
I'd appreciate a quick response.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: questions on S-ATA and ICH5 (now owns hardware :)
atapci1: port 0xd000-0xd00f,0xcc00-0xcc03,0xc800-0xc807,0xc400-0xc403,0xc000-0xc007 irq 9 at device 31.2 on pci0 ... ata2: at 0xc000 on atapci1 ad4: success setting UDMA133 on Intel ICH5 chip ad4: ATA-6 disk at ata2-master ad4: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, UDMA133 ad4: piomode=12 dmamode=34 udmamode=70 cblid=1 Shouldn't this drive be found as a SATA150 device? Well, technically yes, but in practice the modes the drives reports back as supported are the old UDMA ones, however the interface will run at SATA150 speed no matter what. I've not found a surefire way to tell this apart yet that also gives resonable results if you use a SATA->PATA dongle and other wierd comboes now possible... Yeah. My drive shows up as UDMA133 also. What I did notice is that my WD Raptor was slightly outperformed a few times on UFS2 by my actual ATA-100 Western Digital drive. This seems somewhat bad as the Raptor costs a hell of a lot more and one would hope that it would pound the ATA-100 drive pretty thoroughly. Even the CPU overheads on both drives were about the same. Maybe its that 8MB caching :). I haven't found a good reason yet. Soeren, do you actually have SATA drives to test with or do you just have SATA adapters with SATA->PATA dongles? Do you need more hardware to run some benchmarks yourself? [I don't know that I can afford to buy you a SATA disk but I wonder anyway :)] Dave -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]"
panic while reading ntfs partition
Hi, Not sure if this is useful, but I'm getting a perfectly reproducible panic when doing 'grep -R foo .' (as normal user) in a read-only mounted ntfs partition on a -current as of ~3 weeks ago: Good dump found on device /dev/ad0s2b Architecture: i386 Architecture version: 1 Dump length: 259461120B (247 MB) Blocksize: 512 Dumptime: Thu Jul 24 13:51:36 2003 Hostname: phys9911.phys.tue.nl Versionstring: FreeBSD 5.1-CURRENT #3: Fri Jul 4 10:56:05 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/KAYJAY Panicstring: bundirty: buffer 0xc72d9868 still on queue 2 Bounds: 3 Since I have no idea whether the ntfs partition is OK because the Win2000 there does not boot anymore (not even in safe mode), I'm not sure if it might be due to an unclean ntfs partition. But then, shouldn't FreeBSD detect this at mount time or is it the user's responsibility? Karel. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: questions on S-ATA and ICH5 (now owns hardware :)
> Yeah. My drive shows up as UDMA133 also. What I did notice is that > my WD Raptor was slightly outperformed a few times on UFS2 by > my actual > ATA-100 Western Digital drive. This seems somewhat bad as the Raptor > costs a hell of a lot more and one would hope that it would pound the > ATA-100 drive pretty thoroughly. > > Even the CPU overheads on both drives were about the same. Maybe its > that > 8MB caching :). I haven't found a good reason yet. Keep in mind that you are dealing with 36GB vs. 60 or 80GB platter density. The Raptor ought to be quicker but the older WD drive could be faster. Especially in long sequential reads. -Will ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ata tagged queuing support question
helo.
ata-disk.c
/* use tagged queueing if allowed and supported */
#if 0 /* disable tags for now */
if (ata_tags && ad_tagsupported(adp)) {
adp->num_tags = atadev->param->queuelen;
adp->flags |= AD_F_TAG_ENABLED;
adp->device->channel->flags |= ATA_QUEUED;
if (ata_command(atadev, ATA_C_SETFEATURES,
0, 0, ATA_C_F_DIS_RELIRQ, ATA_WAIT_INTR))
ata_prtdev(atadev, "disabling release interrupt failed\n");
if (ata_command(atadev, ATA_C_SETFEATURES,
0, 0, ATA_C_F_DIS_SRVIRQ, ATA_WAIT_INTR))
ata_prtdev(atadev, "disabling service interrupt failed\n");
}
#endif
tagged queueing broken in -current? i have IBM ICxAV drives and want
to use this feature. can i enable this block?
/swp
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fuword(), suword(), etc.
On Thu, 2003-07-24 at 03:40, Terry Lambert wrote: > It's actually unlikely that IBM will ever release enough documentation > to get a full 64 bit Linux running on a PPC 970, let alone FreeBSD, > and that you will be stuck with a 32 bit kernel that runs 64 bit apps, > and which talks to IBM's internal undocumented glue on the bottom end > while running in a virtual environment, such that the interfaces to > that glue are not exposed in the source code they publish. That's very interesting to me as IBM has been rather forthcoming about making sure everyone knows that the 32bit bridge was only temporary and to not rely on it being there in the future. I would hope that would indicate that they may be willing to release more informaation in the future regarding this. Of course, what do I know? :p -- Shawn <[EMAIL PROTECTED]> http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ata tagged queuing support question
It seems mitrohin a.s. wrote:
> ata-disk.c
>
> /* use tagged queueing if allowed and supported */
> #if 0 /* disable tags for now */
> if (ata_tags && ad_tagsupported(adp)) {
> adp->num_tags = atadev->param->queuelen;
> adp->flags |= AD_F_TAG_ENABLED;
> adp->device->channel->flags |= ATA_QUEUED;
> if (ata_command(atadev, ATA_C_SETFEATURES,
> 0, 0, ATA_C_F_DIS_RELIRQ, ATA_WAIT_INTR))
> ata_prtdev(atadev, "disabling release interrupt failed\n");
> if (ata_command(atadev, ATA_C_SETFEATURES,
> 0, 0, ATA_C_F_DIS_SRVIRQ, ATA_WAIT_INTR))
> ata_prtdev(atadev, "disabling service interrupt failed\n");
> }
> #endif
>
> tagged queueing broken in -current? i have IBM ICxAV drives and want
> to use this feature. can i enable this block?
It doesn't work for now, and question is if it will ever be enabled
again as it causes more problems than it solves.
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
File system deadlock. GBDE(4) and/or MD(4) related.
Hello. I've found deadlock in gbde(4) and/or md(4). Here is a complete procedure hot to repeat it: # touch /mnt/test.file # mdconfig -a -t vnode -f /mnt/test.file -s 512M -u 1 # mkdir /etc/gbde # gbde init /dev/md1 -L /etc/gbde/md1 Enter new passphrase: Reenter new passphrase: Wrote key 0 at 25444352 # gbde attach md1 -l /etc/gbde/md1 Enter passphrase: # newfs -U -O2 /dev/md1.bde /dev/md1.bde: 496.5MB (1016768 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 124.12MB, 7944 blks, 15936 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 254368, 508576, 762784 # mkdir /mnt/test # mount /dev/md1.bde /mnt/test # cp -R /usr/src /mnt/test & [ wait about 10 seconds ] # ls /mnt/te[TAB] or # sync;sync -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: OT: X aperture
On Thursday 24 July 2003 07:53 am, [EMAIL PROTECTED] wrote: > Hello again! > Sorry for trolling. > I have just found one more way to have X and seculevel coexisting. > It's applicable for desktops mostly.Here's the trick: > Start the system with seculevel "-1", run startx and then type > '/sbin/sysctl -w kern.securelevel=1' in a terminal. The last requires as > all know requires root privileges or sudo. Yes, already said that. But if the X server crashes or exits, you won't be able to start it again without rebooting. That's why OpenBSD's APERTURE option is superior. > Thanks for your patience, > Dimitar Vassilev -- Farid Hajji. http://www.farid-hajji.net/address.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ata tagged queuing support question
mitrohin a.s. wrote:
helo.
ata-disk.c
/* use tagged queueing if allowed and supported */
#if 0 /* disable tags for now */
if (ata_tags && ad_tagsupported(adp)) {
adp->num_tags = atadev->param->queuelen;
adp->flags |= AD_F_TAG_ENABLED;
adp->device->channel->flags |= ATA_QUEUED;
if (ata_command(atadev, ATA_C_SETFEATURES,
0, 0, ATA_C_F_DIS_RELIRQ, ATA_WAIT_INTR))
ata_prtdev(atadev, "disabling release interrupt failed\n");
if (ata_command(atadev, ATA_C_SETFEATURES,
0, 0, ATA_C_F_DIS_SRVIRQ, ATA_WAIT_INTR))
ata_prtdev(atadev, "disabling service interrupt failed\n");
}
#endif
tagged queueing broken in -current? i have IBM ICxAV drives and want
to use this feature. can i enable this block?
Don't. It's very frequently broken by *hardware* and not worth the trouble
in terms of performance.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: File system deadlock. GBDE(4) and/or MD(4) related.
On Thu, Jul 24, 2003 at 03:57:07PM +0200, Pawel Jakub Dawidek wrote: +> I've found deadlock in gbde(4) and/or md(4). Yes, it is gbde fault: db> show lockedvnods [...] 0xc3332920: tag ufs, type VREG, usecount 1, writecount 0, refcount 21, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc2ca5000 ino 8214, on dev md0.bde (4, 23) 0xc33325b4: tag ufs, type VREG, usecount 2, writecount 1, refcount 25, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc2ec3980 ino 8217, on dev md0.bde (4, 23) [...] Look at refcounts. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: ata tagged queuing support question
On Thu, Jul 24, 2003 at 03:26:53PM +0200, Soeren Schmidt wrote:
> It seems mitrohin a.s. wrote:
> > ata-disk.c
> >
> > /* use tagged queueing if allowed and supported */
> > #if 0 /* disable tags for now */
> > if (ata_tags && ad_tagsupported(adp)) {
> > adp->num_tags = atadev->param->queuelen;
> > adp->flags |= AD_F_TAG_ENABLED;
> > adp->device->channel->flags |= ATA_QUEUED;
> > if (ata_command(atadev, ATA_C_SETFEATURES,
> > 0, 0, ATA_C_F_DIS_RELIRQ, ATA_WAIT_INTR))
> > ata_prtdev(atadev, "disabling release interrupt failed\n");
> > if (ata_command(atadev, ATA_C_SETFEATURES,
> > 0, 0, ATA_C_F_DIS_SRVIRQ, ATA_WAIT_INTR))
> > ata_prtdev(atadev, "disabling service interrupt failed\n");
> > }
> > #endif
> >
> > tagged queueing broken in -current? i have IBM ICxAV drives and want
> > to use this feature. can i enable this block?
>
> It doesn't work for now, and question is if it will ever be enabled
> again as it causes more problems than it solves.
>
> -S?ren
thanks...
/swp
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ata tagged queuing support question
On Thu, Jul 24, 2003 at 04:08:01PM +0200, Marcin Dalecki wrote: > >tagged queueing broken in -current? i have IBM ICxAV drives and want > >to use this feature. can i enable this block? > > Don't. It's very frequently broken by *hardware* and not worth the trouble > in terms of performance. hmm... but RELENG_4 enable this... /swp ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: File system deadlock. GBDE(4) and/or MD(4) related.
In message <[EMAIL PROTECTED]>, Pawel Jakub Dawidek writ es: > >On Thu, Jul 24, 2003 at 03:57:07PM +0200, Pawel Jakub Dawidek wrote: >+> I've found deadlock in gbde(4) and/or md(4). > >Yes, it is gbde fault: I don't know what you have found, but I can guarantee you that it is _not_ gbde that holds references on vnodes. GBDE doesn't even know what a vnode is. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: File system deadlock. GBDE(4) and/or MD(4) related.
In message <[EMAIL PROTECTED]>, Pawel Jakub Dawidek writ es: > # touch /mnt/test.file You are probably missing: dd if=/dev/null of=/mnt/test.file bs=1m count=512 > # mdconfig -a -t vnode -f /mnt/test.file -s 512M -u 1 What you have found has nothing to do with GBDE, I think it is the usual "vnode backed md(4)" deadlock. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ata tagged queuing support question
It seems mitrohin a.s. wrote: > On Thu, Jul 24, 2003 at 04:08:01PM +0200, Marcin Dalecki wrote: > > >tagged queueing broken in -current? i have IBM ICxAV drives and want > > >to use this feature. can i enable this block? > > > > Don't. It's very frequently broken by *hardware* and not worth the trouble > > in terms of performance. > > hmm... but RELENG_4 enable this... Yes, and its problematic there as well, but I havn't gotten around to do anything about it yet (ENOTIME)... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
login.conf issue
I am using login.conf to set a minimul password length in the default class and root class, after adding :minpasswordlen=8: to default and :minpasswordlen=11: to root and then running $ cap_mkdb /etc/login.conf I can still use a password of 1 character. This is on FreeBSD 5.1-RELEASE i386. I have tried this on a 4.8 system and this works fine, did I miss something in the release notes? Below are the steps I took for 5.1 $ vim /etc/login.conf default:\ :passwd_format=md5:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\ :path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin ~/bin:\ :nologin=/var/run/nologin:\ :cputime=unlimited:\ :datasize=unlimited:\ :stacksize=unlimited:\ :memorylocked=unlimited:\ :memoryuse=unlimited:\ :filesize=unlimited:\ :coredumpsize=unlimited:\ :openfiles=unlimited:\ :maxproc=unlimited:\ :sbsize=unlimited:\ :vmemoryuse=unlimited:\ :priority=0:\ :ignoretime@:\ :umask=022:\ :minpasswordlen=8: root:\ :ignorenologin:\ :minpasswordlen=8:\ :tc=default: $ cap_mkdb /etc/login.conf $ passwd -l test Changing local password for test. New password: a Retype new password: a passwd: updating the database... passwd: done $ On 4.8, edits to login.conf are the same, and I get this for passwd: $ passwd -l test Changing local password for mcarlson. New password: a Please enter a password at least 8 characters in length New password: ^c Password unchanged. passwd: /etc/master.passwd: unchanged $ Thanks Mike Carlson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: login.conf issue
Michael Carlson wrote: I am using login.conf to set a minimul password length in the default class and root class, after adding :minpasswordlen=8: to default and :minpasswordlen=11: to root and then running $ cap_mkdb /etc/login.conf I can still use a password of 1 character. This is on FreeBSD 5.1-RELEASE i386. I have tried this on a 4.8 system and this works fine, did I miss something in the release notes? login.conf(5): The minpasswordlen and minpasswordcase facilities for enforcing restric- tions on password quality, which used to be supported by login.conf, have been superseded by the pam_passwdqc(8) PAM module. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Bradley's Bromide: If computers get too powerful, we can organize them into a committee -- that will do them in. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: login.conf issue
Michael Carlson wrote: I am using login.conf to set a minimul password length in the default class and root class, after adding :minpasswordlen=8: to default and :minpasswordlen=11: to root and then running $ cap_mkdb /etc/login.conf I can still use a password of 1 character. This is on FreeBSD 5.1-RELEASE i386. I have tried this on a 4.8 system and this works fine, did I miss something in the release notes? I might also add that the same man page says this about these two capabilities: RESERVED CAPABILITIES The following capabilities are reserved for the purposes indicated and may be supported by third-party software. They are not implemented in the base system. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Bradley's Bromide: If computers get too powerful, we can organize them into a committee -- that will do them in. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
syntax problem with /etc/rc.d/nfslocking
Occasionally, one of my systems gets rpc.lockd stuck using all of the CPU cycles. I fix it by running '/etc/rc.d/nfslocking restart'. That works but it shows there is a syntax error somewhere. Here is the output that I get: [: checkyesno: unexpected operator Stopping statd. [: checkyesno: unexpected operator Stopping lockd. Starting statd. Starting lockd. I have the following in /etc/rc.conf: nfs_client_enable="YES" nfs_server_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" rpcbind_enable="YES" -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: File system deadlock. GBDE(4) and/or MD(4) related.
Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, Pawel Jakub Dawidek writ es: # touch /mnt/test.file You are probably missing: dd if=/dev/null of=/mnt/test.file bs=1m count=512 # mdconfig -a -t vnode -f /mnt/test.file -s 512M -u 1 What you have found has nothing to do with GBDE, I think it is the usual "vnode backed md(4)" deadlock. I wrote a howto that is somewhat similare to the desired steps in case anybody is interested in another way: http://www.ezunix.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=67&page=1 I've used gbde extensivly and have doubts about any issues. However, maybe some sanity checks in gbde would catch the problem? -Jon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: syntax problem with /etc/rc.d/nfslocking
Thanks! I just committed a fix (reproduced here for your convenience). Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! Index: etc/rc.subr === RCS file: /home/ncvs/src/etc/rc.subr,v retrieving revision 1.13 diff -u -r1.13 rc.subr --- etc/rc.subr 9 Jun 2003 17:31:06 - 1.13 +++ etc/rc.subr 24 Jul 2003 18:15:02 - @@ -669,7 +669,7 @@ # if the precmd failed and force # isn't set, exit # - if [ -n $_precmd ]; then + if [ -n "$_precmd" ]; then eval $_precmd _return=$? [ $_return -ne 0 ] && [ -z "$rc_force" ] && ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: File system deadlock. GBDE(4) and/or MD(4) related.
On Thu, Jul 24, 2003 at 05:03:23PM +0200, Poul-Henning Kamp wrote: +> ># touch /mnt/test.file +> +> You are probably missing: +> +> dd if=/dev/null of=/mnt/test.file bs=1m count=512 You mean /dev/zero? But this doesn't change anything. +> ># mdconfig -a -t vnode -f /mnt/test.file -s 512M -u 1 +> +> What you have found has nothing to do with GBDE, I think it is the +> usual "vnode backed md(4)" deadlock. Hmm? So you're trying to tell that this is somehow normal behaviour? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Buildworld /rescue failures in 5.1
At 12:44 AM -0700 7/24/03, Gordon Tetlow wrote: On Wed, Jul 23, 2003 at 10:13:20PM -0400, Garance A Drosihn wrote: > > I was going to do some debugging of what 'make' is doing, > but it looks like crunchgen gets confused if make has any > kind of debugging flags turned on. I just committed 1.14 of src/rescue/rescue/Makefile that should fix the -j build with rescue. Please let me know if it doesn't work. Otherwise, I'm heading to bed. Night. This has worked for me. I did a cvsup, and then did the same sequence of steps which has consistently failed. This time the buildworld completed with no errors. Nice job, Thanks! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: File system deadlock. GBDE(4) and/or MD(4) related.
In message <[EMAIL PROTECTED]>, Pawel Jakub Dawidek writ es: >+> dd if=3D/dev/null of=3D/mnt/test.file bs=3D1m count=3D512 > >You mean /dev/zero? But this doesn't change anything. Yes, /dev/zero of course. >+> > # mdconfig -a -t vnode -f /mnt/test.file -s 512M -u 1 >+>=20 >+> What you have found has nothing to do with GBDE, I think it is the >+> usual "vnode backed md(4)" deadlock. > >Hmm? So you're trying to tell that this is somehow normal behaviour? We've had problems like this before with vnode backed MD(4) devices (and vn(4) devices before that). One way or another: It is _not_ a GBDE problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Portable USB hard drive regression
On Wed, Jul 23, 2003 at 11:00:18AM -0700, John-Mark Gurney wrote: > Please provide more information, such as dmesg including the controller > you are using. Also, you don't state if this is USB2.0 device or a > USB1.1 device. This makes it hard to debug and understand. > > Also, I would recomment you recompile your kernel w/ USB_DEBUG, and > be prepared to turn on various sysctl's to provide more information. OK, here's the data you asked for: The hard drive says it supports USB 2.0, but my machine only has USB 1.0 controllers. The complete dmesg is at: http://people.freebsd.org/~mtm/dmesg.boot , but the USB part is: uhci0: port 0xb400-0xb41f irq 12 at device 7.2 on pc i0 usb0: 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 ums0: Microsoft Microsoft Wheel Mouse Optical\M-., rev 1.10/1.21, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci1: port 0xb800-0xb81f irq 12 at device 7.3 on pc i0 usb1: 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 ugen0: Genesys Logic USB Host To Host Bridge, rev 1.00/1.80, addr 2 The output when I try to connect the device (with options USB_DEBUG): Jul/24 [EMAIL PROTECTED] ~% sysctl -a | grep usb hw.usb.ehci.debug: 0 hw.usb.ohci.debug: 1 hw.usb.ugen.debug: 1 hw.usb.uhci.debug: 1 hw.usb.uhci.loop: 0 hw.usb.uhid.debug: 0 hw.usb.uhub.debug: 1 hw.usb.ukbd.debug: 0 hw.usb.ulpt.debug: 0 hw.usb.umass.debug: 1 hw.usb.ums.debug: 0 hw.usb.urio.debug: 1 hw.usb.uscanner.debug: 0 hw.usb.debug: 1 uhub_explore: status change hub=1 port=1 usbd_new_device bus=0xc261 port=1 depth=1 speed=2 usbd_new_device: adding unit addr=3, rev=200, class=0, subclass=0, protocol=0, maxpacket=64, len=18, speed=2 usbd_new_device: new dev (addr 3), dev=0xc2670200, parent=0xc2640b00 usbd_probe_and_attach: trying device specific drivers usbd_probe_and_attach: no device specific driver found usbd_probe_and_attach: looping over 1 configurations usbd_set_config_index: status=0x0001, error=NORMAL_COMPLETION usbd_set_config_index: (addr 2) cno=3 attr=0xc0, selfpowered=1, power=98 usbd_set_config_index: set config 2 umass0: NewAge International STORIX Fusion25, rev 2.00/11.00, addr 3 umass0: SCSI over Bulk-Only; quirks = 0x umass0:4:0:-1: Attached to scbus4 uhci_timeout: uxfer=0xc29a5100 uhci_timeout_task: xfer=0xc29a5100 uhci_check_intr: aborted xfer=0xc29a5100 uhci_timeout: uxfer=0xc2526500 uhci_timeout_task: xfer=0xc2526500 uhci_check_intr: aborted xfer=0xc2526500 umass0: BBB reset failed, TIMEOUT uhci_timeout: uxfer=0xc29a5100 uhci_timeout_task: xfer=0xc29a5100 uhci_check_intr: aborted xfer=0xc29a5100 uhci_timeout: uxfer=0xc2526500 uhci_timeout_task: xfer=0xc2526500 uhci_check_intr: aborted xfer=0xc2526500 umass0: BBB reset failed, TIMEOUT uhci_timeout: uxfer=0xc29a5100 uhci_timeout_task: xfer=0xc29a5100 uhci_check_intr: aborted xfer=0xc29a5100 uhci_timeout: uxfer=0xc2526500 uhci_timeout_task: xfer=0xc2526500 uhci_check_intr: aborted xfer=0xc2526500 umass0: BBB reset failed, TIMEOUT uhci_timeout: uxfer=0xc29a5100 uhci_timeout_task: xfer=0xc29a5100 uhci_check_intr: aborted xfer=0xc29a5100 uhci_timeout: uxfer=0xc2526500 uhci_timeout_task: xfer=0xc2526500 uhci_check_intr: aborted xfer=0xc2526500 umass0: BBB reset failed, TIMEOUT uhci_timeout: uxfer=0xc29a5100 uhci_timeout_task: xfer=0xc29a5100 uhci_check_intr: aborted xfer=0xc29a5100 uhci_timeout: uxfer=0xc2526500 uhci_timeout_task: xfer=0xc2526500 uhci_check_intr: aborted xfer=0xc2526500 umass0: BBB reset failed, TIMEOUT Please let me know how else I can be of assistance. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Floppyless release build of sparc64
On Wed, Jul 23, 2003 at 07:07:30PM +0300, Ruslan Ermilov wrote: > On Wed, Jul 23, 2003 at 11:57:58AM -0400, Jake Burkholder wrote: > > Apparently, On Wed, Jul 23, 2003 at 09:16:43AM +0300, > > Ruslan Ermilov said words to the effect of; > > > > > A similar change would be in order for sparc64. Patch is > > > attached, please review. The net effect is that we save > > > huge CPU times in release.9 and do not create the useless > > > boot.flp floppy image (the sparc64/mkisoimages.sh script > > > doesn't need it). > > > > boot.flp is actually useful on sparc64 because you can dd it to a disk > > from solaris and then boot off it to install. I'm happy with having > > the option of not building it if it saves time but please make it an > > option. > > OK, then things will be left as is. There's already an option for > this; it's called NO_FLOPPIES (documented in the release(7) manpage). BUT the size of the "floppy" should be something like 10MB so that we know we will *never* overflow it during "make release". -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: File system deadlock. GBDE(4) and/or MD(4) related.
On Thu, Jul 24, 2003 at 08:38:02PM +0200, Poul-Henning Kamp wrote: +> >+> What you have found has nothing to do with GBDE, I think it is the +> >+> usual "vnode backed md(4)" deadlock. +> > +> >Hmm? So you're trying to tell that this is somehow normal behaviour? +> +> We've had problems like this before with vnode backed MD(4) devices +> (and vn(4) devices before that). +> +> One way or another: It is _not_ a GBDE problem. Hey, Poul! I'm not trying to show that gbde(4) is a buggy software, I'm not trying to destroy you work, your image or FreeBSD, really. I believe that this isn't bug in gbde(4), my fault, sorry. But one thing I know, is that bug is somewhere and I just want to help track it down. This information could be useful: When I've mounted file system on /private (not on /mnt/private) there is no problem anymore. So maybe deadlock is caused by some directory locking or something? Because if file system in mounted on /mnt/private deadlock is 100% reproducable. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Buildworld /rescue failures in 5.1
Garance A Drosihn wrote:
Wed Jul 23 20:08:06 EDT 2003 Starting make depend
in /usr/obj/usr/src/rescue/rescue/usr/src/gnu/usr.bin/gzip
Wed Jul 23 20:08:07 EDT 2003 Finished make depend
in /usr/obj/usr/src/rescue/rescue/usr/src/gnu/usr.bin/gzip
Wed Jul 23 20:08:09 EDT 2003 Starting make depend
in /usr/obj/usr/src/rescue/rescue/usr/src/gnu/usr.bin/tar
So indeed, that 'make depend' had not finished before the 'make'
for the object had started.
There's another possibility here: suppose two copies
of make are running simultaneously and both get to
this sequence at about the same time:
tar_make:
(cd $(tar_SRCDIR) && \
$(MAKE) $(BUILDOPTS) $(tar_OPTS) depend &&\
$(MAKE) $(BUILDOPTS) $(tar_OPTS) $(tar_OBJS))
The first make to run this will start building dependencies.
The second copy will see that ".depend" already exists (note that
bsd.dep.mk builds .depend incrementally) and then go on to the
next step. Depending on the exact timing, this could result in
an attempt to build the object files with an incomplete '.depend' file.
I wonder if something like the attached patch (which causes .depend
to be created atomically) affects things?
Tim
Index: share/mk/bsd.dep.mk
===
RCS file: /usr/cvs/FreeBSD-CVS/src/share/mk/bsd.dep.mk,v
retrieving revision 1.41
diff -u -r1.41 bsd.dep.mk
--- share/mk/bsd.dep.mk 3 Jul 2003 11:43:57 - 1.41
+++ share/mk/bsd.dep.mk 24 Jul 2003 19:08:11 -
@@ -112,25 +112,29 @@
# Different types of sources are compiled with slightly different flags.
# Split up the sources, and filter out headers and non-applicable flags.
+PID != /bin/sh -c 'echo '
+
${DEPENDFILE}: ${SRCS}
- rm -f ${DEPENDFILE}
+ rm -f ${DEPENDFILE} ${DEPENDFILE}.${PID}
.if ${SRCS:M*.[cS]} != ""
- ${MKDEPCMD} -f ${DEPENDFILE} -a ${MKDEP} \
+ ${MKDEPCMD} -f ${DEPENDFILE}.${PID} -a ${MKDEP} \
${CFLAGS:M-nostdinc*} ${CFLAGS:M-[BID]*} \
${.ALLSRC:M*.[cS]}
.endif
.if ${SRCS:M*.cc} != "" || ${SRCS:M*.C} != "" || ${SRCS:M*.cpp} != "" || \
${SRCS:M*.cxx} != ""
- ${MKDEPCMD} -f ${DEPENDFILE} -a ${MKDEP} \
+ ${MKDEPCMD} -f ${DEPENDFILE}.${PID} -a ${MKDEP} \
${CXXFLAGS:M-nostdinc*} ${CXXFLAGS:M-[BID]*} \
${.ALLSRC:M*.cc} ${.ALLSRC:M*.C} ${.ALLSRC:M*.cpp} ${.ALLSRC:M*.cxx}
.endif
.if ${SRCS:M*.m} != ""
- ${MKDEPCMD} -f ${DEPENDFILE} -a ${MKDEP} \
+ ${MKDEPCMD} -f ${DEPENDFILE}.${PID} -a ${MKDEP} \
${OBJCFLAGS:M-nostdinc*} ${OBJCFLAGS:M-[BID]*} \
${OBJCFLAGS:M-Wno-import*} \
${.ALLSRC:M*.m}
.endif
+ mv ${DEPENDFILE}.${PID} ${DEPENDFILE}
+ rm -f ${DEPENDFILE}.${PID}
.if target(_EXTRADEPEND)
_EXTRADEPEND: .USE
${DEPENDFILE}: _EXTRADEPEND
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Memory Mangament Problem in 5.1-RELEASE
Hi, I have 160Mb of SDRAM (PC100) on a 233Mhz CyrixInstead machine and I seem to have memory mangament problems. The BIOS indicates I have 160, so does the BSD bootstrap program. When I launch GNOME 2.2 everythings is good as gold untill I open the System monitor program. It says that I have 149 Mb of RAM which is fine ( 4Mb of video..and the rest...god knows). I open every program I have and after 107Mb the machine starts to swap with about 50Mb left unused!! I recompliled the GENERIC kernal for the sake of it really (Im still an amature) I didn't mess with the configuration files or anything (I just don't know how!!). Is this normal or mismanagement of memory in the 5.1 version of the excellent FreeBSD kernel?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Memory Mangement Problem in 5.1-RELEASE
Hi, I have 160Mb of SDRAM (PC100) on a 233Mhz CyrixInstead machine and I seem to have memory mangament problems. The BIOS indicates I have 160, so does the BSD bootstrap program. When I launch GNOME 2.2 everythings is good as gold untill I open the System monitor program. It says that I have 149 Mb of RAM which is fine ( 4Mb of video..and the rest...god knows). I open every program I have and after 107Mb the machine starts to swap with about 50Mb left unused!! I recompliled the GENERIC kernal for the sake of it really (Im still an amature) I didn't mess with the configuration files or anything (I just don't know how!!). Is this normal or mismanagement of memory in the 5.1 version of the excellent FreeBSD kernel?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
Ahmed Al-Hindawi wrote: Hi, I have 160Mb of SDRAM (PC100) on a 233Mhz CyrixInstead machine and I seem to have memory mangament problems. The BIOS indicates I have 160, so does the BSD bootstrap program. When I launch GNOME 2.2 everythings is good as gold untill I open the System monitor program. It says that I have 149 Mb of RAM which is fine ( 4Mb of video..and the rest...god knows). I open every program I have and after 107Mb the machine starts to swap with about 50Mb left unused!! I recompliled the GENERIC kernal for the sake of it really (Im still an amature) I didn't mess with the configuration files or anything (I just don't know how!!). Is this normal or mismanagement of memory in the 5.1 version of the excellent FreeBSD kernel?? The mistake is in the way the Gnome System Monitor display the free memory. I just watched both 'top' and the System Monitor as I opened program after program until the system started swapping, and System monitor reports almost 100M free while top reported less than 10M. To _always_ have a little memory free is A Good Thing(tm). FreeBSD has some pretty advanced memory management that will start swapping _before_ the system runs out of RAM. However, the System Monitor's display of this is simply inaccurate. There was NOT 100M free when it started swapping on my system. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: File system deadlock. GBDE(4) and/or MD(4) related.
In message <[EMAIL PROTECTED]>, Pawel Jakub Dawidek writ es: >+> One way or another: It is _not_ a GBDE problem. > >Hey, Poul! I'm not trying to show that gbde(4) is a buggy software, >I'm not trying to destroy you work, your image or FreeBSD, really. > >I believe that this isn't bug in gbde(4), my fault, sorry. No worries, I just want to make sure that the mail archives contain a definitive statement that this was not a GBDE problem. >But one thing I know, is that bug is somewhere and I just want to help >track it down. > >This information could be useful: > >When I've mounted file system on /private (not on /mnt/private) there >is no problem anymore. So maybe deadlock is caused by some directory >locking or something? Because if file system in mounted on /mnt/private >deadlock is 100% reproducable. Using vnode backed md(4) devices is sort of incestuous, and that may be what happens here: For certain operations it is necessary to lock all the way to the top of the filesystem, and this may be what results in a deadlock for you now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
On Thu, 24 Jul 2003 15:53:21 -0400, Bill Moran <[EMAIL PROTECTED]> wrote: Ahmed Al-Hindawi wrote: Hi, I have 160Mb of SDRAM (PC100) on a 233Mhz CyrixInstead machine and I seem to have memory mangament problems. The BIOS indicates I have 160, so does the BSD bootstrap program. When I launch GNOME 2.2 everythings is good as gold untill I open the System monitor program. It says that I have 149 Mb of RAM which is fine ( 4Mb of video..and the rest...god knows). I open every program I have and after 107Mb the machine starts to swap with about 50Mb left unused!! I recompliled the GENERIC kernal for the sake of it really (Im still an amature) I didn't mess with the configuration files or anything (I just don't know how!!). Is this normal or mismanagement of memory in the 5.1 version of the excellent FreeBSD kernel?? The mistake is in the way the Gnome System Monitor display the free memory. I just watched both 'top' and the System Monitor as I opened program after program until the system started swapping, and System monitor reports almost 100M free while top reported less than 10M. To _always_ have a little memory free is A Good Thing(tm). FreeBSD has some pretty advanced memory management that will start swapping _before_ the system runs out of RAM. However, the System Monitor's display of this is simply inaccurate. There was NOT 100M free when it started swapping on my system. Well, the 5.0, old -CURRENT and 4.8 have never touch the swap, until 5.1- CURRENT. My system has 256mb ram and it's always touch swap now. If I compile some stuff, sometime it will get around 300mb swap. Current, I only have Gnome 2.3.x and Opera running, so what my top looks like this: Mem: 85M Active, 29M Inact, 51M Wired, 4496K Cache, 35M Buf, 73M Free Swap: 512M Total, 79M Used, 433M Free, 15% Inuse But, I will remove the Gnome System Monitor applet, then reboot and see how it goes for the whole afternoon. Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld /rescue failures in 5.1
At 12:12 PM -0700 7/24/03, Tim Kientzle wrote:
Garance A Drosihn wrote:
So indeed, that 'make depend' had not finished before the
'make' for the object had started.
There's another possibility here: suppose two copies
of make are running simultaneously and both get to
this sequence at about the same time:
tar_make:
(cd $(tar_SRCDIR) && \
$(MAKE) $(BUILDOPTS) $(tar_OPTS) depend &&\
$(MAKE) $(BUILDOPTS) $(tar_OPTS) $(tar_OBJS))
The first make to run this will start building dependencies.
The second copy will see that ".depend" already exists (note
that bsd.dep.mk builds .depend incrementally) and then go on
to the next step.
I am still not exactly sure what is going on here, but it
looks like Gordon has committed a change which has solved
the problem which I kept running into. It's a little
tricky to figure out exactly what is going on, since the
problem so dependent upon the exact timing of the events.
However, I would note that in at least some of my testing,
the .depend file did *not* exist -- not at all -- in the
directory that it needed to be in.
Still, it does sound like a good idea to make the creation
of .depend to be an atomic operation. I might prefer to use
the 'mktemp' command, instead of adding a PID. Something
along the lines of:
DEPENDTMP=`mktemp ${DEPENDFILE}.X`
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
Jeremy Messenger wrote: On Thu, 24 Jul 2003 15:53:21 -0400, Bill Moran <[EMAIL PROTECTED]> wrote: Ahmed Al-Hindawi wrote: Hi, I have 160Mb of SDRAM (PC100) on a 233Mhz CyrixInstead machine and I seem to have memory mangament problems. The BIOS indicates I have 160, so does the BSD bootstrap program. When I launch GNOME 2.2 everythings is good as gold untill I open the System monitor program. It says that I have 149 Mb of RAM which is fine ( 4Mb of video..and the rest...god knows). I open every program I have and after 107Mb the machine starts to swap with about 50Mb left unused!! I recompliled the GENERIC kernal for the sake of it really (Im still an amature) I didn't mess with the configuration files or anything (I just don't know how!!). Is this normal or mismanagement of memory in the 5.1 version of the excellent FreeBSD kernel?? The mistake is in the way the Gnome System Monitor display the free memory. I just watched both 'top' and the System Monitor as I opened program after program until the system started swapping, and System monitor reports almost 100M free while top reported less than 10M. To _always_ have a little memory free is A Good Thing(tm). FreeBSD has some pretty advanced memory management that will start swapping _before_ the system runs out of RAM. However, the System Monitor's display of this is simply inaccurate. There was NOT 100M free when it started swapping on my system. Well, the 5.0, old -CURRENT and 4.8 have never touch the swap, until 5.1- CURRENT. My system has 256mb ram and it's always touch swap now. If I compile some stuff, sometime it will get around 300mb swap. Current, I only have Gnome 2.3.x and Opera running, so what my top looks like this: Well, the old YMMV applies, but I'm not seeing this kind of behaviour. I'm also not running 5.1-CURRENT, but 5.1-RELEASE, so it may be a newly introduced problem. The original poster didn't specify whether he was using -CURRENT or 5.1-RELEASE. Mem: 85M Active, 29M Inact, 51M Wired, 4496K Cache, 35M Buf, 73M Free Swap: 512M Total, 79M Used, 433M Free, 15% Inuse Did something use most of the memory up to start the system swapping? If it started using swap while there was still 73M free, then that's new to me. But, I will remove the Gnome System Monitor applet, then reboot and see how it goes for the whole afternoon. I'm not saying that Gnome System Monitor is causing the problem, I'm just saying that it reports inaccurate numbers. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Floppyless release build of sparc64
On Thu, Jul 24, 2003 at 11:55:10AM -0700, David O'Brien wrote: > On Wed, Jul 23, 2003 at 07:07:30PM +0300, Ruslan Ermilov wrote: > > On Wed, Jul 23, 2003 at 11:57:58AM -0400, Jake Burkholder wrote: > > > Apparently, On Wed, Jul 23, 2003 at 09:16:43AM +0300, > > > Ruslan Ermilov said words to the effect of; > > > > > > > A similar change would be in order for sparc64. Patch is > > > > attached, please review. The net effect is that we save > > > > huge CPU times in release.9 and do not create the useless > > > > boot.flp floppy image (the sparc64/mkisoimages.sh script > > > > doesn't need it). > > > > > > boot.flp is actually useful on sparc64 because you can dd it to a disk > > > from solaris and then boot off it to install. I'm happy with having > > > the option of not building it if it saves time but please make it an > > > option. > > > > OK, then things will be left as is. There's already an option for > > this; it's called NO_FLOPPIES (documented in the release(7) manpage). > > BUT the size of the "floppy" should be something like 10MB so that we > know we will *never* overflow it during "make release". > Should the need arise for that, it's a two-line change to release/Makefile, by just bumping MFSSIZE and BIGBOOTSIZE for sparc64. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Memory Mangement Problem in 5.1-RELEASE
On Thu, 24 Jul 2003 16:46:12 -0400, Bill Moran <[EMAIL PROTECTED]> wrote: Jeremy Messenger wrote: On Thu, 24 Jul 2003 15:53:21 -0400, Bill Moran <[EMAIL PROTECTED]> wrote: Ahmed Al-Hindawi wrote: Hi, I have 160Mb of SDRAM (PC100) on a 233Mhz CyrixInstead machine and I seem to have memory mangament problems. The BIOS indicates I have 160, so does the BSD bootstrap program. When I launch GNOME 2.2 everythings is good as gold untill I open the System monitor program. It says that I have 149 Mb of RAM which is fine ( 4Mb of video..and the rest...god knows). I open every program I have and after 107Mb the machine starts to swap with about 50Mb left unused!! I recompliled the GENERIC kernal for the sake of it really (Im still an amature) I didn't mess with the configuration files or anything (I just don't know how!!). Is this normal or mismanagement of memory in the 5.1 version of the excellent FreeBSD kernel?? The mistake is in the way the Gnome System Monitor display the free memory. I just watched both 'top' and the System Monitor as I opened program after program until the system started swapping, and System monitor reports almost 100M free while top reported less than 10M. To _always_ have a little memory free is A Good Thing(tm). FreeBSD has some pretty advanced memory management that will start swapping _before_ the system runs out of RAM. However, the System Monitor's display of this is simply inaccurate. There was NOT 100M free when it started swapping on my system. Well, the 5.0, old -CURRENT and 4.8 have never touch the swap, until 5.1-CURRENT. My system has 256mb ram and it's always touch swap now. If I compile some stuff, sometime it will get around 300mb swap. Current, I only have Gnome 2.3.x and Opera running, so what my top looks like this: Well, the old YMMV applies, but I'm not seeing this kind of behaviour. I'm also not running 5.1-CURRENT, but 5.1-RELEASE, so it may be a newly introduced problem. The original poster didn't specify whether he was using -CURRENT or 5.1-RELEASE. It's in the subject, he said that he has 5.1-RELEASE. Mine is... === # uname -a FreeBSD mezz.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Jul 18 18:43:42 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ i386 === I am planning to CVSup and do the another update of -CURRENT sometime this weekend. Mem: 85M Active, 29M Inact, 51M Wired, 4496K Cache, 35M Buf, 73M Free Swap: 512M Total, 79M Used, 433M Free, 15% Inuse Did something use most of the memory up to start the system swapping? If it started using swap while there was still 73M free, then that's new to me. Well, it still should not touch the swap since I have very few stuff running with 256mb ram. I just reboot and start with Gnome 2.3.x and Opera, then doing the update (compile/install) gnome-panel. Now, it's already use the swap in minutes and later hours I will get more mbs or swap. === last pid: 69694; load averages: 0.30, 0.73, 0.54up 0+00:26:23 15:56:49 49 processes: 2 running, 47 sleeping CPU states: 25.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 75.0% idle Mem: 123M Active, 21M Inact, 41M Wired, 5776K Cache, 35M Buf, 53M Free Swap: 512M Total, 3M Used, 512M Free === Cheers, Mezz But, I will remove the Gnome System Monitor applet, then reboot and see how it goes for the whole afternoon. I'm not saying that Gnome System Monitor is causing the problem, I'm just saying that it reports inaccurate numbers. -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible problem with ACL masks and getfacl (fwd)
On Thu, 24 Jul 2003, Glen Gibb wrote: > Whoops - it helps if I attach the patch :) Glen, This looks good to me -- I've committed the patch. If you pick up acl_to_text.c:1.11, it should have it. Let me know if there are any problems. 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]"
PATCH: Disable 6 byte commands for USB, firewire, ATAPICAM
Attached is a patch that disables ever sending 6 byte commands to buses
that do not support them. Numerous USB devices hang when receiving a 6
byte command. For testing, this patch comments out the scsi_da quirks for
devices that I believe are addressed by this patch and no longer need the
quirk.
Please test devices such as USB keys, USB cameras, Firewire hard disks,
and ATAPICAM cd drives to be sure they still work with this patch.
Especially if you've needed a quirk before, it is important to see if this
patch does not break your device. I hope to get this into the tree early
so there is plenty of testing before 5.2.
Thanks,
NateIndex: /sys/cam/cam_ccb.h
===
RCS file: /home/ncvs/src/sys/cam/cam_ccb.h,v
retrieving revision 1.25
diff -u -r1.25 cam_ccb.h
--- /sys/cam/cam_ccb.h 14 Jun 2003 22:17:38 - 1.25
+++ /sys/cam/cam_ccb.h 25 Jul 2003 01:01:45 -
@@ -513,7 +513,8 @@
PIM_SCANHILO= 0x80, /* Bus scans from high ID to low ID */
PIM_NOREMOVE= 0x40, /* Removeable devices not included in scan */
PIM_NOINITIATOR = 0x20, /* Initiator role not supported. */
- PIM_NOBUSRESET = 0x10 /* User has disabled initial BUS RESET */
+ PIM_NOBUSRESET = 0x10, /* User has disabled initial BUS RESET */
+ PIM_NO_6_BYTE = 0x08 /* Do not send 6-byte commands */
} pi_miscflag;
#ifdef CAM_NEW_TRAN_CODE
Index: /sys/cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.146
diff -u -r1.146 scsi_da.c
--- /sys/cam/scsi/scsi_da.c 18 Jul 2003 16:26:36 - 1.146
+++ /sys/cam/scsi/scsi_da.c 25 Jul 2003 01:54:34 -
@@ -145,6 +145,7 @@
static struct da_quirk_entry da_quirk_table[] =
{
+#ifndef DA_OLD_QUIRKS
/*
* Logitec USB/Firewire LHD-P30FU
*/
@@ -158,6 +159,7 @@
{T_DIRECT, SIP_MEDIA_FIXED, "LSILogic", "SYM13FW*", "*"},
/*quirks*/ DA_Q_NO_6_BYTE
},
+#endif /* !DA_OLD_QUIRKS */
{
/*
* Fujitsu M2513A MO drives.
@@ -257,6 +259,7 @@
{T_DIRECT, SIP_MEDIA_REMOVABLE, "MATSHITA", "FDD CF-VFDU*","*"},
/*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
},
+#ifndef DA_OLD_QUIRKS
{
/*
* Sony Memory Stick adapter MSAC-US1 and
@@ -517,6 +520,7 @@
{T_DIRECT, SIP_MEDIA_REMOVABLE, "OTi", "Flash Disk", "*"},
/*quirks*/ DA_Q_NO_6_BYTE
}
+#endif /* !DA_OLD_QUIRKS */
};
static disk_strategy_t dastrategy;
@@ -1087,6 +1091,7 @@
int s;
struct da_softc *softc;
struct ccb_setasync csa;
+ struct ccb_pathinq cpi;
struct ccb_getdev *cgd;
char tmpstr[80], tmpstr2[80];
caddr_t match;
@@ -1133,6 +1138,15 @@
softc->quirks = ((struct da_quirk_entry *)match)->quirks;
else
softc->quirks = DA_Q_NONE;
+
+ /* Check if the SIM does not want 6 byte commands */
+ xpt_setup_ccb(&cpi.ccb_h, periph->path, /*priority*/1);
+ cpi.ccb_h.func_code = XPT_PATH_INQ;
+ xpt_action((union ccb *)&cpi);
+ if (cpi.ccb_h.status == CAM_REQ_CMP && (cpi.hba_misc & PIM_NO_6_BYTE)) {
+ printf("daregister: setting no 6 byte\n");
+ softc->quirks |= DA_Q_NO_6_BYTE;
+ }
snprintf(tmpstr, sizeof(tmpstr), "CAM DA unit %d", periph->unit_number);
snprintf(tmpstr2, sizeof(tmpstr2), "%d", periph->unit_number);
Index: /sys/cam/scsi/scsi_cd.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_cd.c,v
retrieving revision 1.79
diff -u -r1.79 scsi_cd.c
--- /sys/cam/scsi/scsi_cd.c 10 Jun 2003 18:14:04 - 1.79
+++ /sys/cam/scsi/scsi_cd.c 25 Jul 2003 01:13:08 -
@@ -640,6 +640,7 @@
{
struct cd_softc *softc;
struct ccb_setasync csa;
+ struct ccb_pathinq cpi;
struct ccb_getdev *cgd;
char tmpstr[80], tmpstr2[80];
caddr_t match;
@@ -687,6 +688,15 @@
softc->quirks = ((struct cd_quirk_entry *)match)->quirks;
else
softc->quirks = CD_Q_NONE;
+
+ /* Check if the SIM does not want 6 byte commands */
+ xpt_setup_ccb(&cpi.ccb_h, periph->path, /*priority*/1);
+ cpi.ccb_h.func_code = XPT_PATH_INQ;
+ xpt_action((union ccb *)&cpi);
+ if (cpi.ccb_h.status == CAM_REQ_CMP && (cpi.hba_misc & PIM_NO_6_BYTE)) {
+ printf("cdregister: setting no 6 byte\n");
+ softc->quirks |= CD_Q_10_BYTE_ONLY;
+ }
snprintf(tmpstr, sizeof(tmpstr), "CAM CD unit %d", periph->unit_number);
snprintf(tmpstr2, sizeof(tmpstr2), "%d", periph->unit_number);
Index: /sys/dev/ata/atapi-cam.c
===
RCS file: /home/
Re: panic while reading ntfs partition
On Thu, Jul 24, 2003 at 02:14:20PM +0200, Karel J. Bosschaart wrote:
> Not sure if this is useful, but I'm getting a perfectly reproducible
> panic when doing 'grep -R foo .' (as normal user) in a read-only
> mounted ntfs partition on a -current as of ~3 weeks ago:
>
[...]
> Panicstring: bundirty: buffer 0xc72d9868 still on queue 2
[...]
Thanks for the report - I thought I'd already fixed this problem. Would you
mind trying the attached patch? It seems to fix the problem for me, but
grep uses an awful lot of memory in the process (perhaps it's trying to
read a "line" from the pagefile containing mostly zeroes.)
See these two for more info on the bug:
http://perforce.freebsd.org/chv.cgi?CH=34967
http://perforce.freebsd.org/chv.cgi?CH=33434
diff -ru sys/fs/ntfs.old/ntfs_subr.c sys/fs/ntfs/ntfs_subr.c
--- sys/fs/ntfs.old/ntfs_subr.c Fri Jul 25 12:26:18 2003
+++ sys/fs/ntfs/ntfs_subr.c Fri Jul 25 12:18:09 2003
@@ -1442,9 +1442,16 @@
off = ntfs_btocnoff(off);
while (left && ccl) {
- tocopy = min(left,
- min(ntfs_cntob(ccl) - off, MAXBSIZE - off));
+ /*
+* Always read and write single clusters at a time -
+* we need to avoid requesting differently-sized
+* blocks at the same disk offsets to avoid
+* confusing the buffer cache.
+*/
+ tocopy = min(left, ntfs_cntob(1) - off);
cl = ntfs_btocl(tocopy + off);
+ KASSERT(cl == 1 && tocopy <= ntfs_cntob(1),
+ ("single cluster limit mistake"));
ddprintf(("ntfs_writentvattr_plain: write: " \
"cn: 0x%x cl: %d, off: %d len: %d, left: %d\n",
(u_int32_t) cn, (u_int32_t) cl,
@@ -1540,23 +1547,19 @@
off = ntfs_btocnoff(off);
while (left && ccl) {
- tocopy = min(left,
- min(ntfs_cntob(ccl) - off,
- MAXBSIZE - off));
- cl = ntfs_btocl(tocopy + off);
-
/*
-* If 'off' pushes us to next
-* block, don't attempt to read whole
-* 'tocopy' at once. This is to avoid
-* bread() with varying 'size' for
-* same 'blkno', which is not good.
+* Always read single clusters at a
+* time - we need to avoid reading
+* differently-sized blocks at the
+* same disk offsets to avoid
+* confusing the buffer cache.
*/
- if (cl > ntfs_btocl(tocopy)) {
- tocopy -=
- ntfs_btocnoff(tocopy + off);
- cl--;
- }
+ tocopy = min(left,
+ ntfs_cntob(1) - off);
+ cl = ntfs_btocl(tocopy + off);
+ KASSERT(cl == 1 &&
+ tocopy <= ntfs_cntob(1),
+ ("single cluster limit mistake"));
ddprintf(("ntfs_readntvattr_plain: " \
"read: cn: 0x%x cl: %d, " \
diff -ru sys/fs/ntfs.old/ntfs_vfsops.c sys/fs/ntfs/ntfs_vfsops.c
--- sys/fs/ntfs.old/ntfs_vfsops.c Fri Jul 25 12:26:18 2003
+++ sys/fs/ntfs/ntfs_vfsops.c Fri Jul 25 12:18:09 2003
@@ -311,6 +311,14 @@
goto out;
ntmp = malloc( sizeof *ntmp, M_NTFSMNT, M_WAITOK | M_ZERO);
bcopy( bp->b_data, &ntmp->ntm_bootfile, sizeof(struct bootfile) );
+ /*
+* We must not cache the boot block if its size is not exactly
+* one cluster in order to avoid confusing the buffer cache when
+* the boot file is read later by ntfs_readntvattr_plain(), which
+* reads a cluster at a time.
+*/
+ if (ntfs_cntob(1) != BBSIZE)
+ bp->b_flags |= B_NOCACHE;
brelse( bp );
bp = NULL;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe
Re: We have ath, now what about Broadcom?
On Wed, 23 Jul 2003, Kevin Oberman wrote: > > From: "Matthew Emmerton" <[EMAIL PROTECTED]> > > Date: Wed, 23 Jul 2003 18:21:23 -0400 > > > > > The folks at Broadcom have not been willing to release any information > > > on their 800.11g chips for fear of violating FCC regs. The required > > > NDA would prohibit the release of the source. You can program > > > both the transmit power and frequency if you have this. (I make no > > > claim as to whether their concerns have any validity.) > > > > > > For that reason there has been no open-source support for these chips. > > > > Why would Broadcom be scared? Obviously it's the _driver_ that controls the > > power/freq output of the chip, so the responsibility of staying within FCC > > regs is that of the driver authors. Of course, the "no warranty" aspects of > > open source drivers turns a blind eye to liability, but would things really > > come back to Broadcom? > > The logic is simple. the FCC hold the manufacturer responsible for > improper RF from any product. The Broadcom chip makes it easy to > generate illegal RF if you know where to poke. Can't they just redact that information from the spec.? -- Chris BeHanna Software Engineer (Remove "bogus" before responding.) [EMAIL PROTECTED] I was raised by a pack of wild corn dogs. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: We have ath, now what about Broadcom?
In message: <[EMAIL PROTECTED]> Chris BeHanna <[EMAIL PROTECTED]> writes: : Can't they just redact that information from the spec.? Typically no. Even in a redacted spec it would be painfully obvious what to do. Also, different regulatory domains have different frequencies that are real no-nos in other regulatory domains and they'd need to document how to properly generate the RF in both cases. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: We have ath, now what about Broadcom?
On Thu, Jul 24, 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Chris BeHanna <[EMAIL PROTECTED]> writes: > : Can't they just redact that information from the spec.? > > Typically no. Even in a redacted spec it would be painfully obvious > what to do. Also, different regulatory domains have different > frequencies that are real no-nos in other regulatory domains and > they'd need to document how to properly generate the RF in both > cases. So, assuming that there's at least one person smart enough to reverse engineer the binary driver but stupid enough to release it publicly, what happens to the manufacturer there? Can they now take "they took relevant steps" as a defence in a law court? Adrian -- Adrian Chadd learning is bad <[EMAIL PROTECTED]>it just makes the people around you dumber (angryskul == [EMAIL PROTECTED]) :( ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
Stephane Raimbault wrote:
> I recently realized that I was miss-understanding how much free memory I had
> on the system, and I doubt I even need the full 4Gig's.
>
> Perhaps I can re-confirm how to check how much free real memory is available
> on the system.
For 4G of physical RAM, with 3G of KVA and 1G of UVA, you have
enough memory to hold the kernel and the page mappings for all
of KVA + the pages dedicated to the kernel, plust the defaults
for buffers (if you *do not* autotune) for ~2G of mbufs and
tuning for approximately 280,000 socket connections and open
files, *IF* you disable IPSEC, AND you intend to run one or
two processes in user space and use mode of the 1G of address
space there.
If you autotune, the numbers of connections you can run drops
sharply.
Also note that the default UVA/KVA plist is *not* 1G/3G, it's
2G/2G, and it used to be 3G/1G. For 4G server systems, the
very first thing I always recommend, if you want the highest
load capacity possible, is to reduce the UVA and increse the
KVA so you have enough space in the KVA to map and store the
resources you'll need for a high load. The most common thing
to run out of, in everything but database servers, is KVA
space ("panic: kmem_map too small").
For databases with large data sets, you have to artificially
restrict the amount of total KVA that everything added together
can consume to keep it under the 2G ceiling. This usually
means a tradeoff between number of connections and database
size.
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fuword(), suword(), etc.
On Thu, Jul 24, 2003, Terry Lambert wrote: > Marcel Moolenaar wrote: > > > for i386 it would be an alternate name for fuword32() and suword32() > > > I'm not sure what it would be on other architectures > > > > fuword64 and suword64. PowerPC is like i386. > > PPC 970 explicitly supports mixed mode programming between user > and kernel, as do most other 64 bit processors, in order to support > legacy applications. > > It's actually unlikely that IBM will ever release enough documentation > to get a full 64 bit Linux running on a PPC 970, let alone FreeBSD, > and that you will be stuck with a 32 bit kernel that runs 64 bit apps, > and which talks to IBM's internal undocumented glue on the bottom end > while running in a virtual environment, such that the interfaces to > that glue are not exposed in the source code they publish. Will any releases of MacOS X have the "full 64 bit" code? Will Darwin ever be released with the "full 64 bit" code? Adrian -- Adrian Chadd learning is bad <[EMAIL PROTECTED]>it just makes the people around you dumber (angryskul == [EMAIL PROTECTED]) :( ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
Stephane Raimbault wrote: > Well I went to go change my /boot/loader.conf options to reflect the > following: > > kern.vm.kmem.size="35" Assuming this is in pages, it is 1/3 of the total physical RAM in the system. This is way too large, unless you have recompiled your kernel to have 3G KVA vs. 1G UVA, instead of the default. Kernel recompilation is required because the load address is a fixed virtual address based on the KVA size, subtracted from the top of memory. This is so that user programs do not have to be recompiled when you move the ratio of UVA to KVA around (with the exception of the Linux emulator, if you are using Linux threads, since it seems to want its threads mailboxes at a known location in memory). > kern.ipc.nmbclusters="8192" This is large, as well. You need to turn off automatic tuning, and act like you are on a memory budget equal to the amount of KVA space in the system, which you can use for different things, but not at the same time. If you leave the system at the defaults, it will (mostly) be able to keep itself under the budget ceiling for an assumed 2G KVA space, but as soon as you start tuning some things up, you will very quickly blow your budget, since you tuning something you want to use up will not necessarily tune something you aren't going to use down, to avoid blowing your total budget. > and enabled "options DDB" in my kernel. > > Unfortunately, I ran into a problem on the reboot, the SMP kernel would fail > to load due to some of my /boot/loader.conf changes perhaps I > miss-understood something in your instructions... anyhow, this is what was > displayed on the console when I set those above settings in the > /boot/loader.conf... and since I had the debugger running, I did a trace and > included in the paste below... is that the kind of stuff you will want if > the box crashes again as originally mentioned in this thread. This particular panic is an initialization of a region with a header structure, where the memory allocation has failed because you have already blown your budget, and so the allocation returns NULL. This happens early enough in the system startup that there is no error checking to ensure that the allocation has succeeded. But even if you added error checking in all these places, the best the system is going to be able to do is pnaic with a slightly more informative message. When it goes to fill in this structure, it tries to fill in a field containing something 8 bytes into the structure, and explodes. If you look at the function where the traceback says it crashed, this should be visibly obvious to you. A good rule of thumb for tuning is to start with the autotuned defaults (though they can screw you on occasion, since RAM is installed in discrete amounts, and the autotuning tends to use a continuous function of the amount of physical RAM, so you get a "stair function", and not all possible steps in the stair have actually been tested with all possible resource allocations having been made, to see if a problem occurs). Once you know those, you hard-code them so that they are no longer autotuned. Then you tweak the resource allocations for resources you don't care about using down. Then you tweak what you do care about using up, until you crash. Then you back off on your last tweak to give you some safety margin. This will get you within 85%-90% of where you can get without modifying code. The only other alternative is to know where every byte of memory is going. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fuword(), suword(), etc.
Shawn wrote: > On Thu, 2003-07-24 at 03:40, Terry Lambert wrote: > > It's actually unlikely that IBM will ever release enough documentation > > to get a full 64 bit Linux running on a PPC 970, let alone FreeBSD, > > and that you will be stuck with a 32 bit kernel that runs 64 bit apps, > > and which talks to IBM's internal undocumented glue on the bottom end > > while running in a virtual environment, such that the interfaces to > > that glue are not exposed in the source code they publish. > > That's very interesting to me as IBM has been rather forthcoming about > making sure everyone knows that the 32bit bridge was only temporary and > to not rely on it being there in the future. I would hope that would > indicate that they may be willing to release more informaation in the > future regarding this. Of course, what do I know? :p IBM doesn't want people running 32 bit code on their 64 bit hardware forever, and making it look bad, so they have stated publically that they intend to withdraw support for the 32 bit bridge in the future, I'll agree. As to whether this will really happen, or is just a scare tactic to prevent people from writing new code that depends on the bridge (which is supposed to be there only to provide support for old code), I don't know; I haven't worked for IBM for nearly 3 years now. Maybe Greg Lehey can comment. I do know that even if they remove the bridge, they are unlikely to provide enough documentation to boot and run natively on the hardware without having IBM code setting up the bus arbitration and other bits that are currently undocumented. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
