As Jeremy Chadwick wrote:
Just an informational note about inducing a panic: I tend to, once at
the db prompt, do bt then immediately call doadump. That induces
memory being written to swap, then do reboot.
OK, reproduced the panic (which was easy ;), and did it that way.
Now, the stack
On 25.05.2011 13:36, Joerg Wunsch wrote:
Well, the workaround is easy (just return -1 from gv_taste() when
noticing the offset is not on a sector boundary - this can never be a
valid gvinum device anyway), but I'm curious about why this panic now
happens in RELENG_8 when it didn't before. I
As Andrey V. Elsukov wrote:
Are you sure that it is RELENG_8?
Yes, I am.
Or maybe you added options INVARIANTS
to your kernel?
I did (for other rasons, which you can read about in the freebsd-scsi
list).
Anyway, it appears to be a software bug. Ah, OK, it's quite possible
the bug has
On 25.05.2011 15:15, Joerg Wunsch wrote:
Or maybe you added options INVARIANTS
to your kernel?
I did (for other rasons, which you can read about in the freebsd-scsi
list).
Anyway, it appears to be a software bug. Ah, OK, it's quite possible
the bug has always been there, even in
As Andrey V. Elsukov wrote:
Anyway, it appears to be a software bug. Ah, OK, it's quite possible
the bug has always been there, even in RELENG_7 ... I just never
tested that one against INVARIANTS.
I committed the fix in the r83, can you test it?
Спасибо, I'll test it tonight when
Hello Jeremy and FreeBSD friends,
On Sun, May 22, 2011 at 12:16:42AM -0700, Jeremy Chadwick wrote:
On Sat, May 21, 2011 at 11:20:37AM +0200, Willy Offermans wrote:
Dear FreeBSD friends,
I need support with a MultiTech modem, MT9234ZPX-PCIE-NV
Dear Daniel and FreeBSD friends,
On Sun, May 22, 2011 at 10:48:03AM +0200, Daniel O'Connor wrote:
On 22/05/2011, at 9:16, Jeremy Chadwick wrote:
However, as the boot process already mentions, there is no driver attached
and I cannot get the modem to appear as an accessible and functional
On 25/05/2011, at 16:10, Willy Offermans wrote:
According to the manufacturer
(http://www.multitech.com/en_US/PRODUCTS/Families/MultiModemZPX/)
it is not a soft modem, but a ``hardware'' modem. It says: Built-in
processor does the work, so your computer doesn't have to. I do not know if
this
On 25/05/2011, at 16:04, Willy Offermans wrote:
I'm using FreeBSD 7.2-RELEASE-p2. I have enclosed the dmesg.boot file.
puc was already incorporated into the kernel:
kosmos# kldload -v puc
kldload: can't load puc: File exists
So I assume puc has already been loaded.
You could try
On Saturday, May 21, 2011 5:20:37 am Willy Offermans wrote:
Dear FreeBSD friends,
I need support with a MultiTech modem, MT9234ZPX-PCIE-NV
(http://www.multitech.com/en_US/PRODUCTS/Families/MultiModemZPX/)
The modem is recognised during the boot event:
snip
pci6: simple comms, UART at
As Andrey V. Elsukov wrote:
Anyway, it appears to be a software bug. Ah, OK, it's quite possible
the bug has always been there, even in RELENG_7 ... I just never
tested that one against INVARIANTS.
I committed the fix in the r83, can you test it?
Works fine!
--
cheers, Jorg
Le Tue, 24 May 2011 16:21:08 +0300,
Andriy Gapon a...@freebsd.org a écrit :
Hello,
I am planning on some changes in head and would like to see if people
use the following features:
- machdep.hyperthreading_allowed tunable and sysctl
If I remember well, these tunables were introduced because
On Tue, 24 May 2011 18:27:47 +0200, Josh Carroll josh.carr...@gmail.com
wrote:
Whatever you do, please leave at least some way (at least a tunable) to
enable/disable HTT - some workloads are better with, and some without
it,
and some BIOSes are unreliable in enabling/disabling it :)
I
13 matches
Mail list logo
