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 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'
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. Apparently
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, J"or
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 tonigh
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 al
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 s
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):
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 wher
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: Una
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 perhap
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 hap
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 s
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
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
Lowell Gilbert 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 e.g. recompile it while
the machine
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: at port
0x100-0x10f iomem 0x2000-0
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 ad
18 matches
Mail list logo
