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-capabl
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:
http
Em 2010.07.28. 17:48, Dag-Erling Smørgrav escreveu:
Gabor Kovesdan writes:
b. f. 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 mat
On Wed, Jul 28, 2010 at 8:23 AM, wrote:
> On Wed, Jul 28, 2010 at 10:37 AM, 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.
> >
> >
On Wed, Jul 28, 2010 at 11:19 AM, David Cornejo wrote:
> On Wed, Jul 28, 2010 at 7:37 AM, 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
>>
On Wed, Jul 28, 2010 at 7:37 AM, 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 at 0xfef07
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 isol
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
On Wed, Jul 28, 2010 at 10:37 AM, 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 at 0xfef07f
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: enabled
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
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
>>>
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: irq 16 at device 20.2
> > on pci0
> > hdac0: HDA Driv
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 par
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 in
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: irq 16 at device 20.2 on
> pci0
> hdac0: HDA Driver Revision: 20100226_0142
> hdac0: [ITHREAD]
> hdac0: hdac_get_capabilities:
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? :)
> >
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: at devi
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: at device 20.2 (no driver attached)
> > pci0: at device 20.2 (no driv
on 28/07/2010 19:01 Anton Shterenlikht said the following:
> here it is:
So did it work? :)
> % dmesg|fgrep -i hda
> pci0: at device 20.2 (no driver attached)
> pci0: at device 20.2 (no driver attached)
> hdac0: irq 16 at device 20.2 on
> pci0
> hdac0: HDA Driver Revision: 20100226_0142
> hda
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=0x438310
Gabor Kovesdan writes:
> b. f. 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 grep.
> Ok, thanks, then
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 dif
On 7/28/10, Gabor Kovesdan 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 fact it seems to
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 sea
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 in
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_D
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 dev
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. / Adva
Dag-Erling Smørgrav wrote:
> Dag-Erling Smørgrav writes:
>> Andriy Gapon writes:
>>> Michael Butler 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
>>> aroun
Dag-Erling Smørgrav writes:
> Andriy Gapon writes:
> > Michael Butler 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"
Andriy Gapon writes:
> Michael Butler 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" ?
Only for legacy drives, but since Mic
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.
>
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 user-spac
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
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
http://lists.freebsd.org
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
37 matches
Mail list logo
