On Tue, Apr 27, 2010 at 7:06 PM, Maxim Sobolev wrote:
> Alexander Sack wrote:
>>
>> On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin wrote:
>>>
>>> On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote:
John Baldwin wrote:
>
> On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wro
Alexander Sack wrote:
On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin wrote:
On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote:
John Baldwin wrote:
On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote:
John Baldwin wrote:
Hmm, I think you should definitely commit the atkbdc_isa.c cha
On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin wrote:
> On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote:
>> John Baldwin wrote:
>> > On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote:
>> >> John Baldwin wrote:
>> >>> Hmm, I think you should definitely commit the atkbdc_isa.c change fi
On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote:
> John Baldwin wrote:
> > On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote:
> >> John Baldwin wrote:
> >>> Hmm, I think you should definitely commit the atkbdc_isa.c change first
> >>> of
> >>> all. I'm still thinking about the othe
John Baldwin wrote:
On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote:
John Baldwin wrote:
Hmm, I think you should definitely commit the atkbdc_isa.c change first of
all. I'm still thinking about the other change. I wonder if we can figure
out that a keyboard isn't present sooner someh
On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote:
> John Baldwin wrote:
> > Hmm, I think you should definitely commit the atkbdc_isa.c change first of
> > all. I'm still thinking about the other change. I wonder if we can figure
> > out that a keyboard isn't present sooner somehow? Do y
John Baldwin wrote:
Hmm, I think you should definitely commit the atkbdc_isa.c change first of
all. I'm still thinking about the other change. I wonder if we can figure
out that a keyboard isn't present sooner somehow? Do you know if the keyboard
appears to be present but just slow vs if the
On Tue, Apr 27, 2010 at 12:04 PM, John Baldwin wrote:
> On Thursday 22 April 2010 4:07:37 pm Maxim Sobolev wrote:
>> John Baldwin wrote:
>> > On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote:
>> >> John Baldwin wrote:
>> >>> On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
>>
On Thursday 22 April 2010 4:07:37 pm Maxim Sobolev wrote:
> John Baldwin wrote:
> > On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote:
> >> John Baldwin wrote:
> >>> On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
> Maxim Sobolev wrote:
> > There is already a code to detec
John Baldwin wrote:
On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote:
John Baldwin wrote:
On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
Maxim Sobolev wrote:
There is already a code to detect non-existing AT keyboard and avoid
attaching atkbd to it. The code is i386-only at
On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote:
> John Baldwin wrote:
> > On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
> >> Maxim Sobolev wrote:
> >>> There is already a code to detect non-existing AT keyboard and avoid
> >>> attaching atkbd to it. The code is i386-only at t
John Baldwin wrote:
On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
Maxim Sobolev wrote:
There is already a code to detect non-existing AT keyboard and avoid
attaching atkbd to it. The code is i386-only at the moment, I am trying
to figure out how to modify it so that it works on amd
On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
> Maxim Sobolev wrote:
> > There is already a code to detect non-existing AT keyboard and avoid
> > attaching atkbd to it. The code is i386-only at the moment, I am trying
> > to figure out how to modify it so that it works on amd64 as wel
Maxim Sobolev wrote:
There is already a code to detect non-existing AT keyboard and avoid
attaching atkbd to it. The code is i386-only at the moment, I am trying
to figure out how to modify it so that it works on amd64 as well.
Looks like this huge delay is caused by the inb() being astonishin
John Baldwin wrote:
On Tuesday 20 April 2010 7:35:46 pm Matthew Jacob wrote:
On 04/20/2010 03:44 PM, Maxim Sobolev wrote:
Maxim Sobolev wrote:
Maybe try adding
hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"
to /boot/device.hints? That has reportedly removed minute-long boot
delays on
On Tuesday 20 April 2010 7:35:46 pm Matthew Jacob wrote:
> On 04/20/2010 03:44 PM, Maxim Sobolev wrote:
> > Maxim Sobolev wrote:
> >>> Maybe try adding
> >>>
> >>> hint.atkbdc.0.disabled="1"
> >>> hint.atkbd.0.disabled="1"
> >>>
> >>> to /boot/device.hints? That has reportedly removed minute-long
> On 21.04.2010 10:01, pluknet wrote:
> > Hmm.. That's strange to hear.
> > We have in production a number of x3650m2: 7.2-R, 7.3-R (all amd64).
> > All runs flawlessly.
> > I'll try to boot it from head today if that matters.
>
> It was about 1.5 hour ago when i entered "autoboot" in loader pro
On 21.04.2010 10:01, pluknet wrote:
Hmm.. That's strange to hear.
We have in production a number of x3650m2: 7.2-R, 7.3-R (all amd64).
All runs flawlessly.
I'll try to boot it from head today if that matters.
It was about 1.5 hour ago when i entered "autoboot" in loader prompt.
It still show
2010/4/21 Andrey V. Elsukov :
> On 21.04.2010 2:44, Maxim Sobolev wrote:
>>
>> Maxim Sobolev wrote:
Maybe try adding
hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"
>>
>> Actually it helped, thank you very much! The problem was that I have had
>> my hints compiled into
On 21.04.2010 2:44, Maxim Sobolev wrote:
Maxim Sobolev wrote:
Maybe try adding
hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"
Actually it helped, thank you very much! The problem was that I have had
my hints compiled into the kernel itself.
Hi, Maxim.
I tried to boot 9.0-CURRENT amd6
On Apr 20, 2010, at 5:48 PM, Maxim Sobolev wrote:
> John Baldwin wrote:
>> On Tuesday 20 April 2010 8:30:42 am Maxim Sobolev wrote:
>>> Update: I've discovered that the 7.3 kernels actually boot after some
>>> ridiculously long waiting period after the "boot" command (i.e. 10 minutes
>>> or eve
On 04/20/2010 03:44 PM, Maxim Sobolev wrote:
Maxim Sobolev wrote:
Maybe try adding
hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"
to /boot/device.hints? That has reportedly removed minute-long boot
delays on some Nehalem machines.
No, that have not helped at all. I measured the delay
Maxim Sobolev wrote:
Maybe try adding
hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"
to /boot/device.hints? That has reportedly removed minute-long boot
delays on some Nehalem machines.
No, that have not helped at all. I measured the delay - it's about 6
minutes from boot command to t
John Baldwin wrote:
On Tuesday 20 April 2010 8:30:42 am Maxim Sobolev wrote:
Update: I've discovered that the 7.3 kernels actually boot after some
ridiculously long waiting period after the "boot" command (i.e. 10
minutes or even more). I suspect that it might be caused by the memory
probing,
John Baldwin wrote:
On Tuesday 20 April 2010 8:30:42 am Maxim Sobolev wrote:
Update: I've discovered that the 7.3 kernels actually boot after some
ridiculously long waiting period after the "boot" command (i.e. 10
minutes or even more). I suspect that it might be caused by the memory
probing,
On Tuesday 20 April 2010 8:30:42 am Maxim Sobolev wrote:
> Update: I've discovered that the 7.3 kernels actually boot after some
> ridiculously long waiting period after the "boot" command (i.e. 10
> minutes or even more). I suspect that it might be caused by the memory
> probing, which as far a
Update: I've discovered that the 7.3 kernels actually boot after some
ridiculously long waiting period after the "boot" command (i.e. 10
minutes or even more). I suspect that it might be caused by the memory
probing, which as far as I know the FreeBSD does to determine if the
physical memory th
Maxim Sobolev wrote:
the boot command, HEAD - filled in console with funny blinking characters.
...and hanged machine after that as well.
-Maxim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
Hi,
For the first time in many years, I've stumbled across a server hardware
where FreeBSD kernel refuses to boot. It's FUJITSU PRIMERGY RX200 S5
server with 2x Quad core E5520 processors and 16GB of RAM. Linux boots
on that hardware just fine. Linux dmesg is available here:
http://sobomax.s
29 matches
Mail list logo
