Re: syscons options and memory use
In the last episode (Mar 31), Ronald Klop said: On Thu, 31 Mar 2005 01:04:10 -0600, Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Mar 31), Ronald Klop said: The syscons manual page says: The following options will remove some features from the syscons driver and save kernel memory. [...] SC_NO_SYSMOUSE This option removes mouse support in the syscons driver. The mouse daemon moused(8) will fail if this option is defined. This option implies the SC_NO_CUTPASTE option too. How much memory does this save (or how can I discover that)? Is it worth it on a 96MB PentiumII laptop? I would guess that the memory savings is probably on the order of kilobytes. Useful if you're trying to prevent excessive swapping on an 8MB system. Not worth disabling on your system. How can I see the size of my kernel? I know vmstat -m and netstat -m, but from that info I don't see if I reduced the memory footprint after disabling an option or device. For the kernel size itself, just ls -l /boot/kernel/kernel :) A more interesting number might be the output of sysctl hw.usermem, which I believe is the amount of memory available to user processes. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Wednesday 30 March 2005 09:49 pm, Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 22:27:43 -0700, Scott Long wrote: Jon Noack wrote: On 03/30/05 23:14, Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 21:28:36 -0700, Scott Long wrote: Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 23:01:03 -0500, John Baldwin wrote: It would be interesting to see the contents of your MADT to see if it's trying to use a 64-bit PA for your APIC. Any suggestions about how to do so? man acpidump How do you run that on a system that won't boot? You said the system worked with 4 GB (albeit detecting only 3.5 GB). Yes, this is correct. A number of people have explained why it only detected 3.5 GB in this configuration. You're also being confused by the implementation of the 'real memory' report. If you take a 30 second glance at the code, you'll see that it is reporting the same units that the hw.maxmem tunable uses. ie: it is the LIMIT or Highest Address that the system has, not the sum total of all the parts. eg: see the machdep.c comment next to the printf * Maxmem isn't the maximum memory, it's one larger than the * highest page of the physical address space. It should be * called something like Maxphyspage. We may adjust this * based on ``hw.physmem'' and the results of the memory test. The SMAP lines are what you need to pay attention to. In the output you posted with 8G, you can see the 4GB going from the 4-8GB range, exactly. SMAP type 1 is usable memory. -Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syscons options and memory use
On Thu, 2005-Mar-31 09:53:59 +0200, Ronald Klop wrote: In the last episode (Mar 31), Ronald Klop said: The syscons manual page says: The following options will remove some features from the syscons driver and save kernel memory. [...] SC_NO_SYSMOUSE This option removes mouse support in the syscons driver. The mouse daemon moused(8) will fail if this option is defined. This option implies the SC_NO_CUTPASTE option too. How much memory does this save (or how can I discover that)? Is it worth it on a 96MB PentiumII laptop? It basically removes scmouse.c, sysmouse.c and a largish chunk of code in scvgarndr.c - my estimate is about 9KB. You can probably do better looking elsewhere. For loadable devices, looking at the module size is a good guideline. How can I see the size of my kernel? server% size /boot/kernel/kernel textdata bss dec hex filename 3045945 229911 978784 4254640 40ebb0 /boot/kernel/kernel server% Remember that this doesn't include dynamic memory allocated by the kernel which can be quite significant. Look at the real memory and avail memory lines in your boot dmesg to get a better idea of the basic kernel memory requirements. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
USB JetFlash
Hello! FreeBSD 5.4-PRERELEASE #0: Mon Mar 21 12:07:18 MSK 2005 JetFlash TS512MJF2B 2.00 (512Mb) works well: umass0: USB Flash Disk, rev 2.00/2.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: JetFlash TS512MJF2B 2.00 Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 500MB (1024000 512 byte sectors: 64H 32S/T 500C) umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached but JetFlash TS1GJF2B 2.00 produses many errors: da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, (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) (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 and so on until (da0:umass-sim0:0:0:0): Retries Exhausted 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): 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) (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: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached How can I fix this? Thanks in advance. -- Mikhail Godovitcin http://www.kc.ru/~mg/pgpkey.txt pgpnoFNY0QGVz.pgp Description: PGP signature
Re: USB JetFlash
Mikhail Godovitcin wrote: Hello! FreeBSD 5.4-PRERELEASE #0: Mon Mar 21 12:07:18 MSK 2005 JetFlash TS512MJF2B 2.00 (512Mb) works well: umass0: USB Flash Disk, rev 2.00/2.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: JetFlash TS512MJF2B 2.00 Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 500MB (1024000 512 byte sectors: 64H 32S/T 500C) umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached Me too :-( ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB JetFlash
Mikhail Godovitcin wrote: I believe I should be able to help you. I've got smaller JetFlash which works. Yours might need a quirk entry in umass.c. Can you send us the output of 'usbdevs -v'? Hello! FreeBSD 5.4-PRERELEASE #0: Mon Mar 21 12:07:18 MSK 2005 JetFlash TS512MJF2B 2.00 (512Mb) works well: umass0: USB Flash Disk, rev 2.00/2.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: JetFlash TS512MJF2B 2.00 Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 500MB (1024000 512 byte sectors: 64H 32S/T 500C) umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached but JetFlash TS1GJF2B 2.00 produses many errors: da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, (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) (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 and so on until (da0:umass-sim0:0:0:0): Retries Exhausted 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): 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) (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: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached How can I fix this? Thanks in advance. -- Mikhail Godovitcin http://www.kc.ru/~mg/pgpkey.txt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: USB JetFlash
Hello! Thursday, March 31, 2005, 16:48, you wrote: I believe I should be able to help you. I've got smaller JetFlash which works. Yours might need a quirk entry in umass.c. Can you send us the output of 'usbdevs -v'? Yes, sure. Here it is. # usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 addr 2: full speed, power 100 mA, config 1, Flash Disk(0x2168), USB(0x0ea0), rev 2.00 port 2 powered # camcontrol inquiry da0 pass0: JetFlash TS1GJF2B 2.00 Removable Direct Access SCSI-2 device pass0: Serial Number pass0: 1.000MB/s transfers Thanks in advance. -- Mikhail Godovitcin http://www.kc.ru/~mg/pgpkey.txt pgpuBrTlGGvxF.pgp Description: PGP signature
Re: Problems with AMD64 and 8 GB RAM?
On Mar 31, 2005, at 1:00 AM, Jon Noack wrote: My limited research (as in, Google) shows that the MADT was defined as part of ACPI 2.0: http://www.microsoft.com/whdc/system/platform/64bit/IA64_ACPI.mspx According to your previous link the motherboard specs, it supports both ACPI 1.0A and 2.0. Perhaps there is a BIOS knob to toggle between the two? It's part if ACPI 1.0 as well. Trust me, I have machines built before ACPI 2.0 was defined that have MADTs. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Mar 30, 2005, at 11:08 PM, Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 23:01:03 -0500, John Baldwin wrote: On Mar 30, 2005, at 8:54 PM, Greg 'groggy' Lehey wrote: lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI - LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high -ioapic0 Version 0.3 irqs 0-23 on motherboard +ioapic0 Version 0.0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00040010 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff This shows that in the - case the APIC is broken somehow (0.0 isn't a valid I/O APIC version). You mean the + case, I suppose. Yes, that's what I suspected. It would seem that the system has mapped RAM over top of the I/O APIC perhaps? That's what I suspected too, but imp doesn't think so. Actually, if the full version register were zero, it would not have had 24 IRQs (irqs 0-23 part), so I'm not sure what it is doing. 0.3 isn't really a valid APIC version AFAIK either, though I'm more familiar with the versions used in Intel APICs (usually 1.1, 1.2, or 2.0). It would be interesting to see the contents of your MADT to see if it's trying to use a 64-bit PA for your APIC. Any suggestions about how to do so? Boot with 4g or boot an i386 version and get acpidump -t output. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Mar 31, 2005, at 12:49 AM, Greg 'groggy' Lehey wrote:
This may be the case, but between man page and output some terminology
must have changed. I can't see any reference to anything like an MADT
there. Does that mean that there isn't one, or that ACPI can't find
it, or does the section APIC refer to/dump the MADT? Here's the
complete output of acpidump -t, anyway:
MADT is the name of the table (Multiple APIC Descriptor Table or some
such), but APIC is the 4 character signature of the MADT, hence
seeing 'APIC' output from acpidump -t when looking at the MADT.
Similarly, the MP Table is known as the MP Table, but the signature for
the table that you search for in the BIOS is _MP_.
/*
APIC: Length=104, Revision=1, Checksum=145,
OEMID=VIAK8, OEM Table ID=AWRDACPI, OEM Revision=0x42302e31,
Creator ID=AWRD, Creator Revision=0x0
Local APIC ADDR=0xfee0
Flags={PC-AT}
Type=Local APIC
ACPI CPU=0
Flags={ENABLED}
APIC ID=0
Type=Local APIC
ACPI CPU=1
Flags={ENABLED}
APIC ID=1
Type=IO APIC
APIC ID=2
INT BASE=0
ADDR=0xfec0
Type=INT Override
BUS=0
IRQ=0
INTR=2
Flags={Polarity=conforming, Trigger=conforming}
Type=INT Override
BUS=0
IRQ=9
INTR=9
Flags={Polarity=active-lo, Trigger=level}
Type=Local NMI
ACPI CPU=0
LINT Pin=1
Flags={Polarity=active-hi, Trigger=edge}
Type=Local NMI
ACPI CPU=1
LINT Pin=1
Flags={Polarity=active-hi, Trigger=edge}
*/
Nothing strange here, and it is giving a 64-bit PA for the I/O APIC,
albeit one that is 4GB. One thing to verify is that the physical
addresses listed here for the APICs (0xfec0 and 0xfee0) aren't
included in the SMAP as valid RAM addresses in both cases. It might be
useful to boot an i386 CD with 8GB in the machine to see if the MADT
looks any different in that case.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Mar 31, 2005, at 12:27 AM, Scott Long wrote: Jon Noack wrote: On 03/30/05 23:14, Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 21:28:36 -0700, Scott Long wrote: Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 23:01:03 -0500, John Baldwin wrote: On Mar 30, 2005, at 8:54 PM, Greg 'groggy' Lehey wrote: lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI - LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high -ioapic0 Version 0.3 irqs 0-23 on motherboard +ioapic0 Version 0.0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00040010 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff This shows that in the - case the APIC is broken somehow (0.0 isn't a valid I/O APIC version). You mean the + case, I suppose. Yes, that's what I suspected. It would seem that the system has mapped RAM over top of the I/O APIC perhaps? That's what I suspected too, but imp doesn't think so. I'd be more inclined to believe that there is an erroneous mapping by the OS, not that things are fundamentally broken in hardware. Agreed. This has been my favourite hypothesis all along. But isn't that what jhb is saying? Your SMAP table shows everything correctly. It's becoming hard to break through your pre-concieved notions here and explain how things actually work. No, there's nothing to break through. I think you're just having problems 1. expressing yourself, and 2. understanding what I'm saying. I have no preconceived notions. All I can see here is an antagonistic attitude on your part. What's the problem? You'll recall from my first message that I asked for suggestions about how to approach the issue. jhb provided some; you haven't so far. From what you've written, it's unclear whether you disagree with jhb or not. If you do, why? If you don't, what's your point here? It would be interesting to see the contents of your MADT to see if it's trying to use a 64-bit PA for your APIC. Any suggestions about how to do so? man acpidump How do you run that on a system that won't boot? You said the system worked with 4 GB (albeit detecting only 3.5 GB). My perception of this whole ACPI thing is that it is fixed in your BIOS (although it can be overridden by the OS). As such, the amount of RAM you have in the machine shouldn't change acpidump results. Is that not correct? Jon This is absolutely correct. It might though. Notice the change in APIC version with 4GB of RAM vs 8GB. The APIC hardware is the same, so that's already indicative of something fishy going on. I think that his APIC address is correct though as otherwise no interrupts at all would work and it wouldn't claim to have 24 IRQs on the APIC in both cases. One can always boot an i386 non-PAE kernel with 8GB in the machine and get an acpidump though. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: file /usr/src/etc/rc.d/network is not installed
Martin Jakob [EMAIL PROTECTED] writes: I searched a way to activate new interface/network settings after changes to /etc/rc.conf (defaultrouter, interface aliases, etc.). I found the /etc/netstart script, which does what i want. In the script i found a comment, which says, that this script is obsoleted by /etc/rc.network, but i (well, actually locate) can't find this file anywhere. The comment is incorrect. Just ignore it and run /etc/netstart. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy ATA controller: I can install 4.11, but not 5.3 !?!
--- Doug White [EMAIL PROTECTED] wrote: AFAIK the RZ1000 bug was that it would corrupt data to the slave channel if the primary channel was also active. If you only have one device then you may not be able to reproduce it. I have two harddisks on ata0: ad0: 520MB ST3660A [1057/16/63] at ata0-master BIOSPIO ad1: 2423MB SAMSUNG WINNER-3 WN32543A(2.5GB) [4924/16/63] at ata0-slave BIOSPIO ad0 has the base OS, and ad1 has /usr/src and /usr/obj for recompiling world and kernel. So far no problems. However, if I remember well, the other IDE connector on the motherboard does not seem to work, which now I realize could be caused by the buggy RZ 1000 chip. Do you have verbose boot output from the non-working 5.x boot? No, not at the moment. I may try 5.3 (or probably 5.4) later once again. What part of the output would be particularly interesting? I ask, because I am managing this PC at the other end of the world, giving instructions to a non-Unix, non-FreeBSD user overthere :). Regards, Rob. __ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ, pf and VLANs
On Thursday 31 March 2005 04:38, Marko uk wrote: Max, that solution works fine. I have tried it and it works fine for me. Thanks. Anyway, do you know some issues with dropping traffic on em0 vlan enabled interfaces and tcpdump-ing ? The average traffic, that we tcpdump is cca 10-20mbit/s and when tcpdump-ing, we get allmost 90% packet loss on interfaces. Any clue ? Ugh, I know of such an issue, but was thinking that it should be fixed by now. Can you make sure that you have your kernel/em(4) built with if_em.c 1.44.2.6 or later? The effect should simply be that it disables VLAN hardware support which doesn't seem to work with promiscuous mode. You could also try to disable it manually (ifconfig) to see if that improves on the packet loss. Marko Max Laier wrote: On Tuesday 29 March 2005 20:28, Marko uk wrote: Will that be fixed in 5.4 ? Right now, today it won't work without a patch. pfctl: vlan0: driver does not support altq Please see: http://lists.freebsd.org/mailman/htdig/freebsd-net/2005-February/006456.ht ml If you still can't live without ALTQ rate-limitting on VLAN submit a PR and throw it my way. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpBlNri7O7tK.pgp Description: PGP signature
Re: FreeBSD 5.3 SMP freezes with MySQL 4.1
Thank you very much. My server's uptime last two days by refer to Klein's configuration, it's impactful, thanks to Klein. My concern of stablility is focus on mysql's build options as BUILD_STATIC BUILD_OPTIMIZED, but it looks like ridiculous without any logicality, build_static should have not any different between dynamatic lib. I will do some testing after the current configuration to be proven by uptime over one week, and try to find out how to repeat the panic. -- Young Lee On Wed, 30 Mar 2005 23:18:56 +1000 Michael Vince [EMAIL PROTECTED] wrote: I am running 1 mildly busy new MySQL server thats running fine on5.3-RELEASE-p5 #5: Sat Jan 22 04:54:07 EST 2005 from the generic confkernel Its a Dell 1850 Dual P4 Xeon CPU 3.00GHz EMT64 with HTT enabled FYI I actually have a Dell 2650 thats not doing anything at the momentbecause it had sluggish performance when I started to put some seriousburden on it. I recently updated to the latest MySQL to 4.1.10a from 4.1.5 with usingthis set of settings (I hate using ports manually) portupgrade -Rfri -m 'BUILD_OPTIMIZED=yes BUILD_STATIC=yes'/var/db/pkg/mysql-server-4.1* I copied the default large.cnf file to /var/db/mysql/my.cnf for betterperformance but thats about it, I am still evaluating MySQL performance. To give you a remote idea how busy this MySQL server is, here aresome bits running mysqladmin extended-status | Bytes_received | 49227436 | | Bytes_sent | 71933703 | | Threads_connected| 25 | | Threads_created | 42 | | Uptime | 101775 | According to MySQL manual Threads_created gives an idea of the load onthe MySQL server. phpMyAdmin lists MySQL status in a much nicer way This MySQL server has been running for 1 days, 4 hours, 38 minutes and28 seconds. Query statistics: Since its startup, 335,544 queries have beensent to the server. Total oslash; per hour oslash; per minute oslash; per second 335,544 11,715.47 195.26 3.25 select 204,621 7,144.3161.04 % insert 29,149 1,017.738.70 % show keys 85,395 2,981.5525.48 % This server is doing more things then I originally planned it to do,its also running a Postgres 7.4 server that has over 500megs of dataand almost constant 100% usage of disk IO according to top via m, Ihave statistics enabled on postgres but no way to show some simplesummaries. I run Apache2 in prefork mode and currently has around 350 averageapache daemons ps -auxww | grep -c httpd 356 Its doing over 1 million dynamic page loads a day (some page loadsdon't use database) This server also is running 12 separate Java processes each at around200megs of size. Since cvsuping to the latest 5_3 for release security patches andcritical updates the server is been perfectly stable, before that I didhave kernel panic reboot problems that I believe were caused be massivethread usage from the java processes. Although I have rebooted just a little while ago the servers uptime iscurrently 33days. With your server how have you been updating your server to 5.3-P5release? Its possible you have a similar problem. I am emailing this in HTML format in the hope the tables come out morenicely. Regards, Mike Young Lee wrote: I have try your solution yesterday, so far it is stable, and willobserve the stability for some days. btw, i turn debug.mpsafenet=0 in /boot/loader.conf to evade the possible network stack deadlock under SMP. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DANGER WILL ROBINSON! SERIOUS problem with current 5.4-PRERELEASE
On Wed, 2005-03-30 at 23:30 -0600, Karl Denninger wrote: BTW its NOT your hardware at fault here - the same hardware that returns these complaints for me on 5.x works perfectly with 4.11. There have been changes made to the ATA code that apparently interact VERY badly with some controllers - particularly some very common SATA (SII chipset, used on Adaptec and Bustek boards, among others) ones. It's not just a SATA problem. I get the problem (though more infrequently than it seems you do) on an Intel PIIX4 UDMA33 controller. The problem occurs on two different systems (one Gateway, one Dell), and only started happening some way through the 5.x life cycle, indicating to me that a serious regression was introduced (in 5.2, I believe). The problem does not afflict 4.x. I don't know if GEOM/GMIRROR is truly involved here although that's the easiest way for me to provoke it - I suspect not - its just that GEOM/GMIRROR produces an I/O load pattern that is conducive to the breakage showing up. Specifically, a DD from one or more disks does NOT fail - a mix of reads and writes and fairly significant load appears necessary to cause trouble. Of course installation produces a very nice load of that type On both systems that experience the problem, I am using some kind of software mirroring. On one I'm using geom_mirror, and on the other I'm using geom_vinum. Both suffer from the WRITE_DMA disconnect problem. The Dell, using geom_mirror, is now running HEAD. The Gateway running RELENG_5 is annoying because when a drive becomes disconnected, the only way right now to rebuild the plexes on the geom_vinum drive that is down is to reboot the system. (I've used setstate to flag the drive as up, but then gvinum start of any down plex causes an immediate panic/reboot.) Ian Dowse posted a patch to the freebsd-current mailing list for the WRITE_DMA issue (http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-February/046773.html). According to Dowse, the patch attempts to clean up the handling of timeouts in the ATA code by using the new callout_init_mtx() function. It was successful for me. I still got the WRITE_DMA timeouts, but not the disconnects. I don't know if RELENG_5 has the new callout_init_mtx() function. If it does, this patch might help there, too. I opened a PR on this quite some time ago - IMHO this sort of breakage should be considered a critical fault sufficient to stop a release until its completely resolved. A workaround that stops the system from blowing up but leaves the pauses and errors isn't really a fix - I doubt anyone will consider that acceptable as a means of truly addressing the problem (at least I hope not!) I agree that it wouldn't be ideal, but having something that fixed just the disconnects in the tree would be better than nothing at all. It's a pain to have to track third-party patches. I got surprised by this (in a bad way) and have been fighting workarounds since 5.3 was deemed production quality. Going back to 4.x is possible for me, but highly undesireable for a number of reasons, not the least of which is the official FreeBSD posture on where work is and will be done on the OS down the road. It's disappointing the way this problem appears to have been silently ignored (except by those whom it afflicts), because it is a regression that occurred during the 5.x lifecycle. It's one thing to know that your hardware won't work properly going from 4.x to 5.x, but another thing to have it stop working going from one 5.x release to another. (Or maybe it isn't, given the strange Early Adopter status of the start of the 5.x release cycle.) Anyway, I'm glad you are trying to keep this problem in the spotlight, because an unreliable ATA subsystem is a miserable thing to have to suffer. :-( Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release fails
On Tue, Mar 29, 2005 at 04:41:55PM +0400, Michael Lednev wrote:
hello
i'm trying to build my own release cd for 4-STABLE branch. doing make
release BUILDNAME=4-STABLE-20050328-0300 CHROOTDIR=/usr/release
CVSROOT=/home/ncvs RELEASETAG=RELENG_4 -DSEPARATE_LIVEFS in
/usr/src/release results in error like this
cd /usr/src/release/../etc make distrib-dirs DESTDIR=/R/stage/trees/bin
set - `grep ^[a-zA-Z] /usr/src/etc/locale.deprecated`; while [ $# -gt 0
] ; do for dir in /usr/share/locale /usr/share/nls
/usr/local/share/nls; do test -d /R/stage/trees/bin/${dir} cd
/R/stage/trees/bin/${dir}; test -L $2 rm -rf $2; test \! -L $1
test -d $1 mv $1 $2; done; shift; shift; done
mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p /R/stage/trees/bin/
mtree: /R/stage/trees/bin/: No such file or directory
*** Error code 1
Stop in /usr/src/etc.
*** Error code 1
Stop in /usr/src/release.
+ umount /dev
*** Error code 1
Stop in /usr/src/release.
what to change in my make command or in system to build release? host
system is 5.3-STABLE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
This is not an officially supported way of building releases.
That's why there is some magic to finish this procedure.
Even if it will complete successfully it won't neccessary mean it will work
correctly. You'd better try building 4.x release on RELENG_4 box.
However if you don't have an opportunity to do so maybe I'll be able
to provide you with some help. I did built RELENG_5 release on RELENG_4
box successfully some time ago. Contact me offline if you are still interested.
-ip
--
You can lead a horse to water, but if you can get him to
float on his back, you've really got something.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DANGER WILL ROBINSON! SERIOUS problem with current5.4-PRERELEASE - UPDATE (real this time)
On Wed, 30 Mar 2005, Karl Denninger wrote:
Removing the FIRST delta, which is:
218a219,221
if (!dumping)
callout_reset(request-callout, request-timeout * hz,
(timeout_t*)ata_timeout, request);
appears to get rid of the crashes while not harming data integrity OR the
reqeueing.
I'd be interested to know if the attached patch does anything.
--
10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00Index: ata-queue.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-queue.c,v
retrieving revision 1.32.2.6
diff -u -u -r1.32.2.6 ata-queue.c
--- ata-queue.c 23 Mar 2005 04:50:26 - 1.32.2.6
+++ ata-queue.c 31 Mar 2005 17:00:46 -
@@ -217,8 +217,7 @@
}
else {
if (!dumping)
- callout_reset(request-callout, request-timeout * hz,
- (timeout_t*)ata_timeout, request);
+callout_drain(request-callout);
if (request-bio !(request-flags ATA_R_TIMEOUT)) {
ATA_DEBUG_RQ(request, finish bio_taskqueue);
bio_taskqueue(request-bio, (bio_task_t *)ata_completed, request);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DANGER WILL ROBINSON! SERIOUS problem with current 5.4-PRERELEASE - UPDATE (real this time)
On Thu, Mar 31, 2005 at 12:02:20PM -0500, Matthew N. Dodd wrote:
On Wed, 30 Mar 2005, Karl Denninger wrote:
Removing the FIRST delta, which is:
218a219,221
if (!dumping)
callout_reset(request-callout, request-timeout * hz,
(timeout_t*)ata_timeout, request);
appears to get rid of the crashes while not harming data integrity OR the
reqeueing.
I'd be interested to know if the attached patch does anything.
--
10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00
Index: ata-queue.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-queue.c,v
retrieving revision 1.32.2.6
diff -u -u -r1.32.2.6 ata-queue.c
--- ata-queue.c 23 Mar 2005 04:50:26 - 1.32.2.6
+++ ata-queue.c 31 Mar 2005 17:00:46 -
@@ -217,8 +217,7 @@
}
else {
if (!dumping)
- callout_reset(request-callout, request-timeout * hz,
- (timeout_t*)ata_timeout, request);
+callout_drain(request-callout);
if (request-bio !(request-flags ATA_R_TIMEOUT)) {
ATA_DEBUG_RQ(request, finish bio_taskqueue);
bio_taskqueue(request-bio, (bio_task_t *)ata_completed, request);
It'll be a few hours before I will know on the production machine - the RAID
array has to rebuild before I can trigger the problem, and we're scheduled
for some power work here in an hour or so - which I suspect will get in the
way.
What do you expect the patch to do, given that removing the delta appears to
fix the instability problem?
--
--
Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist
http://www.denninger.netMy home on the net - links to everything I do!
http://scubaforum.org Your UNCENSORED place to talk about DIVING!
http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME!
http://genesis3.blogspot.comMusings Of A Sentient Mind
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DANGER WILL ROBINSON! SERIOUS problem with current5.4-PRERELEASE - UPDATE (real this time)
On Thu, 31 Mar 2005, Karl Denninger wrote: What do you expect the patch to do, given that removing the delta appears to fix the instability problem? I expect the patch to properly stop the callout. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ, pf and VLANs
I am still running 5.3-RELEASE-p5 and there is /*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.2 2004/10/15 22:12:59 tackerman Exp $*/ , obviously unpatched and bad driver. I'll try to cvsup to 5.4-PRE, but I'm a little worried with stability, as this is my main firewall for whole network. 2nd thing... try to disable it manually ? What :) ? I don't quite understand you on that . ifconfig em1 disable ? :) I have traffic on it :) ( I'll be running carp as soon and pfsync as I'll learn how to and if it will work fine :) , to have redaudant firewall ) Cuk Max Laier wrote: On Thursday 31 March 2005 04:38, Marko uk wrote: Max, that solution works fine. I have tried it and it works fine for me. Thanks. Anyway, do you know some issues with dropping traffic on em0 vlan enabled interfaces and tcpdump-ing ? The average traffic, that we tcpdump is cca 10-20mbit/s and when tcpdump-ing, we get allmost 90% packet loss on interfaces. Any clue ? Ugh, I know of such an issue, but was thinking that it should be fixed by now. Can you make sure that you have your kernel/em(4) built with if_em.c 1.44.2.6 or later? The effect should simply be that it disables VLAN hardware support which doesn't seem to work with promiscuous mode. You could also try to disable it manually (ifconfig) to see if that improves on the packet loss. Marko Max Laier wrote: On Tuesday 29 March 2005 20:28, Marko uk wrote: Will that be fixed in 5.4 ? Right now, today it won't work without a patch. pfctl: vlan0: driver does not support altq Please see: http://lists.freebsd.org/mailman/htdig/freebsd-net/2005-February/006456.ht ml If you still can't live without ALTQ rate-limitting on VLAN submit a PR and throw it my way. -- Private: http://cuk.nu Sports: http://www.cuk.nu Slovenian FreeBSD mirror admin http://www2.si.freebsd.org Work @ http://www.xenya.si ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ipnat on RELENG_5/amd64
Dear colleagues, are there any issues with amd64 and ipnat? Trying to set up new multi-vlan router in our ISP network I've found very strange issues: machine hangs cold, no console (only comconsole is available) messages or reaction, more than one time, right after activating the first VLAN with active ipnat. Unfortunately I had no time for deep experiments yet; I'll try to set up DDB together with test network tomorrow, but for now I would want to hear your opinions. /etc/make.conf is fairly standard: CPUTYPE=athlon64 KERNCONF?= gwhx GENERIC NOINET6=yes NO_MODULES= yes MODULES_WITH_WORLD=yes COMPAT_4X= yes (and MASTER_SITES settings) Hardware issues should not be the source of the problem, as platform had been stress-tested by massive buildworlds, memtest86, etc. Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DANGER WILL ROBINSON! SERIOUS problem with current5.4-PRERELEASE - UPDATE (real this time)
On Thu, Mar 31, 2005 at 12:19:13PM -0500, Matthew N. Dodd wrote: On Thu, 31 Mar 2005, Karl Denninger wrote: What do you expect the patch to do, given that removing the delta appears to fix the instability problem? I expect the patch to properly stop the callout. Ok, so the implication is that the callouts are/were being triggered and dumped on the floor without it? Would you prefer me to validate that path before or after I attempt to validate that removing the first delta fixes the crashes on my production machine? (Reason for the question is that the latter will require most of the rest of the day and evening, while the former can likely be done by 3-4 pm today) -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy ATA controller: I can install 4.11, but not 5.3 !?!
On Thu, 31 Mar 2005, Rob wrote: --- Doug White [EMAIL PROTECTED] wrote: AFAIK the RZ1000 bug was that it would corrupt data to the slave channel if the primary channel was also active. If you only have one device then you may not be able to reproduce it. I have two harddisks on ata0: ad0: 520MB ST3660A [1057/16/63] at ata0-master BIOSPIO ad1: 2423MB SAMSUNG WINNER-3 WN32543A(2.5GB) [4924/16/63] at ata0-slave BIOSPIO ad0 has the base OS, and ad1 has /usr/src and /usr/obj for recompiling world and kernel. So far no problems. However, if I remember well, the other IDE connector on the motherboard does not seem to work, which now I realize could be caused by the buggy RZ 1000 chip. Entirely possible. Do you have verbose boot output from the non-working 5.x boot? No, not at the moment. I may try 5.3 (or probably 5.4) later once again. What part of the output would be particularly interesting? I ask, because I am managing this PC at the other end of the world, giving instructions to a non-Unix, non-FreeBSD user overthere :). Ugh. That will make this really hard to debug then. To get the verbose output you want to use a serial console. That output will say why it won't attach the ata controller. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ, pf and VLANs
On Thursday 31 March 2005 19:29, Marko uk wrote: I am still running 5.3-RELEASE-p5 and there is /*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.2 2004/10/15 22:12:59 tackerman Exp $*/ , obviously unpatched and bad driver. I'll try to cvsup to 5.4-PRE, but I'm a little worried with stability, as this is my main firewall for whole network. 2nd thing... try to disable it manually ? What :) ? I don't quite understand you on that . Whoops, sorry - work blindness. I meant to say: Try to disable the hardware supported VLAN tagging manually $ifconfig em0 -vlanhwtag ifconfig em1 disable ? :) I have traffic on it :) ( I'll be running carp as soon and pfsync as I'll learn how to and if it will work fine :) , to have redaudant firewall ) Cuk Max Laier wrote: On Thursday 31 March 2005 04:38, Marko uk wrote: Max, that solution works fine. I have tried it and it works fine for me. Thanks. Anyway, do you know some issues with dropping traffic on em0 vlan enabled interfaces and tcpdump-ing ? The average traffic, that we tcpdump is cca 10-20mbit/s and when tcpdump-ing, we get allmost 90% packet loss on interfaces. Any clue ? Ugh, I know of such an issue, but was thinking that it should be fixed by now. Can you make sure that you have your kernel/em(4) built with if_em.c 1.44.2.6 or later? The effect should simply be that it disables VLAN hardware support which doesn't seem to work with promiscuous mode. You could also try to disable it manually (ifconfig) to see if that improves on the packet loss. Marko Max Laier wrote: On Tuesday 29 March 2005 20:28, Marko uk wrote: Will that be fixed in 5.4 ? Right now, today it won't work without a patch. pfctl: vlan0: driver does not support altq Please see: http://lists.freebsd.org/mailman/htdig/freebsd-net/2005-February/006456. ht ml If you still can't live without ALTQ rate-limitting on VLAN submit a PR and throw it my way. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpwv7NGncfpG.pgp Description: PGP signature
Re: Problems with AMD64 and 8 GB RAM?
On Wed, Mar 30, 2005 at 03:25:37PM -0800, Peter Wemm wrote: Greg: The busdma problems from 5.3-RELEASE are fixed. That doesn't mean that there are no *other* problems. Scott is saying the old busdma bug shouldn't be affecting 5.4-PRE, and he's correct. Most likely, something else is happening, eg: you're running out of KVM or something silly like that. I know we're right on the brink at 8GB. The layout of the devices may be just enough to tip it over the edge. Grog's motherboard is a 4+0 configuration -- which would mean he is using (trying to) 2GB DIMM's. There are memory bus loading specifictions he may be out of spec of. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Thu, Mar 31, 2005 at 08:14:45AM +0930, Greg 'groggy' Lehey wrote: I had 4 bad out of 12 tested where the DIMMs were Crucial PC2700 2GB Reg. ECC DIMMs. OK, this makes sense. It might also explain why the 4 GB configuration only recognizes 3.5 GB. No. This is due to the 3.5-4.0GB PA address range that the PeeCee architecture reserves for the PCI config space, AGP GART, memory mapped I/O, etc... Many Opteron BIOS's don't bother to hoist the covered memory above 4GB. Please see the freebsd-amd64 archives -- this has been discussed many times. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Thu, Mar 31, 2005 at 10:32:33AM +0930, Daniel O'Connor wrote: On Thu, 31 Mar 2005 08:14, Greg 'groggy' Lehey wrote: Have you run sysutils/memtest86 with the 8 GB? Heh. Difficult when the system doesn't run. You could try http://www.memtest86.com although that doesn't do 4Gb :( Are you sure version 3.2 does not? -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Thu, Mar 31, 2005 at 11:24:29AM +0930, Greg 'groggy' Lehey wrote: On Thursday, 31 March 2005 at 10:32:33 +0930, Daniel O'Connor wrote: On Thu, 31 Mar 2005 08:14, Greg 'groggy' Lehey wrote: Have you run sysutils/memtest86 with the 8 GB? Heh. Difficult when the system doesn't run. You could try http://www.memtest86.com although that doesn't do 4Gb :( I'm pretty sure it's not the memory. I've tried each pair individually, and it's only when they're both in there together that it's a problem. And yes, I've tried them in each pair of slots. You have a dual-channel memory controller. If you insert one DIMM you perform 64-bit data accesses. If you install DIMM's in pairs (making sure you're using the right paired sockets), you perform 128-bit data accesses. Thus your access pattern is different between these two situations. I'm highly suspious that you can us 4x2GB DIMM's with out knowing the exact part number. Don't forget 2GB DIMM's are double-stacked and thus look like double the electrical bus loads. The same is true for older 1GB DIMM's. Install all the memory you would like to use into your motherboard, download memtest86+ version 1.40 from http://www.memtest.org, dd to floppy or burn the ISO, and report back your findings from running it. Also what version of the BIOS are you using? -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adaptec 3210S, 4.9-STABLE, corruption when disk fails
From: [EMAIL PROTECTED] From: Uwe Doering [mailto:[EMAIL PROTECTED] ... Did you merge 1.3.2.3 as well? This actually should have been one MFC Yes, merged from RELENG_4. I will post later if this happens again, but it will be quite a long time. The machine has 7 drives in it, there are only 3 ones left old enough they might fail before I take it out of service (it originally had 7 1999-era IBM drives, now it has 4 2004-era seagate drives and 3 of the old IBM's. The drives have been in continuous service, so they've lead a pretty good life!) Thanks for the suggestion on the cam timeout, I've set that value. Another drive failed and the same thing happened. After the failure, the raid worked in degrade mode just fine, but many files had been corrupted during the failure. So I would suggest that this merge did not help, and the cam timeout did not help either. This is very frustrating, again I rebuild my postgresql install from backup :( --don ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DANGER WILL ROBINSON! SERIOUS problem withcurrent5.4-PRERELEASE - UPDATE (real this time)
On Thu, 31 Mar 2005, Karl Denninger wrote: Would you prefer me to validate that path before or after I attempt to validate that removing the first delta fixes the crashes on my production machine? (Reason for the question is that the latter will require most of the rest of the day and evening, while the former can likely be done by 3-4 pm today) Your previous email suggests that the callout stuff is to blame. Testing the fix seems like a good plan unless you have any doubts about your earlier results. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DANGER WILL ROBINSON! SERIOUS problem withcurrent5.4-PRERELEASE - UPDATE (real this time)
On Thu, Mar 31, 2005 at 02:16:11PM -0500, Matthew N. Dodd wrote: On Thu, 31 Mar 2005, Karl Denninger wrote: Would you prefer me to validate that path before or after I attempt to validate that removing the first delta fixes the crashes on my production machine? (Reason for the question is that the latter will require most of the rest of the day and evening, while the former can likely be done by 3-4 pm today) Your previous email suggests that the callout stuff is to blame. Testing the fix seems like a good plan unless you have any doubts about your earlier results. I cannot provide solid validation until I test it on the production machine here. The sandbox survived overnight with dozens of write errors, but whether the production system will is not yet known. Will test on the production system and advise. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: USB JetFlash
Mikhail Godovitcin wrote:
Hello!
Thursday, March 31, 2005, 16:48, you wrote:
I believe I should be able to help you. I've got smaller JetFlash which
works. Yours might need a quirk entry in umass.c.
Can you send us the output of 'usbdevs -v'?
Yes, sure. Here it is.
# usbdevs -v
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x), rev 1.00
port 1 addr 2: full speed, power 100 mA, config 1, Flash Disk(0x2168),
USB(0x0ea0), rev 2.00
port 2 powered
# camcontrol inquiry da0
pass0: JetFlash TS1GJF2B 2.00 Removable Direct Access SCSI-2 device
pass0: Serial Number
pass0: 1.000MB/s transfers
Thank you.
I'm afraid I can't easily help you because your device is different than
mine.
You can try attached patch anyways. Apply with 'cd /sys/dev/usb;patch
jmtek.diff;cd /sys/modules/umass;make -DUSB_DEBUG=1;make unload;make
load'.
I won't be surprised if it didn't fix your disk though. You might try to
change UMASS_ADD_DELAY in
{ USB_VENDOR_OTI, USB_PRODUCT_OTI_JETFLASH2, RID_WILDCARD,
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
UMASS_ADD_DELAY
},
to 'IGNORE_RESIDUE | NO_GETMAXLUN | RS_NO_CLEAR_UA'. Maybe
FORCE_SHORT_INQUIRY instead/in addition to these.
After modifying umass.c you need to rebuild and unloadload the kld. If
you have umass (or whole usb) in your kernel ('device umass') you should
comment it out, reinstall kernel and reboot. Then you'll be able to try
different quirk values.
HTH
Michal
Index: umass.c
===
RCS file: /home/fcvs/cvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.121
diff -u -r1.121 umass.c
--- umass.c 25 Mar 2005 01:47:01 - 1.121
+++ umass.c 31 Mar 2005 19:53:51 -
@@ -314,6 +314,8 @@
# define NO_INQUIRY 0x0400
/* Device cannot handle INQUIRY EVPD, return CHECK CONDITION */
# define NO_INQUIRY_EVPD 0x0800
+ /* Device needs time to settle down - should be fixed elsewhere*/
+# define UMASS_ADD_DELAY 0x1000
};
Static struct umass_devdescr_t umass_devdescrs[] = {
@@ -387,6 +389,10 @@
UMASS_PROTO_ATAPI | UMASS_PROTO_BBB,
NO_QUIRKS
},
+ { USB_VENDOR_MSYSTEMS, USB_PRODUCT_MSYSTEMS_DELLMEMKEY, RID_WILDCARD,
+ UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+ UMASS_ADD_DELAY
+ },
{ USB_VENDOR_NEODIO, USB_PRODUCT_NEODIO_ND3260, RID_WILDCARD,
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
FORCE_SHORT_INQUIRY
@@ -399,6 +405,10 @@
UMASS_PROTO_ATAPI | UMASS_PROTO_BBB,
NO_INQUIRY | NO_GETMAXLUN
},
+ { USB_VENDOR_OTI, USB_PRODUCT_OTI_JETFLASH2, RID_WILDCARD,
+ UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+ UMASS_ADD_DELAY
+ },
{ USB_VENDOR_PANASONIC, USB_PRODUCT_PANASONIC_KXLCB20AN, RID_WILDCARD,
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
NO_QUIRKS
@@ -891,6 +901,7 @@
(void) umass_match_proto(sc, sc-iface, uaa-device);
id = usbd_get_interface_descriptor(sc-iface);
+
#ifdef USB_DEBUG
printf(%s: , USBDEVNAME(sc-sc_dev));
switch (sc-protoUMASS_PROTO_COMMAND) {
@@ -2263,6 +2274,7 @@
Static int
umass_cam_attach(struct umass_softc *sc)
{
+ int delay_len;
#ifndef USB_DEBUG
if (bootverbose)
#endif
@@ -2279,7 +2291,11 @@
* completed, when interrupts have been enabled.
*/
- usb_callout(sc-cam_scsi_rescan_ch, MS_TO_TICKS(200),
+ if (sc-quirks UMASS_ADD_DELAY)
+ delay_len = 2000;
+ else
+ delay_len = 200;
+ usb_callout(sc-cam_scsi_rescan_ch, MS_TO_TICKS(delay_len),
umass_cam_rescan, sc);
}
Index: usbdevs
===
RCS file: /home/fcvs/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.226
diff -u -r1.226 usbdevs
--- usbdevs 21 Mar 2005 08:43:54 - 1.226
+++ usbdevs 31 Mar 2005 19:54:21 -
@@ -529,6 +529,7 @@
vendor SITECOM 0x6189 Sitecom
vendor INTEL 0x8086 Intel
vendor HP2 0xf003 Hewlett Packard
+vendor JMTEK 0x0c76 JMTek, LLC.
/*
* List of known products. Grouped by vendor.
@@ -1188,6 +1189,7 @@
/* M-Systems products */
product MSYSTEMS DISKONKEY 0x0010 DiskOnKey
product MSYSTEMS DISKONKEY2 0x0011 DiskOnKey
+product MSYSTEMS DELLMEMKEY 0x0015 Dell Memory Key
/* National Semiconductor */
product NATIONAL BEARPAW1200 0x1000 BearPaw 1200
@@ -1560,3 +1562,9 @@
/* ZyXEL Communication Co. products */
product ZYXEL OMNI56K 0x1500 Omni 56K Plus
product ZYXEL 980N 0x2011 Scorpion-980N keyboard
+
+/* JMTek, LLC. products */
+product JMTEK JETFLASH 0x0005 Transcend JetFlash
+
+/* Ours Technology, Inc. products */
+product OTI JETFLASH2 0x2168 Transcend JetFlash 2.0
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
Date: Thu, 31 Mar 2005 16:12:35 +0900 From: Ganbold [EMAIL PROTECTED] Subject: Re: Problems with AMD64 and 8 GB RAM? Hi, Since we are discussing AMD64 with 8GB RAM, I also would like to point my problem. I'm still looking for possibility to run FreeBSD 5.3-STABLE with more than 4GB RAM on Dual amd64 2.2GHz machine (IBM @server 325) with ServeRAID 6M (ips driver)). Right now I'm using only 4GB RAM and this server is in production. #uname -an FreeBSD publica.ub.mng.net 5.3-STABLE FreeBSD 5.3-STABLE #12: Mon Nov 22 12:04:57 ULAT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AMD amd64 As Scott said a few months ago, problem is below: The ips driver looks like it will fail under heavy load when more than 4GB of RAM is present. It tries to force busdma to not defer requests when the bounce page reserve is low, but that looks to be broken and will result in corrupted commands. [Alan Jay] Since we are talking about FreeBSD on AMD64 on the AMD64 list I have reported issues on that list. I have a TyanThunder K8S pro S2882 twin Operteron with 8Gb of RAM and although I can get the machine to run reasonably stably with 8Gb of RAM with limited loading when pushed it falls over unpredictably. We did some tests with the latest 5.3-STABLE / 5.4-PRERELEASE and still found the same issues when using a mySQL database heavily hit over the Ethernet controller. Our final tests limited the memory on boot-up to 4Gb and the bug is still there so we think it may well be some interaction with the Ethernet controller. The motherboard we have has a BroadcomBCM5704C 10/100/1000 based card on board. Again this works fine initially but then we get a very dramatic failure with no warning messages and the system falls over. There are still a few issues to be ironed out with the FreeBSD 5.x on AMD64 the latest STABLE/PRE-RELEASE is much improved but be aware there may be issues. We will be waiting a few more weeks before re-trying these tests to see if the latest fixes that have been discussed have solved our problems. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adaptec 3210S, 4.9-STABLE, corruption when disk fails
Don Bowman wrote: From: [EMAIL PROTECTED] From: Uwe Doering [mailto:[EMAIL PROTECTED] ... Did you merge 1.3.2.3 as well? This actually should have been one MFC Yes, merged from RELENG_4. I will post later if this happens again, but it will be quite a long time. The machine has 7 drives in it, there are only 3 ones left old enough they might fail before I take it out of service (it originally had 7 1999-era IBM drives, now it has 4 2004-era seagate drives and 3 of the old IBM's. The drives have been in continuous service, so they've lead a pretty good life!) Thanks for the suggestion on the cam timeout, I've set that value. Another drive failed and the same thing happened. After the failure, the raid worked in degrade mode just fine, but many files had been corrupted during the failure. So I would suggest that this merge did not help, and the cam timeout did not help either. This is very frustrating, again I rebuild my postgresql install from backup :( This is indeed unfortunate. Maybe the problem is in fact located neither in PostgreSQL nor in FreeBSD but in the controller itself. Does it have the latest firmware? The necessary files should be available on Adaptec's website, and you can use the 'raidutil' program under FreeBSD to upload the firmware to the controller. I have to concede, however, that I never did this under FreeBSD myself. If I recall correctly I did the upload via a DOS diskette the last time. If this doesn't help either you could ask Adaptec's support for help. You need to register the controller first, if memory serves. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers [EMAIL PROTECTED] | http://www.escapebox.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Mar 31, 2005, at 3:08 PM, Alan Jay wrote: We did some tests with the latest 5.3-STABLE / 5.4-PRERELEASE and still found the same issues when using a mySQL database heavily hit over the Ethernet controller. Our final tests limited the memory on boot-up to 4Gb and the bug is still there so we think it may well be some interaction with the Ethernet controller. The motherboard we have has a BroadcomBCM5704C 10/100/1000 based card on board. I have seen similar with Postgres 8.0 database. Occasionally I'll see a bge0 timout + reset error logged, but many times I'll just see a socket closed unexpectedly type of message from postgres. So far, every 5 days or so, the machine freezes during heavy DB reporting over the net. I have a S2881 mobo, though, with 4GB. I had another identical machine which was reporting in the BIOS that the memory size changed during normal operations, which was very scary... Vivek Khera, Ph.D. +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release fails
On Thu, 31 Mar 2005 09:02:16 +0400, Igor Pokrovsky [EMAIL PROTECTED] wrote: This is not an officially supported way of building releases. That's why there is some magic to finish this procedure. Even if it will complete successfully it won't neccessary mean it will work correctly. You'd better try building 4.x release on RELENG_4 box. However if you don't have an opportunity to do so maybe I'll be able to provide you with some help. I did built RELENG_5 release on RELENG_4 box successfully some time ago. Contact me offline if you are still interested. unfortunately i don't have any RELENG_4 boxes, wanted to make one with this attempt, is there any chance to do so without fetching images from ftp? -- Best Regards, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adaptec 3210S, 4.9-STABLE, corruption when disk fails
From: Uwe Doering [mailto:[EMAIL PROTECTED] Don Bowman wrote: From: [EMAIL PROTECTED] From: Uwe Doering [mailto:[EMAIL PROTECTED] ... Did you merge 1.3.2.3 as well? This actually should have been one MFC Yes, merged from RELENG_4. I will post later if this happens again, but it will be quite a long time. The machine has 7 drives in it, there are only 3 ones left old enough they might fail before I take it out of service (it originally had 7 1999-era IBM drives, now it has 4 2004-era seagate drives and 3 of the old IBM's. The drives have been in continuous service, so they've lead a pretty good life!) Thanks for the suggestion on the cam timeout, I've set that value. Another drive failed and the same thing happened. After the failure, the raid worked in degrade mode just fine, but many files had been corrupted during the failure. So I would suggest that this merge did not help, and the cam timeout did not help either. This is very frustrating, again I rebuild my postgresql install from backup :( This is indeed unfortunate. Maybe the problem is in fact located neither in PostgreSQL nor in FreeBSD but in the controller itself. Does it have the latest firmware? The necessary files should be available on Adaptec's website, and you can use the 'raidutil' program under FreeBSD to upload the firmware to the controller. I have to concede, however, that I never did this under FreeBSD myself. If I recall correctly I did the upload via a DOS diskette the last time. If this doesn't help either you could ask Adaptec's support for help. You need to register the controller first, if memory serves. The latest firmware bios is in the controller (upgraded the last time I had problems). Tried adaptec support, controller is registered. The problem is definitely not in postgresql. Files go missing in directories that are having new entries added (e.g. I lost a 'PG_VERSION' file). Data within the postgresql files becomes corrupt. Since the only application running is postgresql, and it reads/writes/fsyncs the data, its not unexpected that it's the one that reaps the 'rewards' of the failure. I have to believe this is either a bug in the controller, or a problem in cam or asr. --don ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adaptec 3210S, 4.9-STABLE, corruption when disk fails
Don Bowman wrote: From: Uwe Doering [mailto:[EMAIL PROTECTED] Don Bowman wrote: [...] Another drive failed and the same thing happened. After the failure, the raid worked in degrade mode just fine, but many files had been corrupted during the failure. So I would suggest that this merge did not help, and the cam timeout did not help either. This is very frustrating, again I rebuild my postgresql install from backup :( This is indeed unfortunate. Maybe the problem is in fact located neither in PostgreSQL nor in FreeBSD but in the controller itself. Does it have the latest firmware? The necessary files should be available on Adaptec's website, and you can use the 'raidutil' program under FreeBSD to upload the firmware to the controller. I have to concede, however, that I never did this under FreeBSD myself. If I recall correctly I did the upload via a DOS diskette the last time. If this doesn't help either you could ask Adaptec's support for help. You need to register the controller first, if memory serves. The latest firmware bios is in the controller (upgraded the last time I had problems). Tried adaptec support, controller is registered. The problem is definitely not in postgresql. Files go missing in directories that are having new entries added (e.g. I lost a 'PG_VERSION' file). Data within the postgresql files becomes corrupt. Since the only application running is postgresql, and it reads/writes/fsyncs the data, its not unexpected that it's the one that reaps the 'rewards' of the failure. I have to believe this is either a bug in the controller, or a problem in cam or asr. As far as I understand this family of controllers the OS drivers aren't involved at all in case of a disk drive failure. It's strictly the controller's business to deal with it internally. The OS just sits there and waits until the controller is done with the retries and either drops into degraded mode or recovers from the disk error. That's why I initially speculated that there might be a timeout somewhere in PostgreSQL or FreeBSD that leads to data loss if the controller is busy for too long. A somewhat radical way to at least make these failures as rare an event as possible would be to deliberately fail all remaining old disk drives, one after the other of course, in order to get rid of them. And if you are lucky the problem won't happen with newer drives anyway, in case the root cause is an incompatibility between the controller and the old drives. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers [EMAIL PROTECTED] | http://www.escapebox.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy ATA controller: I can install 4.11, but not 5.3 !?!
--- Doug White [EMAIL PROTECTED] wrote: On Thu, 31 Mar 2005, Rob wrote: No, not at the moment. I may try 5.3 (or probably 5.4) later once again. What part of the output would be particularly interesting? I ask, because I am managing this PC at the other end of the world, giving instructions to a non-Unix, non-FreeBSD user overthere :). Ugh. That will make this really hard to debug then. To get the verbose output you want to use a serial console. That output will say why it won't attach the ata controller. OK, I will certainly try that then, giving the proper insturctions, since this Pentium1 FreeBSD PC will soon have a Windows PC next to it. However, I need a little advice/help: the handbook is still out-of-date for making serial console install floppies. Chapter 2.12 of the handbook talks about kern.flp and mfsroot.flp, whereas we have three floppies with 5.X install. Which one(s) of the three floppies of 5.X needs to be modified by the procedure of chapter 2.12 ? Windows HyperTerminal is then the way to go, isn't it? Thanks, Rob. __ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MNT_NOEXEC on root filesystem with diskless PXE boot?
Tom Alsberg wrote:
Perhaps this should go to -STABLE, I just couldn't be sure.
It will get more attention on freebsd-stable@, so I'm CCing that list.
We are trying out FreeBSD 5.4-PRERELEASE on diskless clients. I
noticed one problem, being that when setting the LD_LIBRARY_PATH
(or for that matter, LD_PRELOAD, and LD_LIBMAP_DISABLE) environment
variables, nothing will run, as /libexec/ld-elf.so.1 complains:
Cannot execute objects on /
According to the sources, this was added in 5.4, and will happen
if / is mounted noexec.
Yes, that's quite correct -- although I can't imagine how a bug which
caused / to be labelled as noexec managed to avoid causing major
problems until now.
I don't know anything about NFS, but hopefully someone on -stable
will be able to work out what's going on from the rest of your
email (quoted below).
Colin Percival
In this case, / is mounted by the BTX PXE loader over NFS (from a
FreeBSD 5.3 server, right now). mount does not show the noexec
flag. However, with the attached little C program I verified that
statfs really returns this flag (0x0006).
Now, I see that on FreeBSD 5.3 diskless clients this flag is also
returned on / - just it happened that nobody looked at it until
the change in rtld.c of FreeBSD 5.4:
if (fs.f_flags MNT_NOEXEC) {
_rtld_error(Cannot execute objects on %s\n, fs.f_mntonname);
close(fd);
return NULL;
}
I didn't yet understand (didn't check much) - why does statfs report
the MNT_NOEXEC flag on the / filesystem (and only the / filesystem,
when it's mounted from NFS by the bootloader - not any other
NFS filesystems)? BTW, this happens also with NetApp as the NFS
server - just to rule out any possibility of relation here.
Ideas appreciated,
-- Tom
#include stdio.h
#include fcntl.h
#include sys/param.h
#include sys/mount.h
int main(int argc, char *argv[])
{
if (argc != 2) {
fprintf(stderr, invalid number of arguments);
return -1;
}
struct statfs stbuf;
if (statfs(argv[1], stbuf) != 0) {
perror(fstatfs);
return -1;
}
printf(FLAGS: 0x%08X\n, stbuf.f_flags);
if (stbuf.f_flags MNT_NOEXEC)
printf(MNT_NOEXEC\n);
return 0;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buggy ATA controller: I can install 4.11, but not 5.3 !?!
On Thu, 31 Mar 2005, Rob wrote: --- Doug White [EMAIL PROTECTED] wrote: On Thu, 31 Mar 2005, Rob wrote: No, not at the moment. I may try 5.3 (or probably 5.4) later once again. What part of the output would be particularly interesting? I ask, because I am managing this PC at the other end of the world, giving instructions to a non-Unix, non-FreeBSD user overthere :). Ugh. That will make this really hard to debug then. To get the verbose output you want to use a serial console. That output will say why it won't attach the ata controller. OK, I will certainly try that then, giving the proper insturctions, since this Pentium1 FreeBSD PC will soon have a Windows PC next to it. However, I need a little advice/help: the handbook is still out-of-date for making serial console install floppies. Chapter 2.12 of the handbook talks about kern.flp and mfsroot.flp, whereas we have three floppies with 5.X install. Which one(s) of the three floppies of 5.X needs to be modified by the procedure of chapter 2.12 ? Windows HyperTerminal is then the way to go, isn't it? The instructions there are outdated. There aren't special floppies to activate serial console. You drop to the loader command prompt (type '6' at the beastie menu) and type set console=comconsole and you should get an OK prompt on the serial console host. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_5, snapshots and disk lock time
On Mon, Mar 07, 2005 at 11:58:02AM -0500, Paul Mather wrote: On Mon, 2005-03-07 at 15:21 +0300, Dmitry Morozovsky wrote: Dear colleagues, dumping the snapshot of 140G ufs2 fyle system under contemporary RELENG_5 I found that during mksnap_ffs file system is unresponsible even for reading for more than 3 minutes (it's on modern SATA disk with 50+ MBps linear transfer). Is it normal? Oddly enough, this happened to me last night on a RELENG_5 system. In my case, things were so bad that mksnap_ffs appeared to wedge everything, meaning I'll have to make a trek in to where the machine is located and press the ol' reset button to get things going again. :-( I am investigating using snapshots for backup purposes and am running into similar difficulties, on a 1TB FS it takes over an hour to create a snapshot, during which time an errant ls or two can lock up the system. Reading through list archives suggests that the the amount of time it takes to create the snapshot is not something that is going to go away and that the issue of an ls in the .snap directory during snapshot creation lacks a fix and that best current practise is 'try to avoid that'. Yes, this is normal. See the documentation about the snapshots implementation (a README in the kernel source tree, I think, and paper written by Kirk). That document also says: As is detailed in the operational information below, snapshots are definitely alpha-test code and are NOT yet ready for production use. Is this the current opinion of snapshots ? The machine in question makes and mounts snapshots of all its filesystems for backup each night via Tivoli TSM. This has worked flawlessly for many months. Last night, I had many BitTorrent sessions active on the filesystem that wedged. I guess the activity broke the snapshot mechanism. :-( The odd thing is that it survived the night before, when there were also BitTorrent sessions active. It's possible there are still deadlock conditions in the snapshot code. Some familiarity with DDB would help to diagnose this (see the chapter on kernel debugging in the developers' handbook). You'd need to work with Kirk to debug these, if you're willing. I wonder how much activity mksnap_ffs can take? I don't think this is the issue, directly. signature.asc Description: OpenPGP digital signature
Re: make release fails
Hi, Michael Lednev,
Tuesday, March 29, 2005, 4:41:55 PM:
ML what to change in my make command or in system to build release? host
ML system is 5.3-STABLE
You can try the following:
1. Change /etc/make.conf
OSVERSION=491102 # st this to kern.osreldate value in RELENG_4
OSREL=4.11
2. make buildworld
3. make release
after done release.2 break it, and put into ${CHROOTDIR}/etc/make.conf
OSVERSION and OSREL variables like /etc/make.conf
4. make rerelase with RELEASENOUPDATE=yes
5. After done release.7 release fail in doFS.sh. You must build
mdconfig without shared libraries. Go in source code tree of
current 5.3 system, into src/sbin/mdconfig and make -DNOSHARED
depend all. Copy mdconfig from obj/usr/src/sbin/mdconfig into
${CHROOTDIR}/sbin/
6. Mount devfs:
mount_devfs devfs ${CHROOTDIR}/dev
7. make rerelease
--
WBR, Andrey V. Elsukov
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
