On Tuesday 18 January 2011 04:42:38 William Kenworthy wrote:
> On Mon, 2011-01-17 at 16:23 -0800, Grant wrote:
> And for those with gigabytes of swap, keep in mind that the majority of
> processors can only access up to 32 x 2G swapfiles under linux, so 4G is
> only going to be half used.
Unles
Apparently, though unproven, at 09:27 on Tuesday 18 January 2011, Mick did
opine thusly:
> BTW, it used to be that the kernel would not (easily?) access more than
> 128M of swap for some reason and multiple 128M swap partitions were more
> efficient than a single larger space, but this has proba
On Tue, 2011-01-18 at 07:27 +, Mick wrote:
> On Tuesday 18 January 2011 04:42:38 William Kenworthy wrote:
> > On Mon, 2011-01-17 at 16:23 -0800, Grant wrote:
>
> > And for those with gigabytes of swap, keep in mind that the majority of
> > processors can only access up to 32 x 2G swapfiles und
Am 18.01.2011 00:06, schrieb Stefan G. Weichinger:
> http://smartmontools.sourceforge.net/badblockhowto.html
>
> looks also worth reading
I had badblocks running over night, it told me that it found 33 bad blocks.
Reallocated_Sector_Ct, Current_Pending_Sector and Offline_Uncorrectable
incr
Am 18.01.2011 10:31, schrieb Stefan G. Weichinger:
> Am 18.01.2011 00:06, schrieb Stefan G. Weichinger:
>
>> http://smartmontools.sourceforge.net/badblockhowto.html
>>
>> looks also worth reading
>
> I had badblocks running over night, it told me that it found 33 bad blocks.
>
> Reallocated
Alan McKinnon writes:
> Apparently, though unproven, at 03:39 on Monday 17 January 2011, William
> Kenworthy did opine thusly:
>
>> On Sun, 2011-01-16 at 17:26 -0800, Mark Knecht wrote:
>> > On Sun, Jan 16, 2011 at 5:13 PM, William Kenworthy
> wrote:
>> > > On Sun, 2011-01-16 at 14:41 -0800, G
William Kenworthy writes:
> On Mon, 2011-01-17 at 16:23 -0800, Grant wrote:
>> > I think the idea is never use swap if possible, but in a case where
>> > you don't have swap space or run out of swap space I think it's still
>> > possible to lose data.
>>
>> Isn't swap just an extension of system
My last update bumped XFCE to 4.8, and I quickly learned that it's got
some serious bugs. So, I need to roll back to whatever the prevous
version was. How do I tell portage to not use 4.8?
I tried adding this line in /etc/portage/package.mask:
>=xfce-base/xfce4-meta-4.8
But that does nothing
On Tuesday 18 January 2011 10:45:37 Stefan G. Weichinger wrote:
> Am 18.01.2011 10:31, schrieb Stefan G. Weichinger:
> > Am 18.01.2011 00:06, schrieb Stefan G. Weichinger:
> >> http://smartmontools.sourceforge.net/badblockhowto.html
> >>
> >> looks also worth reading
> >
> > I had badblocks
Jason Weisberger writes:
> On Jan 17, 2011 4:15 PM, "Volker Armin Hemmann"
> wrote:
>> On Monday 17 January 2011 15:13:54 Jason Weisberger wrote:
>>>
>>> The update killed your free core :)
>>
>> a 'free core' that is probably broken in mysterious and hard to find but
>> nonetheless very dang
On 2011-01-18, Grant Edwards wrote:
> My last update bumped XFCE to 4.8, and I quickly learned that it's
> got some serious bugs. So, I need to roll back to whatever the
> prevous version was. How do I tell portage to not use 4.8?
>
> I tried adding this line in /etc/portage/package.mask:
>
>
On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy wrote:
> The bios microcode update is likely an enable setting rather than the
> bios actually updating the cpu. You need to do some reading/asking of
> the manufacturers (not here) if it bothers you.
Thanks for the links, I didn't realize they
On Tue, 18 Jan 2011 15:22:20 + (UTC), Grant Edwards wrote:
> But that does nothing. Do I have to individually mask all 20+
> components of XFCE?
Yes, but it's not difficult:
qlist -ICv xfce-base/ | sed 's/^/~/' >/etc/portage/package.mask/xfce-48
--
Neil Bothwick
mandelbug /man'del-buhg/
On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman
wrote:
> On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy
> wrote:
>> The bios microcode update is likely an enable setting rather than the
>> bios actually updating the cpu. You need to do some reading/asking of
>> the manufacturers (not here) i
btw, very related:
http://blog.flameeyes.eu/2011/01/17/microupdates-for-microcodes
Hi,
does anybody if it's safe to flash the BIOS using a DOS emulator like
app-emulation/dosemu ?
Thanks for sharing your experience,
Helmut.
On Tue, Jan 18, 2011 at 10:41 AM, Helmut Jarausch
wrote:
>
> Hi,
>
> does anybody if it's safe to flash the BIOS using a DOS emulator like
> app-emulation/dosemu ?
>
> Thanks for sharing your experience,
> Helmut.
I don't think it will work (unless you are flashing the emulated BIOS?)
On Tuesday 18 January 2011 17:41:52 Helmut Jarausch wrote:
> Hi,
>
> does anybody if it's safe to flash the BIOS using a DOS emulator like
> app-emulation/dosemu ?
>
> Thanks for sharing your experience,
> Helmut.
it is not considered safe. Get an usb stick with freedos or systemrescue cd or
us
On Tue, Jan 18, 2011 at 8:16 AM, Mark Knecht wrote:
> On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman
> wrote:
>> On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy
>> wrote:
>>> The bios microcode update is likely an enable setting rather than the
>>> bios actually updating the cpu. You need t
On Tuesday 18 January 2011 09:34:14 Mark Knecht wrote:
> On Tue, Jan 18, 2011 at 8:16 AM, Mark Knecht wrote:
> > On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman
> >
> > wrote:
> >> On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy
wrote:
> >>> The bios microcode update is likely an enable sett
On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht wrote:
> OK, I got it to load by hand:
>
> 1) emerge microcode-ctl
>
> which also emerges microcode-data. Unfortunately microcode-data looks
> to be out of date.
The ebuild for newer versions (including the latest 20101123) is in
portage as ~amd64 and
On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
wrote:
> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht wrote:
>> OK, I got it to load by hand:
>>
>> 1) emerge microcode-ctl
>>
>> which also emerges microcode-data. Unfortunately microcode-data looks
>> to be out of date.
>
> The ebuild for newer ver
On 2011-01-18, Neil Bothwick wrote:
> On Tue, 18 Jan 2011 15:22:20 + (UTC), Grant Edwards wrote:
>
>> But that does nothing. Do I have to individually mask all 20+
>> components of XFCE?
>
> Yes, but it's not difficult:
>
> qlist -ICv xfce-base/ | sed 's/^/~/' >/etc/portage/package.mask/xfce-
On 01/18/2011 06:41 PM, Helmut Jarausch wrote:
Hi,
does anybody if it's safe to flash the BIOS using a DOS emulator like
app-emulation/dosemu ?
It won't work. The flashing tools are designed to be run in real mode.
Dosemu runs in vm86 mode.
Your best bet is to get a bootable *.iso from t
i'm sorry,but chinese doc is different form english doc,
i read chinese doc and loss some step.
2011/1/16 Mick
> On Sunday 16 January 2011 13:53:14 doherty pete wrote:
> > how can i confim i have evdev,if i donn't have ,i think i have to edite
> > /etc/make.cof USE=-evdev -dri -dri2 or VIDEOCARD
On 2011-01-18 17:41, Helmut Jarausch wrote:
> does anybody if it's safe to flash the BIOS using a DOS emulator like
> app-emulation/dosemu ?
If you have a compatible board you could try flashrom. It's in portage
and the homepage is: http://www.flashrom.org/Flashrom
MfG
Peter K
On 1/17/2011 8:42 PM, William Kenworthy wrote:
No swap contains pages from memory that have not been accessed for
awhile so they can be stored elsewhere freeing ram for actual active
pages. When they need to be accessed, they have to be swapped back in,
and often something swapped back out to m
I've just installed & compiled gentoo-sources-2.6.37
& am getting msgs in all my terminals
Message from syslogd@localhost at Tue Jan 18 14:32:38 2011 ...
localhost kernel: [Hardware Error]: No human readable MCE decoding support on
this CPU type.
Message from syslogd@localhost at Tue Jan 18 1
On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht wrote:
> On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
> wrote:
>> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht wrote:
>>> OK, I got it to load by hand:
>>>
>>> 1) emerge microcode-ctl
>>>
>>> which also emerges microcode-data. Unfortunately microco
On Tue, Jan 18, 2011 at 1:53 PM, Philip Webb wrote:
> I've just installed & compiled gentoo-sources-2.6.37
> & am getting msgs in all my terminals
>
> Message from syslogd@localhost at Tue Jan 18 14:32:38 2011 ...
> localhost kernel: [Hardware Error]: No human readable MCE decoding support on
>
On Tue, Jan 18, 2011 at 2:51 PM, Paul Hartman
wrote:
> On Tue, Jan 18, 2011 at 1:53 PM, Philip Webb wrote:
>> I've just installed & compiled gentoo-sources-2.6.37
>> & am getting msgs in all my terminals
>>
>> Message from syslogd@localhost at Tue Jan 18 14:32:38 2011 ...
>> localhost kernel: [
On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote:
> On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht wrote:
> > On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
> >
> > wrote:
> >> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht
wrote:
> >>> OK, I got it to load by hand:
> >>>
> >>> 1) emerge m
On Tue, Jan 18, 2011 at 2:56 PM, Mick wrote:
> On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote:
>> On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht wrote:
>> > On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
>> >
>> > wrote:
>> >> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht
> wrote:
>> >>>
Am 18.01.2011 16:30, schrieb Volker Armin Hemmann:
> yes, rerun badblocks in destructive write mode. Twice. The second time create
> a badblocks file and use it with mkfs - that way bad blocks should be skipped.
Like in:
# badblocks -p2 -wv /dev/sdb6
?
On Tuesday 18 January 2011 21:13:49 Paul Hartman wrote:
> On Tue, Jan 18, 2011 at 2:56 PM, Mick wrote:
> > On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote:
> >> On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht
wrote:
> >> > On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
> >> >
> >> > wrote:
On Tue, Jan 18, 2011 at 12:56 PM, Mick wrote:
>
> Is the /etc/microcode.dat path a bug, now that firmware is typically placed in
> /lib/firmware?
>
> Shall I create a symlink or raise a bug report?
> --
> Regards,
> Mick
>
Mick,
I don't think so. Seems to me Gentoo can put this where ever it
I upgraded my xorg from 1.76 to 1.9 yesterday, including downloading the most
recent drivers. When the new system did not work, I checked the xorg log
(attached) and I thought that the problem was the mode setting. So in the
kernel, I "enabled the modesetting by default" and now the card does no
On 01/19/2011 06:46 AM, dan blum wrote:
I upgraded my xorg from 1.76 to 1.9 yesterday, including downloading the
most recent drivers. When the new system did not work, I checked the
xorg log (attached) and I thought that the problem was the mode setting.
So in the kernel, I "enabled the modesetti
38 matches
Mail list logo
