Scott Long; Devin Teske
>>> Subject: Re: revisiting tunables under Safe Mode menu option
>>>
>>> on 01/03/2012 03:34 Devin Teske said the following:
>>>>
>>>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe
>>>&g
Devin Teske fisglobal.com> writes:
> ...
> > > So I would welcome discussions involving development of something better
> > (and am
> > > willing to help).
> >
> ...
> Not exactly sure what "service safemode start" should do (BSD doesn't have the
> same concept of runlevels as Linux does; so it
> -Original Message-
> From: Julian Elischer [mailto:jul...@freebsd.org]
> Sent: Thursday, March 01, 2012 1:52 PM
> To: Devin Teske
> Cc: 'Andriy Gapon'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin'
> Subject: Re: revisiting
> -Original Message-
> From: Scott Long [mailto:sco...@samsco.org]
> Sent: Thursday, March 01, 2012 1:43 PM
> To: Devin Teske
> Cc: 'Julian Elischer'; freebsd-current@freebsd.org; 'Devin Teske'; 'John
Baldwin';
> 'Andriy Gapon
On 3/1/12 1:35 PM, Devin Teske wrote:
Right, making the assumption that FreeBSD's safe mode will do the same thing as
Windows' safe mode is a poor assumption.
As you point out, all those things that Windows safe mode does, FreeBSD does
not.
X11 drivers are not affected by safe mode.
Network is
On Mar 1, 2012, at 2:39 PM, Devin Teske wrote:
>
> I'm interested in which path you would choose amongst what I've seen mentioned
> thus far:
>
> a. Modifying the boot menu to offer fine-grain control over each aspect of
> Safe
> Mode (wherein perhaps the Safe Mode option becomes a hook for a s
> -Original Message-
> From: Julian Elischer [mailto:jul...@freebsd.org]
> Sent: Thursday, March 01, 2012 1:28 PM
> To: Scott Long
> Cc: Devin Teske; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin';
> 'Andriy Gapon'
> Su
> -Original Message-
> From: Julian Elischer [mailto:jul...@freebsd.org]
> Sent: Thursday, March 01, 2012 1:22 PM
> To: Devin Teske
> Cc: 'Andriy Gapon'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin'
> Subject: Re: revisiting
On 3/1/12 9:13 AM, Scott Long wrote:
1. There are a number of knobs that can be manipulated to help enable a
non-booting system boot, which in turn gives a system administrator a fighting
chance to figure out what's wrong. ACPI is (or was) one of these options, but
there are several others,
On 3/1/12 8:52 AM, Devin Teske wrote:
.
Indeed, I've watched field engineers when exploring the menu options and their
eyes light-up when they see that "Safe Mode" toggles ACPI off when enabled.
Extrapolating on their surprise, they appear to have an "Aha!"-moment a ...
they have all seen 'safe
> -Original Message-
> From: Andriy Gapon [mailto:a...@freebsd.org]
> Sent: Thursday, March 01, 2012 9:07 AM
> To: Devin Teske
> Cc: 'John Baldwin'; freebsd-current@FreeBSD.org; 'Scott Long'; 'Devin Teske'
> Subject: Re: revisiting tunable
> -Original Message-
> From: Scott Long [mailto:sco...@samsco.org]
> Sent: Thursday, March 01, 2012 9:13 AM
> To: Devin Teske
> Cc: 'Andriy Gapon'; 'John Baldwin'; freebsd-current@FreeBSD.org; 'Devin Teske'
> Subject: Re: revisiting tunab
vin Teske
>> Subject: Re: revisiting tunables under Safe Mode menu option
>>
>> on 01/03/2012 03:34 Devin Teske said the following:
>>>
>>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe
>>> Mode knows about ACPI but only acts
vin Teske
>> Subject: Re: revisiting tunables under Safe Mode menu option
>>
>> on 01/03/2012 03:34 Devin Teske said the following:
>>>
>>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe
>>> Mode knows about ACPI but only acts
On Thursday, March 01, 2012 3:39:21 am Andriy Gapon wrote:
> on 01/03/2012 03:34 Devin Teske said the following:
> >
> > +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe
> > Mode knows about ACPI but only acts on it when being enabled).
>
> Can you explain why?
> +1 for
> -Original Message-
> From: Andriy Gapon [mailto:a...@freebsd.org]
> Sent: Thursday, March 01, 2012 12:39 AM
> To: Devin Teske
> Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske
> Subject: Re: revisiting tunables under Safe Mode menu option
>
on 01/03/2012 03:07 Kevin Oberman said the following:
> I disabled APIC with a tunable (hint.apic.0.disabled=1). The T43 has
> no BIOS setting to turn it off.
>
> I have some time and still have the computer and it is up and running
> 9-Stable. In theory, I am retired, but still work part-time job
on 01/03/2012 03:34 Devin Teske said the following:
>
> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe
> Mode knows about ACPI but only acts on it when being enabled).
Can you explain why?
+1 for having both menu items and each doing its own thing without any
entanglem
On Feb 28, 2012, at 5:46 AM, John Baldwin wrote:
> On Tuesday, February 28, 2012 1:23:11 am Scott Long wrote:
>> I still think that it's useful to be able to disable ACPI. Just because
> ACPI works well on modern hardware doesn't mean that everything crummy from
> 2000-2007 suddenly disappeare
On Wed, Feb 29, 2012 at 1:49 AM, Andriy Gapon wrote:
> on 29/02/2012 00:18 Kevin Oberman said the following:
>> APIC is required for SMP, but works on many older, single CPU systems
>> and removes the massive sharing of IRQs common on non-APIC systems.
>>
>> OTOH, some ThinkPads simply won't boot
on 29/02/2012 00:18 Kevin Oberman said the following:
> APIC is required for SMP, but works on many older, single CPU systems
> and removes the massive sharing of IRQs common on non-APIC systems.
>
> OTOH, some ThinkPads simply won't boot with APIC. My old T43
> (Pentium-M) had this issue. I had t
On Mon, Feb 27, 2012 at 10:23 PM, Scott Long wrote:
>
> On Feb 27, 2012, at 3:38 PM, Andriy Gapon wrote:
>>>
>>> Turning off the APIC turns off SMP in a very efficient, clean manner. I
>>> added this not to isolate the APIC code, but to turn off SMP. That's why
>>> it's there, and I'd like the a
On Feb 28, 2012, at 6:46 AM, John Baldwin wrote:
> On Tuesday, February 28, 2012 1:23:11 am Scott Long wrote:
>> I still think that it's useful to be able to disable ACPI. Just because
> ACPI works well on modern hardware doesn't mean that everything crummy from
> 2000-2007 suddenly disappeare
On Feb 28, 2012, at 6:44 AM, John Baldwin wrote:
> On Monday, February 27, 2012 2:03:21 pm Scott Long wrote:
>>
>> On Feb 27, 2012, at 3:45 AM, Andriy Gapon wrote:
>>
>>> on 30/01/2012 18:59 Andriy Gapon said the following:
First, I think that this proposal/discussion could have been
On Monday, February 27, 2012 4:49:34 pm Andriy Gapon wrote:
> on 27/02/2012 18:26 John Baldwin said the following:
> > On Monday, February 27, 2012 5:45:39 am Andriy Gapon wrote:
> >> How does the following look?
> >> diff --git a/sys/boot/forth/menu-commands.4th
> >> b/sys/boot/forth/menu-command
On Tuesday, February 28, 2012 1:23:11 am Scott Long wrote:
> I still think that it's useful to be able to disable ACPI. Just because
ACPI works well on modern hardware doesn't mean that everything crummy from
2000-2007 suddenly disappeared off the face of the earth. But I agree that
turning it
On Monday, February 27, 2012 2:03:21 pm Scott Long wrote:
>
> On Feb 27, 2012, at 3:45 AM, Andriy Gapon wrote:
>
> > on 30/01/2012 18:59 Andriy Gapon said the following:
> >>
> >> First, I think that this proposal/discussion could have been more useful
> >> before
> >> the 9.0. Maybe the RE wo
On Feb 27, 2012, at 3:38 PM, Andriy Gapon wrote:
>>
>> Turning off the APIC turns off SMP in a very efficient, clean manner. I
>> added this not to isolate the APIC code, but to turn off SMP. That's why
>> it's there, and I'd like the ability to turn off SMP to stay there in some
>> form.
>
>
on 27/02/2012 21:03 Scott Long said the following:
>
> On Feb 27, 2012, at 3:45 AM, Andriy Gapon wrote:
>
>> on 30/01/2012 18:59 Andriy Gapon said the following:
>>>
>>> First, I think that this proposal/discussion could have been more useful
>>> before the 9.0. Maybe the RE would be interested
on 27/02/2012 18:26 John Baldwin said the following:
> On Monday, February 27, 2012 5:45:39 am Andriy Gapon wrote:
>> How does the following look?
>> diff --git a/sys/boot/forth/menu-commands.4th
>> b/sys/boot/forth/menu-commands.4th
>> index 828a148..41ba317 100644
>> --- a/sys/boot/forth/menu-co
On Feb 27, 2012, at 3:45 AM, Andriy Gapon wrote:
> on 30/01/2012 18:59 Andriy Gapon said the following:
>>
>> First, I think that this proposal/discussion could have been more useful
>> before
>> the 9.0. Maybe the RE would be interested in adding another item to their
>> pre-release checklist
On Monday, February 27, 2012 5:45:39 am Andriy Gapon wrote:
> on 30/01/2012 18:59 Andriy Gapon said the following:
> >
> > First, I think that this proposal/discussion could have been more useful
> > before
> > the 9.0. Maybe the RE would be interested in adding another item to their
> > pre-rel
On Feb 27, 2012, at 2:45 AM, Andriy Gapon wrote:
> on 30/01/2012 18:59 Andriy Gapon said the following:
>>
>> First, I think that this proposal/discussion could have been more useful
>> before
>> the 9.0. Maybe the RE would be interested in adding another item to their
>> pre-release checkli
on 30/01/2012 18:59 Andriy Gapon said the following:
>
> First, I think that this proposal/discussion could have been more useful
> before
> the 9.0. Maybe the RE would be interested in adding another item to their
> pre-release checklist: ask developers about what could be dropped and what
> s
On Jan 30, 2012, at 11:30 AM, Ian Lepore wrote:
On Mon, 2012-01-30 at 18:59 +0200, Andriy Gapon wrote:
o hw.ata.ata_dma, hw.ata.atapi_dma - I am not sure if there have
been any
significant problems with ATA DMA recently. Maybe these could be
removed?
I still have to work with hardware
On Mon, 2012-01-30 at 18:59 +0200, Andriy Gapon wrote:
>
> o hw.ata.ata_dma, hw.ata.atapi_dma - I am not sure if there have been any
> significant problems with ATA DMA recently. Maybe these could be removed?
I still have to work with hardware that requires ata_dma disabled. It
seems to be requ
First, I think that this proposal/discussion could have been more useful before
the 9.0. Maybe the RE would be interested in adding another item to their
pre-release checklist: ask developers about what could be dropped and what
should
be added to the Safe Mode settings in a new (.0) release. P
37 matches
Mail list logo
