result.
And turns out I have this in my sysctl.conf :-)
# should give more responsivness on desktop
# suggested by David Xu davi...@freebsd.org
kern.sched.preempt_thresh=220
Apparently I have it for so long in there that I forgot that I do.
Thanks again!
--
Andriy Gapon
functions are supported.
Interesting...
Yeah, I've heard that they are adding SMT capabilities in Bulldozer
processors, so I guess they have to change CPU topology detection indicators.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
(G33) -
enabling OpenGL desktop effects in KDE4 leads to the consequences like what you
describe. With all GUI bells and whistles disabled the system behaves quite
like the AMD system.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
.
Thanks!
--
Andriy Gapon
___
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
Oops, the patch had a small mistake.
I've put it here now, just in case I'll want to fix/cleanup anything else:
http://people.freebsd.org/~avg/intel-cpu-topo.diff
on 28/08/2010 23:22 Andriy Gapon said the following:
So, here is my take on the problem.
The attached patch is against sources
on 28/08/2010 01:02 Andriy Gapon said the following:
BTW, it may be not that hard.
It seems that 0x4 topology building involves knowing the masks and we already
have that data (just interpreted differently), and APIC IDs of the CPUs and it
seems that we also have that. We don't need to bind
that we try to detect the topology by doing stuff only
on BSP and that's why we handle properly only uniform topologies. So that would
make your point about correct cores moot.
Am I mistaken?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
though,
detected topology looks different.
So I'd rather not worry about the general case of virtual machines right now.
Let's first see more evidence of whether we should trust them or not.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
, then the hardware
is emulated properly and the problem is with the patch.
What is your point? :)
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable
] )) represents the maximum number of addressable IDs (Core_ID)
that can be used to enumerate different processor cores in a physical package.
The value also can be different than the actual number of processor cores that
are present in the hardware of a physical package.
--
Andriy Gapon
on topo_probe to know hyperthreading_cpus value.
So, either cpu_apic_ids could be split out or alternatively we could use
cpu_info[] similarly to how it's done in topo_probe_0xb (skipping !cpu_present
and cpu_disabled entries).
--
Andriy Gapon
on 28/08/2010 01:03 Jung-uk Kim said the following:
On Friday 27 August 2010 04:19 pm, Andriy Gapon wrote:
I still don't get your point.
My point is that if the Intel's code gets the topology right, then
the hardware is emulated properly and the problem is with the
patch.
What is your point
, but messing with APs I don't want :)
Also, don't forget jhb's work based on ACPI affinity tables.
Not sure how they are applicable here.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
you read the decoded message?
Please re-read it.
I still recommend reading at least the summary of the RAM ECC research article
to make your own judgment about need to replace DRAM.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
on 25/08/2010 13:41 Dan Langille said the following:
On 8/25/2010 3:11 AM, Andriy Gapon wrote:
Have you read the decoded message?
Please re-read it.
I still recommend reading at least the summary of the RAM ECC research
article
to make your own judgment about need to replace DRAM
it's possible to configure an interrupt for Bank 4 events as
well (perhaps other banks too), but I need to refresh my memory of BKDG.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
on 25/08/2010 18:02 Andriy Gapon said the following:
on 25/08/2010 15:23 John Baldwin said the following:
That is because machine checks for corrected errors have to be polled and
the
kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a
separate interrupt (CMCI
HDD.
You may find this interesting:
http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd
(or want to)
keep running stuff on the hardware that is broken is another question.
Have you read the article? :)
If not, read at least the summary.
On Tue, Aug 24, 2010 at 1:15 AM, Andriy Gapon a...@icyb.net.ua wrote:
on 24/08/2010 09:14 Ronald Klop said the following:
A little off topic
the summary.
On Tue, Aug 24, 2010 at 1:15 AM, Andriy Gapon a...@icyb.net.ua wrote:
on 24/08/2010 09:14 Ronald Klop said the following:
A little off topic, but what is 'a low rate of corrected ECC errors'? At
work
one machine has them like ones per day, but runs ok. Is ones per day much?
That's up
.
John Baldwin has a port of it to FreeBSD, but it seems to be WIP and is private
so far. Wait and watch John posting decoded text in this thread :-)
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
ensure that system doesn't hang while dumping or in reset
routine or etc.
Another workaround is to set watchdog timeout large enough for dumping to
complete, but that increases time that system is unavailable during a 'hard'
hang
(e.g. caused by hardware).
--
Andriy Gapon
there could be hundreds of such errors per day.
Either replace memory modules or learn to live with these messages.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any
definition of 'available_memory' was here
*** Error code 1
Sorry for the breakage. And in stable/8 too.
Late night MFC and such a trivial mistake in such a trivial merge.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org
, should I try
and use SW_WATCHDOG, or forget about it?
Just test it more while having physical access before making any conclusions.
There could be a number of radically different possibilities ranging from
hardware peculiarities to configuration problems to pilot errors to etc.
--
Andriy Gapon
on 19/08/2010 22:15 pluknet said the following:
On 19 August 2010 21:27, Andriy Gapon a...@icyb.net.ua wrote:
on 19/08/2010 19:56 pluknet said the following:
CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class
CPU)
Origin = GenuineIntel Id = 0x106a5 Family = 6
suboptimal topology.
Can you debug, e.g. with printfs, what exactly goes wrong?
I wonder if in this case code follows some unusual/unexpected path.
BTW, could you please also provide CPU name/model/features as detected by the
kernel?
Thanks!
--
Andriy Gapon
) x 32 HTT threads
cpu0 (BSP): APIC ID: 0
cpu1 (AP/HT): APIC ID: 2
cpu2 (AP/HT): APIC ID: 4
Thanks!
BTW, what does Intel's code report?
Jung-uk's convenience script:
http://people.freebsd.org/~jkim/cpu_topology-12212009.sh
--
Andriy Gapon
it to the
other disks by hand?
Fix for this has been recently MFC-ed to stable/8.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr
on 04/08/2010 15:08 Alex V. Petrov said the following:
Hi All!
$ dd if=/dev/random of=/tank/test bs=3M count=1000
/dev/random is slow.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
is a hardware problem where interrupt message route between
ioapic2 and CPU to which lapic3 belongs is flaky.
Perhaps, this might be a FreeBSD problem: it could be that the system somehow
tells to not set up such routes, but we don't listen. But this is far fetched.
--
Andriy Gapon
on 21/07/2010 11:33 Andriy Gapon said the following:
Not sure how to interpret this properly.
One possibility is a hardware problem where interrupt message route between
ioapic2 and CPU to which lapic3 belongs is flaky.
Or, I/O path between that CPU and the PCI slot where the device resides
on 21/07/2010 15:25 Markus Gebert said the following:
On 21.07.2010, at 10:33, Andriy Gapon wrote:
on 21/07/2010 03:57 Markus Gebert said the following:
Another thing though: Today I compared verbose boot output from 8-stable
and the current box. I saw that the ioapic sets up IRQ routing
ioc0 is it.
--
Andriy Gapon
___
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
output (asize?).
If I remember correctly, that actual size should be a multiple of some rather
large power of two, so it could be that it is smaller than 'User Capacity' of
both
old and new drives.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing
SATA driver. Therefore, PC BSD is
not installable on my machine as it deterministically panics on
boot. The same machine runs FreeBSD 7.3 just fine.
I guess that your best bet is to directly ping mav@ in case he missed the PR and
this thread.
--
Andriy Gapon
on 15/07/2010 14:58 Oliver Fromme said the following:
Andriy Gapon wrote:
Could you please try to do the following?
1. Fetch topo-12212009.tar from the top of this page:
http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/
2. Untar
was to the new kernel), then perhaps
jkim would be interested in this issue.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr
if (cpu_high = 0x4)
+ if (cpu_high = 0x4 cpu_cores == 0)
topo_probe_0x4();
}
if (cpu_cores == 0)
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
. Run cpu_topology64.out and report back its output.
Thanks!
--
Andriy Gapon
___
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
.
Indeed. Your patch looks so much cleaner too.
Thanks!
--
Andriy Gapon
___
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
(vm_paging_target() -2048))
I am not sure that what comment says is actually what the code checks.
For both pre-patch and post-patch versions.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
aspects it's even better than i386. So, if something
doesn't properly work, then it's just a bug that should be appropriately
reported.
Just in case. Were the problems that you encountered amd64-specific? I.e. did
they _not_ happen when you tried i386?
--
Andriy Gapon
week of changes.
Does anyone have an idea what might be causing this? Do I
have to be alarmed by this? The system is reliable despite these
messages.
This messages just warns about bad programming, but in this case the ioctl is
processed correctly.
--
Andriy Gapon
on 19/06/2010 09:50 Doug Barton said the following:
On 06/18/10 10:26, Andriy Gapon wrote:
on 18/06/2010 18:51 Жиндарев Алексей said the following:
Jun 18 19:33:54 last message repeated 371 times
Jun 18 19:41:31 last message repeated 1359 times
Jun 18 19:43:29 kernel: WARNING pid 31369
can not be found.
But I am not sure, just trying to come up with an explanation.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr
into kernel, that
servers begin boots fine.
Can you please produce _verbose_ dmesg for booting with acpi+mpt and no acpi, no
mpt? And also, _verbose_ dmesg of acpi and !mpt.
You can capture the latter with serial console.
If you don't have it, try to get screenshots.
--
Andriy Gapon
ioctl. Look through the code where this is passed via a
variable
of incorrect type. Correct type for ioctl request should be unsigned long.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
that works is power key, and when it
is pressed and hold, the messages stop to scroll and the last message is
there for a really small fraction of time.
Do you have a digital camera? Perhaps you can snap a screenshot?
Other options - serial or firewire console from another machine.
--
Andriy Gapon
different usage/load patterns and hit different
hardware problems with higher probability.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd
in clutter-cairo is incorrect, e.g. it expects clutter to
provide version N some shared lib, while in fact it provides version M.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
= 19 (flowcleaner)
trap number = 12
panic: page fault
cpuid = 1
Stacktrace would be helpful.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
) will be read repeatedly if the system
is under memory pressure.
No. Contents of mfsboot is loaded into physical memory and always stays there.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
by ACPICA layer since ACPICA 20091214.
--
Andriy Gapon
___
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
because I
wrote the below documentation:
Guys, you could have used donotboot_ prefix there and it would still work :-)
_type, _name and _load suffixes are what is important in this particular case.
See description of these suffixes in loader.conf(5).
--
Andriy Gapon
, otherwise use
cvsup-master.freebsd.org (not recommended).
CVS commit:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_ntptime.c
Jeremy, thanks for stepping up!
Michael and all, apologies for the breakage.
--
Andriy Gapon
___
freebsd-stable
noexpandtab in vim-speak.
--
Andriy Gapon
___
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
into FreeBSD.
Chris
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
--
Andriy Gapon
:
-mpreferred-stack-boundary=2 is not between 4 and 12
*** Error code 1
You are cross-compiling a kernel for a different architecture but you haven't
built a toolchain for that architecture.
See kernel-toolchain in build(7).
--
Andriy Gapon
___
freebsd
been MFC-ed to 8.
Most likely a red herring.
AFAIK, there were no ACPI-related changes in 8 for the last couple of months, so
the issue must be elsewhere.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman
.
But I am not sure what would be an optimal strategy for that case. If we try to
keep some lucky processes on the same core, then cpu time might be shared
unfairly. Shuffling cores provides more fairness, but can hurt total
performance.
--
Andriy Gapon
- for the things to get
in line.
4: In the debugger it prints: $1 = 0, so I suppose yeah, it is set to
zero.
I really suspect faulty hardware here.
Maybe dead CMOS/NVRAM battery or dead crystal or some chip or circuit.
--
Andriy Gapon
___
freebsd
on 15/04/2010 16:23 Adam Vande More said the following:
Is is possible to add a tunable to the scheduler for it's aggressiveness
in switching cores?
No idea; not a scheduler person.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
!
--
Andriy Gapon
___
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
on 14/04/2010 16:28 Akephalos said the following:
On Wed, 14 Apr 2010 00:06:56 +0300 Andriy Gapon a...@icyb.net.ua wrote:
What is not obvious is why your RTC doesn't work as expected. I have no
answer to that.
One thing that makes me suspicious is that HPET also doesn't seem to work
.
Those things are possible on FreeBSD.
Perhaps, there are more things like that.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr
to the cores.
--
Andriy Gapon
___
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
, etc)?
4. Can you please double-check that lapic_allclocks is zero in kernel?
You can run 'kgdb /boot/kernel/kernel /dev/mem' and then 'print lapic_allclocks'
Thanks!
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org
are greater that the data stays in cache.
--
Andriy Gapon
___
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
for you to test recent 8-STABLE?
Just for the sake of experiment.
--
Andriy Gapon
___
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
on 10/04/2010 07:21 Akephalos said the following:
On Thu, 08 Apr 2010 18:03:08 +0300 Andriy Gapon a...@icyb.net.ua wrote:
Really shooting in the dark here: are there any BIOS options about HPET and
RTC on this system? Can you try playing with them?
-- Andriy Gapon
I'm sorry
on 13/04/2010 02:33 Maho NAKATA said the following:
From: Andriy Gapon a...@freebsd.org
Another question is what compilers (what versions of GCC) were used on both
system to compile the program?
Hi
on Ubuntu $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured
with: ../src
many threads does it have and what do
they do, how do they communicate?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr
on 12/04/2010 17:41 Andriy Gapon said the following:
It would also be get good to learn more about your program.
How much memory does it typically use, how does it allocate it?
Is it single-threaded or not? If not, how many threads does it have and what
do
they do, how do they communicate
of 'vmstat -i' and Interrupt request lines portion of 'devinfo -u'
output.
Thanks!
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr
on 08/04/2010 10:22 Attilio Rao said the following:
2010/4/8 Andriy Gapon a...@icyb.net.ua:
on 08/04/2010 04:29 Akephalos said the following:
Attilio, I csup-dated several hours ago and rebuilt and installed the kernel
(and world, in case it matters).
%uname -a FreeBSD free.bsd369441.org 8.0
on 08/04/2010 15:04 Akephalos said the following:
On Thu, 08 Apr 2010 10:11:50 +0300
Andriy Gapon a...@icyb.net.ua wrote:
Interesting, I couldn't see anything obviously wrong about your hardware.
Could you please post a verbose dmesg from a problematic boot somewhere?
Also, output of 'vmstat
on 08/04/2010 15:44 Akephalos said the following:
On Thu, 08 Apr 2010 16:33:09 +0300
Andriy Gapon a...@icyb.net.ua wrote:
Thank you for the data.
So looks like RTC indeed doesn't generate any interrupts after startup.
Still I would like to get a _verbose_ dmesg :-)
--
Andriy Gapon
Really shooting in the dark here: are there any BIOS options about HPET and RTC
on
this system? Can you try playing with them?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
results?
Thanks!
--
Andriy Gapon
___
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
on 07/04/2010 14:20 Julian H. Stacey said the following:
I wonder if it's eg a corrupt FS not being fsck'd first ?
Have you given a look to the backtrace that Mikhail had posted?
I think that it answers your question.
--
Andriy Gapon
___
freebsd
you post output of acpidump -dt?
Thanks!
--
Andriy Gapon
___
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
times, once updating to CURRENT and
once to STABLE, through buildkernel/world, hopefully someone else will
be able to provide the feedback.
So we weren't fast enough and lost you :-(
Holidays, you know.
--
Andriy Gapon
___
freebsd-stable@freebsd.org
://wiki.freebsd.org/HAST
--
Andriy Gapon
___
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
on 04/04/2010 09:32 Akephalos Akephalos said the following:
- 'top -P' displays only one CPU and its load is 0% everything all the time,
despite any load
So this is probably the root cause.
Do you I have any unusual messages in dmesg after the upgrade?
Anything about RTC?
--
Andriy Gapon
on FreeBSD 8.
Does anyone have a clue about the problem ?
Yes, it's a known problem.
It is caused by you having userquota/groupquota options for root filesystem in
your fstab.
Previously it was OK, but it got broken when a new feature was implemented in
r193192.
--
Andriy Gapon
on 09/02/2010 14:53 Andriy Gapon said the following:
on 09/02/2010 12:32 Matthew D. Fuller said the following:
On Tue, Feb 09, 2010 at 04:37:50PM +1030 I heard the voice of
Daniel O'Connor, and lo! it spake thus:
Probably the result of idiotic penny pinching though :-/
Irritating. One of my
-16M) solved the problem here, but
that shouldn't be a solution. I wonder whether it's a loader-, or a
BIOS-problem, since memory-allocation should respect reserved
areas.
True. Please also keep in mind that BIOS should report reserved areas
correctly too.
--
Andriy Gapon
.
Long thread reference:
http://thread.gmane.org/gmane.os.freebsd.current/121035/focus=121457
possible AMD errata 147
147?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
be
that deep in create code path, because we need hold this lock as reader.
It isn't visible in 'show alllocks' output, because this lock is special
(rrwlock.c).
BTW, it seems that our 'stock' rwlock implements exactly the same thing as
rrwlock.c - recursive readers, etc.
--
Andriy Gapon
.
I submitted my patches to k3b upstream developer, but they are not included
still.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable
. it is locked in ata_conn_event and then ata_reinit locks it again.
Of course, an external condition is needed to trigger ata_conn_event in the
first
place.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman
on 15/02/2010 00:24 Peter Jeremy said the following:
On 2010-Feb-05 00:40:24 +0200, Andriy Gapon a...@icyb.net.ua wrote:
I came up with some things with which you can try to experiment:
1. Boot with hw.pci.usb_early_takeover=0 in loader.conf.
2. Comment out the following line in sys/dev/usb
check might be
enabled/done by firmware (e.g. BIOS). This typically could be the case for
high-end-ish/server systems.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe
.
--
Andriy Gapon
___
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
further and will provide any
additional information -- just name it.
Please check if your X binary is linked with libthr (using ldd).
I saw similar problems when it was not.
That was because it was compiled without HAL support.
--
Andriy Gapon
the latest 8.0/STABLE.
Could you please try hw.pci.usb_early_takeover=0 in loader.conf?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable
superpages in the guests.
--
Andriy Gapon
___
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
on 10/02/2010 18:01 Vitaly Magerya said the following:
Andriy Gapon wrote:
Please check if your X binary is linked with libthr (using ldd).
I saw similar problems when it was not.
That was because it was compiled without HAL support.
It is not, and yes I use WITHOUT_HAL. Currently disabling
on 10/02/2010 19:05 Ivan Voras said the following:
On 02/10/10 17:05, Andriy Gapon wrote:
on 10/02/2010 17:36 Ivan Voras said the following:
It looks like I've stumbled upon a bug in vSphere 4 (recent update) with
FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s
601 - 700 of 947 matches
Mail list logo
