on 28/07/2010 06:01 Michael Butler said the following:
I have a custom kernel for my laptop which uses ATA_CAM rather than the
now aging ATA driver ..
You do realize that ATA_CAM just (well, mostly) introduces a wrapper around the
now aging ATA driver ?
No magic pixie dust to fix the bugs in
Hi,
When is it safe to free memory which has been mmapped to a user-space
application? After close() or during close() or before close() or when the
process/thread terminates?
--HPS
___
freebsd-current@freebsd.org mailing list
Hello,
By searching the net I was only able to find that better support for
9.0 is on its way. So I'd like to ask if MCEs (like ECC-related messages
from, say Supermicro boards) are being already processed by the kernel.
Are there any (plans for) tools to handle and process these messages in
From close(3):
The close(2) system call does not unmap pages, see munmap(2) for further
information.
The pages can be freed when the process terminates.
-- Jille
Op 28-7-2010 10:56, Hans Petter Selasky schreef:
Hi,
When is it safe to free memory which has been mmapped to a
on 28/07/2010 12:31 V. T. Mueller, Continum said the following:
Hello,
By searching the net I was only able to find that better support for
9.0 is on its way. So I'd like to ask if MCEs (like ECC-related messages
from, say Supermicro boards) are being already processed by the kernel.
Are
Andriy Gapon a...@icyb.net.ua writes:
Michael Butler i...@protected-networks.net writes:
I have a custom kernel for my laptop which uses ATA_CAM rather than
the now aging ATA driver ..
You do realize that ATA_CAM just (well, mostly) introduces a wrapper
around the now aging ATA driver ?
Dag-Erling Smørgrav d...@des.no writes:
Andriy Gapon a...@icyb.net.ua writes:
Michael Butler i...@protected-networks.net writes:
I have a custom kernel for my laptop which uses ATA_CAM rather than
the now aging ATA driver ..
You do realize that ATA_CAM just (well, mostly) introduces a
Dag-Erling Smørgrav wrote:
Dag-Erling Smørgrav d...@des.no writes:
Andriy Gapon a...@icyb.net.ua writes:
Michael Butler i...@protected-networks.net writes:
I have a custom kernel for my laptop which uses ATA_CAM rather than
the now aging ATA driver ..
You do realize that ATA_CAM just (well,
on 27/07/2010 20:20 Anton Shterenlikht said the following:
yes, thanks, the panic has gone away.
There still seems to be a problem with this device:
hd...@pci0:0:20:2:class=0x040300 card=0x30c2103c chip=0x43831002 rev=0x00
hdr=0x00
vendor = 'ATI Technologies Inc. / Advanced
In message 201007281056.43100.hsela...@c2i.net, Hans Petter Selasky writes:
When is it safe to free memory which has been mmapped to a user-space
application? After close() or during close() or before close() or when the
process/thread terminates?
Assuming you mean memory activated via
on 27/07/2010 19:53 Gavin Atkinson said the following:
Thanks. Can you try
http://people.freebsd.org/~gavin/mexas-hda-panic.diff
and see if that solves things for you?
(Credit goes to avg@ for looking into this before me :)
BTW, it seems that there is an epidemic of free(sc, M_DEVBUF)
On Wed, Jul 28, 2010 at 04:14:10PM +0300, Andriy Gapon wrote:
on 27/07/2010 19:53 Gavin Atkinson said the following:
Thanks. Can you try
http://people.freebsd.org/~gavin/mexas-hda-panic.diff
and see if that solves things for you?
(Credit goes to avg@ for looking into this before
Em 2010.07.27. 5:59, b. f. escreveu:
Other important differences between bsdgrep and GNU grep:
The --include option in bsdgrep does not have the same effect as the
corresponding option in GNU grep -- in GNU grep, that option causes
_only_ those files matching the file inclusion pattern to be
On 7/28/10, Gabor Kovesdan ga...@freebsd.org wrote:
Em 2010.07.27. 5:59, b. f. escreveu:
Thanks for bringing this up, I'll take a look and try to implement the
same behaviour. And I will also document the behaviour.
I don't think that the current behavior of bsdgrep is necessarily bad
-- in
Em 2010.07.28. 17:26, b. f. escreveu:
I don't think that the current behavior of bsdgrep is necessarily bad
-- in fact it seems to me to be simple and intuitive: nothing is
excluded or included implicitly, and (I think) the last match wins,
unlike in gnu grep. I mention it only because it is
Gabor Kovesdan ga...@freebsd.org writes:
b. f. bf1...@gmail.com writes:
I don't think that the current behavior of bsdgrep is necessarily bad
-- in fact it seems to me to be simple and intuitive: nothing is
excluded or included implicitly, and (I think) the last match wins,
unlike in gnu
On Wed, Jul 28, 2010 at 03:56:34PM +0300, Andriy Gapon wrote:
on 27/07/2010 20:20 Anton Shterenlikht said the following:
yes, thanks, the panic has gone away.
There still seems to be a problem with this device:
hd...@pci0:0:20:2: class=0x040300 card=0x30c2103c chip=0x43831002
on 28/07/2010 19:01 Anton Shterenlikht said the following:
here it is:
So did it work? :)
% dmesg|fgrep -i hda
pci0: multimedia, HDA at device 20.2 (no driver attached)
pci0: multimedia, HDA at device 20.2 (no driver attached)
hdac0: ATI SB600 High Definition Audio Controller irq 16 at
On Wed, Jul 28, 2010 at 07:07:34PM +0300, Andriy Gapon wrote:
on 28/07/2010 19:01 Anton Shterenlikht said the following:
here it is:
So did it work? :)
not as far as I can tell
% dmesg|fgrep -i hda
pci0: multimedia, HDA at device 20.2 (no driver attached)
pci0: multimedia, HDA at
on 28/07/2010 19:17 Anton Shterenlikht said the following:
On Wed, Jul 28, 2010 at 07:07:34PM +0300, Andriy Gapon wrote:
on 28/07/2010 19:01 Anton Shterenlikht said the following:
here it is:
So did it work? :)
not as far as I can tell
% dmesg|fgrep -i hda
pci0: multimedia, HDA at
On Wed, Jul 28, 2010 at 07:33:44PM +0300, Andriy Gapon wrote:
on 28/07/2010 19:17 Anton Shterenlikht said the following:
On Wed, Jul 28, 2010 at 07:07:34PM +0300, Andriy Gapon wrote:
on 28/07/2010 19:01 Anton Shterenlikht said the following:
here it is:
So did it work? :)
not as far
on 28/07/2010 19:44 Anton Shterenlikht said the following:
But I just rebooted again, and reset
to defaults in BIOS, now I get:
% dmesg | fgrep -i hda
hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2 on
pci0
hdac0: HDA Driver Revision: 20100226_0142
hdac0:
On Wed, Jul 28, 2010 at 04:14:10PM +0300, Andriy Gapon wrote:
on 27/07/2010 19:53 Gavin Atkinson said the following:
Thanks. Can you try
http://people.freebsd.org/~gavin/mexas-hda-panic.diff
and see if that solves things for you?
(Credit goes to avg@ for looking into this before
on 28/07/2010 19:59 Pyun YongHyeon said the following:
When I started to write snd_audiocs(4) for sparc64 I also noticed
that. The practice of sound driver was to explicitly allocate softc
structure in device attach routine and release it after use. I
don't remember details but other parts
On Wed, Jul 28, 2010 at 07:51:08PM +0300, Andriy Gapon wrote:
on 28/07/2010 19:44 Anton Shterenlikht said the following:
But I just rebooted again, and reset
to defaults in BIOS, now I get:
% dmesg | fgrep -i hda
hdac0: ATI SB600 High Definition Audio Controller irq 16 at device 20.2
on 28/07/2010 20:13 Anton Shterenlikht said the following:
On Wed, Jul 28, 2010 at 07:51:08PM +0300, Andriy Gapon wrote:
on 28/07/2010 19:44 Anton Shterenlikht said the following:
But I just rebooted again, and reset
to defaults in BIOS, now I get:
% dmesg | fgrep -i hda
hdac0: ATI SB600
Hi,
I have been having interrupt related problems with various subsystems. I
suspect this is related to the changes in the event timer infrastructure.
The subsystems that have experienced interrupt problems:
- hda: this is the easiest to reproduce and what I used to isolate the
commits. I
I have a 2 cpu virtual image of FreeBSD current. It panics during
boot after building in the NUMA support.
I'll transcribe the SRAT bootverbose messages and panic message as best I can.
Table 'SRAT' at 0xfef07f6
SRAT: Found table at 0xfef07f6
SRAT: Found memory domain 0 addr 0 len a:
On Wed, Jul 28, 2010 at 10:37 AM, m...@freebsd.org wrote:
I have a 2 cpu virtual image of FreeBSD current. It panics during
boot after building in the NUMA support.
I'll transcribe the SRAT bootverbose messages and panic message as best I can.
Table 'SRAT' at 0xfef07f6
SRAT: Found table
David Naylor wrote:
I have been having interrupt related problems with various subsystems. I
suspect this is related to the changes in the event timer infrastructure.
The subsystems that have experienced interrupt problems:
- hda: this is the easiest to reproduce and what I used to
David Naylor wrote:
I have been having interrupt related problems with various subsystems. I
suspect this is related to the changes in the event timer infrastructure.
The subsystems that have experienced interrupt problems:
- hda: this is the easiest to reproduce and what I used to isolate
On Wed, Jul 28, 2010 at 7:37 AM, m...@freebsd.org wrote:
I have a 2 cpu virtual image of FreeBSD current. It panics during
boot after building in the NUMA support.
I'll transcribe the SRAT bootverbose messages and panic message as best I
can.
Table 'SRAT' at 0xfef07f6
SRAT: Found table
On Wed, Jul 28, 2010 at 11:19 AM, David Cornejo d...@dogwood.com wrote:
On Wed, Jul 28, 2010 at 7:37 AM, m...@freebsd.org wrote:
I have a 2 cpu virtual image of FreeBSD current. It panics during
boot after building in the NUMA support.
I'll transcribe the SRAT bootverbose messages and panic
On Wed, Jul 28, 2010 at 8:23 AM, m...@freebsd.org wrote:
On Wed, Jul 28, 2010 at 10:37 AM, m...@freebsd.org wrote:
I have a 2 cpu virtual image of FreeBSD current. It panics during
boot after building in the NUMA support.
I'll transcribe the SRAT bootverbose messages and panic message
Em 2010.07.28. 17:48, Dag-Erling Smørgrav escreveu:
Gabor Kovesdanga...@freebsd.org writes:
b. f.bf1...@gmail.com writes:
I don't think that the current behavior of bsdgrep is necessarily bad
-- in fact it seems to me to be simple and intuitive: nothing is
excluded or included
Hi Current,
I set up a Facebook profile where I can post my pictures, videos and events and
I want to add you as a friend so you can see it. First, you need to join
Facebook! Once you join, you can also create your own profile.
Thanks,
Aryeh
To sign up for Facebook, follow the link below:
On Wed, Jul 28, 2010 at 01:42:30PM +0200, Dag-Erling Sm??rgrav wrote:
Sorry, I misparsed ATA_CAM as ahci. Why on earth would anyone want to
use ATA_CAM these days?
Well, I am not sure if you really meant ATA_CAM and not ATAPICAM? But in
case you meant it, for people who do not use SATA-capable
37 matches
Mail list logo
