When trying to use doscmd on 8-stable, all I get is:
Error mapping HMA, HMA disabled: : Invalid argument
Segmentation fault (core dumped)
The segfault happens at the end of mem_init(), when the allocated DOS
memory (which is located at virtual address 0) is attempted to be
written to.
As Kostik Belousov wrote:
So does anyone have an idea
why this mmap() call:
...
yields an EINVAL now under 8-stable?
Do sysctl security.bsd.map_at_zero=1
Ah, thanks! Now it works. Well, at least it doesn't crash anymore (I
somehow have to fix my boot environment, hopefully I'll be
As Kostik Belousov wrote:
Do sysctl security.bsd.map_at_zero=1
Just for the record, this sysctl also makes my really really old utree
binary work again. The binary dates back to 386BSD 0.0, and I'm only
keeping it out of curiosity:
j@uriah 66% ls -l /usr/local/bin/utree
-rwxr-xr-x 1 bin bin
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
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
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
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
After I recently (finally) upgraded my main machine to RELENG_8, I
tried to rip a CD today, using abcde, and got
panic: wrong offset 4096 for sectorsize 2352
Any ideas why this happens, and how to avoid it?
(I've got a coredump of the kernel, so I could analyze it if
someone has got an idea
As Andriy Gapon wrote:
panic: wrong offset 4096 for sectorsize 2352
Any ideas why this happens, and how to avoid it?
Backtrace would be a first thing.
OK, here we go (the core has been dumped from within a serial console
BREAK DDB entry, I'm omitting the frames related to that):
#16
As Joerg Wunsch wrote:
OK, at kernel #11 :), I can now say it's the USB subsystem. Just
leaving device usb (and also device uhci) in makes it work.
So the question appears to be why keeping the USB driver in makes the
interrupt storm detection work...
Maybe that's the relationship?
camel
As M. Warner Losh wrote:
: I guess vgapci0 doesn't really use interrupts, so this leaves cbb0/1
: and uhci0 sharing an interrupt. Apparently, the interrupt storm at
: cbb gets detected correctly as long as at least another device
: installs an interrupt handler on irq 11.
Does this happen
As M. Warner Losh wrote:
: Does this happen on a cold boot or a warm boot?
:
: That doesn't matter.
Bummer. I'll have to look at the original data a little more
closely. I'd like to know what causes this, if possible.
OK, I could insert any printf you'd like me to. I could perhaps
As M. Warner Losh wrote:
I'd like to know what causes this, if possible.
One more datapoint, don't know whether it's related or not.
I've got a cardbus ethernet card around (a Xircom one), which it is
normally used in a different machine. When I insert it into the
TP600, I get:
cardbus1:
As M. Warner Losh wrote:
Yes. Do other cards cause this same problem?
Nope, but the xe card is the only one I've got that tries to use the
memory space. The remaining cards use the ep(4) driver which only
uses IO space access.
The cbb1: Bad Vcc is a
big clue something is going wrong with
As John Baldwin wrote:
Sounds like the process of removing things prevented the interrupt
storm from being throttled somehow, and that ejecting the card
caused the interrupt storm to finally stop at which point the card
was probed. I would talk to Warner (imp@) about trying to fix the
I'm running into a strange problem with 8-current (or 8.0-RELEASE) on
an elderly Thinkpad 600E.
As long as I'm using the GENERIC kernel, an Intel Etherexpress PC card
works as expected:
interrupt storm detected on irq11:; throttling interrupt source
xe0: Intel EtherExpress(TM) PRO/100 PC Card
Lowell Gilbert freebsd-stable-lo...@be-well.ilk.org wrote:
Try device cbb. Also make sure you have pccard. I don't think
you'll need cardbus with that setup, but I'm not certain.
cbb, pccard, and also cardbus are part of the kernel config. I
originally left out xe on purpose (so I could
As Andriy Gapon wrote:
Now:
(0x44 1) 0xff == (0xc4 1) 0xff = 0x88 (looks like RTC)
(0x50 1) 0xff == (0xd0 1) 0xff = 0xa0 (well known SPD addr)
(0x52 1) 0xff == (0xd2 1) 0xff = 0xa4 (well known SPD addr)
(0x80 1) 0xff = 0x0 (mentioned above global address)
(0x88 1) 0xff ==
18 matches
Mail list logo
