Re: ATI Mobility Radeon HD 5470
My laptop has a Radeon HD 5470. Xorg and consoles work perfectly. There is little or no hardware acceleration though. This means no 3D games for sure. I remember videos being rather jerky in full screen as well but with the most recent version of the ati driver, even full HD videos seem to run just fine. The only thing I miss is DPMS support. The screen will go blank but the backlight will never turn off. My workaround is to restart Xorg with the vesa driver and run vbetool dpms off from the command line whenever I want to keep the laptop running with the screen off. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Keyboard LEDs stay on after shutdown -p
PS/2 or USB keyboard? The same is happening on my system. My keyboard has a DIN connector plugged into a PS/2 adapter plugged into a USB adapter plugged into a powered USB hub plugged into the FreeBSD box. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: required by?
Once you have a port installed, pkg_info -R gconf\* will tell you. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
As the processor gets hotter, internal clocks and so on are throttled within the hardware to try and stabilise the temperature (to keep the thermal trip point being reached, re: emergency shutdown), which greatly decreases performance. I'm not sure if there's a way to detect this, but I would hope (?) that it would be visible via the CPU clock frequency (on FreeBSD this would be sysctl dev.cpu.X.freq). sysctl dev.cpu.X.freq is used to set the frequency. I have not found any way to read back its internal state so far. If you boot into another operating system such as Linux or Windows, do you see the same overall behaviour? Linux might be easier and might have some built-in way to get at CPU temperatures (via /proc?). I will download a Linux ISO and give it a try. The machine currently has FreeBSD and nothing else installed on it. Trying to figure out if this is a FreeBSD issue or not is difficult. Can you please provide: - Contents of rc.conf # Console keymap=german.iso # Set German keyboard map # Network hostname=taiko.lan# Set hostname to taiko.lan ifconfig_re0=DHCP # Configure wired Ethernet via DHCP # Daemons powerd_enable=YES # Run powerd to lower our power usage sshd_enable=YES # Run the SSH daemon moused_enable=YES # Run the mouse daemon dbus_enable=YES # Run the D-Bus daemon hald_enable=YES # Run the HAL daemon webcamd_enable=YES# Run the webcam daemon cupsd_enable=YES # Run the CUPS printer daemon # Miscellaneous clear_tmp_enable=YES # Clear /tmp at startup devfs_system_ruleset=local# Apply the local ruleset to /dev # PostgreSQL postgres_enable=YES # Run the PostgreSQL server - sysctl -a hw.acpi hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: NONE hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.acline: 1 hw.acpi.battery.life: -1 hw.acpi.battery.time: -1 hw.acpi.battery.state: 7 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 26.8C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 100.0C hw.acpi.thermal.tz0._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 0.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 95.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 100.0C hw.acpi.thermal.tz1._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 0 hw.acpi.thermal.tz1._TC2: 2 hw.acpi.thermal.tz1._TSP: 10 - sysctl -a dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.temperature: 82.0C dev.cpu.0.freq: 1333 dev.cpu.0.freq_levels: 1734/45000 1599/41741 1466/38582 1333/35485 1199/32426 1066/29457 933/26552 816/23233 699/19914 583/16595 466/13276 349/9957 233/6638 116/3319 dev.cpu.0.cx_supported: C1/3 C2/245 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% last 285us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.temperature: 82.0C dev.cpu.1.cx_supported: C1/3 C2/245 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% last 383us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.temperature: 82.0C dev.cpu.2.cx_supported: C1/3 C2/245 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% 0.00% last 238us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.temperature: 82.0C dev.cpu.3.cx_supported: C1/3 C2/245 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% 0.00% last 187us dev.cpu.4.%desc: ACPI CPU dev.cpu.4.%driver: cpu dev.cpu.4.%location: handle=\_PR_.CPU4 dev.cpu.4.%pnpinfo: _HID=none _UID=0 dev.cpu.4.%parent: acpi0 dev.cpu.4.temperature: 82.0C dev.cpu.4.cx_supported: C1/3 C2/245 dev.cpu.4.cx_lowest: C1 dev.cpu.4.cx_usage: 100.00% 0.00% last 426us dev.cpu.5.%desc: ACPI CPU dev.cpu.5.%driver: cpu dev.cpu.5.%location: handle=\_PR_.CPU5 dev.cpu.5.%pnpinfo: _HID=none _UID=0 dev.cpu.5.%parent: acpi0 dev.cpu.5.temperature: 82.0C
Re: System extremely slow under light load
dev.cpu.X.freq does reflect the current frequency; I don't know whether or how any internal clock throttling might be exposed. From what I have seen, dev.cpu.X.freq always retains the value I set it to. Internal CPU throttling does not seem to be reported this way. a bit of hunting found your previous overheating problems on a Dell Studio 1557 from April last year: and your eventual apparent solution which included some fiddling with thermal parameters but primarily by disabling p4tcc and acpi_throttle Yes, that thread described the issues I had with my previous laptop before Dell exchanged it. I never posted an actual solution as I never found one. The problem only went away because the laptop went away. Disabling p4tcc and acpi_throttle may have seemed to address the problems at first - but longer-term evaluation showed that the issues persisted unchanged. hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 I just tried this on my current Dell Studio 1558, with devastating results. The first boot attempt ended with the machine shutting down due to overheating while loading the kernel. I let it cool down a bit and then booted again. This time, I got to my desktop - with a CPU temperature of 95°C. If the DSDT was fixed, the machine would have shut down at this point. I only got down the temperature by reducing the maximal temperature to 1.2GHz again. With the above settings, the machine is idling at 80°C now and very sluggish - some internal throttling appears to be active again. tz0 looks to be a fan. It seems unlikely that any temp. sensor inside a machine with CPU temp. at 82C could possibly be as low as 26.8C, so this value is likely as bogus as the 0.0C CPU reported by tz1. Yes, the 26.8°C is bogus. It never changes. Unfortunately, I have not found a way to fix this reading. The two thermal zones are implemented very differently in the DSDT and I have only managed to fix tz1. However, there is no second fan inside the laptop. I have taken it apart down to the last screw. There is one fan only and that corresponds to tz0. This fan should come on at 55C and run fastest above 71C. If your CPU is at 82C and the fan isn't running flat out, it'd overheat for sure. tz0.active is -1, not running - but maybe the BIOS is controlling it? Yes, the BIOS appears to control the fan. The thresholds exposed via ACPI seem to be purely informative. Whether I fix the DSDT so that temperature readings work or not, the fan turns on at 55°C and speeds up at 71°C. It never spins down again after that as the CPU keeps running very hot. _ACx is N/A here, unless there's a separate CPU fan? Anyway at bogus 0.0C it's never going to trigger passive or active cooling. You said before that with the fixed DSDT to get proper temperature reading here, it shut down due to over temperature, which of course it should .. does that fixed DSDT include fixing detected tz0 temperature .. if so the fan might behave itself without having to use .thermal.user_override=1 See above: Fixing the DSDT makes tz1 work. tz0 remains broken. Are you limiting it to 1333 manually, or with powerd's -M switch? I have tried both. It appears to make no difference whether I use powerd -M or just set dev.cpu.0.freq directly. Clearly including p4tcc and/or acpi_throttle N*12.5% rates; compare to dev.est.0.freq_settings below to figure the freqs added by throttling. Hopefully this machine will respond as well to disabling both methods as your earlier one, as you reported here (same subject, later thread): See above: Unfortunately, the machine did nor respond well at all. Instead, it is overheating even worse. Try using C2. It helps more with some CPUs than others, but it's worth a try for further reducing heat, especially at idle. Ie in rc.conf: performance_cx_lowest=C2 economy_cx_lowest=C2 I have set dev.cpu.X.cx_lowest=C2 at run-time. If I understand correctly, this should achieve the same effect. The CPU does not seem to ever make it to C2 though, even after I enable it: %sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 100.00% 0.00% last 270us dev.cpu.1.cx_usage: 100.00% 0.00% last 399us dev.cpu.2.cx_usage: 100.00% 0.00% last 403us dev.cpu.3.cx_usage: 100.00% 0.00% last 404us dev.cpu.4.cx_usage: 100.00% 0.00% last 323us dev.cpu.5.cx_usage: 100.00% 0.00% last 313us dev.cpu.6.cx_usage: 100.00% 0.00% last 174us dev.cpu.7.cx_usage: 100.00% 0.00% last 137us dev.est.0.freq_settings: 1734/45000 1733/45000 1599/41741 1466/38582 1333/35485 1199/32426 1066/29457 933/26552 With throttling disabled, those are what you should be left with for dev.cpu.0.freq_levels. Yes, these are the frequencies I have available now. 1333 makes the machine idle around 85°C, 1999 leads to 78-80°C. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to
Re: System extremely slow under light load
I am not sure tz0 is the real thermal zone, especially given values of _tc1, _tc2 and _tsp. Temperature value (3001) looks suspicious as well. I agree. tz0 looks entirely bogus. There is no second fan to control for it and I have no idea what it is supposed to be monitoring. Can you, by any chance, put your ASL someplace accessible and provide a description of what you have done to fix the temperature reporting. Certainly. I have uploaded the files at [1] through [5]. The DSDT source returned by acpidump -d is at [1]. I modified this so that it can be compiled back into AML without errors or warnings. This modified source is at [2]. It contains no functional changes. The thermal zones are still broken. A variant with fixed tz1 is at [3]. For convenience, I have also uploaded diffs between these source files. [4] is the diff required to make the source compile (difference between [1] and [2]). [5] is the actual change I made to fix tz1 (difference between [2] and [3]). As you can see, all I did was to remove a bogus function that ends up always returning 0°C. As the side note: I have seen and do own pieces of equipment that use thermal zones to initiate critical shutdown for various and unrelated reasons. In my case, the thermal zone and its various tripping points do correspond to the actual system fan. It is just that the BIOS enforces power management itself, ignoring ACPI - except for critical shutdown which appears to be triggered by ACPI only. - Bartosz [1] http://www.fabianowski.de/dsdt/decompiled.asl [2] http://www.fabianowski.de/dsdt/compilable.asl [3] http://www.fabianowski.de/dsdt/fixed.asl [4] http://www.fabianowski.de/dsdt/decompile_compilable.diff [5] http://www.fabianowski.de/dsdt/compilable_fixed.diff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Sorry to hear none of that helped. It seems a very serious problem, and it would be useful to know if it behaves any better under linux or not. I am still on the hunt for a bootable Linux distribution. I am in the unfortunate situation of having no CD-Rs at hand. And because it is Easter, shops are closed. Most Linux distributions require you to run a proprietary tool from inside Windows or another Linux installation to create a bootable USB medium. I found a USB image for OpenSUSE but that failed to boot. I am continuing to hunt... You need sysctl hw.acpi.cpu.cx_lowest=C2 instead .. that's what /etc/rc.d/power_profile adjusts when you apply or remove power. I doubt it's likely to help much given the scale of overheating. I use the correct sysctl now, the cx_lowest value changed from C1 to C2 for all CPUs but nothing seems to have changed otherwise: %sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 100.00% 0.00% last 230us dev.cpu.1.cx_usage: 100.00% 0.00% last 216us dev.cpu.2.cx_usage: 100.00% 0.00% last 159us dev.cpu.3.cx_usage: 100.00% 0.00% last 323us dev.cpu.4.cx_usage: 100.00% 0.00% last 320us dev.cpu.5.cx_usage: 100.00% 0.00% last 357us dev.cpu.6.cx_usage: 100.00% 0.00% last 378us dev.cpu.7.cx_usage: 100.00% 0.00% last 374us That's pretty sad. Not sure what the first two differing by only 1MHz means .. but I'm out of ideas, and my depth. Thanks for all the tips. I will report back once I have had a chance to compare with Linux. If nothing else helps, I will call Dell again in the futile attempt to have them magically fix the issue somehow. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Try Knoppix, or Ubuntu LiveCD. I tend to use the former for rescue situations: Thanks. I am aware of both - but neither boots from USB (and I have no CD-Rs at hand). I am running UNetbootin under Windows XP in VirtualBox right now to try and get Xubuntu 10.04 onto a USB key. It is really sad that almost all Linux distributions require this detour via a proprietary operating system. I'll be very surprised if Dell is of any assistance, as the last I checked they did not officially support FreeBSD (that's usually their statement). I think testing Linux and/or Windows will overall act as a better confirmation. Absolutely, they do not support FreeBSD. But if the laptop overheats during normal usage, to me, the hardware is broken and needs to be fixed. So far, Dell have been very cooperative, sent out technicians several times and in the end provided me with a completely new laptop. Going by this previous experience, I expect them to send out a technician again and attempt a repair. I am doubtful it will actually fix anything though. I wish I knew what else to recommend too, or what else to check. :-( Folks familiar with ACPI tables might be able to shed some light on the situation, if it is indeed a problem there. I will be able to provide a comparison with Linux soon. This may be helpful. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Please , see the site http://www.mandriva.com/en/linux/ Thanks for the link. It looks like this a USB with a preinstalled Mandriva Linux on it that you have to buy for €50 though. I am looking for an image that I can just download. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
click the link 2009 Rescue iso , which will lead to http://dl1.mandriva.com/flash/rescue/2009.0/ Thanks. There is no mention anywhere on the page that the ISO files can be treated as USB boot images as well. Hence, I did not realize they would suit my needs. Also you may see : http://www.archlinux.org/download/ I know ArchLinux ISO files are also bootable from USB. However, Arch provides no LiveCD, just a simple installer. That said, I find Arch to be an excellent distribution. It just does not fit my particular needs at the moment. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
GRML ISOs (from grml.org) can be dd-ed directly to a USB stick and should then boot with any reasonable current BIOS. Thanks. It is great to see that so many ISOs can be dd-ed to USB keys. I wish the distributions would make it clearer which ISOs work as USB images and which do not. I am reluctant to download gigabytes of ISOs just to find that most do not work. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
If you boot into another operating system such as Linux or Windows, do you see the same overall behaviour? Linux might be easier and might have some built-in way to get at CPU temperatures (via /proc?). I finally found a working USB Linux image and have run some tests: Linux power management is quite different from FreeBSD. It clocks all cores at 933 MHz by default. When I start exercising the CPU, only the cores actually working hard get clocked up all the way to 1.7 GHz. This seems like a good idea but is not possible on FreeBSD right now as the only frequency sysctl is dev.cpu.0.freq. With the CPU idling at 933 MHz, the temperature is about 68°C. I am running FreeBSD with powerd -M 933 right now and the CPU is idling at 76°C while being clocked down to about 200 MHz most of the time. So Linux does something better here and manages to shave off about 10°C. As recommended by Kevin, I tried running md5 on a large chunk of data. I chose a Linux ISO file instead of /dev/random output to have reproducible input. Under FreeBSD, the machine currently is not sluggish and an md5 run completes in 5.7 seconds. I will retry the md5 experiment when the box becomes sluggish and will see whether I can detect TCC kicking in. Under Linux, the same md5 run took 12.6 seconds. This is surprising on the one hand as Linux clocked up all the way to 1.7 GHz while under FreeBSD, I was limiting the CPU to 1.199 GHz. On the other hand, Linux was running from a USB key while FreeBSD is properly installed. I tried running multiple copies of md5 in parallel to exercise multiple cores to the maximum under Linux. This actually made the temperature climb very quickly up to 95°-98°C. At 95°C, the fan audibly switched into a higher gear. I now remember that I have heard this under FreeBSD before as well. The fan seems to be controlled by the BIOS after all so when the CPU reaches 95°C, the BIOS turns up the fan, irrespective of the OS I am running. The great difference between FreeBSD and Linux was that I did not get any of the sluggishness and non-interactive response. Even under high load with a CPU temperature of 95°C and the fan in high gear, KDE was responsive and usable. I did have a few system stalls but according to the console, those were due to problems with reading from the USB key. There seemed to be no sudden breakdown of interactive performance even under load and thermal stress. So something is off under FreeBSD... - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Please , see : http://cdimage.debian.org/debian-cd/6.0.1-live/amd64/ http://cdimage.debian.org/debian-cd/6.0.1-live/i386/ By using dd , you may copy a hybrid .iso to USB stick . Thanks. I downloaded the amd64 image. It booted perfectly after copying to a USB key via dd. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
As several have either discovered or pointed out, the dev.cpu.X.freq is telling you what FreeBSD is requesting, not what the CPU is actually doing. Particularly, if high temperatures cause TCC to kick in, this will not show up. Yes, this is what I thought as well. IF you really want to monitor CPU temperature on an Intel CPU, use the coretemp kernel module. I use it on Intel systems that lack ACPI support for temperature monitoring. It uses a junction on the die, so it will be somewhat higher than the package temperature. Yes, I am using that module and monitoring the dev.cpu.X.temperature output. Technically, my system has support for ACPI monitoring but as I mentioned in earlier messages, the DSDT provided by Dell is broken. I would assume that means that TCC should kick in at about 95 or 96C which does not entirely explain what you are seeing. Unfortunately, your system does not provide a value for _PSV, so I have no idea when it will actually kick in, but it should be in the data sheet for the CPU. If ACPI does not hange it, it runs in a purely automated fashion with no human intervention available. I downloaded and read the specs. If I understand them correctly, the maximal junction temperature for this CPU is 100°C. TCC should kick in when any of the cores exceeds this value. It is unclear to me when exactly TCC deactivates again but if the diagrams in the documentation are drawn to scale, a pretty wide hysteresis is involved. So one explanation for what I am seeing may be this: One of the cores, for a split second, jumps over 100°C. TCC kicks in and does not turn off for a long while. During that time, the system feels sluggish and slow. Try running md5 or sha256 on a bunch of random (/dev/random) data. Collect the time it takes to do a bunch of these and you will see it increase by .125 every time throttling adds another step to the pause time. It will be fairly dramatic and very close to steps of exactly .125 of the original time. Thanks, I will be using that to try and determine whether it really is TCC that makes my machine sluggish under load. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
I could be wrong, but in my experience this really sounds like it is a hardware problem with the cooling system, and a very serious one at that. I would encourage you to take this up with Dell at once. Yes, I will. They have exchanged a lot of components already though (including the whole laptop) and so far, nothing has helped. While it's certainly possible that newer FreeBSD releases are failing to control the temperature as well as older ones due to some change, that does not mean that this is a FreeBSD problem - these temperatures are so far out of line that anything FreeBSD managed to do before should be viewed as an unexpectedly successful workaround. This box has been running FreeBSD 8 since day one. It always had trouble with high temperatures. But now that summer is coming and ambient temperatures are rising, the issue keeps getting worse. Apart from your immediate problems, in my past experience this range of CPU temperatures is likely to lead to early failure of the CPU, very likely within a year or less. Yes, I am afraid that may happen. Then again, Intel's data sheet clearly states that this CPU is designed to operate at up to 100°C. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Have you tried just using dd to copy the iso image of a Ubuntu / Linux LiveCD to a suitably sized USB memory stick? It has worked for me in the past. As per Mehmet's tip, I did just that with a Debian image. If it works for Ubuntu images as well then I really wonder why the only documented way is via Unetbootin. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
The specified maximum CPU temperature is usually the same at the ACPI _CRT, not _PSV. That is the temperature when an ACPI shutdown should be triggered, but TCC should kick in at some point below this. This laptop is a replacement for an earlier one that had similar overheating issues. On that earlier laptop, Dell had managed to set _CRT=85°C with _PSV=95°C. This meant that the laptop did an emergency shutdown at 85°C *before* TCC got a chance to kick in at 95°C. At least on this one, _CRT=100°C and _PSV=95°C represent a more reasonable combination. It works to tell you that TCC is doing the job, but does not explain in any way why your CPU is so hot. I'll be very curious as to what you find when running another OS. I experimented with a Debian Live CD. The results are here: http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/062407.html - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Did you try to set OS override to any of the values, recognized by your BIOS, with most interesting being Windows 2001 SP2, Windows 2006 and Windows 2009. Yes, I tried this a while ago, before messing with the DSDT. I figured it was unlikely that Dell shipped a DSDT which leads to 0°C readings under Windows. Alas, no OS override seemed to change anything. The CPU was running just as hot and the temperature reported by ACPI remained 0°C. Now that I have tried Linux, I can confirm that there, too, the temperature is 0°C. The DSDT is completely broken. Additionally, could you, by any chance, replace _TMP method in TZ01 with the snippet below and let me know what the result is: I am running with that change right now. It seems to have the same effect as my own fixes: hw.acpi.thermal.tz1.temperature works and returns a temperature that agrees with dev.cpu.X.temperature. No other obvious changes. All temperatures are still in the same ranges. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
This appears to be a different issue from the one I am seeing. The system is very responsive at first and only under load (and with rising temperatures) becomes extremely sluggish. As load (and temperatures) drop, the system becomes usable again. Also, there is no difference between Qt and Gtk apps. All of them are equally fast or slow. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Just for an experiment, try to disable powerd and look if things improve. Or just bump it to maximum, temporarily. I have tried both now. The results are as follows: * With powerd disabled and the CPU clocked down, the computer is responsive when almost nothing is going on but becomes very slow as soon as there is a light load. This is identical to the behavior I am seeing with powerd enabled and a reduced maximum frequency. * With powerd disabled and the CPU clocked to its full speed, the computer is running much hotter but responsiveness is not improved. It appears that powerd is not at fault. Something else is making this computer run unbelievably slow. My Atom netbook regularly outperforms this Core i7 when building ports. This just cannot be right :(. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
did you test the caches? I've seen such a behavior when cpu cache was disabled. The Dell BIOS setup is very minimalistic and would not even allow me to turn off caches. So unless the FreeBSD boot loader somehow turned them off, the caches should be active. Is there some tool I can use to verify my caches are active? and it can be thermal throttle in case of bad contact between cpu and heatsink. try to reapply thermal compound The CPU temperature is about 60°C-70°C when idle, 80°-90°C under light load and exceeds 90°C under heavy load. All of these readings are obtained from sysctl dev.cpu as ACPI always reports a temperature of 0°C. If I fix the DSDT to correctly report temperatures, a medium to heavy load forces an emergency shutdown. To prevent this, I am running with the original broken DSDT and the CPU throttled from 1.8GHz to 1.3GHz where it never exceeds 90°C. Yes, the CPU is very warm. But it does not appear to be critically hot. The ACPI critical threshold is 95°C. It seems that this model (Dell Studio 15) always runs that hot. I have had several visits from a Dell technician who changed everything from heat pipe to complete motherboard. The temperatures never changed. Dell finally exchanged the entire laptop for a slightly newer model but the temperatures remained as they were. So reapplying thermal grease or even swapping components does not seem to change anything. Again, a tool would be useful that can tell me whether the CPU is throttling itself. Does such a thing exist? - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
I don't know which i7 you have, but the intel datasheet for the i7-870 states that the maximum case temperature is 72.7C. I have a Core i7 Q740 with a native speed of 1.73GHz. My previous Dell had a Q730. Both were exhibiting the same problems. Since this is a laptop, I would expect temperatures to be higher than in a desktop box. So up to 50-60°C CPU temperature while idling and 90°C under load may be acceptable. But the behavior the computer is exhibiting definitely is not acceptable. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
System extremely slow under light load
Hi list I am having problems with my 8.2-STABLE laptop. At times, even a very light load makes the system grind to a halt. Once an application is in the foreground, I can interact with it just fine. But when I click on a long-unused menu item or try to switch applications, I have to wait dozens of seconds or even minutes. It feels as if things were being swapped in very slowly. However, top says otherwise: The box has 4 GB of RAM with only 680 MB used. On top of that, 69 MB of swap are in used. That last number does not seem to be changing, so nothing is being swapped in or out. The load that seems to cause the worst problems is an import of OpenStreetMap data into a PostgreSQL 9 database. This does not exercise the CPU (a Core i7 Quad) much as CPU load hovers around the 20% mark most of the time and powerd is happy to reduce the operating frequency down to a few hundred MHz. There also does not seem to be much disk activity. So, memory, CPU and disk all seem fine. And still, whenever I try to switch applications, I have to wait minutes for them to appear. I am having a hard time figuring out what is going on. Any tips would be greatly appreciated. I am including the outputs of vmstat -c 2 and iostat -c 2 in the hope that these may shed some light on this. Thanks, - Bartosz Fabianowski vmstat -c 2 procs memory pagedisks faults cpu r b w avmfre flt re pi pofr sr ad0 cd0 in sy cs us sy id 0 1 20 21376M 203M 1652 2 1 1 2993 289 0 0 90 949 2764 5 2 93 0 0 20 21378M 197M 1332 0 5 1 2165 0 58 0 208 7875 3614 2 2 96 iostat -c 2 ttyada0 cd0pass0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 188 2367 51.73 22 1.12 0.00 0 0.00 0.00 0 0.00 3 1 2 0 93 1 991 18.06 49 0.86 0.00 0 0.00 0.00 0 0.00 3 0 2 0 94 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powerd / cpufreq question
I just noticed this thread a day after my own fight with powerd and load
percentages that did not seem to make any sense.
The patch I came up with is attached. It modifies powerd to use the load
percentage of the busiest core. This reduces the range of values back to
0%...100% also for multi-core systems.
On my Core i7 setup here, the change seems to work well.
- Bartosz
--- powerd.c.old2011-04-07 17:30:58.0 +0200
+++ powerd.c2011-04-07 17:38:28.0 +0200
@@ -128,7 +128,7 @@
static long *cp_times = NULL, *cp_times_old = NULL;
static int ncpus = 0;
size_t cp_times_len;
- int error, cpu, i, total;
+ int error, cpu, i, total, max;
if (cp_times == NULL) {
cp_times_len = 0;
@@ -151,7 +151,7 @@
return (error);
if (load) {
- *load = 0;
+ max = 0;
for (cpu = 0; cpu ncpus; cpu++) {
total = 0;
for (i = 0; i CPUSTATES; i++) {
@@ -160,9 +160,12 @@
}
if (total == 0)
continue;
- *load += 100 - (cp_times[cpu * CPUSTATES + CP_IDLE] -
+ total = 100 - (cp_times[cpu * CPUSTATES + CP_IDLE] -
cp_times_old[cpu * CPUSTATES + CP_IDLE]) * 100 /
total;
+ if (total max)
+ max = total;
}
+ *load = max;
}
memcpy(cp_times_old, cp_times, cp_times_len);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powerd / cpufreq question
On my Core i7 setup here, the change seems to work well. ... in your specific workload. And you haven't described how you measured system performance to prove that it haven't decreased. My measure of performance is entirely unscientific: This is a desktop box. Performance is good if KDE reacts to inputs quickly. My patch preserves this for me while making the box run a bit cooler. I am by no means advocating that my patch be made the default behavior. But as you said, it may be nice to include it as one of several algorithms the user can choose from. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: loading module sdhci causes panic
Can anyone verify that sdhci is compatible with FreeBSD 8? I loaded mmc, mmcsd, and sdhci when I first installed FreeBSD 8.0 without any problems. Since then, I have updated to -STABLE and put these three devices in my kernel configuration file. No problems either. It must be very recent breakage or some incompatibility with your particular hardware. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: net/iwi-firmware refuses to build on 7.2-STABLE
iwicontrol is not used on 7 any more. You can use sysctl to query the hardware switch instead: sysctl dev.iwi.0.radio - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Rockbox on a USB device causes kernel panic on 7.0
I think that this is related to some changes on the rsync end, specifically their New USB stack with limited capability. The new USB stack is not enabled by default. Rockbox still reboots the iPod into emergency disk mode when USB is plugged in, just like it always did. That said, Apple's disk mode has always been very good at panicking my 6-STABLE machines. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rockbox on a USB device causes kernel panic on 7.0
the same device that FreeBSD used to identify as IPOD is now identified as Rockbox The Rockbox USB code keeps changing with each build - it used to request power (using its own USB stack) until very recently for me, but as of a couple of days ago, reboots into the original firmware again. It will be difficult to debug the FreeBSD side of things when the Rockbox code is so volatile and fragile. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Analysis of disk file block with ZFS checksum error
I'd say that's the mork database format [1,2], as used by Mozilla products, for example in the Firefox history.dat file. - Bartosz [1] http://www.mozilla.org/mailnews/arch/mork/primer.txt [2] http://www.jwz.org/hacks/mork.pl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading FreeBSD Questions
can you upgrade from the test releases of 7 available now to the final release when ready? Or do you have to wipe? Some machines out there have been continuously upgraded since the FreeBSD 2.x days. So yes, by all means, FreeBSD can be upgraded without wiping. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads UP - MFC for em coming shortly
/home/obj/src/sys/dev/em/if_em.c: In function `em_allocate_intr': /home/obj/src/sys/dev/em/if_em.c:2647: warning: passing arg 6 of `bus_setup_intr' from incompatible pointer type /home/obj/src/sys/dev/em/if_em.c:2647: error: too many arguments to function `bus_setup_intr' This has just been fixed, but for me it now breaks with: /usr/src/sys/modules/em/../../dev/em/if_em.c: In function `em_init_locked': /usr/src/sys/modules/em/../../dev/em/if_em.c:1299: error: structure has no member named `laa_is_present' /usr/src/sys/modules/em/../../dev/em/if_em.c: In function `em_local_timer': /usr/src/sys/modules/em/../../dev/em/if_em.c:2400: error: structure has no member named `mac_type' /usr/src/sys/modules/em/../../dev/em/if_em.c:2401: error: structure has no member named `laa_is_present' - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic and reboot with USB hard disk
Hi list
A 2.5 USB hard disk I recently got has been giving me a lot of trouble.
When using the disk, I routinely get panics or random data corruption.
This happens with two separate machines, both running 6-STABLE. I found
that one file residing on the disk, when read, always makes the kernel
panic.
While I know this smells of a hardware error (bad sector, reads
failing), the disk repeatedly passed badblocks' tests, both read-only
and read-write, with no errors. I am therefore thinking that this may
have something to do with FreeBSD's USB stack.
A kernel with no debugger simply reboots when it encounters the error,
without producing a crash dump. When KDB and DDB are compiled in, I end
up in the debugger prompt where trace points to a routine apparently
handling USB interrupts. Unfortunately, I have to run call doadump to
get a crash dump, after which kgdb seems to show backtraces of the
doadump call, not of the original error.
I would really appreciate any help in debugging this problem. I have
debug kernels on both machines, have a working test case and am happy to
run any debugger commands required. The output of a kgdb backtrace is
attached, although I fear it's not of much use.
As a final note, the disk is 160GB in size, has a single UFS partition
and is GELI encrypted.
panic: vm_fault: fault on nofault entry, addr: db4f9000
KDB: enter: panic
panic: from debugger
Uptime: 30s
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xdb4f9000
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc06d7580
stack pointer = 0x28:0xde342464
frame pointer = 0x28:0xde342498
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 21 (irq11: cbb0 bfe0+*)
Dumping 767 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 767MB (196270 pages) 751 735 719 703 687 671 655 639 623 607
591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319
303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc044d196 in db_fncall (dummy1=0, dummy2=0, dummy3=1999,
dummy4=0xde342294 ) at /usr/src/sys/ddb/db_command.c:492
#2 0xc044cf12 in db_command (last_cmdp=0xc07761a4, cmd_table=0x0,
aux_cmd_tablep=0xc07367e0, aux_cmd_tablep_end=0xc07367e4) at
/usr/src/sys/ddb/db_command.c:350
#3 0xc044d025 in db_command_loop () at /usr/src/sys/ddb/db_command.c:458
#4 0xc044f265 in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:222
#5 0xc0575f07 in kdb_trap (type=0, code=0, tf=0xde342424) at
/usr/src/sys/kern/subr_kdb.c:473
#6 0xc06d98db in trap_fatal (frame=0xde342424, eva=0) at
/usr/src/sys/i386/i386/trap.c:829
#7 0xc06d8ef4 in trap (frame=
{tf_fs = -567017464, tf_es = -1066532824, tf_ds = -567017432,
tf_edi = -615542784, tf_esi = -402886656, tf_ebp = -567008104, tf_isp =
-567008176, tf_ebx = -1001486592, tf_edx = 0, tf_ecx = 1024, tf_eax =
-615563264, tf_trapno = 12, tf_err = 2, tf_eip = -1066568320, tf_cs =
32, tf_eflags = 589830, tf_esp = -1001501696, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:270
#8 0xc06c376a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#9 0xc06d7580 in memcpy () at /usr/src/sys/i386/i386/support.s:681
Previous frame inner to this frame (corrupt stack?)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic and reboot with USB hard disk
With the help of some folks in #freebsd on freenode, I have since been able to fix this problem. Here is the solution for future reference: There is a bug in GELI that makes it corrupt data and panic kernels when certain non-standard settings are used. I had set the GELI sector size to 8192 and the AES key length to 256. After reinitializing GELI with sector size 4096 and AES key length 128, the problems have vanished. Even under extreme I/O load to the drive, the kernel does not panic and no data corruptions occur. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: deinstall ports
If a port is depend on others ports, during the deinstall it will deinstall and all dependencies? No. Only the one port you specify will be deinstalled. If you want to remove dependencies that are no longer needed, use ports-mgmt/pkg_cutleaves. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another newbie question, about makefile options
So my question is, should i pass the makefile options only when running make to compile the program (that would make sence wouldnt it?) or should i use them everytime i run make as in both when doing make and make install clean. I think your experience already showed you that the options have to be specified both when compiling and when installing. The reason is that when you run make a second time, the makefile gets parsed again and the dependencies are checked again. Even if you pass the same flags, new dependencies may still appear during the make install stage. These are run-time dependencies that were not required to build the port but must be present in order for it to function correctly. Thus, always pass the same options to make but do not be surprised if make install still pulls in new dependencies. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 nvidia x11 driver: weird 16bpp/24bpp colorspace damage
I've used portdowngrade for that purpose. My GF3 is not supported by 97xx as well. The x11/nvidia-driver port has a WITH_LEGACY_GPU_SUPPORT knob that downgrades it all the way to version 7184, which supports many older GPUs. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading to 6.2 stable - failed to compile kernel
I was just fightened by all this make.conf stuff! If everything is in my kernel file in /usr/src/sys/i386/conf/MINIMUM_PPS, can I just ignore make.conf? Your MINIMUM_PPS file contains the entire kernel configuration and unless you want to tweak additional options (compiler flags and optimization settings for example), there is no need to modify make.conf. I wasn't sure if that was necessary. I takes about 2 hours to build the kernel without modules, about 15 hours with modules - I've no idea how long buildworld is going to take... A buildworld takes considerably longer than a kernel build. If a kernel takes hours, a buildworld could be a few days... you must be using a very slow machine. A kernel build on my Centrino 1.6GHz takes only a few minutes. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
Since the iwi driver has been MFC'd, I cannot build a kernel any more. I csupped my src/sys to RELENG_6 a couple of hours ago. Everything compiles fine, but when linking the kernel, make barfs: linking kernel if_iwi.o(.text+0x29c4): In function `iwi_getfw': : undefined reference to `firmware_get' if_iwi.o(.text+0x29d3): In function `iwi_getfw': : undefined reference to `firmware_get' if_iwi.o(.text+0x2a1d): In function `iwi_put_fw': : undefined reference to `firmware_put' if_iwi.o(.text+0x49a5): In function `iwi_init_locked': : undefined reference to `firmware_get' I have device iwi in my kernel configuration. Should I remove it and use a module instead? Or is this supposed to work? - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 - 5 - 6: significant performance regression
You wrote that Giant is needed in 6.0 and now you write it has been removed. In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not normally required, making file system operations faster. When you enable QUOTA, you basically get back to the 4.x behavior where Giant is needed for each write. This is why in 6.x UFS will normally be faster but if you enable QUOTA, you lose the newly gained performance again. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipw + WPA not working on 6.1-RC
I am experiencing the exact same problem with 6.1-RC and iwi trying to connect to an OpenWrt wireless router. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: shutting off the internal Sendmail Daemom
Setting sendmail_enable to no in rc.conf does not work Did you remember to set it to NONE, not just NO? This distinction was introduced a long time ago and sendmail_enable=NONE has always done the trick for me since then. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: shutting off the internal Sendmail Daemom
sendmail_enable=NONE has been deprecated and will disappear in a future release. Thanks for pointing that out. According to /etc/rc.d/sendmail, sendmail_enable=NONE corresponds to the following settings: sendmail_enable=NO sendmail_submit_enable=NO sendmail_outbound_enable=NO sendmail_msp_queue_enable=NO - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=athlon-xp and loader
I filed a bug report for this in January of 2005: http://www.freebsd.org/cgi/query-pr.cgi?pr=75898 - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Required audit group is missing...
/usr/src # make installworld ERROR: Required audit group is missing, see /usr/src/UPDATING. *** Error code 1 You probably forgot to run mergemaster -p before make installworld. /usr/src # grep audit /usr/src/UPDATING The note is there in -current. It was not MFCd. That's certainly a mistake and should be fixed. File a big report and some dev should pick it up. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How do I chase 5.*4* stable?
resulted in a quite broken (and *un*stable) 5.5-PRERELEASE RELENG_5 is 5.x-STABLE *most* of the time. When a release is nearing, the first few steps of preparation happen directly on the stable branch, so it will become 5.y-PRERELEASE (and IIRC even 5.y-BETA1). Then, when the new release gets its own branch, the stable branch will become 5.y-STABLE. 1) How can I chase 5.4-STABLE? Can I just use: *default release=cvs tag=RELENG_5_4 in my stable-src-supfile and ports-supfile to accomplish this? In your stable-src-supfile - yes, this is correct. This will give you the 5.4 errata branch. In your ports-supfile - don't do this. Ports should always be checked out from HEAD. There is no such thing as a ports errata branch for a particular old release in FreeBSD. Ports from HEAD should work on all supported (and many unsupported older) releases of FreeBSD. 2) After a fresh install from 5.4 CD's cvsup with (stable) settings then a make/ install/ kernel make (build)/ install world, can I simply copy /etc/passwd /etc/group *over* top of the one(s) created; there-by (safely) maintaining my current userbase/ permissions? No. This is what mergemaster is for. It allows you to merge your customized settings with whatever changes might have occurred in the source tree. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How do I chase 5.*4* stable?
re-instate the previous userbase (including those that applications create). How would I best use mergemaster to accomplish this? Just copy your customized files to /etc/passwd, /etc/group and then run mergemaster to pick them up. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open office 20 fails to build
# The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2-p8-rmvg_08_feb_2006_22_56 mixed mode) This problem has been fixed in revision 1.4.2p8_3 of java/jdk14, committed on 11th February. Upgrade your JDK to the current revision and try building OOo again. - Bartosz PS: There is a separate list for OOo related discussions, [EMAIL PROTECTED] You should use that instead of [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: Need serious help with Dell D600 Latitude laptop and Power Management please :)
I am running a Dell D600 Latitude laptop [...] Here in FreeBSD, my fans are running FULL SPEED all of the time and also seems to be hotter than many conventional ovens. I'm on a Dell Inspiron 8600C (which is the cheaper consumer-grade version of your laptop) and it runs nice and cool for me. You are probably missing the power management daemon (powerd). For more information, see man powerd and to see whether it helps, add the following to your /etc/rc.conf: powerd_enable=YES HTH, - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freeBSD 5.5 Prerelease ( 5.4 stable )
but i need a working OS, not a bata ! If you don't like using a beta (nothing wrong with that), you definitely should not be using -stable either. There are even less promises regarding the reliability and quality of -stable than there are of a beta. After all, during the prerelease and beta cycles, the tree is getting in shape for a release and there is a focus on fixing as many little nits as possible. In between releases, bigger MFCs might hit -stable from time to time and make it less reliable. So, while you are getting confused by the branch name changing, you should also rethink whether you want -stable at all. It really seems like you should be aiming for RELENG_5_4 (and then RELENG_5_5 once 5.5 is out) instead. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recompiled 6.0 does not boot -- need help !!
thanks, but the issue is with the loader itself Telling it to use loader.old should definitely work around that problem. Unless, of course, the problem lies within something that starts even earlier. In this case, you could always use a 6.0 CD to restore the original, working, files. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop choices
Or, can the touch pads be disabled in the bios? I have a Dell Inspiron 8600C, which only has a touch pad. *But* its immediate predecessor, the 8600, had a track pad and one of those little pink joysticks (what are they called anyway?) and I know for a fact that the keyboard and wrist rest in the 8600C can be swapped for the 8600 model, which is often available cheaply on eBay. So, you could get a reasonably new 8600C (they were only replaced by the 6000 line a couple of months ago) and add the stick you like for a couple bucks. But I think that the touch pad will still be enabled - unless you cut a couple of wires, which shouldn't matter much because in case of a warranty return, you can swap back in the original keyboard and wrist rest, so nobody at Dell will see the cut wires :). Of course, this is not a Thinkpad clone, but it is a very good laptop nonetheless (especially the awesome 15.4 1920x1200 screen). - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop choices
It's so much better than the standard 1024x768 that you have to see it to understand. At least in my experience, it also makes people call you nuts all the time. I am using tiny fonts for things that are not as important (like menu bars, for example) and bit fonts for text that I really want to read. To me, that's the real use of this 150 dpi screen - save a lot of screen real estate where readability does not matter and get beautiful glyphs where you have text that you actually want to use. One thing that really annoys me though is how those brain dead fixed width website designs break down big time when I increase the font size from say 10px to 30px in order to get a reasonable size on the screen... - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recompiled 6.0 does not boot -- need help !!
now, when i think of it, i suspect the reason might be CPUTYPE=pentium-m The relevant bug is 75898, which I filed almost a year ago. It has been fixed and MFC'd though, so it should not be affecting 6.0-release (I am using CPUTYPE=pentium-m on 6.0 myself). Most likely, something else went wrong. Still, all is not lost. When your system is starting up, hit any key after the BIOS has finished initializing the computer and before FreeBSD has given you any output on the screen. You'll end up in a prompt where you can select the boot loader. When you installed a new kernel, the previous loader got renamed to loader.old and that's the one you want to run. On my system, the prompt is: Default: 0:ad(0,a)/boot/loader boot: Simply copy the default line and append .old, as in: boot: 0:ad(0,a)/boot/loader.old Once the boot loader has started up, it will count down a few seconds before starting the kernel. Since you're saying your kernel might be b0rked as well, you should hit any key but enter to get another prompt. It will look like this: OK Here, you can tell the loader to boot the previous kernel: OK boot /boot/kernel.old This should get you up and running again. You certainly should try to build a new, working kernel. But you should *absolutely* make sure to back up loader.old and kernel.old first, because if you install another kernel, those two will be overwritten by your current, broken loader and kernel. Simply run (as root): cp /boot/loader.old /boot/loader.good cp -R /boot/kernel.old /boot/kernel.good This way, you can always revert to loader.good and kernel.good if something goes wrong. Actually, it doesn't hurt to have a working kernel and loader lying around just in case. Update it periodically and you will always have a little safeguard in case you render your system unbootable. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recompiled 6.0 does not boot -- need help !!
loader.old??? AFAIK loader is not rebuilt while compiling kernel and there is no such file like loader.old created! It is installed with world and not kernel then. Sorry for getting that wrong, I didn't check. But it makes no difference to the original poster because he reinstalled both world and kernel: i recompiled kernel (and world) and it does not boot anymore. Of course, the handbook recommends installing a new kernel and rebooting before installing world, but people keep doing it differently ;). - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop choices
I'd say the Dell's video is more likely to work (even 3d). Well, not quite yet. X.Org 6.8 doesn't have any 3D support for modern Radeon chips and the forthcoming 6.9/7.0 will have experimental support. But 2D is working just fine (I am typing this on an Inspiron 8600C with ATI Radeon). I'd try 6.0 myself. Seconded. So many things work better in 6.0 than they did in 5.4. Also, getting wireless to work is much easier - and WPA is available, while in 5.4, it is not. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop choices
Mmm, the radeon man page claims Radeon 9000's are supported without caveats. Oops, I sent my initial reply off-list. To summarize for everybody else: Yes, you're right; I was thinking the Radeon 9000 was a newer chip, while it is an oder one (an rv250), which has been fully supported for a while. Sorry for the noise. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new FreeBSD-webpage
monitor are wider than taller, why restrain horizontal space ? A fixed width design is very fashionable these days and you see it creeping up everywhere. It's what's considered professional these days, so I can't really blame anybody trying to appear professional for choosing it. But I still think that this is a bad trend. On my wide screen laptop, 50% of the screen are wasted blank space. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
malloc() debugging flags broken on RELENG_5
Hi Some commit in the last few weeks has broken the malloc() debug flags on RELENG_5. According to the man page, a call to free() or realloc() with a modified pointer should cause a warning. Setting the A flag in either /etc/malloc.conf or MALLOC_OPTIONS should turn this into an error. However, what happens is that this *always* causes an error. And even setting the corresponding a flag does not turn it into a warning. This is very unfortunate as some poorly written programs (KDE's Kopete messenger in my case) seem to rely on the fact that free() and realloc() with modified pointers are OK. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc() debugging flags broken on RELENG_5
You're not running as root, are you? The A flag is always set for root or setuid processes as a security measure. No, I am running as a normal user. There hasn't been any changes to the malloc code in 5.x since 5.3. I realize there shouldn't have been any changes and I also cannot find everything in the CVS logs. But when I run Kopete, I get the following: kopete in free(): error: modified (chunk-) pointer ^ According to the man page, this word should read warning instead of error and the application should not be aborted. File a bugreport; a program must pass the same pointer to free() that it received from malloc(). Obviously, there is a bug in Kopete. But it runs for other people with earlier versions of RELENG_5. I am currently downgrading to 1st March to see whether that fixes the issue for me. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc() debugging flags broken on RELENG_5
The actual test in the malloc code reads: if (malloc_abort || issetugid() || getuid() == 0 || getgid() == 0) wrterror(p) , so it may also trigger if your primary groupid is 0 (wheel). Just being a member of the wheel group won't trigger it. Thank you very much for pointing this out. I should have looked myself before complaining, of course. My user's primary group is indeed wheel. I will patch my source tree, recompile libc and see whether this helps (I realize this is much more of a hack than a solution but as long as it works, I am fine). - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
Can you try with just -mno-sse2? I'd like to litter the compile command line as little as possible. I just tried. -mno-sse2 indeed is all that's required to make the kernel work. The same flag also makes the loader run again: --- /usr/src/sys/boot/i386/loader/Makefile.old Tue Mar 15 18:03:13 2005 +++ /usr/src/sys/boot/i386/loader/Makefile Fri Feb 27 15:10:09 2004 @@ -40,7 +40,7 @@ CLEANFILES=vers.c loader loader.bin loader.help -CFLAGS+= -Wall -mno-sse2 +CFLAGS+= -Wall LDFLAGS= -static -Ttext 0x0 # i386 standalone support library ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
That last patch was reversed. Sorry: --- /usr/src/sys/boot/i386/loader/Makefile.old Tue Mar 15 18:03:13 2005 +++ /usr/src/sys/boot/i386/loader/Makefile Fri Feb 27 15:10:09 2004 @@ -40,7 +40,7 @@ CLEANFILES=vers.c loader loader.bin loader.help -CFLAGS+= -Wall +CFLAGS+= -Wall -mno-sse2 LDFLAGS= -static -Ttext 0x0 # i386 standalone support library ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
Are you saying, all we need to do is commit this diff to make everyone's environment happy? Obviously, I can't speak for everyone. For me, your patch fixes the kernel. But the loader still causes an exception. That's of course because your patch only affects the kernel itself and not the loader. If it was possible to do a similar tweak for the loader, I am confident it would make the bug go away. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
i have read that were some problems compiling the kernel and the loader with pentium-m in CPUTYPE. are they fixed now? I'm the one who filed the original bug report: http://www.freebsd.org/cgi/query-pr.cgi?pr=75898 Since it hasn't been touched yet by anybody, my guess is that the problems persist. If you want to try for yourself, just recompile your kernel with CPUTYPE=pentium-m and see whether it boots or panics. is it safe to compile the world with that switch on (and downgrade to something else - pentium3? - for kernelloader) ? I'd assume the answer to this one is yes - it's safe. Personally, I compile world and kernel as pentium3, but that's just out of laziness. As you can read in the bug report, the problem is that SSE2 instructions get used by the kernel and loader before they are enabled. Once the boot gets to the first userland programs, SSE2 is enabled so any world programs should run just fine when compiled as pentium-m. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I can not surf on Flash powered sites.
/usr/ports/www/linuxpluginwrapper/pkg-message says: Firefox has a double free problem wih Flash7. So I don't support it. Please don't send me a report about firefox. Of course, I always welcome to recieve fixed problems report. That's kept me away from trying it. Yes, Flash 7 doesn't seem to work. But Flash 6 does. And that should be enough for almost all websites and cute animations. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Persisting troubles with periodic stalls every few minutes
top -qbSs 1 -d max /var/tmp/somefile Thank you, that helped. Although top did not tell me which process was guilty directly, it allowed me to track it down. For the record: The process hogging the entire CPU was Xorg, which in turn was being pushed by the KDE World Clock. At my screen resolution, the clock redraws itself every 45 minutes. Apparently, it does this in a very inefficient way, using a lot of CPU and making heavy use of the disk drive. I have filed a bug report on this with KDE: http://bugs.kde.org/show_bug.cgi?id=97565 Thanks Gavin and Kris for your input, - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Persisting troubles with periodic stalls every few minutes
Hi list, I have been having a lot of trouble with performance on my laptop, which I first set up with 5.3-RELEASE and constantly keep up to date with 5.3-STABLE. The box runs stable, but periodically, somewhere between every few minutes down to every few seconds, it stalls for 5 seconds. By that I mean that the screen is not being refreshed and all keyboard strokes go into some kind of buffer to get processed when the stall is over. Some key strokes also get lost or reversed in order, which makes this even more annoying. I know that during the stalls, CPU usage goes up to 100%, so it is some process that periodically wakes up and hogs the CPU for a few seconds. Also, during the stalls, there is always a lot of disk activity. The only special thing about this machine is that /usr/home is GBDE encrypted. But even when I am not doing anything on that partition, stalls occur. The rate of stalls varies a depending on what I am doing. Even when the box is idle, it does stall periodically. But when I am making world, the box becomes almost completely unusable as disk activity on /usr (which is not GBDE encrypted) triggers the same symptoms. The trouble is that I cannot figure out how to find the responsible process. Tools such as top(1) update in one second intervals at best and as there are no screen updates during the stall, so they produce nothing useful. The only tool that gave me some kind of information was systat(1). When I invoke systat -vmstat 1, I see the following: When everything is working normally, the CPU is at: 15% system30% user65% idle At the first screen update after a stall, the CPU is at: 15% system85% user 0% idle Also, the VM statistics such as zfod and ofod have jumped from their usual zero level to several thousand. And disk activity is reported as high, of course. A couple seconds after the stall is over, all statistics return to their normal values. So, some user process is misbehaving. And has been doing so ever since this box was set up. Plus, it is somehow disk related and happens no matter what I am running or not, what I am doing or not. Any ideas on how to debug this? How can I find the guilty process? Thanks for any and all input, - Bartosz Fabianowski PS: According to sysctl, DMA is enabled on both ata and atapi so that is not the issue. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant reboots with CPUTYPE=pentium-m
Note that I only see the problem when building the loader as part of a buildworld. Compiling just the boot stuff in /usr/src/sys/boot/ (i.e., without a bootstrapped gcc) results in a loader that works fine. Curious. Either what you are seeing is a different problem then or it somehow shows in a different way than on my system. I would be very interested in investigating this further. To find the root of the cause, I guess it would be best to compare the .s files generated for the loader when a) compiling it as part of the world and b) compiling it on its own. In both cases, CPUTYPE=athlon-xp should be set, of course. Also, you should be using the exact same GCC to eliminate the possibility that different GCC binaries behave in different ways. I am not sure how much space this would take, but if you have the space, it would be great if you could do a full buildworld with -save-temps and then a separate build of the loader, with -save-temps again. For me, one of the offending files is: /usr/obj/usr/src/sys/boot/i386/loader/bcache.s You could try diffing that file and if it shows no differences, all the other .s files in that directory. Some file must change when the loader breaks / unbreaks after all. If you can send me the diffs, I will be glad to look into it. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant reboots with CPUTYPE=pentium-m
I use the athlon-xp switch on 3 boxes with no problems all of them running 5.3 What CFLAGS are you using? I have CFLAGS=-O -pipe in my make.conf. Maybe you have optimization turned off and that's making a difference? - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant reboots with CPUTYPE=pentium-m
Replying to myself, I have found the problem and filed a but report: http://www.freebsd.org/cgi/query-pr.cgi?pr=75898 Thanks for all the help everybody, - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Instant reboots with CPUTYPE=pentium-m
Hi list, I am still having the problems with instant reboots that I reported [1] a couple of weeks ago. I have a bit more info now and hope that someone can lead me in the right direction. The problem is that setting CPUTYPE=pentium-m in make.conf leads to a corrupt boot loader and a corrupt kernel being generated. This setting for the CPUTYPE has been available on -STABLE since 16th December, when revision 1.40.2.1 of bsd.cpu.mk was committed. I have traced the start of my problems to that exact commit (the commiter is CC'd). On -current, the setting has been available for a longer time and has led to the same problems for some people. Also, it seems that not only pentium-m is broken, but athlon-xp as well. The end of a thread on the -current mailing list discussing this issue is in [2]. Unfortunately, it provides no insight as to where the problem lies. It seems to me that every other part of the world, including GCC itself, is built correctly when CPUTYPE is set to pentium-m. The issue only affects the boot loader and the kernel for some reason. When I changed the CPUTYPE from pentium-m down to pentium3 (essentially just disabling SSE2) and recompiled the boot loader, I instantly got a working loader again. I have attached a diff of the .s files generated for the loader with CPUTYPE=pentium3 and CPUTYPE=pentium-m. I do not see any real changes except for the use of xmm registers when CPUTYPE=pentium-m is set. Does anybody have an idea how to debug this further? I am totally out of ideas and really do not know where to continue looking. I have some time on my hands to go searching for the bug - all I need is some direction. - Bartosz [1] http://lists.freebsd.org/pipermail/freebsd-stable/2004-December/010594.html [2] http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042127.html diff -u loader_dir_p3/bcache.s loader_dir_pm/bcache.s --- loader_dir_p3/bcache.s Wed Jan 5 21:56:29 2005 +++ loader_dir_pm/bcache.s Wed Jan 5 21:56:29 2005 @@ -684,7 +684,7 @@ pushl %edi pushl %esi pushl %ebx - subl$36, %esp + subl$28, %esp movl12(%ebp), %ebx movl16(%ebp), %esi leal-16(%ebp), %eax @@ -692,21 +692,19 @@ calltime movl$0, -20(%ebp) movlbcache_ctl, %eax - movl12(%eax), %eax - movl%eax, -24(%ebp) + movd12(%eax), %xmm0 movl$1, %ecx cmplbcache_nblks, %ecx jae .L99 - movlbcache_ctl, %eax - movl%eax, -36(%ebp) - movl%eax, -28(%ebp) - movlbcache_nblks, %eax - movl%eax, -32(%ebp) + movd%eax, %xmm1 + movl%eax, -24(%ebp) + movlbcache_nblks, %edi + movl%edi, -28(%ebp) .p2align 4,,15 .L103: movl%ecx, %eax sall$4, %eax - movl-36(%ebp), %edi + movd%xmm1, %edi movl4(%eax,%edi), %edx xorl%esi, %edx movl(%eax,%edi), %eax @@ -717,18 +715,17 @@ jmp .L99 .p2align 4,,7 .L101: - movl-28(%ebp), %edx + movl-24(%ebp), %edx movl%ecx, %eax sall$4, %eax - movl-24(%ebp), %edi + movd%xmm0, %edi cmpl%edi, 12(%eax,%edx) jge .L100 - movl12(%eax,%edx), %eax - movl%eax, -24(%ebp) + movd12(%eax,%edx), %xmm0 movl%ecx, -20(%ebp) .L100: incl%ecx - cmpl-32(%ebp), %ecx + cmpl-28(%ebp), %ecx jb .L103 .L99: movlbcache_blksize, %eax @@ -753,7 +750,7 @@ movl%eax, bcache_bcount movlbcache_ctl, %eax movl%edx, 12(%ecx,%eax) - addl$36, %esp + addl$28, %esp popl%ebx popl%esi popl%edi diff -u loader_dir_p3/interp_backslash.s loader_dir_pm/interp_backslash.s --- loader_dir_p3/interp_backslash.sWed Jan 5 21:56:29 2005 +++ loader_dir_pm/interp_backslash.sWed Jan 5 21:56:29 2005 @@ -12,7 +12,7 @@ pushl %edi pushl %esi pushl %ebx - subl$32, %esp + subl$28, %esp movl8(%ebp), %ebx movl$0, %edi movl$0, %esi @@ -211,39 +211,39 @@ subl$55, %eax sall$6, %eax .L31: - movl%eax, -24(%ebp) + movd%eax, %xmm0 movsbl 1(%ebx),%eax leal-48(%eax), %edx - movl%edx, -40(%ebp) - movl-24(%ebp), %edx + movl%edx, -36(%ebp) + movd%xmm0, %edx leal-384(%edx,%eax,8), %eax - cmpl$9, -40(%ebp) + cmpl$9, -36(%ebp) jbe .L37 movsbl 1(%ebx),%eax leal-97(%eax), %edx - movl%edx, -40(%ebp) - movl-24(%ebp), %edx + movl%edx, -36(%ebp) + movd%xmm0, %edx leal-696(%edx,%eax,8), %eax -
Recent CPUTYPE changes breaking kernel on Centrino
Hi list, I posted this question a few days ago, but it got lost in a thread I fear. With the recent changes to bsd.cpu.mk, the setting CPUTYPE=pentium-m in make.conf now gets picked up and leads to GCC flags being set accordingly. Unfortunately, something gets enabled that the Pentium M (actually a P3 with some additional features) does not support. What happens then is that a newly built world works just fine, while the kernel does not even boot. Both the boot loader and the kernel itself cause instant reboots at startup. I'm wondering if somebody knowledgeable with the GCC flags for a P3 would have a clue which flag or feature it is that could be triggering this. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE changes ? (RELENG_5)
Apparently, the CPU type changes have some unintended side effects. For me, they render the system unbootable. I have been investigating what broke my system between a 10th December cvsup and a 20th December one and it boils down to bsd.cpu.mk. I am on a Centrino laptop, which uses a Pentium M (Pentium III with some additional features) CPU. I have CPUTYPE set to pentium-m. I know this is officially not documented, but bsd.cpu.ml recognizes it and sets the compiler flags accordingly. Unfortunately, something is wrong with the flags. Some feature gets enabled that this CPU does not support and a freshly compiled kernel simply reboots the box on startup. It also affects the boot loader, which shows a register dump for a split second and then reboots the machine as well. I'd love to get to the root of this as currently, it prevents me from keeping my machine up-to-date since anything newer than 15th December leads to an unbootable system :(. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Constant short stalls on 5-stable
Hi list, I am having trouble with 5-stable on an Intel Centrino notebook. The system was installed from scratch using 5.3-release CDs and is updated every few days to the latest 5-stable. The output of uname -a is: FreeBSD takahe.local 5.3-STABLE FreeBSD 5.3-STABLE #6: Fri Nov 19 00:42:30 CET 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAKAHE i386 It's running as a desktop with xorg and KDE 3.3.1. The /usr/home partition is GBDE encrypted. Everything is working fine, but there are constant stalls. What I mean by that is that the machine will suddenly stop responding to any input. The mouse cursor will keep moving, but keyboard input will end up in a buffer somewhere and mouse clicks will get lost completely. After a second or two, everything comes back to normal. Characters typed during the stall come out of the buffer (although often in the wrong order and with some characters missing) and the system can be used again. A minute or two later, the next stall occurs. Needless to say, this is very annoying. I know that with such a vague description, probably nobody can help me. But maybe someone has a debugging tip for me. Where should I look? How can I see what is hogging up the CPU or some other important system resource during a stall? - Bartosz ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
