Re: overheating Thinkpad X60s with 7.0-RC1
On Sun, 06 Jan 2008 20:22:48 -0500
Nathan Lay <[EMAIL PROTECTED]> wrote:
> I do notice, however, that FreeBSD seemed to never use the fan to its
> potential on any of the Thinkpads I've used (T40 for 3 years, T43 for 3
> years). Comparably, Windows XP would rev the fan far higher than even
> setting 'dev.acpi_ibm.0.fan_level=7' when under load. The fan can
> certainly work faster (even when booting FreeBSD, its audibly
> faster)...but 7 is the highest level acpi_ibm allows one to set.
yes, this is true - even booting under knoppix and loading some special
drivers, u can pass -1 (or some special value) to the linux driver and it will
let the fan spin lose...and it definitely goes far faster than the
approximately 3.5K rpm it does with fan_level=7 and fan=0.
I have a Thinkpad Z60m, single core, 2 GHz. Everything original except the
memory, increased to 1.5 GB.
in my case, i think the GPU heats up pretty badly... it is very hot where I
think the video card is located.
I've posted to both mobile@ and acpi@ under the subject of 'Management of
Thermal' with my woes while on the latest 6.2 before 7 went into Beta1. Since
my upgrade to 7 i've had no major issues with heat. The emails i've posted
previously show the settings i have been using, as well as whatever I had done
in knoppix to manage the speed of the fan.
cheers,
B
_
{Beto|Norberto|Numard} Meijome
"Caminante no hay camino, se hace camino al andar"
Antonio Machado
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Cannot mount a nfs share after doing a snapshot
On Sun, Jan 06, 2008 at 05:38:30PM +0100, Jose Garcia Juanino wrote: > El domingo 06 de enero a las 15:41:21 CET, Greg Byshenk escribi?: > > On Sat, Jan 05, 2008 at 11:28:31PM +0100, Jose Garcia Juanino wrote: > > > > > I have a 7.0-PRERELEASE i386 system with a nfs server, with an unique > > > export > > > line in /etc/exports file: > > > > > > / -maproot=root -network 192.168.1.0 -mask 255.255.255.0 > > > > > > After a reboot, I have no problem mounting this nfs share from a nfs > > > client. > > > But after issuing the following command on the server: > > > > > > # mount -u -o snapshot /.snap/now / > > Is the problem that you are trying to mount your snapshot on top of the / > > directory? I use snapshots, but have never tried to do this, and can > > imagine that there might be a problem, since the snapshot is itself a > > snapshot of a filesystem (different than the actual root filesystem). > > > > That would explain the error: > > > Jan 5 22:47:03 gauss mountd[542]: can't delete exports for /: > > > Cross-device link > No, I am not trying to mount the snapshot. I am just taking (making) the > snapshot, as man mount says. Sorry, I wasn't following this (as I said, I don't work with snapshots in this way). I've looked at the 'mount' man page, and it seems that it should work the way you are trying to do it. That said, because taking a snapshot grabs the entirety of a filesystem, I can well imagine that trying to take a snapshot of the root filesystem while at the same time exporting that filesystem via NFS will cause a problem. > > What happens if you create a directory and mount your snapshot there: > > > > mkdir /snapshotmount > > mount -u -o snapshot /.snap/now /snapshotmount > > > > If this works, then you may need a separate exports line for /snapshotmount. > # file /.snap/now > /.snap/now: Unix Fast File system [v2] (little-endian) last mounted on > /, last written at Sun Jan 6 16:24:19 2008, clean flag 1, readonly flag > 1, number of blocks 130721, number of data blocks 126520, number of > cylinder groups 4, block size 16384, fragment size 2048, average file > size 16384, average number of files in dir 64, pending blocks to free 0, > pending inodes to free 0, system-wide uuid 0, minimum percentage of free > blocks 8, TIME optimization Ok, so it looks like your /.snap/now snapshot actually exists, and is being made, so it looks like the command # mount -u -o snapshot /.snap/now / is actually working. (So ignore the rest of what I said last time...) I've just played with this a bit myself (I'm no expert, but I use snapshots currently with 6-STABLE and want to know about any future problems), and I can reproduce the problem (7.0-PRERELEASE as of 2 Jan 2008). I see the same sort of errors as you report, and they cannot be cleared even by removing the snapshot file and restarting nfsd/mountd. The only solution appears to be to remove the snapshot and restart the machine. I can see how this might be a bit inconvenient. That said, there appears to be a problem with using the # mount -u -o snapshot form of the command. The problem does _not_ occur (at least in my test) if you use the the # mksnap_ffs command. Can you try taking a snapshot using mksnap_ffs? If mksnap_ffs works, while 'mount -u -o' fails, then it looks like a bug... -greg -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kmem_map too small under ZFS
I have been experimenting with ZFS recently, and have been seeing the occasional reboot with the above error. A quick google shows that this is a known problem, but that it should go away if you increase kernel memory. I have done this, but I am still seeing the problem - and not uunder high load either. Is there anything else I can try to mitigate this ? I am running 7.0-RC1 from Jan 3rd at the moment.. cheers, -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kmem_map too small under ZFS
> vm.kmem_size="512M" > vm.kmem_size_max="512M" I have similar to this in mine... vm.kmem_size=629145600 vm.kmem_size_max=629145600 which is about 600 meg - the machine has 2 gig of RAM. > vfs.zfs.prefetch_disable="1" > vfs.zfs.arc_max="150M" > kern.maxvnodes="40" now these I havent got - I did see a reference to disabling the intent log, which is what I was about to try. I will give your settings a shot too. > Most of these settings came from various mailing list postings. It's > possible that some don't do anything useful, but I haven't had a zfs > related panic since. Worth a try - might see if I can find a way tro reliably trigger the opanic and then tyrn these bits back on one at a time too. thanks, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kmem_map too small under ZFS
I have the following in /boot/loader.conf and it seems to be doing well for me on FreeBSD-i386 with 1G RAM. vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_max="150M" kern.maxvnodes="40" Most of these settings came from various mailing list postings. It's possible that some don't do anything useful, but I haven't had a zfs related panic since. On Jan 7, 2008 4:00 AM, Pete French <[EMAIL PROTECTED]> wrote: > I have been experimenting with ZFS recently, and have been seeing the > occasional reboot with the above error. A quick google shows that this is > a known problem, but that it should go away if you increase kernel > memory. I have done this, but I am still seeing the problem - and not > uunder high load either. Is there anything else I can try to mitigate this ? > I am running 7.0-RC1 from Jan 3rd at the moment.. > > cheers, > > -pcf. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[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: Cannot mount a nfs share after doing a snapshot
El lunes 07 de enero a las 12:06:50 CET, Greg Byshenk escribió: > > # file /.snap/now > > /.snap/now: Unix Fast File system [v2] (little-endian) last mounted on > > /, last written at Sun Jan 6 16:24:19 2008, clean flag 1, readonly flag > > 1, number of blocks 130721, number of data blocks 126520, number of > > cylinder groups 4, block size 16384, fragment size 2048, average file > > size 16384, average number of files in dir 64, pending blocks to free 0, > > pending inodes to free 0, system-wide uuid 0, minimum percentage of free > > blocks 8, TIME optimization > > Ok, so it looks like your /.snap/now snapshot actually exists, and is being > made, so it looks like the command > > # mount -u -o snapshot /.snap/now / > > is actually working. (So ignore the rest of what I said last time...) > > > I've just played with this a bit myself (I'm no expert, but I use snapshots > currently with 6-STABLE and want to know about any future problems), and I > can reproduce the problem (7.0-PRERELEASE as of 2 Jan 2008). I see the same > sort of errors as you report, and they cannot be cleared even by removing > the snapshot file and restarting nfsd/mountd. The only solution appears to > be to remove the snapshot and restart the machine. I can see how this might > be a bit inconvenient. > > That said, there appears to be a problem with using the > > # mount -u -o snapshot > > form of the command. > > The problem does _not_ occur (at least in my test) if you use the the > > # mksnap_ffs > > command. Can you try taking a snapshot using mksnap_ffs? Yes, as I have explained in my first post. Taking the snapshot with mksnap_ffs has no problem at all. > > If mksnap_ffs works, while 'mount -u -o' fails, then it looks like a bug... > Yes, I think so. The annoying fact is that I am using the sysutils/freebsd-snapshot port to take periodic snapshots and it executes mount -u -o snapshot to make the snapshots instead of mksnap_ffs . Best regards pgp8pkLm8w7sm.pgp Description: PGP signature
Re: Cannot mount a nfs share after doing a snapshot
I too saw mountd / exports just fail on 2 systems upgraded in last days from 7RC4 to newest 7 Stable (CTM src-7 80, received here Jan 6 15:15 CEST=GMT+01:00). I am not using .snap snapshot. My other AMD & NFS on other FreeBSD-4 & 6 hosts remains OK. AMD & NFS as client & server was working till then. I just upgraded src/ & rebooted & exports failed. messages: mountd[563]: can't change attributes for / mountd[563]: bad exports list line / host1 host2 host3 named seems to resolve hosts OK though. (my usual first suspect :-) su; mount_nfs lapd:/usr /mnt [udp] lapd:/usr: Permission denied Maybe changed hosts/pam/ssh/inetd type root auth defaults between RC4 & now ? -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mixer default values not restored
On Jan 7, 2008 7:30 AM, John Baldwin <[EMAIL PROTECTED]> wrote: > > On Wednesday 02 January 2008 08:35:40 am Jouke Witteveen wrote: > > Hello, > > > > I'm running FreeBSD 7.0 RC1 with the following in my kernel configuration: > > --- > > device sound > > device snd_emu10kx > > --- > > My soundcard is a Soundblaster Live! > > > > In trying to make the rear-channel volume default to "100" I added the > > following to my /boot/device.hints: > > --- > > hint.pcm.1.vol="100" > > hint.pcm.1.pcm="100" > > --- > > This method is suggested on page 164 (section 7.2.4) of the Handbook. > > > > The problem is that these mixer levels do not apply: > > --- > > $ mixer -f /dev/mixer1 > > Mixer vol is currently set to 75:75 > > Mixer pcm is currently set to 75:75 > > --- > > There is no problem however in manualy settig these values. > > > > Any help is welcome. My machine can - may it be needed - be used as a > > testbase. > > Hmm, probably /etc/rc.d/mixer is overriding the tunables as it is restoring > the settings > to those from the previous boot. You can disable the mixer script perhaps. > > -- > John Baldwin > Like I said; initialy I had the script disabled. Can someone please test de kernel tunables (hints) on his/her machine? Thanks, - Jouke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kmem_map too small under ZFS
On 1/7/08, Pete French <[EMAIL PROTECTED]> wrote: > > vm.kmem_size="512M" > > vm.kmem_size_max="512M" > > I have similar to this in mine... > > vm.kmem_size=629145600 > vm.kmem_size_max=629145600 > > which is about 600 meg - the machine has 2 gig of RAM. > > > vfs.zfs.prefetch_disable="1" > > vfs.zfs.arc_max="150M" > > kern.maxvnodes="40" > > now these I havent got - I did see a reference to disabling the intent log, > which is what I was about to try. I will give your settings a shot too. > > > Most of these settings came from various mailing list postings. It's > > possible that some don't do anything useful, but I haven't had a zfs > > related panic since. > > Worth a try - might see if I can find a way tro reliably trigger the > opanic and then tyrn these bits back on one at a time too. > I use the following settings that were obtained from the ZFSTuningGuide a while back. # # ZFS Tunning (amd64) - http://wiki.freebsd.org/ZFSTuningGuide # # kern.maxvnodes="40" - sysctl.conf # 1073741824 = 1G vm.kmem_size="1073741824" vm.kmem_size_max="1073741824" #vfs.zfs.zil_disable=1 #vfs.zfs.prefetch_disable=1 # arc_max = 2 * kmem_size / 3 #vfs.zfs.arc_max="683M" The commented out settings are no longer in the guide, and I haven't had any problems with just setting vm.kmem_size* on FreeBSD/amd64. Is your system FreeBSD/amd64 or FreeBSD/i386? If it is FreeBSD/i386 you will need to increase KVA_PAGES as suggested in the guide. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: overheating Thinkpad X60s with 7.0-RC1
On Sun, Jan 06, 2008 at 02:55:32PM -0800, Jeremy Chadwick wrote: > I won't even bother mentioning what happens when I run something that's > CPU or GPU intensive. I haven't had any crashes, but in some cases, > I've seen the GPU temperatures reach over 80C -- completely > unacceptable, and bordering on insane. It's gotten to the point where > to use my T60p *quietly*, I'm forced to prop the rear corners up on > little blocks or whatever, and then place a desk fan nearby, blowing > cold air more or less underneathe the laptop. This keeps the fan in low > speed mode, which is semi-tolerable. Makes me wonder why you didn't return these laptops for repair... > I would urge those here to consider booting XP somehow (if possible) and > running tp4xfancontrol to check actual temperatures, since FreeBSD's > h/w monitoring capability is spotty at best (I think Linux wins out > here, but at least there's room for growth...) ... or just use FreeBSD's own acpi_ibm(4) for reading those temperatures: $ sysctl dev.acpi_ibm.0.thermal dev.acpi_ibm.0.thermal: 49 52 -1 47 32 -1 32 -1 Now, who are you calling "spotty"? http://www.thinkwiki.org/wiki/Thermal_Sensors has some hints about possible sensor locations, although no one has yet submitted information on sensor locations for the X60s. Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> pgp6If0LYk599.pgp Description: PGP signature
Re: Mixer default values not restored
On Monday 07 January 2008 08:32:49 am Jouke Witteveen wrote:
> On Jan 7, 2008 7:30 AM, John Baldwin <[EMAIL PROTECTED]> wrote:
> >
> > On Wednesday 02 January 2008 08:35:40 am Jouke Witteveen wrote:
> > > Hello,
> > >
> > > I'm running FreeBSD 7.0 RC1 with the following in my kernel
configuration:
> > > ---
> > > device sound
> > > device snd_emu10kx
> > > ---
> > > My soundcard is a Soundblaster Live!
> > >
> > > In trying to make the rear-channel volume default to "100" I added the
> > > following to my /boot/device.hints:
> > > ---
> > > hint.pcm.1.vol="100"
> > > hint.pcm.1.pcm="100"
> > > ---
> > > This method is suggested on page 164 (section 7.2.4) of the Handbook.
> > >
> > > The problem is that these mixer levels do not apply:
> > > ---
> > > $ mixer -f /dev/mixer1
> > > Mixer vol is currently set to 75:75
> > > Mixer pcm is currently set to 75:75
> > > ---
> > > There is no problem however in manualy settig these values.
> > >
> > > Any help is welcome. My machine can - may it be needed - be used as a
testbase.
> >
> > Hmm, probably /etc/rc.d/mixer is overriding the tunables as it is
restoring the settings
> > to those from the previous boot. You can disable the mixer script
perhaps.
> >
> > --
> > John Baldwin
> >
>
> Like I said; initialy I had the script disabled.
> Can someone please test de kernel tunables (hints) on his/her machine?
Err, I don't see anywhere in your message where you disabled it. You would
need to add 'mixer_enable="NO"' to /etc/rc.conf. The hints are honored in
the mixer_init() function in sys/dev/sound/pcm/mixer.c here:
for (i = 0; i < SOUND_MIXER_NRDEVICES; i++) {
v = snd_mixerdefaults[i];
if (resource_int_value(device_get_name(dev),
device_get_unit(dev), snd_mixernames[i], &val) == 0) {
if (val >= 0 && val <= 100) {
v = (u_int16_t) val;
}
}
mixer_set(m, i, v | (v << 8));
}
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mixer default values not restored
On Jan 7, 2008 8:02 PM, John Baldwin <[EMAIL PROTECTED]> wrote:
>
> On Monday 07 January 2008 08:32:49 am Jouke Witteveen wrote:
> > On Jan 7, 2008 7:30 AM, John Baldwin <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wednesday 02 January 2008 08:35:40 am Jouke Witteveen wrote:
> > > > Hello,
> > > >
> > > > I'm running FreeBSD 7.0 RC1 with the following in my kernel
> configuration:
> > > > ---
> > > > device sound
> > > > device snd_emu10kx
> > > > ---
> > > > My soundcard is a Soundblaster Live!
> > > >
> > > > In trying to make the rear-channel volume default to "100" I added the
> > > > following to my /boot/device.hints:
> > > > ---
> > > > hint.pcm.1.vol="100"
> > > > hint.pcm.1.pcm="100"
> > > > ---
> > > > This method is suggested on page 164 (section 7.2.4) of the Handbook.
> > > >
> > > > The problem is that these mixer levels do not apply:
> > > > ---
> > > > $ mixer -f /dev/mixer1
> > > > Mixer vol is currently set to 75:75
> > > > Mixer pcm is currently set to 75:75
> > > > ---
> > > > There is no problem however in manualy settig these values.
> > > >
> > > > Any help is welcome. My machine can - may it be needed - be used as a
> testbase.
> > >
> > > Hmm, probably /etc/rc.d/mixer is overriding the tunables as it is
> restoring the settings
> > > to those from the previous boot. You can disable the mixer script
> perhaps.
> > >
> > > --
> > > John Baldwin
> > >
> >
> > Like I said; initialy I had the script disabled.
> > Can someone please test de kernel tunables (hints) on his/her machine?
>
> Err, I don't see anywhere in your message where you disabled it. You would
> need to add 'mixer_enable="NO"' to /etc/rc.conf. The hints are honored in
> the mixer_init() function in sys/dev/sound/pcm/mixer.c here:
>
> for (i = 0; i < SOUND_MIXER_NRDEVICES; i++) {
> v = snd_mixerdefaults[i];
>
> if (resource_int_value(device_get_name(dev),
> device_get_unit(dev), snd_mixernames[i], &val) == 0) {
> if (val >= 0 && val <= 100) {
> v = (u_int16_t) val;
> }
> }
>
> mixer_set(m, i, v | (v << 8));
> }
>
> --
> John Baldwin
>
My sincere apologies. The thread had evolved a bit further on the
multimedia list. That is where I stated I initialy did not use the
mixer script.
As to the initial problem: forgive me being extremely stubborn. In my
ignorance I though not having any references to the mixer script in my
rc.conf meant I was not using it. I looked over a line in the defaults
though...
Setting the suggested 'mixer_enable="NO"' in /etc/rc.conf *does* make
the hints work.
Thanks to everybody,
- Jouke
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: overheating Thinkpad X60s with 7.0-RC1
Thanks for that reply! :-) On 1/7/08, Alexandre Sunny Kovalenko <[EMAIL PROTECTED]> wrote: > > > > First -- the disclaimer -- mine is X60 (not X60s), but with 1.83GHz > 32-bit CPU, so it should be somewhat similar to yours. At the moment it > has USB drivers loaded, which tends to bump CPU utilization and > temperature. It has UltraBase attached and is sitting on top of the > aluminum passive cooler pad. I guess the two should be rather similar. May I ask what you mean with "aluminum passive cooler pad"? Is that located underneath your UltraBase? If yes, does it help? Mine does not get that hot there. > > I does look shade cooler then yours, and fan is running at the lower > speed. An that is what makes me wonder... I will try to list things that I do/have done, and you can compare them > to your setup: > -- BIOS is updated to the latest level (I do keep XP partition for this > specific purpose). That is not the case with mine because of the lack of a XP partition. Do you have any idea whether these FreeDOS BIOS-flash mechanisms are working? -- I run powerd: > powerd_enable="YES" Yes. powerd_flags="-a adaptive -b adaptive -i 75 -r 65" The later one (-i 75 -r 65) I've added now. -- I set hw.pci.do_power_nodriver="3" in /boot/loader.conf Done that too. -- I run GNOME (please, no religious wars here) No religious wars needed, I hope. ;-) -- I set low CPU state to C2 in rc.conf > performance_cx_lowest="C2"# Online CPU idle state > economy_cx_lowest="C2" # Offline CPU idle state Done. Concerning the later cpufreq discussion: done that too. So far so good. The cpufreq module gives module_register: module pci/ichss_pci already exists! Module pci/ichss_pci failed to register: 17 module_register: module cpu/ichss already exists! Module cpu/ichss failed to register: 17 module_register: module cpu/est already exists! Module cpu/est failed to register: 17 module_register: module cpu/p4tcc already exists! Module cpu/p4tcc failed to register: 17 module_register: module cpu/powernow already exists! Module cpu/powernow failed to register: 17 module_register: module cpu/smist already exists! Module cpu/smist failed to register: 17 in the booting process. Then portupgrade gcc and trying to trace it with dev.acpi_ibm: dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1443 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 9 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 3450 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 57 56 -1 54 37 -1 32 -1 when it started. Rather healthy although the fan is rather high. dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1443 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 9 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4081 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 81 57 -1 79 37 -1 32 -1 some ten minutes later. dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1443 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 9 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4709 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 87 57 -1 85 37 -1 32 -1 again ten minutes more. dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1443 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 9 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4675 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 88
Interspersed logging output and workarounds
Hi, I'm running 7-PRERELEASE on amd64, and have the problem of interspersed logging output, eg: Jan 8 09:40:55 osiris kernel: <<11101>0>iippfw:f w: 3830080 0D eDneyny UUDDPP 11929.21.681.61.81.0:15.35130 2:254.305.03. 25212:543.530 .0o.u2t5 1:vi5a 3x5l3 0i A search on the list archives suggests that setting PRINTF_BUFR_SIZE=128 could possibly solve the problem, but my very simple kernel config file of: include GENERIC ident OSIRIS options PRINTF_BUFR_SIZE=128 doesn't appear to solve the problem. Any other suggestions welcome (or has a fix been implemented, and I just need to wait for it to be MFC'd?). Cheers. -- Jonathan Chen <[EMAIL PROTECTED]> -- "Only the meek get pinched. The bold survive." - Ferris Bueller ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sun Fire X2100 SATA problem [was - sun x2100 gmirror problem]
Miroslav Lachman wrote: [EMAIL PROTECTED] wrote: Hi, We're using gmirror on our sun fire x2100 and FreeBSD 6.1-p10. Some days ago I found this in the logs: Apr 1 02:12:05 x2100 kernel: ad6: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=612960533 Apr 1 02:12:05 x2100 kernel: ad6: FAILURE - WRITE_DMA48 status=51 error=10 LBA=612960533 Apr 1 02:12:05 x2100 kernel: GEOM_MIRROR: Request failed (error=5). ad6[WRITE(offset=313835792896, length=4096)] Apr 1 02:12:05 x2100 kernel: GEOM_MIRROR: Device gm0: provider ad6 disconnected. Normally it looks like a disk error, but I think our half year old disks (WD RE2) shouldn't fail after this short time. Of course they have moving parts so they MAY fail. :( Yesterday I tried to reinit the sata channel and insert the disk back into the mirror. I got this: Apr 3 23:00:32 x2100 kernel: GEOM_MIRROR: Device gm0: provider ad6 detected. Apr 3 23:00:32 x2100 kernel: GEOM_MIRROR: Device gm0: rebuilding provider ad6. Apr 3 23:00:36 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=245760 Apr 3 23:00:38 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=392576 Apr 3 23:00:38 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=392960 Apr 3 23:00:53 x2100 kernel: ad6: FAILURE - device detached After this, the disk disappeared from the sata channel completely. The wierd is that we used the onboard nvidia-raid and the very same error occured, but there was no report in the kernel the machine just don't asked for operating system. Later I found out that the disk was forgotten ~2 weeks before that reboot (data was ~2 week old on it). Otherwise that "forgotten/failed" disk was also half year old and was fine without a problem. Is there anybody who experienced something similar with SUN X2100 or any other servers running FreeBSD 6 and sata? Regards, Andras Hi, I can confirm your problem. I have same problem on one X2100 but not on the others. Currenty I have 4 X2100 machines, but only one with this strange problem. The problem is not caused by HDD it self, I tried to replace it with brand new and same error appears after few days. May be there are some problems with cables / connectors or something on mainboard. I am well known by problems with SATA(n) disk drives problems / disappearing on this list and local (czech) mailing list. I had similar problems on ASUS boards with Intel chipsets... so in my point of view - there is something bad with SATA in general. I never had problem like this with old good ATA drives. I have not solution for this problem. Disk is OK after reboot for a few dasy or weeks... if there is somebody which can help with investigating this kind of problem, I'll be happy to cooperate. output of dmesg, smartctl, gmirror etc.: http://www.quip.cz/1/freebsd/sata-hdd-problems/2007-03-07_errors_ad6.txt Miroslav Lachman Just for the record - mine problem was fixed by SATA cable replacement. Machine has uptime 227 days and no more disk errors. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: overheating Thinkpad X60s with 7.0-RC1
On Mon, 2008-01-07 at 21:42 +0100, Johannes Dieterich wrote: > Thanks for that reply! :-) > > On 1/7/08, Alexandre Sunny Kovalenko <[EMAIL PROTECTED]> wrote: > > > > > > > > First -- the disclaimer -- mine is X60 (not X60s), but with 1.83GHz > > 32-bit CPU, so it should be somewhat similar to yours. At the moment it > > has USB drivers loaded, which tends to bump CPU utilization and > > temperature. It has UltraBase attached and is sitting on top of the > > aluminum passive cooler pad. > > I guess the two should be rather similar. May I ask what you mean with > "aluminum passive cooler pad"? Is that located underneath your UltraBase? If > yes, does it help? Mine does not get that hot there. Chunk of aluminum with two dead fans inside -- used to be "active cooler pad" when fans were alive ;) I use second HD in the UltraBase every now and again and it gets warm. > > > > > > I does look shade cooler then yours, and fan is running at the lower > > speed. > > An that is what makes me wonder... > > > I will try to list things that I do/have done, and you can compare them > > to your setup: > > -- BIOS is updated to the latest level (I do keep XP partition for this > > specific purpose). > > That is not the case with mine because of the lack of a XP partition. Do you > have any idea whether these FreeDOS BIOS-flash mechanisms are working? On my 42p (work machine), I normally use USB floppy with FreeDOS to flash the BIOS -- IBM^H^H^HLenovo usually distributes two BIOS updates -- you want one marked as the "floppy version". I think if you look through the mail archives, you should be able to find suggestion on making bootable CD, if USB floppy is out of reach. > -- I set low CPU state to C2 in rc.conf > > performance_cx_lowest="C2"# Online CPU idle state > > economy_cx_lowest="C2" # Offline CPU idle state > > Done. Ahem... if "LOW" there does not render your machine unusable, it is even better. > > Concerning the later cpufreq discussion: done that too. So far so good. The > cpufreq module gives > > module_register: module pci/ichss_pci already exists! > Module pci/ichss_pci failed to register: 17 > module_register: module cpu/ichss already exists! > Module cpu/ichss failed to register: 17 > module_register: module cpu/est already exists! > Module cpu/est failed to register: 17 > module_register: module cpu/p4tcc already exists! > Module cpu/p4tcc failed to register: 17 > module_register: module cpu/powernow already exists! > Module cpu/powernow failed to register: 17 > module_register: module cpu/smist already exists! > Module cpu/smist failed to register: 17 I guess, here might be another difference -- I load acpi as the module. If you think it will help, I can mail you my kernel config outside of the list. > > in the booting process. > > Then portupgrade gcc and trying to trace it with dev.acpi_ibm: > > dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras > dev.acpi_ibm.0.%driver: acpi_ibm > dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY > dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 > dev.acpi_ibm.0.%parent: acpi0 > dev.acpi_ibm.0.initialmask: 2060 > dev.acpi_ibm.0.availmask: 16777215 > dev.acpi_ibm.0.events: 0 > dev.acpi_ibm.0.eventmask: 2060 > dev.acpi_ibm.0.hotkey: 1443 > dev.acpi_ibm.0.lcd_brightness: 0 > dev.acpi_ibm.0.volume: 9 > dev.acpi_ibm.0.mute: 0 > dev.acpi_ibm.0.thinklight: 0 > dev.acpi_ibm.0.bluetooth: 0 > dev.acpi_ibm.0.wlan: 1 > dev.acpi_ibm.0.fan_speed: 3450 > dev.acpi_ibm.0.fan_level: 7 > dev.acpi_ibm.0.fan: 1 > dev.acpi_ibm.0.thermal: 57 56 -1 54 37 -1 32 -1 > > when it started. Rather healthy although the fan is rather high. > > dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras > dev.acpi_ibm.0.%driver: acpi_ibm > dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY > dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 > dev.acpi_ibm.0.%parent: acpi0 > dev.acpi_ibm.0.initialmask: 2060 > dev.acpi_ibm.0.availmask: 16777215 > dev.acpi_ibm.0.events: 0 > dev.acpi_ibm.0.eventmask: 2060 > dev.acpi_ibm.0.hotkey: 1443 > dev.acpi_ibm.0.lcd_brightness: 0 > dev.acpi_ibm.0.volume: 9 > dev.acpi_ibm.0.mute: 0 > dev.acpi_ibm.0.thinklight: 0 > dev.acpi_ibm.0.bluetooth: 0 > dev.acpi_ibm.0.wlan: 1 > dev.acpi_ibm.0.fan_speed: 4081 > dev.acpi_ibm.0.fan_level: 7 > dev.acpi_ibm.0.fan: 1 > dev.acpi_ibm.0.thermal: 81 57 -1 79 37 -1 32 -1 > > some ten minutes later. > > dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras > dev.acpi_ibm.0.%driver: acpi_ibm > dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY > dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 > dev.acpi_ibm.0.%parent: acpi0 > dev.acpi_ibm.0.initialmask: 2060 > dev.acpi_ibm.0.availmask: 16777215 > dev.acpi_ibm.0.events: 0 > dev.acpi_ibm.0.eventmask: 2060 > dev.acpi_ibm.0.hotkey: 1443 > dev.acpi_ibm.0.lcd_brightness: 0 > dev.acpi_ibm.0.volume: 9 > dev.acpi_ibm.0.mute: 0 > dev.acpi_ibm.0.thinklight: 0 > dev.acpi_ibm.0.bluetooth: 0 > dev.acpi_ibm.0.wlan: 1 > dev.acpi_ibm.0.fan_speed: 4709 > dev.acpi_ibm.0.fan_level: 7 > dev
Re: overheating Thinkpad X60s with 7.0-RC1
Alexandre "Sunny" Kovalenko wrote: On Sun, 2008-01-06 at 20:22 -0500, Nathan Lay wrote: Alexandre "Sunny" Kovalenko wrote: On Sun, 2008-01-06 at 23:58 +0100, Johannes Dieterich wrote: On 1/6/08, Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: On Sun, Jan 06, 2008 at 10:26:48PM +0100, Johannes Dieterich wrote: X and T series of the thinkpads are rather different, even the cores are completely different (I have a dualcore low-voltage version, I assume yours is running on a dual Pentium m, or?). FWIW, I haven't seen any temperature related issues on my ThinkPad X60s, which has been tracking -CURRENT for the last year or so. It too has had the IPW3945 replaced by an Atheros wireless card, but it is still using the original HDD. Can the HDD change already cause such a thing? Besides that: I have not configured anything myself concerning ACPI. Anyone any idea what/where/how to check? I DO think that the fan is working. I can hear it (and it does not sound ill) and it also shows in $ sysctl dev.acpi_ibm dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1443 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 9 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4071 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 62 61 -1 58 43 -1 40 -1 Now not being touched at all for an hour and just idling around. Besides it did work under 6.2 without problems, would be a crazy coincident if right with the update the fan broke. Any idea anyone? :S First -- the disclaimer -- mine is X60 (not X60s), but with 1.83GHz 32-bit CPU, so it should be somewhat similar to yours. At the moment it has USB drivers loaded, which tends to bump CPU utilization and temperature. It has UltraBase attached and is sitting on top of the aluminum passive cooler pad. It was bought originally with the Atheros card and 100GB drive and 1GB of memory was added later to the total of 2GB. System is -CURRENT as of January 5th 18:00 EST. This laptop was tracking -CURRENT pretty close since I have acquired it 15 month ago. It does buildwords with -j5 at least weekly. At the moment, I am writing this E-mail and playing some music, using Amarok. It is on the wired network ATM, but I do not recall any thermal problems while using wireless connection. dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 133 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 7 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 1 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 2874 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 62 52 -1 61 39 -1 37 -1 RabbitsDen# sysctl -a | grep temperature hw.acpi.thermal.tz0.temperature: 62.0C hw.acpi.thermal.tz1.temperature: 62.0C dev.cpu.0.temperature: 63 // You need coretemp.ko loaded dev.cpu.1.temperature: 63 // to get these values. RabbitsDen# I does look shade cooler then yours, and fan is running at the lower speed. I will try to list things that I do/have done, and you can compare them to your setup: -- BIOS is updated to the latest level (I do keep XP partition for this specific purpose). -- I run powerd: powerd_enable="YES" powerd_flags="-a adaptive -b adaptive -i 75 -r 65" -- I set hw.pci.do_power_nodriver="3" in /boot/loader.conf -- I run GNOME (please, no religious wars here) -- I set low CPU state to C2 in rc.conf performance_cx_lowest="C2"# Online CPU idle state economy_cx_lowest="C2" # Offline CPU idle state I could not think of anything else related to the temperature, ATM. Thanks, Johannes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" 62C looks awfully high for playing music and writing emails. I have a Thank you very much for pointing this out -- turns out that I was missing cpufreq module -- restoring that to its proper place got me down to: dev.acpi_ibm.0.fan_speed: 2866 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 53 54 -1 52 37 -1 34 -1 where it belongs. I don't think it will ever be as well c
Re: overheating Thinkpad X60s with 7.0-RC1
Alexandre "Sunny" Kovalenko wrote: On Mon, 2008-01-07 at 21:42 +0100, Johannes Dieterich wrote: Thanks for that reply! :-) On 1/7/08, Alexandre Sunny Kovalenko <[EMAIL PROTECTED]> wrote: First -- the disclaimer -- mine is X60 (not X60s), but with 1.83GHz 32-bit CPU, so it should be somewhat similar to yours. At the moment it has USB drivers loaded, which tends to bump CPU utilization and temperature. It has UltraBase attached and is sitting on top of the aluminum passive cooler pad. I guess the two should be rather similar. May I ask what you mean with "aluminum passive cooler pad"? Is that located underneath your UltraBase? If yes, does it help? Mine does not get that hot there. Chunk of aluminum with two dead fans inside -- used to be "active cooler pad" when fans were alive ;) I use second HD in the UltraBase every now and again and it gets warm. I does look shade cooler then yours, and fan is running at the lower speed. An that is what makes me wonder... I will try to list things that I do/have done, and you can compare them to your setup: -- BIOS is updated to the latest level (I do keep XP partition for this specific purpose). That is not the case with mine because of the lack of a XP partition. Do you have any idea whether these FreeDOS BIOS-flash mechanisms are working? On my 42p (work machine), I normally use USB floppy with FreeDOS to flash the BIOS -- IBM^H^H^HLenovo usually distributes two BIOS updates -- you want one marked as the "floppy version". I think if you look through the mail archives, you should be able to find suggestion on making bootable CD, if USB floppy is out of reach. -- I set low CPU state to C2 in rc.conf performance_cx_lowest="C2"# Online CPU idle state economy_cx_lowest="C2" # Offline CPU idle state Done. Ahem... if "LOW" there does not render your machine unusable, it is even better. Concerning the later cpufreq discussion: done that too. So far so good. The cpufreq module gives module_register: module pci/ichss_pci already exists! Module pci/ichss_pci failed to register: 17 module_register: module cpu/ichss already exists! Module cpu/ichss failed to register: 17 module_register: module cpu/est already exists! Module cpu/est failed to register: 17 module_register: module cpu/p4tcc already exists! Module cpu/p4tcc failed to register: 17 module_register: module cpu/powernow already exists! Module cpu/powernow failed to register: 17 module_register: module cpu/smist already exists! Module cpu/smist failed to register: 17 I guess, here might be another difference -- I load acpi as the module. If you think it will help, I can mail you my kernel config outside of the list. in the booting process. Then portupgrade gcc and trying to trace it with dev.acpi_ibm: dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1443 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 9 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 3450 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 57 56 -1 54 37 -1 32 -1 when it started. Rather healthy although the fan is rather high. dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1443 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 9 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4081 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 81 57 -1 79 37 -1 32 -1 some ten minutes later. dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1443 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 9 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4709 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 87 57 -1 85 37 -1 32 -1 again ten minutes more. dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acp
routing table and PPP
Hi all, I set up freebsd 7 b4 with ppp server for PPPoE incoming requests but i see a problem. When the user disconnect, the tunnel is closed but the route of his address is not removed from routing table, then, when we try to connect again with the same user (same address) the connection is refused. If i delete the route manually i have success. What do you think? Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RELENG7 using lpt causes panic
I've recently switched some of my home systems to RELENG7. All seemed fairly well until I tried printing a CUPS test page on my backup and print server to an elderly Laserjet IIIp, where I seem to have a reproducible panic. It has happened twice. This is painful, as I have a big home fileystem (striped over two mirrors over most of two 500 GB disks). The gmirror syncronisation and background fsck leave the system close to unusable for hours while they fight over the disks. I was somewhat startled that something so basic as printing causes a panic. There have been no hardware changes since I last printed under RELENG6, but I don't print often, so hardware decay is a possibility. Is this a known problem? If not, I'll take the time to try various tests (with /home unmounted) and raise a PR. I envisage tests such as: * Does switching to a kernel without SMP and apic make a difference? * Does direct output cause a crash? * Does polling make a difference? * Does the parallel port mode (I think extended at present) make a difference? Some detail below. Throwaway comment: On my workstation I find that a GENERIC - SMP - apic + SCHED_ULE kernel is MUCH more responsive during buildworld than a GENERIC kernel. console / dmesg === lpt0: [GIANT-LOCKED] lpt0: [ITHREAD] lpt0: [GIANT-LOCKED] lpt0: [ITHREAD] Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc0a5747b stack pointer = 0x28:0xe67ea968 frame pointer = 0x28:0xe67ea96c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = 1421 (parallel) trap number = 30 panic: reserved (unknown) fault cpuid = 0 Uptime: 23m3s Physical memory: 1011 MB Dumping 168 MB: 153 137 121 105 89 73 57 41 25 9 Dump complete Which? == RELENG7 cvsupped and built in the late evening of Sunday 06/01/07 [EMAIL PROTECTED] ~]# uname -a FreeBSD rottcodd.hanley.stade.co.uk 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: Sun Jan 6 23:33:45 GMT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 kgdb [EMAIL PROTECTED] ~]# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc0a5747b stack pointer = 0x28:0xe67ea968 frame pointer = 0x28:0xe67ea96c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = 1421 (parallel) trap number = 30 panic: reserved (unknown) fault cpuid = 0 Uptime: 23m3s Physical memory: 1011 MB Dumping 168 MB: 153 137 121 105 89 73 57 41 25 9 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xc0753f07 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc07541c9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a6737c in trap_fatal (frame=0xe67ea928, eva=0) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a6813d in trap (frame=0xe67ea928) at /usr/src/sys/i386/i386/trap.c:686 #5 0xc0a4df4b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc0a5747b in spinlock_exit () at cpufunc.h:365 #7 0xc0a53e20 in ioapic_program_intpin (intpin=0xc3f05d3c) at /usr/src/sys/i386/i386/io_apic.c:273 #8 0xc0a541b1 in ioapic_disable_intr (isrc=0xc3f05d3c) at /usr/src/sys/i386/i386/io_apic.c:375 #9 0xc0a530bc in intr_remove_handler (cookie=0xc47019c0) at /usr/src/sys/i386/i386/intr_machdep.c:208 #10 0xc0a5f1b1 in nexus_teardown_intr (dev=0xc3fc4a80, child=0xc4199980, r=0xc419d6c0, ih=0xc47019c0) at /usr/src/sys/i386/i386/nexus.c:498 #11 0xc0774942 in bus_generic_teardown_intr (dev=0xc3fc4180, child=0xc4199980, irq=0xc419d6c0, cookie=0xc47019c0) at bus_if.h:416 #12 0xc0774942 in bus_generic_teardown_intr (dev=0xc3f52d00, child=0xc4199980, irq=0xc419d6c0, cookie=0xc47019c0) at bus_if.h:416 #13 0xc0774942 in bus_generic_teardown_intr (dev=0xc403d600, child=0xc4199980, irq=0xc419d6c0, cookie=0xc47019c0) at bus_if.h:416 #14 0xc063653d in pci_teardown_intr (dev=0xc403d600, child=0xc4199980, irq=0xc419d6c0, cookie=0xc47019c0)
Re: RELENG7 using lpt causes panic
Adrian Wontroba wrote: > I've recently switched some of my home systems to RELENG7. > > All seemed fairly well until I tried printing a CUPS test page on my > backup and print server to an elderly Laserjet IIIp, where I seem to > have a reproducible panic. It has happened twice. This is painful, as > I have a big home fileystem (striped over two mirrors over most of two > 500 GB disks). The gmirror syncronisation and background fsck leave the > system close to unusable for hours while they fight over the disks. > > I was somewhat startled that something so basic as printing causes a > panic. There have been no hardware changes since I last printed under > RELENG6, but I don't print often, so hardware decay is a possibility. > > Is this a known problem? If not, I'll take the time to try various tests > (with /home unmounted) and raise a PR. > > I envisage tests such as: > * Does switching to a kernel without SMP and apic make a difference? > * Does direct output cause a crash? > * Does polling make a difference? > * Does the parallel port mode (I think extended at present) make a > difference? > > Some detail below. > > Throwaway comment: On my workstation I find that a GENERIC - SMP - apic > + SCHED_ULE kernel is MUCH more responsive during buildworld than a > GENERIC kernel. > > console / dmesg > === > > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > Fatal trap 30: reserved (unknown) fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc0a5747b > stack pointer = 0x28:0xe67ea968 > frame pointer = 0x28:0xe67ea96c > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, IOPL = 0 > current process = 1421 (parallel) > trap number = 30 > panic: reserved (unknown) fault > cpuid = 0 > Uptime: 23m3s > Physical memory: 1011 MB > Dumping 168 MB: 153 137 121 105 89 73 57 41 25 9 > Dump complete > > Which? > == > > RELENG7 cvsupped and built in the late evening of Sunday 06/01/07 > > [EMAIL PROTECTED] ~]# uname -a > FreeBSD rottcodd.hanley.stade.co.uk 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: > Sun Jan 6 23:33:45 GMT 2008 [EMAIL > PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 > > kgdb > > > [EMAIL PROTECTED] ~]# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: > Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > > > Fatal trap 30: reserved (unknown) fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc0a5747b > stack pointer = 0x28:0xe67ea968 > frame pointer = 0x28:0xe67ea96c > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, IOPL = 0 > current process = 1421 (parallel) > trap number = 30 > panic: reserved (unknown) fault > cpuid = 0 > Uptime: 23m3s > Physical memory: 1011 MB > Dumping 168 MB: 153 137 121 105 89 73 57 41 25 9 > > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump () at pcpu.h:195 > #1 0xc0753f07 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc07541c9 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc0a6737c in trap_fatal (frame=0xe67ea928, eva=0) at > /usr/src/sys/i386/i386/trap.c:899 > #4 0xc0a6813d in trap (frame=0xe67ea928) at /usr/src/sys/i386/i386/trap.c:686 > #5 0xc0a4df4b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #6 0xc0a5747b in spinlock_exit () at cpufunc.h:365 > #7 0xc0a53e20 in ioapic_program_intpin (intpin=0xc3f05d3c) at > /usr/src/sys/i386/i386/io_apic.c:273 > #8 0xc0a541b1 in ioapic_disable_intr (isrc=0xc3f05d3c) at > /usr/src/sys/i386/i386/io_apic.c:375 > #9 0xc0a530bc in intr_remove_handler (cookie=0xc47019c0) at > /usr/src/sys/i386/i386/intr_machdep.c:208 > #10 0xc0a5f1b1 in nexus_teardown_intr (dev=0xc3fc4a80, child=0xc4199980, > r=0xc419d6c0, ih=0xc47019c0) > at /usr/src/sys/i386/i386/nexus.c:498 > #11 0xc0774942 in bus_generic_teardown_intr (dev=0xc3fc4180, > child=0xc4199980, irq=0xc419d6c0, cookie=0xc47019c0) at bus_if.h:416 > #12 0xc0774942 in bus_generic_teardown_intr (dev=0xc3f52d00, > child=0xc4199980, irq=0xc419d6c0, cookie=
Re: RELENG7 using lpt causes panic
On Monday 07 January 2008 10:08:57 pm Adrian Wontroba wrote: > I've recently switched some of my home systems to RELENG7. > > All seemed fairly well until I tried printing a CUPS test page on my > backup and print server to an elderly Laserjet IIIp, where I seem to > have a reproducible panic. It has happened twice. This is painful, as > I have a big home fileystem (striped over two mirrors over most of two > 500 GB disks). The gmirror syncronisation and background fsck leave the > system close to unusable for hours while they fight over the disks. > > I was somewhat startled that something so basic as printing causes a > panic. There have been no hardware changes since I last printed under > RELENG6, but I don't print often, so hardware decay is a possibility. > > Is this a known problem? If not, I'll take the time to try various tests > (with /home unmounted) and raise a PR. > > I envisage tests such as: > * Does switching to a kernel without SMP and apic make a difference? > * Does direct output cause a crash? > * Does polling make a difference? > * Does the parallel port mode (I think extended at present) make a > difference? > > Some detail below. This is a known issue and it has to do with some changes in the interrupt code in 7.x that interact badly with the lpt(4) driver (which tears down its interrupt handler and sets it back up again for each character, and the panic you see is because an interrupt came when it wasn't expecting it). The lpt(4) driver does this weird dance to allow coexisting with vpo so you can have lpd running and unplug your printer and plug up a Zip drive w/o having to stop lpd. I think the way I want to fix it is to change the lpt driver to not release the bus (and thus remove its interrupt handler) for every char but to keep the bus while /dev/lpt0 is open (which would be all the time with lpd running). -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG7 using lpt causes panic
On Tue, Jan 08, 2008 at 03:08:57AM +, Adrian Wontroba wrote: > I've recently switched some of my home systems to RELENG7. > > All seemed fairly well until I tried printing a CUPS test page on my > backup and print server to an elderly Laserjet IIIp, where I seem to > have a reproducible panic. It has happened twice. This is painful, as > I have a big home fileystem (striped over two mirrors over most of two > 500 GB disks). The gmirror syncronisation and background fsck leave the > system close to unusable for hours while they fight over the disks. > > I was somewhat startled that something so basic as printing causes a > panic. There have been no hardware changes since I last printed under > RELENG6, but I don't print often, so hardware decay is a possibility. > > Is this a known problem? If not, I'll take the time to try various tests > (with /home unmounted) and raise a PR. There is a PR about this problem with workaround: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117973 Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
