Re: Powerd and est / eist functionality
At 05:42 PM 3/27/2010, Jeremy Chadwick wrote:
>On Sat, Mar 27, 2010 at 04:51:49PM -0700, John Long wrote:
>> At 02:14 AM 3/26/2010, Jeremy Chadwick wrote:
>> % dmesg | grep -i smbus
>> pci0: at device 31.3 (no driver attached)
>
>All this means is that there's a SMBus-class device sitting on the PCI
>bus which has no driver attached to it. Run "pciconf -lvc" and find the
>device in question, and the output relevant to it.
no...@pci0:0:31:3: class=0x0c0500 card=0x50011458 chip=0x27da8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) SMBus Controller'
class = serial bus
subclass = SMBus
put this in
# Intel Core/Core2Duo CPU temperature monitoring driver
device coretemp
# SMBus support, needed for bsdhwmon
device smbus
device smb
device ichsmb
now get this
ichs...@pci0:0:31:3:class=0x0c0500 card=0x50011458 chip=0x27da8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) SMBus Controller'
class = serial bus
subclass = SMBus
%smbmsg -p
Probing for devices on /dev/smb0:
Device @0x10: w
Does not look to be much there if I am doing this right..
>Given the topic of discussion, I'd say your northbridge is Intel-based,
>which means you need the smb, smbus, and ichsmb drivers loaded. You can
>load these as kernel modules as well. When loading them, do not specify
>the trailing ".ko". See the ichsmb(4) man page for some terse details.
>
>Even if you get a driver attached to the SMBus piece of the northbridge,
>like I said, there's no guarantee there's a H/W monitoring IC that's
>wired to the SMBus. As stated, I don't believe in probing slave
>addresses on the SMBus, so the slave address would have to come from
>Gigabyte, or...
>
>There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which
>does do probing and can/does support SMBus. I have no idea if it works
>on Windows 7 or not:
>
>http://www.almico.com/speedfan.php
>
>If SpeedFan shows you all the data you expect/want, and indicates it's
>talking to a H/W IC over SMBus, then I could add support for your board
>to bsdhwmon (since your motherboard does provide acceptable SMBIOS
>tables for identification). I'd still need to know what slave address
>the chip had, and what exact model of H/W IC it was. SpeedFan might
>provide that.
I have a feeling that my smbus is just not hooked up, nothing there..
speedfan looks cool tho.
>
>It would also help (me at least) if you could reboot your system, go
>into your BIOS and find whatever menu item is associated with Hardware
>Monitoring and write down all of the shown attributes and their values.
>What the BIOS shows is what should be accurate above all else.
>I can point you to numerous present-day motherboards that work just fine
>with cpufreq(4) and est under RELENG_8, and also work when using
>acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2
>boards. I'm sure there are many others. In all of these are Core2Duo
>or Core2Quad CPUs. An example from the X7SBA system, running powerd:
It looks good, all working..
>
>I should note that the device attachment error (error 6) is something
>I've seen on my PDSMi+ boards under RELENG_7 when EIST and C1 Enhanced
>Mode were disabled in the BIOS. FreeBSD would report that SpeedStep
>existed but that it wasn't able to attach.
>
>I *explicitly* disabled those features in the BIOS since I saw some
>bizarre process behaviour ("calcru: runtime went backwards ... for pid
>X").
Have you tried to measure the wall power with a kill-a-watt yet or can you?
I am curious that things are actually working and tdp goes down when powerd
is running vs not.
About 20.00 - lowes, costco
etc http://www.google.com/search?q=kill-a-watt very handy to check
everything out. My system takes about 15 secs to lower freq to min and the
power goes up a watt each 5 secs or so. Yes, it looks like it is working
but the power meter tells the truth.
John
>--
>| Jeremy Chadwick j...@parodius.com |
>| Parodius Networking http://www.parodius.com/ |
>| UNIX Systems Administrator Mountain View, CA, USA |
>| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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"
Fwd: random FreeBSD panics
-- Forwarded message -- From: Masoom Shaikh Date: Sun, Mar 28, 2010 at 8:28 AM Subject: random FreeBSD panics To: freebsd-hack...@freebsd.org, freebsd-questions Hello List, I was a happy FreeBSD user, just before I installed FreeBSD8.0-RC1. Since then, system randomly just freezes, and there is no option other than hard boot. I guessed this will get solved in 8.0-RELEASE, but it was not :( Many times I get vmcore files, not always. I have dumpdev set to AUTO in my rc.conf. Almost every time it just fsck's the file-system on reboot. I have not lost any files though. This is a Dell Inspiron 1525 Laptop with 1GB ram, Intel Core2 Duo T5500 with ATI Radeon X1400 card. The installation in question is KDE4 from ports, with radeon/ati driver. I felt the problem is with wpi driver, then suspected dri driver of X. Then I observed system freezes even if none of this is installed. e.g. if it is under some load, like building a port and simultaneously fetching something over network it hangs, and hangs hard. This persuaded me to think something is wrong in kernel scheduling itself. May be it is lost in some deadlock, etc... Thus last weekend I thought I would see how immediate previous version i.e. FreeBSD-7.3-RELEASE would behave. I reinstalled FreeBSD7.1 from iso images, svn up'ed FreeBSD7.3 source, did the normal buildworld, buildkernel, installkernel, installworld cycle. Unfortunatly this kernel is naughty as well ;-), it also freezes with same stubbornness. But difference is this time I happen to catch something interesting. It panics on NMI, fatal trap 19 while in kernel mode. Loaded the vmcore file in kgdb and got the backtrace. I obtained vmcore files on two occasions. I have attached both the back traces. This error most likely suggests hardware error in RAM, but Windox7 and XP boot just fine and never caused any errors. To verify if I have errors in my RAM I let run sysutils/memtest86+ overnight, to double verify I also executed Windows Memory Diagnostic test for four times. None of them reported errors. Can anyone here suggest any solution. Masoom Shaikh forwarding to stable@ with respect to a generous suggestion vmcore0.log Description: Binary data vmcore1.log Description: Binary data ___ 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: NFS lockd problem
On Sat, 27 Mar 2010 20:50:17 +0200, Chuck Swiger wrote: On Mar 26, 2010, at 3:08 AM, Giulio Ferro wrote: Outset: 1 NFS server (with lockd) 2 NFS client (with lockd) The clients serve several jails with apache, whose data (www) resides on the server If you need file locking to work reliably, you pretty much have to give up on using NFS + rpc.lockd and run against a local UFS filesystem. I don't have this experience. I use NFS locking between FreeBSD, Linux, NetApp and SUN stuff. Older versions of FreeBSD had some troubles, but more recent ones work very well. Ronald. ___ 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: NFS lockd problem
On Fri, 26 Mar 2010 12:08:26 +0200, Giulio Ferro wrote: Outset: 1 NFS server (with lockd) 2 NFS client (with lockd) The clients serve several jails with apache, whose data (www) resides on the server From time to time everything seem to freeze. Then, after one minute or so, the system works again as nothing had happened. In these occasions I get this in the logs on the client madchines: Mar 26 10:29:38 virt1 kernel: nfs server 192.168.40.121:/data/mount_servers/wwwsec/www: lockd not responding followed shortly after by: Mar 26 10:29:38 virt1 kernel: nfs server 192.168.40.121:/data/mount_servers/wwwsec/www: lockd is alive again On the server I only get this: Mar 26 10:29:31 data1 kernel: NLM: failed to contact remote rpcbind, stat = 5, port = 28416 I don't think it's a network problem, since all connections are local and high speed (1Gb/s) I must admit that, with the other nfs problem I reported weeks ago, this kind of freebsd system seems less than stable to me, and this is very disappointing... Anyway I'd appreciate any pointer on this issue... I'm no NFS expert, so I don't know if I can help, but regularly people want to know your FreeBSD version(s), your used NFS version, if you are running NFS over TCP or UDP. Does it help to switch between UDP/TCP? Ronald. ___ 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"
[ HEADS UP ] Ports unstable for the next 10 days
Hi, As announced before, a few big commits, that touch some thousands ports are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 April. The first one was done, update of graphics/png (including a shared lib version bump), with about 5000 ports affected. We do _NOT_ recommend updating ports until this commits are all done, and the problems are fixed, except if you want to help testing / fixing. Before reporting failures, please take a look at ports@ list, and http://qat.tecnik93.com/index.php?action=failed_buildports&sort=last_built to find out if the problem hasn't already been reported or even fixed. We also have two incremental builds on Pointy to catch the problems. Thank you, With hat: portmgr@ -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: random FreeBSD panics
On Sun, Mar 28, 2010 at 12:03 PM, Ivan Voras wrote: > On 28 March 2010 13:18, Masoom Shaikh wrote: >> On Sun, Mar 28, 2010 at 10:32 AM, Ivan Voras wrote: >>> Masoom Shaikh wrote: Hello List, I was a happy FreeBSD user, just before I installed FreeBSD8.0-RC1. Since then, system randomly just freezes, and there is no option other than hard boot. I guessed this will get solved in 8.0-RELEASE, but it was not :( >>> >>> I wild shot - did you try disabling superpages? >> >> umm, how do I do that ? > > Set > > vm.pmap.pg_ps_enabled=0 > > in /boot/loader.conf and reboot. Report back if it helps or not. > nopes, this didn't help too, machine freezed again after using for 30 minutes or so all it was doing is playing amarok, fetching sources from svn repos, and using firefox lets assume if this is h/w problem, then how can other OSes overcome this ? is there a way to make FreeBSD ignore this as well, let it result in reasonable performance penalty. ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On 3/28/10 3:38 PM, Ion-Mihai Tetcu wrote: > Hi, > > > As announced before, a few big commits, that touch some thousands ports > are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 > April. > > The first one was done, update of graphics/png (including a shared lib > version bump), with about 5000 ports affected. > > We do _NOT_ recommend updating ports until this commits are all done, > and the problems are fixed, except if you want to help testing / fixing. What does that mean, the first one was done? The port was updated before this warning? I have updated png this morning, will I now be negatively affected? Thanks, Tobias ___ 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: random FreeBSD panics
On Sun, Mar 28, 2010 at 8:42 AM, Masoom Shaikh wrote: > nopes, this didn't help too, machine freezed again after using for 30 > minutes or so > all it was doing is playing amarok, fetching sources from svn repos, > and using firefox > > lets assume if this is h/w problem, then how can other OSes overcome > this ? is there a way to make FreeBSD ignore this as well, let it > result in reasonable performance penalty. > They would remove or replace the bad hardware. I've seen more that one DIMM which passed every memory checker I could find in it's most extensive testing mode. Only consistently effective option is to replace with a known good piece of memory. -- Adam Vande More ___ 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: random FreeBSD panics
On 28 March 2010 16:42, Masoom Shaikh wrote: > lets assume if this is h/w problem, then how can other OSes overcome > this ? is there a way to make FreeBSD ignore this as well, let it > result in reasonable performance penalty. Very probably, if only we could detect where the problem is. Try adding "options PRINTF_BUFR_SIZE=128" to the kernel configuration file if you can, to see if you can get a less mangled log outout. ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On Sun, 28 Mar 2010 17:56:34 +0200 Tobias Roth wrote: > On 3/28/10 3:38 PM, Ion-Mihai Tetcu wrote: > > Hi, > > > > > > As announced before, a few big commits, that touch some thousands > > ports are being done: png, curl, x11, gnome, kde4. The target ETA > > is 6-7 April. > > > > The first one was done, update of graphics/png (including a shared > > lib version bump), with about 5000 ports affected. > > > > We do _NOT_ recommend updating ports until this commits are all > > done, and the problems are fixed, except if you want to help > > testing / fixing. > > > What does that mean, the first one was done? The port was updated > before this warning? > > I have updated png this morning, will I now be negatively affected? PNG update was committed this morning at 06:47:48 UTC. If you have updated png (not just csup your ports tree) then you'll probably have to update the rest of your ports, since they won't find the old png shared lib. (you could try to map the new lib to the old one, it might or not work) -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
USB UPS detached and cannot reattach ("could not allocate new device")
Hello, On my 8.0-RELEASE machine running GENERIC this happened this afternoon: Mar 28 17:48:13 yomi apcupsd[969]: UPS Self Test switch to battery. Mar 28 17:48:17 yomi kernel: ugen0.2: at usbus0 (disconnected) Mar 28 17:48:18 yomi kernel: usb_alloc_device:1586: set address 2 failed (USB_ERR_STALLED, ignored) Mar 28 17:48:18 yomi kernel: usb_alloc_device:1624: getting device descriptor at addr 2 failed, USB_ERR_STALLED! Mar 28 17:48:19 yomi kernel: usbd_req_re_enumerate:1539: addr=2, set address failed! (USB_ERR_STALLED, ignored) Mar 28 17:48:19 yomi kernel: usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_STALLED! Mar 28 17:48:20 yomi kernel: usbd_req_re_enumerate:1539: addr=2, set address failed! (USB_ERR_STALLED, ignored) Mar 28 17:48:20 yomi kernel: usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_STALLED! Mar 28 17:48:20 yomi kernel: ugen0.2: <(null)> at usbus0 (disconnected) Mar 28 17:48:20 yomi kernel: uhub_reattach_port:435: could not allocate new device! Mar 28 17:48:27 yomi apcupsd[969]: Communications with UPS lost. Unplugging the UPS and replugging it doesn't seem to help, even in a different port. My UPS is a Smart-UPS 750 and my apcupsd is "3.14.5 (10 January 2009) freebsd". ugen0.1: at usbus0, cfg=255 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON dev.usbus.0.%desc: VIA 83C572 USB controller dev.usbus.1.%desc: VIA 83C572 USB controller I'm happy to provide more info if someone sufficiently clueful can tell me where to look :) Thanks, James ___ 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 and est / eist functionality
On Sun, Mar 28, 2010 at 12:16:27AM -0700, John Long wrote:
> At 05:42 PM 3/27/2010, Jeremy Chadwick wrote:
>
> put this in
> # Intel Core/Core2Duo CPU temperature monitoring driver
> device coretemp
coretemp(4) will get you the temperatures of each processor core,
provided via the dev.cpu.X.temperature sysctls.
> %smbmsg -p
> Probing for devices on /dev/smb0:
> Device @0x10: w
>
> Does not look to be much there if I am doing this right..
smbmsg -p won't help here -- I've never seen it detect H/W ICs that sit
on SMBus. In fact, on all my systems, it doesn't report anything exists
on the slave address tied to the boards' Winbond chips. I have no idea
what "probe modus" means (see smbmsg(8) man page) nor how the probe
actually works behind the scenes.
So, it's an ineffective way to get an answer to your dilemma. It would
make more sense to run SpeedFan on Windows, see if it's able to find a
chip via SMBus, and provide those details.
Another alternative would be to try using lm-sensors on Linux, although
I'm pretty sure lm-sensors prefers LPC/ISA mode (claiming "it's more
stable and more reliable" -- whatever). I have no experience with this
software, aside from occasionally having to dig through their spaghetti
code to try and find details about chip quirks.
> >There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which
> >does do probing and can/does support SMBus. I have no idea if it works
> >on Windows 7 or not:
> >
> >http://www.almico.com/speedfan.php
> >
> >If SpeedFan shows you all the data you expect/want, and indicates it's
> >talking to a H/W IC over SMBus, then I could add support for your board
> >to bsdhwmon (since your motherboard does provide acceptable SMBIOS
> >tables for identification). I'd still need to know what slave address
> >the chip had, and what exact model of H/W IC it was. SpeedFan might
> >provide that.
>
> I have a feeling that my smbus is just not hooked up, nothing
> there.. speedfan looks cool tho.
I don't know what you mean by "my smbus is just not hooked up". Your
above 'device' additions to your kernel shows that FreeBSD is now able
to talk to the SMBus interface on your northbridge. As stated, smbmsg
isn't going to help determine what H/W IC is on your board (if any).
I'll see if I can find a very high resolution photo of your motherboard
and try to work out if any ASICs are used for H/W monitoring (these days
such chips also often provide Super I/O support (floppy, LPT, COM,
LPC/ISA, etc.)). I'll probably have to review the user manual.
I'll report back once I do that.
> >It would also help (me at least) if you could reboot your system, go
> >into your BIOS and find whatever menu item is associated with Hardware
> >Monitoring and write down all of the shown attributes and their values.
> >What the BIOS shows is what should be accurate above all else.
>
> >I can point you to numerous present-day motherboards that work just fine
> >with cpufreq(4) and est under RELENG_8, and also work when using
> >acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2
> >boards. I'm sure there are many others. In all of these are Core2Duo
> >or Core2Quad CPUs. An example from the X7SBA system, running powerd:
>
> It looks good, all working..
Okay, but that doesn't help me any. :-) Can you please write down all
the H/W monitoring attributes + values shown in the BIOS and provide
them here?
> >I should note that the device attachment error (error 6) is something
> >I've seen on my PDSMi+ boards under RELENG_7 when EIST and C1 Enhanced
> >Mode were disabled in the BIOS. FreeBSD would report that SpeedStep
> >existed but that it wasn't able to attach.
> >
> >I *explicitly* disabled those features in the BIOS since I saw some
> >bizarre process behaviour ("calcru: runtime went backwards ... for pid
> >X").
>
> Have you tried to measure the wall power with a kill-a-watt yet or
> can you?
I have a couple Kill-a-Watt devices, but I tend to not bother with them
for tests of this nature since they don't provide enough granularity on
the LCD (only 1 or 2 digits past the decimal point).
I also find them to be finicky/unreliable -- for example, I hooked a
residential home toaster up to a RackPDU (which provides amps and watts
used via web + SNMP). Powering on the toaster showed an increase from
0.00 amps to 1.1 amps. Hooking the same toaster up to 2 separate
Kill-a-Watt units returned the same result: 0.4 amps. I performed the
same tests with a standard household fan (3-speed), and I saw similar
readings (the Kill-a-Watt always appearing off by a pretty large
amount).
WRT all the systems I've applied cpufreq(4) + est + powerd to: they're
all production. I'm not willing to power them down, go to the co-lo,
hook up a Kill-a-Watt device, power them on, wait around for 30 minutes,
etc..
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Sy
Re: Powerd and est / eist functionality
On Sun, Mar 28, 2010 at 12:42:02PM -0700, Jeremy Chadwick wrote: > I'll see if I can find a very high resolution photo of your motherboard > and try to work out if any ASICs are used for H/W monitoring (these days > such chips also often provide Super I/O support (floppy, LPT, COM, > LPC/ISA, etc.)). I'll probably have to review the user manual. > > I'll report back once I do that. Success -- the Gigabyte GA-G41M-ES2L board uses an ITE IT8718 Super I/O chip, which also drives H/W monitoring support. Verified both visually and in the user manual. The official datasheets for the IT8718 are here: http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=5,68 Regardless of chip subrevision (J vs. K), neither supports SMBus; the chips appear to be entirely LPC/ISA-based. mbmon could be extended/enhanced to support this chip (mbmon -I would be required), but you'd still need to know what I/O ports are that Gigabyte tie to the chip. That's where Linux lm-sensors comes into play. Based on some Google results, the base I/O port is probably 0x290 (I'm assuming 0x290 = read, 0x291 = write) -- but I'm basing that on some ambiguous output here: http://lists.lm-sensors.org/pipermail/lm-sensors/2009-January/025222.html http://www.lm-sensors.org/wiki/Configurations/Gigabyte There's also this, which is pretty disheartening: http://lists.lm-sensors.org/pipermail/lm-sensors/2006-August/017423.html "The IT8718F also features VID inputs (up to 8 pins) but the value is stored in the Super-I/O configuration space. Due to technical limitations, this value can currently only be read once at initialization time, so the driver won't notice and report changes in the VID value. The two upper VID bits share their pins with voltage inputs (in5 and in6) so you can't have both on a given board." If someone feels like contacting the mbmon author to get this added, be my guest. Or if someone feels like adding it to mbmon, that's cool too. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On 29/03/10 12:38 AM, Ion-Mihai Tetcu wrote: The first one was done, update of graphics/png (including a shared lib version bump), with about 5000 ports affected. The UPDATING entry for the png update looks very wrong. Wrong date, wrong text, wrong instructions for portmaster. 20090328: AFFECTS: users of graphics/png AUTHOR: din...@freebsd.org The png library has been updated to version 1.4.1. Please rebuild all ports that depend on it. If you use portmaster: portmaster -r jpeg- If you use portupgrade: portupgrade -fr graphics/jpeg -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On Sun, Mar 28, 2010 at 6:04 PM, Aristedes Maniatis wrote: > On 29/03/10 12:38 AM, Ion-Mihai Tetcu wrote: >> >> The first one was done, update of graphics/png (including a shared lib >> version bump), with about 5000 ports affected. > > The UPDATING entry for the png update looks very wrong. Wrong date, wrong > text, wrong instructions for portmaster. > > > > 20090328: > AFFECTS: users of graphics/png > AUTHOR: din...@freebsd.org > > The png library has been updated to version 1.4.1. Please rebuild all > ports that depend on it. > > If you use portmaster: > > portmaster -r jpeg- > > If you use portupgrade: > > portupgrade -fr graphics/jpeg The text has been updated: 20100328: AFFECTS: users of graphics/png AUTHOR: din...@freebsd.org The png library has been updated to version 1.4.1. Please rebuild all ports that depend on it. If you use portmaster: portmaster -r png- If you use portupgrade: portupgrade -fr graphics/png Thanks, -Garrett ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On 29/03/10 1:15 PM, Garrett Cooper wrote: portmaster -r png- Is that correct? I haven't seen that notation before (although I might just have missed it in the docs). I would have used portmaster -r graphics/png Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On Sun, Mar 28, 2010 at 7:17 PM, Aristedes Maniatis wrote: > On 29/03/10 1:15 PM, Garrett Cooper wrote: >> >> portmaster -r png- > > Is that correct? I haven't seen that notation before (although I might just > have missed it in the docs). > > I would have used > > portmaster -r graphics/png And yes, the directions are still wrong; it should be: portmaster -r 'png-*' Similarly since this was just a copy-paste of the jpeg instructions, those ones are wrong as well. Thanks, -Garrett ___ 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"
